COMPUTER SECURITY

Computer security includes many diverse subjects, such as controlling authorized (and unauthorized) access, managing user accounts and their privileges, software management, change control, development, and database security, to mention a few. Much of the security is afforded by the operating system responsible for providing the interface between the hardware and the software and ultimately the user. Oper- ating systems come in many types and flavors. Microsoft’s Windows is the most prevalent operating system used today for home and business. UNIX, an operating system born in Bell Labs, has many flavors and versions, such as Linux, BSD, Solaris, and AIX, to name a few of the popular ones.

Historically, computers filled rooms and were centrally located with dumb ter- minals providing access via a serial interface. Security controls were relatively simple. Each terminal was essentially a window into the main system where all the controls were employed. There were no hard drives, floppy drives, or other means of injecting viruses or worms. As users logged in they were provided only what they required to perform their duties; this is typically referred to as Mandatory Access Control (MAC). Security was realized because there was basically one computer with tightly controlled shared access. One person couldn’t see or access files another was using unless those privileges were provided by an administrator.

FIGURE 4.1 Defense-in-Depth within a Security Architecture

Intranet Internet Database Server Middle Ware Web Server Remote Client

Secure Web Server on DMZ, essential services only, hardened operating system, anti-virus and latest patches

Internet router w/ACLs, FW & IDS Features Stateful firewall appliance, VPN, authentication, content filtering Client Firewall, VPN, Anti-Virus, and Authentication Intrusion Detection System Layer 3 switch with VLANS &

ACLS

Hardened application middleware system, specific services, authentication, code in read-only directories, tested application, permit communication

only with Web server and database, authenticated SQL calls to backend server, anti-virus

Core router with ACLs and VLANs

Hardened backend database server, VPN, authentication, controlled access, latest system patches, anti-

virus, administrative controls

Extended Perimeter Control Resource

SSL/VPN

Later, as computers became much cheaper and as common as the TV, people could use them for whatever they wanted. Controls were at the discretion of the user or owner. Of course, businesses saw the opportunity to leverage this inexpensive resource to enhance their productivity. In the early 1980s, Lotus 1-2-3 was the first breakthrough application that engrained computers into the business DNA. Lotus 1- 2-3 was the first spreadsheet program where each cell could contain values and formulas to build complex mathematical computations. Something that was previ- ously done by hand and calculators (requiring enormous amounts of experience and time) could now be built into a spreadsheet and shared as a template with which others could work. Accountants became one of the early adopters and soon nearly all financial firms were using spreadsheets to perform difficult calculations.

At this point in time, there were thousands of individual computers operating independently of each other with very little concern for security. Unfortunately, as the technology grew at an incredible rate, resulting in faster connected systems, security remained in the shadows. Now, we see computers of all types connected together sharing information with various levels of sensitivity. To provide some form of security, Discretionary Access Controls (DAC) were employed to permit the system to manage each user’s privileges based on the ownership of a file or appli- cation. For example, Alice would log in to a system and create or manage her files, which were identified and controlled by the operating system. At that point, it was up to Alice’s discretion to decide who would have access to those files and what level of access that would be. Without centralized computing and data stored in different locations, this was the best that could be realized.

With many shared systems and limited controls provided by an operating system normally designed for personal use, how does one control access to information or applications? How do you control what applications are installed and who can run those applications? Moreover, how do you control what the privileges of the appli- cation are? How does a company provide comprehensive security in a distributed environment with many different users, systems, and access rights? It can get very convoluted very quickly.

Computer security goes well beyond the user. Applications are the reason for a computer’s existence and controlling the type, privileges, and integrity of an appli- cation can become challenging. Enforcing licensing rules when you can copy an entire application as simply as you can copy a file can lead to legal ramifications. How do you control the number of applications in use? What if an application license is based on the number of hours or the number of employees permitted to use it?

Much of what has been discussed is based on theoretical security models created by the Department of Defense in the ‘70s and ‘80s. Most notable is the Rainbow Series, a collection of color-named standards that included system security models. Trusted Computer System Evaluation Criteria (DOD-5200.28-STD), known as the Orange Book, became the de facto standard for computer security. Security was defined in four ratings (D through A), each with increasing levels of security.

One of the more popular security models is BellLaPadula, which defines objects, subjects, and access operations. In theory, the BellLaPadula model was an excep- tional application of security controls but could not be applied in a cost-effective

manner. However, the model still has an impact on system design to this day. Bell LaPadula has two basic security principles: reading data and writing data. What you were permitted to read and write was directly associated with your level of access. You can write above your level, but not below. Finally, you could read below your level but not above. For example, if you had classified access to a system and wanted to sell information to a terrorist organization but could not send classified informa- tion, you would copy the data to a lower level, say unclassified, and send the information. BellLaPadula provides the logistics to control this type of threat. Also, when in doubt, information can be considered sensitive, therefore, the ability to write above your security level is provided. However, because you only have classified access you cannot read above your assigned security level. Therefore, it is possible to write something you can’t read.

Operating system security, as you can see, can come in many forms and each represents its own idiosyncrasies. At its innermost level, an operating system main- tains a kernel, a collection of code that controls every action a system executes. Historically, the kernel was small (typically a few hundred thousand lines of code), containing only the necessary commands to ensure basic operations and everything that was used to support applications, communications, and various customizable attributes was outside the kernel. The implementation of a hardened kernel pro- vided system reliability and integrity. UNIX is a good example of a small kernel to provide core functions; everything else used libraries and other code to support general use.

However, as time moved on, more and more code was included in the kernel to simplify use, increase speed, and support a variety of implementations. The practice of employing a secure kernel, which is responsible for ensuring the integrity of system functions, was lost as features became the driving factors. An example of a large kernel is the Windows operating system. Everything is in the kernel and only applications exist beyond it. The assumption is that everything in the kernel is secure, so if all operations for the computer are placed in the kernel, then the result is a secure operating system. Unfortunately, it makes for a huge kernel (Windows NT is over 4 million lines of code) and makes for a complex system. Because complexity is security’s nemesis, a large complicated kernel represents a breeding ground for vulnerability and is susceptible to errors. When everything is injected into the kernel, rogue or faulty code can compromise the entire system.

Computer security represents the last line of defense, and the evolution of simple operating systems has promoted the introduction of perimeter controls we see today, such as firewalls, filtering routers, and other network-related security.

There has been some evolution of computer security to close the gaps: Trusted Operating Systems (TOS), introduced many years ago but that still have not reached mainstream implementation, construct compartments for services to run and users to work. Compartments are internally controlled, logical boundaries in the system other applications are completely unaware exist. Each compartment is assigned a security level and a low security level cannot access system resources of a higher security level. Although a greatly simplified description, an exploited vulnerability within an application or service will only affect the resources associated with the compartment (i.e., memory, disk space).

Trusted Solaris, HP Presidium, and Argus PitBull are examples of operating systems or add-ons that greatly enhance the overall security of a system. Although a great solution, TOS introduced intense system administration and therefore never took hold as a common platform.

Computer security, better yet the lack of, could be considered the flashpoint for the birth of the common hacker. The pains we’re experiencing today, the constant focus on the perimeter as the primary security provider, the explosion of viruses and worms, and the constant battle of integrity and reliability, all stem from the poor evolution of computer security. Operating system security will not solve world hunger, but a secure system allows greater investment in access controls, compre- hensive network security, and application security with less focus on viruses and small holes that lead to big results.

HARDEN A SYSTEM

Determining what steps are necessary to harden a system can be very frustrating. There are numerous sources of various tactics for securing a system. There are sample configurations and tools that can be used to configure Microsoft and UNIX systems. The following are some common characteristics of hardening a system. Physically Secure It

Many systems are vulnerable to direct access. For this reason, you should make certain that only authorized people can physically access the box. Everything from turning the system off to installing malicious software can be performed on a system if you can get to it.

Common practices are as follows:

• Install case locks on publicly accessible systems, such as workstations. • Place critical systems in a locked cabinet (cage) in a controlled facility. • Avoid the use, or installation, of removable media support such as floppies,

CD-drives, and removable hard drives.

• Disable or remove support for external access ports, such as UBS ports, COM ports, and keyboard support when applicable.

• Set up a BIOS password to reduce the exposure of someone rebooting the system and making changes to the system.

• Disable the power switch or use a lockable switch.

• Ensure power supplies are secured and redundant. It is one thing to hit the power button; it is another to just unplug it.

• Provide suitable operating conditions such as raised floors and environ- mental controls.

• Control access to the computer room. Installing the Operating System

During the installation of an operating system it is typical to know the role that system will play in the company. When concerned about the security of the system, there are several practices to start you on the right foot.

Setup practices include the following:

• Determine if there is a company-approved configuration or system image that is relevant to the role of the system. For example, a Web server configuration may be very different if it is for Internet services as opposed to an internal development system.

• Install the operating system from scratch. In other words, avoid updating an existing operating system. The result may be inheriting vulnerabilities, viruses, or poor configurations.

• Select the appropriate file system format that reflects the needs of the computer. However, based on today’s awareness of security, rarely is a nonsecure file system implemented, such as FAT (File Allocation Table). • If provided the opportunity, such as during the installation of Microsoft, RedHat, Solaris, and BSD, to name a few, do not install any services by default. Look to enable services rather than disable. Windows 2003 installs with all (most) services disabled by default. Disabling services during installation is a trend many operating systems are practicing to reduce the likelihood of frivolous exposures based on unused system elements. • Enable interfaces only when they are necessary to complete the installa-

tion. This will avoid interaction before it is properly configured. For example, to load a specific module you may need to connect to a different system on the network to collect the application for installation. Get It Running

At this point you have a half-baked system somewhere between security and doing what you need it to do. However, you’re still not ready to start piling on applications. There are some tasks to ensure the system is prepared for more serious hardening.

Cleanup practices include the following:

• The first thing to check and configure correctly is that the system is configured to restart in a manner that is expected. For example, the init.d file in UNIX and startup configuration in Windows need to be reviewed to make sure nothing was added or removed during the final stages of the installation.

• Create an administrative account. In UNIX, it is not a good practice to userootfor managing the system on a day-to-day basis and the same is true for other platforms. Therefore, using an administrator or rootequiv- alent user to log in to a system provides one more layer of security. If necessary, the administrators can “SU” (Super User) up to rootto accom- plish specific tasks. By establishing this practice early on in the process, you can configure the system to not allow people to log in as root (locally or remotely), offering greater control over the system.

• Disabling services is a primary phase. During the installation, you avoided installing services, but many systems install some anyway (or are hidden as with Windows).

• Determine application dependencies. Inevitably, some applications are installed to support various system administration. When cleaning the system or extraneous services and applications it is necessary to evaluate relationships in order to avoid rogue processes.

Set System Policies

Now that the operating system is installed and specific services are running, there are administrative configurations that need to be implemented to support moving into a functional role.

Common administration setup is as follows:

• Set up password policies. A handful of accounts may have been created, but now is a good time to set the policy for how new accounts are to be created.

• Assuming more and more elements are going to be added to the system, establish an audit function so you are aware of all changes to the system. With logging enabled, you can look back to system modifications and determine any unauthorized or authorized changes that may have had a detrimental impact on the system’s integrity. This is also helpful in trou- bleshooting initial problems in complex systems. Even authorized tasks can become troublesome.

• Now that you have set user policies and begun collecting system logs, you start constructing the necessary directory structure for the system. Most important, this task includes the creation of directory and file per- missions.

Accessing the System

Assuming the box will be accessible over a network, the next phase is to control the type of remote access for users, services, and applications.

The network setup consists of the following:

• Implement access control lists restricting only the protocols that are going to be used on the system.

• Make protocol stack changes. For example, change the number of per- mitted open connections or shorten the wait time associated with half- open connections.

• Configure the system to accept or deny remote login and remote procedure calls that are associated with execution of remote applications.

Cleanup

Before installing applications and other things that will affect the security of a system the next step is very important and many still don’t do it: applying patches. By the time you get the CDs for installing an operating system there are undoubtedly patches for it. There are three types of patches:

1. Functionality. A patch that fixes or enhances a certain function of the system. For example, how memory is handled, performance of network connections, or adding more options to an administrative program. 2. Feature. A feature patch increases the use of the system, an added feature. 3. Security. A security patch fixes a vulnerability in the system due to unex-

pected conditions the system is in or a misstep in programming.

The simple fact is that patches will exist and must be applied to ensure the integrity of the system. Moreover, this is not a point and shoot and forget solution. As with many things security, you must be prepared to apply patches regularly.