INTRODUCTION (Task 1)
First World Bank Savings and Loan (also referred to as “us”, “we”, “the company”, etc) has been investigating the use of a Linux-based infrastructure architecture. The task team has already made recommendations to evaluate and prototype this kind of set up. Key factors are cost of ownership, scalability, and reliability. Other factors that remain are maintaining confidentiality, integrity, and availability (the CIA triad), and ensuring stable, secure support of the over $100,000,000 in transactions completed annually. As a financial institution, we must also bear in mind compliance with the Gramm-Leach-Bliley Act (GLBA), as well as the Payment Card Industry Data Security Standard (PCI-DSS) since we process credit card transactions, and the Sarbanes-Oxely Act (SOX) as we are publically traded.
Regardless of all these factors, rough estimates indicate we can save close to $4,000,000 in licensing fees alone by moving to a Linux-based infrastructure. Despite the open source nature of Linux, we should be able to meet all of the technical, legal, and security needs for this transition.
TECHNICAL INFRASTRUCTURE NEEDS (Task 2) Thanks to the task team assigned to this project, an outline of what the network and routing needs has already been completed. The following services will be required to support:
• A database server o Recommended solution: DBMS MySQL
• A Web server o Recommended solution: Apache
• A file server o Recommended solution: Red Hat Enterprise/Samba
• An SMTP (Simple Mail Transfer Protocol) server o Recommended solution: hMail
• An LDAP (Lightweight Directory Access Protocol) server o Recommended solution: Apache Directory Server
DBMS MySQL: Oracle has several “best practice” recommendations for MySQL , including but not limited to: changing default settings, restricting use of privileged accounts, using dedicated administrative accounts (for administrative tasks only), enforcing strong password policies, encryption, and securing backups. Oracle provides a PDF overview of these and other best practices to ensure a secure environment. It is worth noting that this document also provides insight on how to comply with PCI-DSS, SOX, and other regulations. Firewalls as additional layers of protection are also suggested.
Apache: Much like Oracle, Apache lists basic security tips that can be used to strengthen your web server . Among these recommendations are maintaining updates and patches, methods to prevent DoS attacks, prevention of standard accounts from gaining root access, and other security methods. Again, the goal is to reset default settings. Apache keeps up to date with current HTTP standards.
Red Hat Enterprise/Samba: Red Hat is a popular Linux distro which requires no client licenses (compared to our current Windows environment!). Red Hat will also allow all of the current file-sharing needs for client computers running Windows. Red Hat touts the scalability of its software, as well as its support of Samba and NFS, making it a perfect solution for our network drives . Again, patching, changing default settings, and utilization of built-in tools and commands to prevent unauthorized connections are recommended by Samba’s website . Samba also recommends using a firewall to secure the file server (more on firewalls later). hMailServer: hMailServer 5 has built-in support for both SSL and TLS security protocols . Using an SSL certificate, we can encrypt the email traffic of our users. As another free open-source solution, hMail will further cut our costs. Its support of common email protocols (IMAP, SMTP, POP3), as well as the built-in anti-spam features make it a great solution for our email server .
LDAP in Apache: Apache supports the latest in LDAP protocol and is released under the Apache license. However, the OpenLDAP command is also available. Its security methods can follow the same used as Apache Web server (change defaults, restrict account access, etc) . Overall, the defense-in-depth methodology is highly recommended. The more layers of protection we have surrounding out network, the safer we will be. It would behoove us to set up a DMZ (de-militarized zone) to separate the web server from the public Internet. Each sever should also be separated by firewalls between them (the servers) and the internal network. Yet another firewall should be placed between the outermost DMZ and the public Internet. (All local user/client machines should also make use of their firewalls, however this policy is covered in other documentation.) A further layer of protection can be found in the utilization of an Intrusion Prevention Service (IPS) instead of an Intrusion Detection Service (IDS). As a company working with people’s finances, detection of potential attacks simply will not suffice. An IPS will aid in detection and prevention of potential attacks—the security team monitoring the IPS will be better able to maintain security. As many users often work from out of the building, whether they are working from home or on a business trip, it is recommended that users are unable to access the files share off-site without the use of a VPN connection and/or a remote desktop session. Even though a VPN will secure traffic to and from the host computer, if a user is not using a company-issue device, we cannot be certain of the security of that device. We do not own a user’s home desktop, and therefore cannot enforce security measures such as updating software, patching vulnerabilities, and preventing use of resources with an unresolved zero-day vulnerability (as we see with Flash often). Users without a company device who require access to internal data must connect to the VPN and then establish a remote session to their work computer. Lastly, while not 100% necessary, it is highly recommended that instructions on how to map network shares are not given to users, and that an approval process for remote desktop access be put in place. This leads to securing user access.

SECURING USER ACCOUNTS/ACCESS (Task 3) By far, the easiest and most efficient method of user account management is to create groups and give said groups access to specific items. For example, the payroll team at First World Bank Savings and Loan should be the only users with access to payroll-related items, such as the payroll database. A group called “payroll” can be created, and only user accounts added to that group would be able to view the payroll database (and any/all other resources linked to that group’s access). The same method goes for securing file shares. Each division should have their own share, unique to that group. A user in the payroll group can log into payroll computers and resources, but cannot, for example, map to the HR file share. (Group access would certainly allow us to set a user with access to multiple division resources, if necessary.) Another benefit of group-based access is the nested security of folders within each share. Basic logon and network drive access gives users the ability to view all folders at the root of their share, but they may not be able to actually open and access data in certain folders. This as-needed access method helps prevent internal mishaps. Standard user accounts will be given to everyone. Standard users are unable to install software or make certain changes without elevating to an administrative account. Since the IT team at First World Bank Savings and Loan maintains machines and software, users will find they very rarely require administrative access for anything. That being said, even the IT team should do daily work with standard accounts. However, each member (from the user support team to the network and systems administrators) should be given a second account with administrative (or root, if deemed necessary) access to use only when required. This prevents accidental issues, and individual accounts set up for each IT employee will aid in audits. Special permissions can be granted on an as-needed basis, and a policy for gaining those special permissions should be created (if not already in place). We understand that users may not enjoy needing to fill a form and have their supervisor give the okay for certain things, however this is not done to complicate anyone’s work. We should educate users on basic security policies (don’t share passwords, use strong passwords, etc) and help them understand that security will very often (if not always) trump ease of access.