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

is equally true whether a system is entirely hardware based, entirely software based, or a combination of both. In this case, the role of a security policy is to inform and guide the design, development, implementation, testing, and maintenance of some particular system. Thus, this kind of security policy tightly targets a single implementation effort (though it may be adapted from other, similar efforts, it should reflect the target as accurately and completely as possible).

For system developers, a security policy is best encountered in the form of a document that defines a set of rules, practices, and procedures that describe how the system should manage, protect, and distribute sensitive information. Security policies that prevent information flow from higher security levels to lower security levels are called multilevel security policies. As a system is developed, the security policy should be designed, built, implemented, and tested as it relates to all applicable system components or elements, including any or all of the following: physical hardware components, firmware, software, and how the organization interacts with and uses the system.

Policy Mechanisms

As with any security program, policy mechanisms should also be put into place. These mechanisms are extensions of basic computer security doctrine, but the applications described in this section are specific to the field of computer architecture and design.

Principle of Least Privilege

In Chapter 1, “Accountability and Access Control,” you learned about the general security principle of least privilege and how it applies to users of computing systems. This principle is also very important to the design of computers and operating systems, especially when applied to system modes. When designing operating system processes, you should always ensure that they run in user mode whenever possible. The greater the number of processes that execute in privileged mode, the higher the number of potential vulnerabilities that a malicious individual could exploit to gain supervisory access to the system. In general, it’s better to use APIs to ask for supervisory mode services or to pass control to trusted, well-protected supervisory mode processes as they're needed from within user mode applications than it is to elevate such programs or processes to supervisory mode altogether.

Separation of Privilege

The principle of separation of privilege builds upon the principle of least privilege. It requires the use of granular access permissions; that is, different permissions for each type of privileged operation. This allows designers to assign some processes rights to perform certain supervisory functions without granting them unrestricted access to the system. It also allows individual requests for services or access to resources to be inspected, checked against access controls, and granted or denied based on the identity of the user making the requests or on the basis of groups to which the user belongs or security roles that the user occupies.

342 Chapter 11 Principles of Computer Design

Accountability

Accountability is an essential component in any security design. Many high-security systems contain physical devices (such as pen registers and non-modifiable audit trails) that enforce individual accountability for privileged functionality. In general, however, such capability relies on a system’s ability to monitor activity on and interactions with a system’s resources and configuration data and to protect resulting logs from unwanted access or alteration so that they provide an accurate and reliable record of activity and interaction that documents every user’s (including administrators or other trusted individuals with high levels of privilege) history on that system.

Distributed Architecture

As computing has evolved from a host/terminal model, where users could be physically distributed but all functions, activity, data, and resources resided on a single centralized system, to a client/server model, where users operate independent fully functional desktop computers but also access services and resources on networked servers, security controls and concept have had to evolve to follow suit. This means that clients have computing and storage capabilities and, typically, that multiple servers do likewise. Thus, security must be addressed everywhere instead of at a single centralized host. From a security standpoint, this means that, because processing and storage are distributed on multiple clients and servers, all those computers must be properly secured and protected. It also means that the network links between clients and servers (and in some cases, these links may not be purely local) must also be secured and protected.

Vulnerabilities

Distributed architectures are prone to vulnerabilities unthinkable in monolithic host/terminal systems. Desktop systems can contain sensitive information that may be at some risk of being exposed and must therefore be protected. Individual users may lack general security savvy or awareness, and therefore the underlying architecture has to compensate for those lacks. Desktop PCs, workstations, and laptops can provide avenues of access into critical information systems elsewhere in a distributed environment because users require access to networked servers and services to do their jobs. By permitting user machines to access a network and its distributed resources, organizations must also recognize that those user machines can become threats if they are misused or compromised.

Communications equipment can also provide unwanted points of entry into a distributed environment. For example, modems attached to a desktop machine that’s also attached to an organization’s network can make that network vulnerable to dial-in attack. Likewise, users who download data from the Internet increase the risk of infecting their own and other systems with malicious code, Trojan horses, and so forth. Desktops, laptops, and workstations— and associated disks or other storage devices—may not be secure from physical intrusion or theft. Finally, when data resides only on client machines, it may not be secured with a proper backup (it’s often the case that while servers are backed up routinely, the same is not true for client computers).

Safeguards

Hopefully the foregoing litany of potential vulnerabilities in distributed architectures argues strongly that such environments require numerous safeguards to implement appropriate security and to ensure that such vulnerabilities are eliminated, mitigated, or remedied. Clients must be subjected to policies that impose safeguards on their contents and their user’s activities. These include the following:

E-mail must be screened so that it cannot become a vector for infection by malicious software; e-mail should also be subject to policies that govern appropriate use and limit potential liability.

Download/upload policies must be created so that incoming and outgoing data is screened and suspect materials blocked.

Systems must be subject to robust access controls, which may include multifactor authentication and/or biometrics to restrict access to desktops and to prevent unauthorized access to servers and services.

Graphic user interface mechanisms and database management systems should be installed, and their use required, to restrict and manage access to critical information.

File encryption may be appropriate for files and data stored on client machines (indeed, drive-level encryption is a good idea for laptops and other mobile computing gear that is subject to loss or theft outside an organization’s premises).

It's essential to separate and isolate processes that run in user and supervisory mode so that unauthorized and unwanted access to high-privilege processes and capabilities is prevented.

Protection domains should be created so that compromise of a client won’t automatically compromise an entire network.

Disks and other sensitive materials should be clearly labeled as to their security classification or organizational sensitivity; procedural processes and system controls should combine to help protect sensitive materials from unwanted or unauthorized access.

Files on desktop machines should be backed up, as well as files on servers—ideally, using some form of centralized backup utility that works with client agent software to identify and capture files from clients stored in a secure backup storage archive.

Desktop users need regular security awareness training to maintain proper security awareness; they also need to be notified when potential threats present themselves and instructed on how to deal with them appropriately.

Desktop computers and their storage media require protection against environmental hazards (temperature, humidity, power loss/fluctuation, and so forth).

Desktop computers should be included in disaster recovery and business continuity planning because they’re potentially as important (if not more important) to getting their users back to work as other systems and services within an organization.

Developers of custom software built in and for distributed environments also need to take security into account, including use of formal methods for development and deployment, such as code libraries, change control mechanisms, configuration management, patch and update deployment, and so forth.

The Biba model was derived as a direct analogue to the Bell-LaPadula model. Biba is also a state machine model based on a classification lattice with mandatory access controls. Biba was designed to address three integrity issues:

Prevent modification of objects by unauthorized subjects.

Prevent unauthorized modification of objects by authorized subjects.

Protect internal and external object consistency.

Biba has two integrity axioms:

Simple Integrity Axiom The Simple Integrity Axiom (SI Axiom) states that a subject at a specific classification level cannot read data with a lower classification level. This is often shortened to “no read down.”

* Integrity Axiom The * (star) Integrity Axiom (* Axiom) states that a subject at a specific classification level cannot write data to a higher classification level. This is often shortened to “no write up.”

These Biba model axioms are illustrated in Figure 11.4.

Critiques of the Biba model mention a few drawbacks:

It only addresses integrity, not confidentiality or availability.

It focuses on protecting objects from external threats; it assumes that internal threats are handled programmatically.

It does not address access control management, nor does it provide a way to assign or change an object’s or subject’s classification level.

It does not prevent covert channels (see Chapter 12).

Clark-Wilson

The Clark-Wilson model is also an integrity-protecting model. The Clark-Wilson model was developed after Biba and approaches integrity protection from a different perspective. Rather than employing a lattice structure, it uses a three-part relationship of subject/program/object known as a triple. Subjects do not have direct access to objects. Objects can be accessed only through programs. Through the use of two principles—well-formed transactions and separation of duties—the Clark-Wilson model provides an effective means to protect integrity.

Well-formed transactions take the form of programs. A subject is able to access objects only by using a program. Each program has specific limitations on what it can and cannot do to an object. This effectively limits the subject’s capabilities. If the programs are properly designed, then the triple relationship provides a means to protect the integrity of the object.

Separation of duties takes the form of dividing critical functions into two or more parts. A different subject must complete each part. This prevents authorized subjects from making unauthorized modifications to objects. This further protects the integrity of the object.

In addition to these two principles, auditing is required. Auditing tracks changes and access to objects as well as inputs from outside the system.

348 Chapter 11 Principles of Computer Design

F I G U R E 1 1 . 4 The Biba model

The Clark-Wilson model can also be called a restricted interface model. A restricted interface model uses classification-based restrictions to offer only subject-specific authorized information and functions. One subject at one classification level will see one set of data and have access to one set of functions, whereas another subject at a different classification level will see a different set of data and have access to a different set of functions.

Information Flow Model

The information flow model focuses on the flow of information. Information flow models are based on a state machine model. The Bell-LaPadula and Biba models are both information flow models. Bell-LaPadula is concerned with preventing information from flowing from a high security level to a low security level. Biba is concerned with preventing information from flowing from a low security level to a high security level. Information flow models don’t necessarily deal with only the direction of information flow; they can also address the type of flow.

Information flow models are designed to prevent unauthorized, insecure, or restricted information flow. Information flow can be between subjects and objects at the same classification level as well as between subjects and objects at different classification levels. An information flow model allows all authorized information flows, whether within the same classification level or between classification levels. It prevents all unauthorized information flows, whether within the same classification level or between classification levels.

Noninterference Model

The noninterference model is loosely based on the information flow model. However, instead of being concerned about the flow of information, the noninterference model is concerned with how the actions of a subject at a higher security level affect the system state or actions of a subject at a lower security level. Basically, the actions of subject A (high) should not affect the actions of subject B (low) or even be noticed by subject B. The real concern is to prevent the actions of subject A at a high level of security classification from affecting the system state at a lower level. If this occurs, subject B may be placed into an insecure state or be able to deduce or infer information about a higher level of classification. This is a type of information leakage and implicitly creates a covert channel.

Composition Theories

Some other models that fall into the information flow category build on the notion of how inputs and outputs between multiple systems relate to one another—which follows how information flows between systems rather than within an individual system. These are called composition theories because they explain how outputs from one system relate to inputs to another system. There are three types of composition theories recognized:

Cascading: Input for one system comes from the output of another system.

Feedback: One system provides input to another system, which reciprocates by reversing those roles (so that system A first provides input for system B, and then system B provides input to system A).

Hookup: One system sends input to another system but also sends input to external entities.

Take-Grant Model

The Take-Grant model employs a directed graph to dictate how rights can be passed from one subject to another or from a subject to an object. Simply put, a subject with the grant right can grant another subject or another object any other right they possess. Likewise, a subject with the take right can take a right from another subject.

Access Control Matrix

An access control matrix is a table of subjects and objects that indicates the actions or functions that each subject can perform on each object. Each column of the matrix is an ACL. Each row of the matrix is a capability list. An ACL is tied to the object; it lists valid actions each subject can perform. A capability list is tied to the subject; it lists valid actions that can be taken on each object. Implementing an access control matrix model usually involves constructing an environment that can create and manage lists of subjects and objects and a function that can return the type associated with whatever object is supplied to that function as input (this is important because an object’s type determines what kinds of operations may be applied to it).

The access control matrix shown in Table 11.2 is for a discretionary access control system. A mandatory or rule-based matrix can be constructed simply by replacing the subject names with classifications or roles. Access control matrixes are used by systems to quickly access whether the requested action by a subject for an object is authorized.

Brewer and Nash Model (a.k.a. Chinese Wall)

This model was created to permit access controls to change dynamically based on a user’s previous activity (making it a kind of state machine model as well). This model applies to a single integrated database; it seeks to create security domains that are sensitive to the notion of conflict of interest (for example, someone who works at Company C who has access to proprietary data for Company A should not also be allowed access to similar data for Company B if those two companies compete with one another). This model is known as the Chinese wall because it creates a class of data that defines which security domains are potentially in conflict and prevents any subject with access to one domain that belongs to a specific conflict class from accessing any other domain that belongs to the same conflict class. Metaphorically, this puts a wall around all other information in any conflict class and explains the terminology. Thus, this model also uses the principle of data isolation within each conflict class to keep users out of potential conflict- of-interest situations. Because company relationships change all the time, this explains the importance of dynamic update to members of and definitions for conflict classes.

Classifying and Comparing Models

Careful reading of the preceding sections on access control models will reveal that they fall into three broad categories, as follows:

Information flow Information flow models deal with how information moves or how changes at one security level affect other security levels. They include the information flow and noninterference models and composition theories.