CISSP - Certified Information Systems Security Professional Study Guide, 2nd Edition (2004)

Increasing the security level of information systems is a challenging task for any organization. Ideally, security is something that is planned and integrated from the very inception of a system’s

architecture and considered at each stage of its development, testing, deployment, and day- to-day use. The first step in this endeavor is to evaluate an organization’s current levels of security exposure by carefully examining its information systems and checking for vulnerability to threats or attack. Next, one must decide what steps to take to remedy any such exposures as may be discovered during the examination process. Making decisions about which solutions will work well can be the most difficult part of the process when seeking to secure information systems properly. If this is not to become a constant case of discovering vulnerabilities and applying relevant security patches or fixes—as is so common with systems like Windows, Unix, and Linux today—the level of security consciousness and attention during initial system design and implementation must be substantially increased.

Understanding the philosophy behind security solutions helps to limit one’s search for the best security controls for a specific situation and for specific security needs. In this chapter, we discuss methods to evaluate the levels of security that a system provides. We also refer back to the general security models (originally introduced in Chapter 11, “Principles of Computer Design”) upon which many security controls are constructed. Next, we talk about Common Criteria and other methods that governments and corporations alike use to evaluate information systems from a security perspective, with particular emphasis on U.S. Department of Defense and international security evaluation criteria. We finish off this chapter by discussing commonly encountered design flaws and other security-related issues that can make information systems susceptible to attack.

Common Security Models, Architectures,

and Evaluation Criteria

The process of determining how secure a system is can be difficult and time consuming. Organizations need methods to evaluate given systems, to assign general security ratings, and to determine if a system meets a security policy’s requirements. Further, any such security rating should be general enough to enable meaningful comparison among multiple systems, along with their relative levels of security. The following sections describe the process involved in evaluating a computer system’s level of security. We begin by introducing and explaining basic concepts and terminology used to describe information system security and talk about secure

Common Security Models, Architectures, and Evaluation Criteria 363

computing, secure perimeters, security and access monitors, and kernel code. We turn to security models to explain how access and security controls may be implemented. We also briefly explain how system security may be categorized as either open or closed; describe a set of standard security techniques used to ensure confidentiality, integrity, and availability of data; discuss security controls; and introduce a standard suite of secure networking protocols.

Trusted Computing Base (TCB)

An old U.S. Department of Defense standard known colloquially as “the Orange Book” (DoD Standard 5200.28, covered in more detail later in this chapter in the “Rainbow Series” section) describes a trusted computing base (TCB) as a combination of hardware, software, and controls that works together to form a trusted base to enforce your security policy. The TCB is a subset in a complete information system. In fact, it’s the only portion of that system that can be trusted to adhere to and enforce the security policy. It is not necessary that every component of a system be trusted. But any time you consider a system from a security standpoint, your evaluation should include all trusted components that define that system’s TCB.

In general, TCB components in a system are responsible for controlling access to the system. The TCB must provide methods to access resources both inside and outside the TCB itself. TCB components commonly restrict the activities of components outside the TCB. It is the responsibility of TCB components to ensure that a system behaves properly in all cases and that it adheres to the security policy under all circumstances.

Security Perimeter

The security perimeter of your system is an imaginary boundary that separates the TCB from the rest of the system. For the TCB to communicate with the rest of the system, it must create secure channels, also called trusted paths. A trusted path is a channel established with strict standards to allow necessary communication to occur without exposing the TCB to security vulnerabilities. A trusted path also protects system users (sometimes known as subjects) from compromise as a result of a TCB interchange. As you learn more about formal security guidelines and evaluation criteria later in this chapter, you’ll also learn that trusted paths are required in systems that seek to deliver high levels of security to their users. According to the TCSEC guidelines described later in this chapter, trusted paths are required in B2 and higher systems.

Reference Monitors and Kernels

When the time comes to implement a secure system, it’s essential to develop some part of the TCB to enforce access controls on system assets and resources (sometimes known as objects). The part of the TCB that validates access to every resource prior to granting access requests is called the reference monitor. The reference monitor stands between every subject and object, verifying that a requesting subject’s credentials meet the object’s access requirements before any requests are allowed to proceed. If such access requirements aren’t met, access requests are turned down. The reference monitor may be a conceptual part of the TCB; it need not be an actual, stand-alone or independent working system component.

364 Chapter 12 Principles of Security Models

The collection of components in the TCB that work together to implement reference monitor functions is called the security kernel. The purpose of the security kernel is to launch appropriate components to enforce reference monitor functionality and resist all known attacks. The security kernel uses a trusted path to communicate with subjects. It also mediates all resource access requests, granting only those requests that match the appropriate access rules in use for a system.

The reference monitor requires descriptive information about each resource that it protects. Such information normally includes its classification and designation. When a subject requests access to an object, the reference monitor consults the object’s descriptive information to discern whether access should be granted or denied (see the sidebar “Tokens, Capabilities, and Labels” for more information on how this works).

Security Models

A security model provides a framework inside which one can implement a security policy. Where a security policy is an abstract statement of security intentions, a security model represents exactly how the policy should be implemented. A good model accurately represents each facet of the security policy and how to implement some control to enforce the facet. The following sections discuss three well-known security models, originally introduced in Chapter 11, and their basic features and functions. Each security model shares similarities with the others but also has its own unique characteristics.

A security model provides a way for designers to map abstract statements in a security policy into the algorithms and data structures necessary to build software. Thus, a security model gives software designers something against which to measure their design and implementation. That model, of course, must support each part of the security policy. In this way, developers can be sure their security implementation supports the security policy.

Tokens, Capabilities, and Labels

There are several different methods in use to describe the necessary security attributes for an object. A security token is a separate object that is associated with a resource and describes its security attributes. This token can communicate security information about an object prior to requesting access to the actual object. In other implementations, various lists are used to store security information about multiple objects. A capabilities list maintains a row of security attributes for each controlled object. Although not as flexible as the token approach, capabilities lists generally offer quicker lookups when a subject requests access to an object. A third common type of attribute storage is called a security label. A security label is generally a permanent part of the object to which it’s attached. Once a security label is set, it normally cannot be altered. This permanence provides another safeguard against tampering that neither tokens nor capabilities lists provide.

Common Security Models, Architectures, and Evaluation Criteria 365

Bell-LaPadula Model

The Bell-LaPadula model was developed by the U.S. Department of Defense (DoD) in the 1970s to address concerns about protecting classified information. The DoD stores multiple levels of classified documents. The classifications the DoD uses are unclassified, sensitive but unclassified, confidential, secret, and top secret. Any person with a secret security clearance can access secret, confidential, sensitive but unclassified, and unclassified documents but not top secret documents. Also, to access a document, the person seeking access must also have a need-to- know for that document.

The complexities involved in ensuring the confidentiality of documents are addressed in the Bell-LaPadula model. This model is built on a state machine concept. The state machine supports multiple states with explicit transitions between any two states; this concept is used because the correctness of the machine, and guarantees of document confidentiality, can be proven mathematically. There are three basic properties of this state machine:

The Simple Security Property states that a subject may not read information at a higher sensitivity level (no read up).

The * (star) Security Property states that a subject may not write information to an object at a lower sensitivity level (no write down).

The Discretionary Security Property states that the system uses an access matrix to enforce discretionary access control.

The Bell-LaPadula properties are in place to protect data confidentiality. A subject cannot read an object that is classified at a higher level than the subject is cleared for. Because objects at one level have data that is more sensitive or secret than data at a lower level, a subject cannot write data from one level to an object at a lower level (with the exception of a trusted subject). That action would be similar to pasting a top secret memo into an unclassified document file. The third property enforces a subject’s “need-to-know” in order to access an object.

The Bell-LaPadula model addresses only the confidentiality of data. It does not address its integrity or availability. Because it was designed in the 1970s, it does not support many operations that are common today, such as file sharing. It also assumes secure transitions between security layers and does not address covert channels (covered later in this chapter). Bell-LaPadula does handle confidentiality well, so it is often used in combination with other models that provide mechanisms to handle integrity and availability.

Biba Model

The Biba model was designed after the Bell-LaPadula model. Where the Bell-LaPadula model addresses confidentiality, the Biba model addresses integrity. The Biba model is also built on a state machine concept. In fact, Biba appears to be pretty similar to the Bell-LaPadula model. Both use states and transitions. Both have basic properties. The biggest difference is their primary focus: Biba primarily protects data integrity. Here are the basic properties of the Biba model state machine:

The Simple Integrity Property states that a subject cannot read an object at a lower integrity level (no read down).

The * (star) Integrity Property states that a subject cannot modify an object at a higher integrity level (no write up).

366 Chapter 12 Principles of Security Models

When you compare Biba to Bell-LaPadula, you will notice that they look like they are opposite. That’s because they focus on different areas of security. Where Bell-LaPadula model ensures data confidentiality, Biba ensures data integrity.

Consider both Biba properties. The second property of the Biba model is pretty straightforward. A subject cannot write to an object at a higher integrity level. That makes sense. What about the first property? Why can’t a subject read an object at a lower integrity level? The answer takes a little thought. Think of integrity levels as being like the purity level of air. You would not want to pump air from the smoking section into the clean room environment. The same applies to data. When integrity is important, you do not want unvalidated data read into validated documents. The potential for data contamination is too great to permit such access.

Because the Biba model focuses on data integrity, it is a more common choice for commercial security models than the Bell-LaPadula model. Most commercial organizations are more concerned with the integrity of their data than its confidentiality.

Clark-Wilson Model

Although the Biba model works in commercial applications, another model was designed in 1987 specifically for the commercial environment. The Clark-Wilson model uses a multifaceted approach to enforcing data integrity. Instead of defining a formal state machine, the Clark-Wilson model defines each data item and allows modifications through only a small set of programs. Clark-Wilson defines the following items and procedures:

A constrained data item (CDI) is any data item whose integrity is protected by the security model.

An unconstrained data item (UDI) is any data item that is not controlled by the security model. Any data that is to be input and hasn’t been validated or any output would be considered an unconstrained data item.

An integrity verification procedure (IVP) is a procedure that scans data items and confirms their integrity.

Transformation procedures (TPs) are the only procedures that are allowed to modify a CDI. The limited access to CDIs through TPs forms the backbone of the Clark-Wilson integrity model.

The Clark-Wilson model uses security labels to grant access to objects, but only through transformation procedures. The model also enforces separation of duties to further protect the integrity of data. Through these mechanisms, the Clark-Wilson model ensures that data is protected from unauthorized changes from any user. The Clark-Wilson design makes it a very good model for commercial applications.

Objects and Subjects

Controlling access to any resource in a secure system involves two entities. The subject of the access is the user or process that makes a request to access a resource. Access can mean reading from or writing to a resource. The object of an access is the resource a user or process wants to access. Keep in mind that the subject and object refer to some specific access request, so the same resource can serve as a subject and an object in different access requests.

Common Security Models, Architectures, and Evaluation Criteria 369

objects. A control uses access rules to limit the access by a subject to an object. Access rules state which objects are valid for each subject. Further, an object might be valid for one type of access and be invalid for another type of access. One common control is for file access. A file can be protected from modification by making it read-only for most users but read-write for a small set of users who have the authority to modify it.

Recall from Chapter 1 that there are both mandatory and discretionary access controls, often called MAC and DAC, respectively. With mandatory controls, static attributes of the subject and the object are considered to determine the permissibility of an access. Each subject possesses attributes that define its clearance, or authority to access resources. Each object possesses attributes that define its classification. Different types of security methods classify resources in different ways. For example, subject A is granted access to object B if the security system can find a rule that allows a subject with subject A’s clearance to access an object with object B’s classification. This is called rulebased access control. The predefined rules state which subjects can access which objects.

Discretionary controls differ from mandatory controls in that the subject has some ability to define the objects to access. Within limits, discretionary access controls allow the subject to define a list of objects to access as needed. This access control list (often called an ACL) serves as a dynamic access rule set that the subject can modify. The constraints imposed on the modifications often relate to the subject’s identity. Based on the identity, the subject may be allowed to add or modify the rules that define access to objects.

Both mandatory and discretionary access controls limit the access to objects by subjects. The primary goals of controls are to ensure the confidentiality and integrity of data by disallowing unauthorized access by authorized or unauthorized subjects.

IP Security (IPSec)

There are various security architectures in use today, each one designed to address security issues in different environments. One such architecture that supports secure communications is the Internet Protocol Security (IPSec) standard. IPSec is an architecture set forth by the Internet Engineering Task Force (IETF). This architecture suggests a standard method for setting up a secure channel to exchange information between two entities. These two entities could be two systems, two routers, two gateways, or any combination of entities. Although generally used to connect two networks, IPSec can be used to connect individual computers, such as a server and a workstation or a pair of workstations (sender and receiver, perhaps). IPSec does not dictate all of the implementation details but is an open, modular framework. This feature allows many manufacturers and software developers to develop IPSec solutions that work well with products from other vendors.

IPSec uses public key cryptography to provide encryption, access control, nonrepudiation, and message authentication, all using IP protocols. The primary use of IPSec is for virtual private networks (VPNs). IPSec operates in either transport or tunnel mode. Tunnel mode is most often used when you set up VPNs between network gateways. In tunnel mode, the message and the original IP header are encrypted. Then a new IP header that addresses the destination’s gateway is added. In contrast, in transport mode, only the message is encrypted, not the IP header.

The two basic protocols that IPSec uses are the Authentication Header and the Encapsulating Security Payload. The Authentication Header (AH) provides integrity, authentication,

370 Chapter 12 Principles of Security Models

and nonrepudiation to the secure message exchange. The Encapsulating Security Payload (ESP) provides encryption of the message. The ESP also provides some authentication, but not to the degree of the AH. Though ESP is sometimes used without AH, it’s rare to see AH used without ESP.

At runtime, you set up an IPSec session by creating a security association (SA). The SA represents the communication session and records any configuration and status information about the connection. The SA represents a simplex connection. If you want a two-way channel, you need two SAs, one for each direction. Also, if you want to support a bidirectional channel using both AH and ESP, you will need to set up four SAs. Some of IPSec’s greatest strengths comes from being able to filter or manage communications on a per-SA basis so that clients or gateways between which security associations exist can be rigorously managed in terms of what kinds of protocols or services can use the IPSec connection. Also, without a valid security association defined, pairs of users or gateways cannot establish IPSec links.

Understanding System

Security Evaluation

Those who purchase information systems for certain kinds of applications—think, for example, about national security agencies where sensitive information may be extremely valuable (or dangerous in the wrong hands) or central banks or securities traders where certain data may be worth billions of dollars—often want to understand their security strengths and weaknesses. Such buyers are often willing to consider only systems that have been subjected to formal evaluation processes in advance and received some kind of security rating so that they know what they’re buying (and, usually, also what steps they must take to keep such systems as secure as possible).

When formal evaluations are undertaken, systems are usually subjected to a two-step process. In the first step, a system is tested and a technical evaluation is performed to make sure that the system’s security capabilities meet criteria laid out for its intended use. In the second step, the system is subjected to a formal comparison of its design and security criteria and its actual capabilities and performance, and individuals responsible for the security and veracity of such systems must decide whether to adopt them, reject them, or make some changes to their criteria and try again. Very often, in fact, trusted third parties (such as TruSecure Corporation, well known for its security testing laboratories) are hired to perform such evaluations; the most important result from such testing is their “seal of approval” that the system meets all essential criteria. Whether or not the evaluations are conducted inside an organization or out of house, the adopting organization must decide to accept or reject the proposed systems. An organization’s management must take formal responsibility if and when systems are adopted and be willing to accept any risks associated with its deployment and use.