19.1 Assurance in Requirements Definition and Analysis

Understanding the role of assurance in the development of requirements means understanding what requirements must provide. The set of requirements must be complete and correct in the context of security policy models. Defining requirements is an iterative process that normally begins with threat definition and culminates with the detailed level requirements that are used in the design, implementation, and maintenance of the system.

19.1.1 Threats and Security Objectives

In building a secure or trusted system, it is a mistake to assume that threats to the system are obvious or well-defined. This section briefly discusses identification of the security threats to the system and development of high-level security requirements, or security objectives, to mitigate the threats. This approach parallels that of the Common Criteria (see Section 21.8).

Definition 19–1. A threat is a potential occurrence that can have an undesirable effect on the system assets or resources. It is a danger that can lead to undesirable consequences.

Threats are different from vulnerabilities.

Definition 19–2. A vulnerability is a weakness that makes it possible for a threat to occur.

At the highest layer of abstraction, security threats are breaches of confidentiality, disruptions of integrity, or denials of service. It is important to refine these threats in relation to the specific system and the environment in which it must operate. Threats may come from either outside or inside some boundary that defines the system. Threats can come from authorized users or from unauthorized users who masquerade as valid users or find ways to bypass security mechanisms. Threats can also come from human errors or from acts of God.

EXAMPLE: An attacker from the Internet penetrating a computer system is an example of an outside threat. A penetration could result in a breach of confidentiality, a breach of integrity, or a denial of service. A successful penetration could result in theft of secrets, compromising of secret information, or the setting up of a denial of service attack.

EXAMPLE: Another example of an outsider threat involves an organizational LAN having restricted access to certain machines. A valid user of the LAN could be an outsider to a specific host and could theoretically mount an outsider attack on that host.

If the system is not connected to external networks, outside attackers may not be a threat. Elimination or mitigation of the threat of penetration does not, however, eliminate the threat of disclosure of secrets, breaches of integrity, or denials of service. Typically, inside users are trusted to use the system correctly, but there are many ways in which this trust can go wrong. One way is through intentional misuse of authorizations, whether for fun, profit, or revenge. Another is the so-called fat-finger error, whereby an authorized user makes a mistake or inadvertently corrupts or misuses the system. Other means of misusing systems include finding ways to defeat or bypass authorization and access controls or other security mechanisms to reach information that would ordinarily be denied the perpetrator.

Every identified threat must be addressed by some countermeasure that mitigates it. Security objectives are high-level requirements that can serve this purpose. For example, threats regarding unauthorized use of the system can be mitigated by an objective that requires user identification and authentication before a user is given access to any system resources. Objectives are requirements at the highest level, and they provide clues about the kinds of mechanisms that are needed to implement them. In addition, objectives reveal information that can help in the subsequent development of a detailed requirement specification. Objectives suggest models and other existing policies. Sometimes security objectives are not sufficient to address all threats, which leads to assumptions about the operating environment, such as physical protection mechanisms, to address all threats.

Mapping the security threats into the set of objectives and assumptions partially addresses the completeness of the system security requirements. Note that every threat must be addressed. Threats may be mitigated by a combination of assumptions or objectives. Often a single objective or assumption can address multiple threats.

19.1.2 Architectural Considerations

An early architectural decision is to determine the primary focus of control of security enforcement mechanisms. Computer security centers on access to information, but the primary focus of control of security protection and enforcement mechanisms may be on user identity or on operations. In operating systems, for example, the focus of control is on the data. Access decisions are based on predefined permissions to data for processes acting on behalf of users. User-based mechanisms include mandatory access control mechanisms, discretionary access control mechanisms, and privileges assigned to users. In applications, the focus of control may be on operations that a user is allowed to perform. A user may be restricted to certain operations. These operations control access to the data needed to perform their functions. Role-based access control mechanisms focus on operations.

Another architectural decision is whether to centralize some security functions or to distribute them among systems or system components. There are trade-offs between a centralized security enforcement mechanism and a distributed mechanism. In distributed systems, a function may be spread across components or centralized in a single component. In a single-host system, a function may be distributed across modules or consolidated into a single module. An example in a distributed system is the collection of security audit information. The system could forward all auditing information to a central audit repository, or each component could do its own auditing. As another example, an operating system can use centralized or distributed mandatory access control checks. The mechanism may be centralized, and called by other routines or may be distributed, and duplicated within the operating system where needed.

Generally, it is easier to analyze and develop sound assurance evidence for centralized mechanisms. A mechanism that is in one place need only be analyzed once, and the remainder of the assurance steps simply argue that the routine is called appropriately. However, a centralized mechanism may be a bottleneck and may impact performance.

19.1.2.1 Security Mechanisms and Layered Architecture

Computer architectures are layered, and security enforcement mechanisms may reside at any architectural layer. Systems designed and built using layers describe the functionality of each layer precisely.

EXAMPLE: Consider an architecture with four layers. The uppermost layer is the application layer. Application programs are those special-purpose programs that are used to perform specific tasks on behalf of a user, varying from personal applications to business applications to Web applications. The next layer is the services or middleware layer. It provides support services for applications. These services, however, are not part of the operating system. Examples of tools at this layer include database management systems and object reference brokers. The next layer is the operating system layer. Software at this layer manages memory, file systems, I/O, and peripheral devices and may be responsible for scheduling and process control. The operating system kernel, which is at this layer, is the part of the operating system that is restricted to specially authorized users and is at the heart of the control of the physical resources of the underlying processor. The lowest layer is the hardware layer. This layer includes firmware, which is code that has been built into the hardware itself and cannot be altered or removed without making a physical change in the processor.

When an application receives a request, it passes the request to the layer underneath the application. That layer processes the request and passes it to the next layer. This continues until the request reaches the layer that can fulfill the request. Successive layers simply follow the instructions they are given by the preceding layers. When the request is satisfied, the pertinent information is passed back up the layers to the user at the application layer.

An early architectural decision is selecting the correct layer for a mechanism. Designers must select the layer at which the mechanism will be the most efficient and the most effective. Security mechanisms for controlling user actions may be most effective at the application level, but security mechanisms for erasing data in freed disk blocks may be most effective at the operating system level.

Once a layer has been chosen for a security mechanism, one must consider how to protect the layers below that layer. For example, a secure operating system requires security mechanisms in the hardware layer as well as in the operating system itself. A secure application requires security mechanisms inside the application as well as at the services, operating system, and hardware layers.

The security mechanisms at the hardware layer may be a combination of physical security mechanisms that isolate the hardware in rooms requiring special access and administrative procedures that restrict access to them. Some computer manufacturers suggest that security mechanisms be built into the firmware and hardware [1000] as well as into the software.

It may not be possible to place a mechanism in the desired layer unless what is being developed includes all the pertinent architectural layers. For example, when developing an application, the builder may not be able to make changes in the operating system layer. Doing so would mean defining requirements for the operating system and acquiring an operating system that meets those requirements. If no such operating system exists, the mechanism must be placed at a less optimal layer, or the builders must consider a special-purpose operating system.

EXAMPLE: Consider an application program that uses a database management system to manage information. The user requests access to a particular data item from the application. The application forwards this request to the database management system. That system processes the request and sends appropriate requests to the operating system. The database management system may use operating system commands or may issue system calls directly to continue the request. The operating system kernel issues commands to the firmware and hardware to physically retrieve the data and pass it back to the operating system. Then the operating system passes the retrieved data to the database management system, which returns the data to the application.

The security enforcement mechanisms of the application and the database management system can only control accesses to the underlying operating system that use the internal mechanisms of the application and the database management system. Application and database mechanisms cannot control a system user from accessing the operating system directly, bypassing the controls of the application or the database mechanism entirely. If a user can access application or database information by accessing the operating system directly, then the system is vulnerable. Regardless of the security mechanisms within the database management system, the operating system must also enforce security. For this reason, all evaluated and rated database management systems require the underlying operating system to provide specific security features and to be a rated and evaluated operating system.

19.1.2.2 Building Security In or Adding Security Later

Like performance, security is an integral part of a computer system. It should be integrated into the system from the beginning, rather than added on later.

Imagine trying to create a high-performance product out of one that has poor performance. If the poor performance is attributable to specific functions, those functions must be redesigned. However, the fundamental structure, design, and style of the system are probably at the heart of the performance problem. Fixing the underlying structure and system design is a much harder problem. It might be better to start over, redesigning the system to address performance as a primary goal. Creating a high-security system from one that previously did not address security is similar to creating a high-performance system. Products claiming security that are created from previous versions without security cannot achieve high trust because they lack the fundamental and structural concepts required for high assurance.

A basic concept in the design and development of secure computer systems is the concept of a reference monitor and its implementation—the reference validation mechanism.

Definition 19–3. [26] A reference monitor is an access control concept of an abstract machine that mediates all accesses to objects by subjects.

Definition 19–4. [26] A reference validation mechanism (RVM) is an implementation of the reference monitor concept. An RVM must be tamperproof, must always be invoked (and can never be bypassed), and must be small enough to be subject to analysis and testing, the completeness of which can be assured.

Any secure or trusted system must obviously meet the first two requirements. The "analysis and testing" of the reference monitor provides evidence of assurance. The third requirement engenders trust by providing assurance that the operational system meets its requirements.

Definition 19–5. [26] A security kernel is a combination of hardware and software that implements a reference monitor.

Security kernels were early examples of reference validation mechanisms. The idea of a security kernel was later generalized by the definition of a trusted computing base, which applies the reference validation mechanism rules to additional security enforcement mechanisms.

Definition 19–6. [285] A trusted computing base (TCB) consists of all protection mechanisms within a computer system—including hardware, firmware, and software—that are responsible for enforcing a security policy.

A TCB consists of one or more components that together enforce the security policy of a system. The ability of a TCB to enforce a security policy depends solely on the mechanisms within the TCB and on the correct input of parameters (such as a user's clearance) related to the security policy.

If a system is designed and implemented so as to be "small enough to be subject to analysis and testing, the completeness of which can be assured," it will be more amenable to assurance than a system that is not so designed and implemented. Design analysis is possible using a variety of formal and informal methods. More thorough testing is possible because what must be tested is clear from the structured, analyzed design. More and deeper assurance leads to a higher level of trust in the resulting system. However, trade-offs may occur between features and simplicity. Inclusion of many features often leads to complexity, which limits the ability to analyze the system, which in turn lowers the potential level of assurance.

Systems in which security mechanisms are added to a previous product are not as amenable to extensive analysis as those that are specifically built for security. Often the functions are spread throughout the system in such a way that a thorough design analysis must analyze the entire system. Rigorous analysis of large and complex designs is difficult. So, it may not be feasible to determine how well the design implements the requirements. Assurance may be limited to test results. Testing of conformance to a flawed design is similar to designing a system to meet inappropriate requirements. The gap in abstraction between security requirements and implementation code may prohibit complete requirements testing. Hence, systems with security mechanisms added after development has been completed are inherently less trustworthy.

Building a system with security as a significant goal may provide the best opportunity to create a truly secure system. In the future, this may be the norm. However, many products today, including many high-assurance products, are developed by rearchitecting existing products and reusing parts as much as possible while addressing fundamental structure as well as adding new security features.

EXAMPLE: Multics [788] was one of the early general-purpose operating systems that was built for secure applications. It borrowed much from the other operating systems of the day. Although it is no longer in use, many security experts consider Multics to be the best example of an operating system built for security.

EXAMPLE: Gemsos [885] is a high-assurance, formally verified operating system that has a minimal UNIX-like kernel and limited functionality. Seaview [649] was a high-assurance database management system that was intended to run on the Gemsos operating system. Seaview was designed for security but was implemented by rearchitecting an existing database product.

EXAMPLE: Information flow control mechanisms, called guards (see Section 16.5), are often high-assurance devices. The RECON guard [28] controls the flow of information from a highly classified reconnaissance database to an unclassified network. The Restricted Access Processor [820] controlled the flow of information between two differently classified networks. Firewalls are a form of guards, although they are usually single-purpose applications built on security-hardened versions of existing operating systems rather than systems developed specifically for high assurance.

EXAMPLE: In the late 1980s and early 1990s, AT&T undertook two projects to provide secure versions of UNIX System V that supported mandatory access controls. The first project was market-driven, in response to specific requests from customers. The underlying goals of this project were quick time to market and minimal impact on the user interface and on the look and feel of the resulting UNIX system, called SV/MLS [143, 359]. The chosen approach was to add security functionality to AT&T UNIX System V Release 3.2. The second project was focused on restructuring and re-creating a UNIX system to provide a medium-to-high level of trust. This version, called SVR4.1ES, involved significant rearchitecting of the UNIX system with security built in [856]. The technical differences between these two products illustrate the superiority of building security in over adding it on. The SVR4.1ES project involved extensive restructuring of the UNIX kernel to meet high-modularity requirements and to incorporate an implementation of the principle of least privilege that was integral to the UNIX kernel. SV/MLS used the existing UNIX kernel modular structure and did not provide an implementation of least privilege. The basic architecture of SVR4.1ES was new, and the architecture of SV/MLS was essentially unchanged from its parent product. In UNIX systems, the inode structure contains attribute information about each file or object, such as access permission information and file owner. The inode also has a pointer to the file or object itself. There is insufficient space in the inode to house security labels of any significant size. SV/MLS chose not to disturb the existing inode structure. The designers created a separate table to hold mandatory access control labels and used a free location in the inode structure to point to the table. When an object is created, a code defining both the mandatory access control label and the discretionary security attributes is stored in the table. Security attributes for subjects are stored internally in the same code structure. An access control check becomes a comparison of the codes for the subject and object, effectively doing a mandatory access control check and a discretionary access control check in one operation. Even if the implementation of this table is correct and the comparison of the codes properly reflects the mandatory and discretionary access control requirements, there are potential weaknesses in this design. The coupling between the table and the file is inherently weaker than the coupling between the inode and the file. Two accesses are required to reach the coded mandatory and discretionary access control attributes of the object (first to the inode, then to the table), potentially weakening the tie between the actual object and its security attributes. Updating of discretionary access control security attributes is done to the inode version of the discretionary access control requirements. An additional step to update the table entry occurs whenever the permissions or owner is changed. This introduces the potential for inconsistency between the inode attributes and the coded interpretation. During a table update, the mandatory access control information for that object may be exposed. Finally, if the table is corrupted, the mandatory and discretionary access permissions for the entire file system may be impacted. Although the SV/MLS implementations addressed these issues satisfactorily, the potential for these vulnerabilities still existed. The SVR4.1ES implementation simply redefined the inode structure. These new inodes, called vnodes, contained the mandatory access control label as well as the discretionary access control attributes in the vnode. Access to the vnode provided access to the mandatory and discretionary attributes. SVR4.1ES reused the UNIX discretionary access control mechanisms and augmented them with access control lists. Checks of mandatory and discretionary access were independent checks. SVR4.1ES was not constrained by minimal impact requirements, resulting in a stronger set of access control mechanisms. Because of the structural change, SVR4.1ES was able to reuse other parts of the system with little impact.

19.1.3 Policy Definition and Requirements Specification

Recall from Section 18.1.2 that we can consider a security policy to be a set of specific statements or security requirements.

Definition 19–7. A specification is a description of characteristics of a computer system or program. A security specification specifies desired security properties.

Good specifications are as important as the properties of the systems or programs that they describe. Specifications can be written at many different levels of abstraction. For example, some specifications may describe the security requirements, whereas other specifications may describe an architectural view of the system. More detailed specifications may describe individual components. Even more detailed specifications may describe individual functions. As this example implies, there may be multiple levels of specifications at different layers of abstraction.

Specifications must be clear, unambiguous, and complete. This is difficult when using informal methods that rely on natural language because natural languages do not have precise syntax or semantics.

EXAMPLE: A specification or an operating system gave "meet C2 security" as a requirement. The specification provided no details of the C2 requirements [285], which included 34 requirements in 11 different categories. Other requirements in the same specification were extremely detailed, such as those for adding a new file system, adding several new devices, and making very detailed changes in the memory control subsystem. The unevenness of the specification made it difficult to use. The developers chartered to "meet C2 security" neither understood what it meant nor knew how to find the detailed requirements.

Precision in stating requirements can be difficult to achieve.

EXAMPLE: The requirement that "users of the system must be identified and authenticated" is ambiguous. It does not specify the type of identification required. Is a driver's license presented to the system operator sufficient? It does not unambiguously specify the entities to be authenticated. Is the user, the representation of the identity, or the system to be authenticated? It also does not specify who is to perform the authentication. Is the system, some other system, or some other entity (such as a guard at the door) to perform the authentication? It is not necessary to name specific identification or authentication mechanisms to answer these questions and clear up the ambiguities. A second iteration might change this requirement to "users of the system must be identified to the system and must have that identification authenticated by the system." This is more precise. The "system" both identifies and authenticates the representation of the user's identity (not the system or the user). However, it still does not address the conditions under which the user must be identified to the system. Is the user to be identified at entry to the site, at login, at a particular time of day, or before certain operations are to be performed? A third iteration produces the requirement that "users of the system must be identified to the system and must have that identification authenticated by the system before the system performs any functions on behalf of that identity." This form addresses the concerns from the previous two versions.

There are several different methods of defining policies or requirement specifications. One technique is to extract applicable requirements from existing security standards, such as the Common Criteria. These specifications tend to be semiformal because of the structure of the requirements and the mappings among them. Another method is to create a new policy by combining the results of a threat analysis with components of existing policies.

A third technique is to map the system to an existing model. If the model is appropriate for the goals of the system, creating a mapping between the model and the system may be simpler and cheaper than constructing a requirements specification by other methods. If the mapping is accurate, the proofs of the original model establish the correctness of the resulting policy.

The expression of the specification can be formal or informal in nature. Section 20.2 contains an example of a formal specification of the Bell-LaPadula Model in the specification language SPECIAL.

EXAMPLE: System X is a product that enhances standard UNIX security mechanisms with mandatory access controls and auditing. The confidentiality components are based on the Bell-LaPadula (BLP) model discussed in Section 5.2.3. The designers use a mapping technique to develop the System X confidentiality policy. The designers map the elements and state variables of BLP to entities in System X. They also justify the existence and functions of any entities in System X that have no counterparts in BLP: System X processes are subjects in the set S of the BLP model. Inode objects (disk files, directories, and other file system constructs), interprocess communication objects, mail messages, processes as destinations for messages, and other passive entities in System X are the objects in the set O of the BLP model. Each system function of System X is given a right from the set P of the BLP model. Functions that create entities (such as creat, which creates a file) have the access type w; functions that read and write entities (such as the system calls read and write) have the types r and w, respectively. Execution and search accesses are mapped to the access type r. The access set b in the BLP model defines the types of access allowed for each object. For example, subjects can use the rights r, w, and a to access inode objects. The access control matrix a for the current state in the BLP model is the current state of both mandatory and discretionary controls in System X. The functions fs, fo, and fc in the BLP model map into three functions in System X. The function f(s) is the maximum security level of the subject s, the function current-level(s) is the current security level of the subject, and f(o) is the security level of an object. The hierarchy H in the BLP model maps differently for different types of objects. For example, inode objects are hierarchical trees represented by the file system hierarchy, whereas other object types map to discrete points in the hierarchy. Next, the designers define BLP properties in the language of System X and demonstrate that each property is consistent with BLP. The mandatory access control property of BLP is translated as a user having read access over an object if and only if the user's clearance dominates the object's classification, and as a user having write access over an object if and only if the object's classification dominates the user's clearance. The discretionary access control property of BLP is translated as giving a user access to an object if and only if the owner of the object has explicitly granted that user access to the object. Label inheritance and user level changes are properties specific to System X. The security level of a newly created object is inherited from the creating subject. The security level of the initial process at user login, and the security level of the initial process after a user level change, are bounded by the security level range defined for that user and by the security level range defined for the terminal. The security level of a newly spawned process is inherited from the parent, except for the first process after a user level change. When a user's level is raised, the child process does not inherit write access to the objects opened by the parent. When a user's level is lowered, all processes and all accesses associated with the higher privilege are terminated. Reclassification is also a property of System X. Specially trusted users are allowed to downgrade objects they own within the constraints of the user's authorizations. The System X property of owner/group transfer allows the ownership or group membership of the process to be transferred to another user or group. Finally, the status property is a property of System X. It restricts the visibility of status information available to users when they use the standard System X set of commands. In this step, the designers define System X rules by mapping System X system calls, commands, and functions to BLP rules. The simple security condition, the *-property, and the discretionary security property are all interpreted for each type of access. From these interpretations, the designers can extract specific requirements for specific accesses to particular types of objects. Finally, the designers demonstrate that the System X rules preserve the security properties. They either show that the rules enforce the properties directly or map the rules directly to a BLP rule or a sequence of BLP rules. System X has nine rules about current access, five rules about functions and security levels, eight access permission rules, and eight more rules about subjects and objects. The designers must show that each rule is consistent with the actions of System X. The results of these steps provide a high degree of assurance that System X correctly enforces the rules of the Bell-LaPadula confidentiality model.

19.1.4 Justifying Requirements

Once the policy has been defined and specified, it must be shown to be complete and consistent. This section examines part of a security policy developed in accordance with the ITSEC [210] guidelines. It also provides a partial informal demonstration that the resulting security policy meets the threats defined for the system.

The ITSEC (see Section 21.3) is a harmonization of security evaluation criteria of several European countries. ITSEC introduced the concept of a security target (ST) that defines the security threats to the system and the functional requirements of the system under evaluation. An ITSEC suitability analysis justifies that the security functional requirements are sufficient to meet the threats to the system.

The suitability analysis maps threats to requirements and assumptions in tabular form. For each threat, a prose description describes how the references address the threat.

EXAMPLE: Consider a system called Y that is under evaluation. A subset of the threats, requirements, and assumptions relevant to our security target are as follows. Threat T1: A person not authorized to use the system gains access to the system and its facilities by impersonating an authorized user. Requirement IA1: A user is permitted to begin a user session only if the user presents a valid unique identifier to the system and if the claimed identity of the user is authenticated by the system by authenticating the supplied password. Requirement IA2: Before the first user/system interaction in a session, successful identification and authentication of the user take place. Assumption A1: The product must be configured such that only the approved group of users has physical access to the system. Assumption A2: Only authorized users may physically remove from the system the media on which authentication data is stored. Assumption A3: Users must not disclose their passwords to other individuals. Assumption A4: Passwords generated by the administrator shall be distributed in a secure manner. The security analysis mapping is as follows. Threat Security Target Reference T1 IA1, IA2, A1, A2, A3, A4 The justification for this mapping requires an examination of the effects of the security target references. The referenced requirements and assumptions guard against unauthorized access. Assumption A1 restricts physical access to the system to those authorized to use it. Requirement IA1 requires all users to supply a valid identity and confirming password. Requirement IA2 ensures that requirement IA1 cannot be bypassed. The referenced assumptions prevent unauthorized users from gaining access by using a valid user's identity and password. Assumption A3 ensures that users keep their passwords secret. Assumption A4 prevents unauthorized users from intercepting new passwords when those passwords are distributed to users. Finally, assumption A2 prevents unauthorized access to authentication information stored on removable media. The justification provides an informal basis for asserting that, if the assumptions hold and the requirements are met, the threat is adequately handled.