This publication is issued by the National Computer Security Center (NCSC) as part of its program to promulgate technical computer security guidelines. This interpretation extends the Department of Defense Trusted Computer System Evaluation Criteria (DOD 5200.28-STD) to computer security subsystems.
This document will be used for a period of at least one year after date of signature. During this period the NCSC will gain experience using the Computer Security Subsystem Interpretation in several subsystem evaluations. After this trial period, necessary changes to the document will be made and a revised version issued.
Anyone wishing more information, or wishing to provide comments on the usefulness or correctness of the Computer Security Subsystem Interpretation may contact: Chief Technical Guidelines Division, National Computer Security Center, Fort George G. Meade, MD 20755-6000, ATTN: Cll.
PATRICK R GALLAGHER, JR. 16 September 1988
Director National Computer Security Center
Computer Security Subsystems ACKNOWLEDGEMENT
Acknowledgment is extended to the members of the working group who produced this Interpretation. Members were: Michael W. Hale, National Computer Security Center (Chair); James P. Anderson; Terry Mayfie!d, Institute For Defense Analyses; Alfred W. Arsenault, NCSC; William Geer, NCSC; John C. Inglis, NCSC; Dennis Steinauer, National Bureau of Standards; Mario Tinto, NCSC; Grant Wagner, NCSC; and Chris Wilcox, NCSC.
Acknowledgement is further extended to those individuals who conducted thorough reviews and and provided constructive comments on this document. Reviewers included: Steve Lipner, Earl Boebert, Virgil Gligor, Debbie Downs, Len Brown, Doug Hardie, Steve Covington, Jill Sole and Bob Morris.
This document provides interpretations of the Department of Defense Trusted Computer System Evaluation Criteria (DoD 5200.28-STD or TCSEC) for computer security subsystems. A computer security subsystem (subsystem) is defined, herein, as hardware, firmware and/or software which can be added to a computer system to enhance the security of the overall system. A subsystem's primary utility is to increase the security of a computer system. The computer system that the subsystem is to protect is referred to as the protected system in this Interpretation.
When incorporated into a system environment, evaluated computer security subsystems may be very effective in reducing or eliminating certain types of vulnerabilities whenever entire evaluated systems are unavailable or impractical.
This Interpretation has been prepared for the following purposes:
The Department of Defense Trusted Computer System Evaluation Criteria (DoD 5200.28-STD or TCSEC) was developed to establish uniform DoD policy and security requirements for "trusted, commercially available, automatic data processing (ADP) systems." Evaluation criteria defined in the TCSEC provides a standard to manufacturers as to what security features to build into their commercial products to satisfy trust requirements for sensitive applications, and serves as a metric with which to evaluate the degree of trust that can be placed in a computer system for the secure processing of classified or other sensitive information.
The TCSEC specifies a variety of features that a computer system must provide to constitute a complete security system. The security requirements specified in the TCSEC depend on and complement one another to provide the basis for effective implementation of a security policy in a trusted computer system. The effectiveness of any one security feature present within a system is, therefore, dependent to some degree on the presence and effectiveness of other security features found within the same system. Because it was intended to be used only for systems which incorporated all the security features of a particular evaluation class, the TCSEC does not, in all cases, completely specify these interdependencies among security features.
In addition to the class of trusted system products, there exists a recognized need for a class of computer security products which may not individually meet all of the security features and assurances of the TCSEC. Instead, these products may implement some subset of the features enumerated in the TCSEC and can potentially improve the security posture in existing systems. These products are collectively known as computer security subsystems.
Evaluation of computer security subsystems against a subset of the requirements given in the TCSEC has proven an extremely difficult task because of the implied dependencies among the various features discussed in the TCSEC. As a consequence, interpretations of these interdependencies and the relative merits of specific subsystem implementations have been highly subjective and given to considerable variation.
This document provides interpretations of the TCSEC for computer security subsystems in an effort to lend consistency to evaluations of these products by explicitly stating the implications in the TCSEC.
Evaluations can be divided into two types: (l) a product evaluation can be perforrned on a subsystem from a perspective that excludes the application environment, or (2) a certification evaluation can be done to assess whether appropriate security measures have been taken to permit an entire system to be used operationally in a specific environment. The product evaluation type is done by the National Computer Security Center (NCSC) through the Trusted Product Evaluation Process using this interpretation for subsystems. The certification type of evaluation lS done in support of a formal accreditation for a system to operate in a specific environment using the TCSEC.
This document interprets the security feature, assurance and documentation requirements of the TCSEC for subsystem evaluations. In this interpretation, the functional requirements of the TCSEC are divided into four general categories:
These categories form the basis for classifying products to be evaluated as computer security subsystems.
The document, in addition to this introductory section, is organized into three major sections and a glossary. Section 2 contains the feature requirements for each of the above four categories on which subsystems evaluations are based. The requirements in this section are listed in increments, with only new or changed requirements being added for each subsequent class of the same feature. All requirements that are quoted from the TCSEC are in bold print for easy identification and are clarified, in the context of subsystems, by interpretation paragraphs.
Section 3 contains the assurance requirements for all subsystems. The assurances that are relevant to each category are listed here in the same format as the requirements in Section 2. Section 4 contains the requirements and interpretations for subsystem documentation, again, in the same forrnat as Section 2.
The TCSEC-related feature and assurance requirements described herein are intended for the evaluation of computer security subsystems designed to protect sensitive information. This Interpretation, like the TCSEC, assumes that physical, administrative, and procedural protection measures adequate to protect the inforrnation being handled are already in place.
This Interpretation can be used to support a certification evaluation. In fact, it would be helpful whenever subsystems are a part of the overall system being certified.
Subsystems are evaluated for the specific security-relevant functions they perforrn. This Interpretation interprets the relevant TCSEC requirements for each function evaluated. So the function(s) for which subsystems are evaluated will be identified within its ratings. Each function has its own set of ratings as identified in Table 1.1. Subsystems that are evaluated for more than one function will receive a separate rating for each function evaluated.
TABLE 1.1. Possible Subsystem Ratings
SUBSYSTEM FUNCTION POSSIBLE RATINGS Discretionary Access Control DAC/D, DAC/Dl, DAC/D2, DAC/D3 Object Reuse OR/D,OR/D2 Identification & Authentication I&A/D, I&A/Dl, I&A/D2 Audit AUD/D, AUD/D2, AUD/D3
Although the requirements for subsystems are derived from the TCSEC, the ratings for subsystems will not directly reflect the TCSEC class they are derived from. Since subsystems, by their very nature, do not meet all of the requirements for a class Cl or higher computer system, it is most appropriate to associate subsystem ratings with the D division of the TCSEC. This Interpretation defines the Dl, D2 and D3 classes within the D division for subsystems. The Dl class is assigned to subsystems that meet the interpretations for requirements drawn from the Cl TCSEC class. Likewise, the D2 class consists of requirements and interpretations that are drawn from the C2 TCSEC class. The D3 subsystem class is reserved for DAC subsystems and audit subsystems that meet the B3 functionality requirements for those functions.
In addition to meeting the functionality requirements and interpretations, subsystems must also meet the assurance and documentation requirements in sections 3 and 4 of this document. The Dl and D2 classes have requirements and interpretations for ~ssurances and documentation as well as functionality.
The D3 class contains additional requirements and interpretations only for functionality, not for assurances or documentation. So, subsystems with this rating will adhere to the D2 assurance and documentation requirements and interpretations.
Like the classes within the TCSEC, the Dl, D2 and D3 classes are ordered hierarchically. Subsystems being evaluated for the Dl class must meet the requirements and interpretations for the Dl class. Subsystems being evaluated for the D2 class must meet the requirements and interpretations for the Dl class plus the additional requirements and interpretations for the D2 class. Subsystems being evaluated for the D3 class must meet the additional requirements and interpretations associated with the functionality at D3.
Although the subsystem requirements and interpretations are derived directly from the TCSEC, subsystems are not considered to be complete computer security solutions. There is no general algorithm to derive a system rating from an arbitrary collection of computer security subsystems. Any collection of individually evaluated subsystems must be evaluated as a whole to determine the rating of the resulting system. The ratings of the individual subsystems in a complete system are not a factor in the rating of that system.
Because all of the TCSEC requirements for a given rating class were intended to be implemented in a complete computer security system, many of the security features are dependent upon each other for support within the system. This poses a certain degree of difficulty with extracting only the relevant requirements from the TCSEC for a given feature. Further, this poses a fundamental problem for subsystems because there is an explicit dependency between security features that restricts the "independent" incorporation of subsystems into the system's environment. The problem has been handled in this Interpretation by discussing the integration requirements for each type of subsystem. The requirements for integration are discussed for each type of subsystem in a sub-section entitled, "Role Within Complete Security System." Furthermore, explicit requirements for integration are stated in the interpretations at appropriate points. The developer must show, and the evaluation shall validate, that the subsystem can be integrated into a system to fulfill its designated role.
Most all computer security subsystems will rely on other security-relevant functions in the enviromnent where they are implemented. Audit subsystems, for example, depend on an identification and authentication function to provide the unique user identities that are necessary for individual accountability. Also, it is important to realize that some of these functions may be dependent on each other in a cyclic fashion (e.g., I&A depends on DAC and DAC depends on I&A). In these cases, the cyclic dependencies should be removed either by complete integration of the functions or by modularizing the functions in a way that allows linear dependencies. Tl~is latter method is termed "sandwiching" and it requires the splitting of one function and surroundmg the other dependent function with the two functions resulting from the split. For example, in the case of DAC and I&A cyclic dependencies, one might split I&A into two parts so that there is a system I&A, a DAC subsystem, and a DAC module containing its own I&A functionality.
With the exception of object reuse, all functions implemented by subsystems will be dependent on other functions as shown in Table 1.2. The functions upon which any subsystem is dependent will be referred to as that subsystem's required supporting functions. These required supporting functions must be present in the subsystem's environment for the effective integration of the subsystem.
TABLE 1.2. Required Supporting Functions
SUBSYSTEM FUNCTION REQUIRED SUPPORTING FUNCTIONS Discretionary Access Control I&A, Audit Object Reuse None Identification & Authentication Audit,DAC2, Audit, I&A, DAC2
Subsystems that are not self-sufficient in providing required supporting functions must, at a minimum, provide an interface to their required
supporting functions. The evaluation team will perform tests to show whether the interface to the required supporting functions is reliable and works properly. The robustness of the required supporting functions on the other side of the interface will not be tested, as the scope of the subsystem evaluation is bounded by the interface.
A more integrated solution is for subsystems to be self- su~cient in providing all of their required supporting functions. Such subsystems w_ill be evaluated and assigned a separate rating for each function they provide. Unlike the previous solution, where only an interface is provided, each required supporting function is performed by the subsystem and must be a part of the subsystem evaluation.
The audit supporting functions are required at D2. 2 Audit and/or authentication data must be protected through domain isolation or DAC.
An overan system rating, such as that provided by the TCSEC, cannot be inferred from the application of one or more separately-rated subsystems. Mechanisms, interfaces, and the extent of required supporting functions for each subsystem may differ substantiany and may introduce significant vulnerabilities that are not present in systems where security features are designed with fun knowledge of interfaces and host system support. Therefore, incorporation of an evaluated subsystem into any system environment does not automaticany confer any rating to the resulting system.
This subsystem provides user-specified, controlled sharing of resources.
This control is established from security policies which define, given identified subjects and objects, the set of rules that are used by the system to determine whether a given subject is authorized to gain access to a specific object.
DAC features include the means for restricting access to objects; the means for instantiating authorizations for objects; and the mechanisms for distribution, review, and revocation of access privileges, especially during object creation and deletion.
The requirement is to give individual users the ability to restrict access to objects created or controlled by them. Thus, given identified subjects and objects, DAC includes the set of rules (group-oriented and/or individually-oriented) used by the subsystem to ensure that only specified users or groups of users may obtain access to data (e.g., based on a need-to-know).
A DAC subsystem controls access to resowces. As such, it shall be integrable with the operating system of the protected system and shall mediate all accesses to the protected resources. To fully protect itself and the resources it controls, the DAC subsystem must be interfaced to the protected system in such a way that it is tamperproof and always invoked.
DAC subsystems use the identifiers of both subjects and DAC-controlled objects as a basis for access control decisions. Thus, they must be supplied with the identifiers in a reliable manner. The DAC subsystem may supply subject identification for itself or it may rely on an I&A mechanism in the protected system or in another subsystem. It is also essential that DAC subsystems be implemented in an environment where the objects it protects are well defined and uniquely identified.
At the DAC/D2 class, the DAC subsystem must interface with an auditing mechanism. This auditing mechanism can be included within the DAC subsystem, or it may reside elsewhere in the subsystem's environment.
Subsystems which are designed to implement discretionary access controls to assist a host in controlling the sharing of a collection of objects must comply with all of the TCSEC requirements as outlined below for features, assurances and documentation. Compliance with these requirements will assure that the subsystem can enforce a specifically defined group-oriented and/or individually-oriented discretionary access control policy.
As a part of the evaluation, the subsystem vendor shall set up the subsystem in a typical functional configuration for security testing. This will show that the subsystem interfaces correctly with the protected system to meet all of the feature requirements in this section and ali of the assurance and documentation requirements in Sections 3 and 4. It will also show that the subsystem can be integrated into a larger system environment.
The interpretations for applying the feature requirements to DAC subsystems are explained in the subsequent interpretations sections. The application of the assurances requirements and documentation requirements is explained in Sections 3 and 4, respectively.
"Cl: New: The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to special and control sharing of those objects by named indinduals or defined groups or both."
In the TCSEC quote, "TCB" is interpreted to mean "DAC subsystem".
DAC subsystems must use some mechanism to determine whether users are authorized for each access attempted. At DAC/Dl, this mechanism must control access by groups of users. The mechanisms that can meet this requirement include, but are not limited to: access control lists, capabilities, descriptors, user profiles, and protection bits. The DAC mechanism uses the identification of subjects and objects to perform access control decisions. This implies that the DAC subsystem must interface with or provide some I&A mechanism. The evaluation shall show that user identities are available to DAC.
The DAC subsystem must provide the capability for users to specify how other users or groups may access the objects they control. This requires that the user have a means to specify the set of authorizations (e.g., access control list) of all users or groups permitted to access an object and/or the set of all objects accessible to a user or group (e.g., capabilities).
The checking of the specified authorizations of a user prior to granting access to an object is the essential function of DAC which must be provided. Mediation either allows or disallows the access.
"C2: Change: The enforcement mechanism (e.g. self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shan provide controls to limit propagation of access rights."
"C2: Add: The discretionary access control mechamsm shan, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls s~ll be capable of including or excluding access to the granularity of a single wer. Access permission to an object by users not already possessing access pernlission shan only be assigned by authorized users."
The following interpretations, in addition to the interpretations for the DAC/Dl Class, shall be satisfied at the DAC/D2 Class.
The DAC/D2 class requires mdividual access controls; therefore, the granularity of user identification must enable the capabili~ to discern an individual user. That is, access control based upon group identi~ alone is insufflcient. To comply with the requirement, the DAC subsystem must either provide unique user identities through its own I&A mechanism or Mterface with an I&A mechanism that provides unique user identities. The DAC subsystem must be able to interface to an auditing mechanism that records data about access mediation events. The evaluation shall show that audit data is created and is available to the auditing mechanism.
The ability to propagate access rights to objects must be lirnited to authorized users. This additional feature is incorporated to limit access rights propagation. This distribution of privileges encompasses granting, reviewing, and revoking of access. The ability to grant the right to grant propagation of access will itself be limited to authorized users.
The DAC mechanism must deny all users access to objects when no explicit action has been taken by the authorized user to allow access.
"B3: Change: The enforcement mechanism (e.g., access control lists) shall allow users to specify and control sharing of those objects, and shall provide controls to limit propagation of access rights. These access controls shall be capable of specifying, for each named object, a list of named individuals and a list of groups of named individuals with their respective modes of access to that object."
"Add: Furtherrnore, for each such named object, it shall be possible to specify a list of named individuals and a list of groups of named individuals for which no access to the object is to be given."
The following interpretation, in addition to the interpretations and
requirements for the DAC/D2 class, shall be satisfied for the DACID3 class.
The DAC subsystem shan anow users to specify the list of individuals or groups of individuals who can access each object. The list shan additionally specify the mode(s) of access that is anowed each user or group. This implies that access control lists associated with each object is the only acceptable mechanism to satisfy the DAC/D3 requirement.
DAC subsystems must comply with an of the assurance requirements for their given class as indicated below. The interpretations for these assurance requirements are contained in Section 3.
Subsystems at the DAC/Dl class must comply with:
Subsystems at the DAC/D2 and DAC/D3 classes must comply with:
DAC subsystems must meet the documentation requirements listed below for their target rating class. The interpretations for these documentation requirements are contained in Section 4.
Subsystems at the DAC/Dl class must comply with:
Subsystems at the DAC/D2 and DAC/D3 classes must comply with:
Object reuse subsystems clear storage objects to prevent subjects from scavenging data from storage objects which have been previously used.
Object reuse can be used to prevent information scavenging by erasing information residue contained in previously used storage objects that have been released by the storage management system. Object reuse subsystems are most effective in environments where some security policy is implemented on the system.
To prevent scavenging of information from previously used storage objects, object reuse subsystems must be fully integrable with the operating system of the protected system. The object reuse subsystem must perform its function for all reusable storage objects on the protected system (i.e., main memory, disk storage, tape storage, I/O buffers, etc.).
Object reuse subsystems must be interfaced with the protected system in such a way that they are tamperproof and always invoked.
Subsystems which implement object reuse must comply with all of the TCSEC requirements as outlined below for features, assurances, and documentation. Compliance with these requirements will show that the subsystem can enforce object reuse adequately to receive an OR/D2 rating for object reuse.
As a part of the evaluation, the subsystem vendor shall set up the subsystem in a typical functional connguration for security testing. This will show that the subsystem interfaces correctly with the protected system to meet all of the feature requirements in this section and all of the assurance and documentation requirements in Sections 3 and 4. It will also show that the subsystem can be integrated into a larger system environment.
The interpretations for applying the feature requirements of object reuse subsystems are explained in the subsequent interpretations section. The application of the assurance requirements listed below is explained in Sections 3 and 4, respectively.
"C2: New: all authorizations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system."
In the TCSEC quote, "TCB" is interpreted to mean "protected system". Otherwise, this requirement applies as stated. The object reuse subsystem shall perform its function for all storage objects on the protected system that are accessible to users.
Object reuse subsystems must assure that no previously used storage objects (e.g., message buffers, page frames, disk sectors, magnetic tape, memory registers, etc.) can be used to scavenge residual information. Information remaining in previously used storage objects can be destroyed by overwriting it with meaningless or unintelligible bit patterns. An alternative way of approaching the problem is to deny read access to previously used storage objects until the user who has just acquired them has overwritten them with his own data.
Object reuse subsystems do not equate to systems used to eliminate magnetic remnance.
Object reuse subsystems must comply with all of the assurance requirements shown below for the D2 class. The interpretations for these assurance requirements for Object Reuse subsystems are contained in Section 3.
Object reuse subsystems must meet the documentation requirements shown below for the D2 class. The interpretations for these documentation requirements are contained in Section 4.
This subsystem provides the authenticated identification of a user seeking to gain access to any resources under the control of the protected system.
The I&A subsystem provides an authenticated user identification needed to provide accountability for and control access to the protected system. The granularity of user identification is determined by the requirements in this interpretation. The granularity increases from group identification at I&A/Dl to individual identification at I&A/D2.
The requirement is to be able to accurately authenticate the claimed identity of a user. The I&A subsystem must determine whether a user is authorized to use the protected system. For all authorized users, the I&A subsystem communicates the identity of the user to the protected system. This identity can then be used by the protected system or other subsystems to provide accountability for use of the system and access controls to protected objects on the system. To be effective and to protect the authentication data it uses, the I&A subsystem must be tamperproof and always invoked.
At I&A/D2, it is important that all uses of the I&A subsystem be recorded in an audit trail. The auditing of these actions may be performed entirely by the auditing mechanism on the I&A subsystem, or through an interface with an auditing mechanism in the protected system or another subsystem.
Subsystems which are designed to implement I&A must comply with all of the TCSEC requirements outlined below for features, assurances, and documentation. Compliance with these requirements will assure that the subsystem can enforce, either wholly or in part, a specific I&A policy. As a part of the evaluation, the subsystem vendor shall set up the subsystem in a typical functional configuration for security testing. This will show that the subsystem interfaces correctly with the protected system to meet all of the feature requirements in this section and all of the assurance and documentation requirements in Sections 3 and 4. It will also show that the subsystem can be integrated into a larger system environment.
The interetations for applying the feature requirements to I&A subsystems are explained in the subsequent interpretations sections. The application of the assurance requirements and documentation requirements listed in the next section is explained in Sections 3 and 4, respectively.
"Cl: New: The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the - TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user."
The I&A subsystem shall require users to identify themselves to it before beginning to perforrn any other actions that the system is expected to mediate. Furthermore, the I&A subsystem shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The I&A subsystem shall protect authentication data so that it cannot be accessed by any unauthorized user.
The I&A subsystem shall, at a minimum, identify and authenticate system users. At I&A/Dl, users need not be individually identified.
Identification and Authentication must be based on at least a two-step process, which is derived from a combination of something the user possesses (e.g., smart card, magnetic stripe card), some physical attribute about the user (e.g., fingerprint, voiceprint), something the user knows (e.g., password, passphrase). The claimed identification of a user must be authenticated by an explicit action of the user. It is not acceptable for one step to be used as both identification and authentication. The claimed identity can be public. The measure used for authentication must be resistant to forging, guessing, and fabricating.
The I&A subsystem must interface to the protected system in such a way that it can reliably pass authenticated user identities to the protected system. The evaluation shall show that authenticated user identities can be passed to the protected system.
"C2: Add: The TCB shan be able to enforce individual accountability by providing the capability to uniqueb identify each individual ADP system user. The TCB shall also ; provide the capabmty of associa~ ~is identity ~nth an auditable actiol~ taken by ; that indindual."
The following interpretations, in addition to those interpretations for I&A/Dl, shall be satisfied at the I&A/D2 Class.
In the TCSEC quote, "TCB" is interpreted to mean "I&A subsystem." The I&A subsystem shall pass to the protected system a unique identifier for each individual.
The I&A subsystem shall be able to uniquely identify each individual user. This includes the ability to identify individual members within an authorized user group and the ability to identify specific system users such as operators, system administrators, etc.
The I&A subsystem shall provide for the audit logging of security-relevant I&A events. For I&A, the origin of the request (e.g., terminal ID, etc.), the date and time of the event, user ID (to the extent recorded), type of event, and the success or failure of the event shall be recorded. The I&A subsystem may meet this requirement either through its own auditing mechanism or by providing an interface for passing the necessary data to another auditing mechanism. ,
The intent of this requirement is for the I&A subsystem to supply a unique identity for each user to the protected system. The subsystem supplies a unique user identity which may or may not be used by an auditing mechanism. This auditing support is : required to maintain consistency with the C2 level of trust as defined by the TCSEC.
I&A subsystems must comply with all of the assurance requirements listed below for their given class. The interpretations for these assurance requirements to I&A subsystems are contained in Section 3.
Subsystems at the I&A/Dl class shall comply with:
Subsystems at the I&A/D2 class shall comply with:
I&A subsystems must meet the documentation requirements listed below for their target rating class. The interpretations for these documentation requirements are contained in Section 4.
Subsystems at the I&A/Dl class shall comply with:
Subsystems at the I&A/D2 class shall comply with:
Accountability is partly achieved through auditing. That is, data from security- relevant events is captured and passed to the audit mechanism to be recorded for use in detecting possible security breaches and providing a trace to the party responsible.
The requirement is to be able to record security-relevant events in a manner that will allow detection and/or after-the-fact investigations to trace security violations to the responsible party.
An auditing subsystem must be capable of recording all security-relevant actions -i - that take place throughout the computer system. To accomplish this goal, it must integrate itself into the mechanisms that mediate access and perform user identification and authentication, and capture data about the events they control. Additionally, an audit subsystem must be interfaced with the protected system in such a way that it is tamperproof and always invoked.
The auditing subsystem must be provided all of the necessary data associated with actions as specified in Section 2.4.3. The necessary data includes the unique identity of the user that is responsible for each action. This implies that an auditing subsystem must be augmented by an identification and authentication mechanism either within the subsystem itself or elsewhere on the system.
Subsystems which are designed to implement audit data collection and control functions for a host must comply with all of the TCSEC requirements as outlined below for features, assurances and documentatioi. Compliance with these features will assure that the subsystem, through its integration, can detect or generate the relevant audit data or can record all relevant audit data passed to it by the host or other subsystems.
As a part of the evaluation, the subsystem vendor shall set up the subsystem in a typical functional configuration for security testing. This will show that the subsystem interfaces correctly with the protected system to meet all of the feature requirements in this section and all of the assurance and documentation requirements in Sections 3 and 4. It will also show that the subsystem can be integrated into a larger system environrnent.
The interpretations for applying the feature requirements to auditing subsystems are explained in the subsequent interpretations sections. The application of the assurance requirements and documentation requirements is explained in Sections 3 and 4, respectively.
"C2: New: The TCB shan be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shan be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms introduction of objects into a user's address space (e.g., file open, program ~. initiation), deletion of objects, actions taken by computer operators and system administrators and/or system security officers, and other security relevant events. For each recorded event, the audit record shall identify: date and time of the event, ~ user, type of event, and success or failure of the event. For identincation/authentication events the origin of request (e.g., terminal ID) shan be - included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object. rne ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity."
The following subsections provide interpretations of the TCSEC requirements which shall be satisfied by auditing subsystems at AUD/D2.
The auditing subsystem shall create and manage the audit trail of security-relevant " events in the system. If the other portions of the system are unable to capture data about such events, the auditiug subsystem shaU coutain the necessary interfaces into the system to perform this function. Alternatively, the auditing subsystem might simply accept and store data about events if the other portions of the system are capable of creating such data and passing them on.
To meet this requirement, it is sufficient that the audit subsystem provides a set of calls which permit the system to supply the needed data as parameters that the audit subsystem puts into a data structure and routes to audit storage (or transmits securely to an audit logger).
It shall be demonstrated that the audit data is protected from unauthorized modification. This protection will be provided either by the subsystem itself or by its integration with the protected system.
The auditing subsystem might store the audit data in a dedicated data storage area that cannot be accessed by any subject on the system except the auditing subsystem itself and the system security officer (or system administrator through the auditing subsystem. Or, if the protected system has adequate access control facilities, the audit data might be stored on the protected system, using its access control mechanisms for protection.
The audit mechanism, auditing parameters, and the audit data storage media shall be protected to ensure access is allowed only to authorized individuals. Individuals who are authorized to access the audit data shall be able to gain access only through the auditing subsystem.
This interpretation assumes that discretionary access controls or physical controls will be in place to keep unauthorized individuals from gaining access to the audit data.
Data about all security relevant events must be recorded. The other portions of the system shall be able to pass data concerning these events to the auditing subsystem, or the auditing subsystem shall have the necessary code integrated into the other portions of the system to pass the data to the collection point.
All of the specific information enumerated in the TCSEC quote shall be captured for each recorded event. Of particular concern, is the recording of the user identity with each recorded event.
This implies that the audit subsystem must be able to acquire user identities from an I&A mechanism, which may be provided on the audit subsystem itself, on the protected system, or in a separate I&A subsystem. Whichever is the case, the evaluation shall show that the audit subsystem has a working interface to an I&A mechanism.
The auditing subsystem shall have the ability to perform selection of audit data based on individual users.
This requirement can be satisfied by pre-selection of the information to be recorded in the audit log (selective logging) and/or by post-selection of information to be extracted from the audit log (selective reduction). The reduction of the audit log must be able to show all of the security-relevant actions performed by any specified individual. The intent of selective logging is to reduce the volume of audit data to be recorded by only recording audit data for those specific individuals that the systcm security officer (or system administrator) specifies. The intent of selective reduction is to reduce the large volume of audit data into a collection of intelligible information which can be more efficiently used by the system administrator.
"B3: Add: The TCB shal~ contain a mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent violation of security policy. This mechanism shall be able to immediately notify the security administrator when thresholds are exceeded and, if the occurrence or accumulation of these securib relevant events continues, the system shall take the least disruptive action to terminate the event."
Audit subsystems, whether being evaluated at AUD/D2 or AUD/D3, must comply with the assurance requirements listed below for the D2 class. The interpretations for these assurance requirements are contained in Section 3.
Audit subsystems, whether being evaluated at AUD/D2 or AUD/D3, must meet the documentation requirements listed below for the D2 class. The interpretations for these documentation requirements are contained in Section 4.
Rated subsystems must provide correct and accurate operations. Assurance must be provided that correct implementation and operation of the subsystem's function exist throughout the subsystem's life cycle. The objective in applying these assurance requirements is to develop confidence that the subsystem has been implemented correctly and that it is protected from tampering and circumvention.
The requirement is that the subsystem must contain hardware/software mechanisms that can be independently evaluated through a combination of inspection and testing to provide sufficient assurance that the subsystem features enforce or support the functions for which the subsystem is intended. To receive a rating, a subsystem must meet the assurance requirements at the same level of trust as it has I met the requirements for functionality. The assurances must be applied to the different types of subsystems as described in the previous sections.
Subsystem architecture evaluation is designed to provide operational assurances with regard to the design and implementation of the protection mechanisms of the subsystem and its interfaces to the host/host TCB.
"Cl: New: The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controned by the TCB may be a defined subset of the subjects and objects in the ADP system."
This requirement applies to all subsystems evaluated at all classes, regardless of the function(s) they perform. There are two specific elements of this requirement: Execution Domain Protection and Defined Subsets.
Protection of the subsystem's mechanism and data from external interference or tampering must be provided. The code and data of the subsystem may be protected' through physical protection (e.g., by the subsystem's dedicated hardware base) or by
logical isolation (e.g., using the protected system's domain mechanism).
The subsystem may be contained entirely on its own hardware base which must protect the operational elements of the mechanisms. Alternatively, all or a portion of the subsystem may be implemented on the hardware of the host, in which case the host system's architecture must protect this portion from external interference or tampering.
I&A subsystems, when used for the system's I&A, define the subset of subjects under the control of the system's TCB. DAC subsystems may protect a subset of the total collection of objects on the protected system.
"C2: Add: The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements."
In the TCSEC quote, "TCB" is interpreted to mean "subsystem".
This requirement applies to all subsystems evaluated at the D2 class or the D3 class. The following interpretations explain how this requirement applies to specific functions performed by subsystems.
All named objects which are in the defined subset of protected objects shall be isolated such that the DAC subsystem mediates all access to those objects.
The system's architecture shall ensure that the auditing mechanism cannot be bypassed by any subjects accessing those objects under the system's control.
The notion of subsetting objects is not applicable to object reuse subsystems. Object reuse subsystems shall perform their function for all storage objects on the protected system that are accessible to users.
This requirement applies to I&A subsystems. Authentication data shall be protected from unauthorized access. Access to the authentication data shall also be recorded in the audit trail.
Subsystem integrity evaluation is designed to provide operational assurances with regard to the correct operation of the protection mechanisms of the subsystem and its interfaces to the protected system.
"Cl: New: Hardware and/or software features shan be provided that can be used to periodicany ~aUdate the correct operation of the on site hardware and firmware elements of the TCB."
In the TCSEC quote, "TCB" is interpreted to mean "subsystem".
This requirement applies to an subsystems evaluated at any class, regardless of the functions they perform.
The capability must exist to validate the correct operation of all hardware and firrnware elements of the system regardless of whether they reside within the subsystem, the protected system, or other interfacing subsystems. If the hardware and/or firmware elements of the protected system or other interfacing subsystems play an integral role in the protection and/or correct operation of the subsystem, then they must comply with this requirement as though they were part of the subsystem.
There are no additional requirements for System Integrity at D2.
Testing, as part of the evaluation, is designed to provide life cycle assurances with regard to the integrity of the subsystem. Further, testing provides additional assurances regarding the correct operation of the protection mechanisms of the subsystem and the subsystem's interfaces to the protected system. These mechanisms and their interfaces to the protected system, are termed the Subsystem's Security- Relevant Portion (SRP).
"Cl: New: The securib mechanisms of the ADP system shan be tested and found to work as claimed in the system documentation. Testing shan be done to assure that there are no ob~ious ways for an unauthorized wer to bypass or otherwise defeat the security protection mechanisms of the TCB. (See the Security Testing Guidelines.) "
This requirement applies to all subsystems evaluated at any class, regardless of the function(s) they perform. In the TCSEC quote, "TCB" is interpreted to mean subsystem.
The subsystem's SRP shall be tested and found to work as claimed in the subsystem's documentation. The addition of a subsystem to a protected system shall not cause obvious flaws to the resulting system. _
Test results shall show that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the subsystem's SRP.
Security testing is a very important part of subsystem evaluations. It is essential that the subsystem be demonstrated to operate securely.
"C2: Add: Testing shan also include a search for obvious flaws that would anow nolation of resource isolation, or that would permit unauthorized access to the audit or authentication data."
This requirement applies to the testing of the SRP of any subsystem evaluated at the D2 class or the D3 class.
The requirement as written in the TCSEC quote is directly applicable. This requirement is to ensure that subsystems at D2 cannot be circumvented or tampered with.
Documentation shan produce evidence that the subsystem can and does provide specified security features. The evaluation will focus on the completeness of this evidence through inspection of documentation structure and content and through a mapping of the documentation to the subsystem's implementation and its operation.
"Cl: New: A single summaIy, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another."
All subsystems shall meet this requirement in that they shall describe the protection mechanisms provided by the subsystem.
It is recognized that some subsystems may be partially or completely transparent to the general user. In such cases, this requirement can be met by documenting the functions the subsystem performs so users will be aware of what the subsystem does. Other subsystems which have a very limited user interface may not need to be accompanied by more than a pocketsize card available to every user. In short, the documentation required to meet this requirement need not be elaborate, but must be clear and comprehenslve.
There are no additional requirements at the D2 class.
"Cl: New: A manual addressed to the ADP system admmistrator shan present cautions about functions and prvileges that should be controlled when running a secure facility."
This requirement applies to all subsystems in that the manual shall present cautions about functions and privileges provided by the subsystem. Further, this manual shall present specific and precise direction for effectively integrating the subsystem into the overall system.
"C2: Add: The procedures for examining and maintaMing the audit files as well as the detailed audit record structure for each type of audit event shall be given."
This requirement applies directly to all auditing subsystems and to other subsystems that maintain their own audit data concerning events that happen under their control. For subsystems that create audit data and pass it to an external auditing collection and maintenance facility, the audit record structure shall be documented; however, the procedures for examination and maintenance of audit files may be left to the external auditing facility.
"Cl: New: The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the securib mechanisms were tested, and results of the security mechanisms' functional testing."
The document shall explain the exact configuration used for security testing. All mechanisms supplying the required supporting functions shall be identified. All interfaces between the subsystem being tested, the protected system, and other subsystems shall be described.
There are no additional requirements at the D2 class.
"Cl: New: Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described. "
This requirement applies directly to all subsystems. Specifically, the design documentation shall state what types of threats the subsystem is designed to protect against (e.g., casual browsing, determined attacks, accidents). This documentation shan show how the protection philosophy is translated into the subsystem's SRP. Design documentation shan also specify how the subsystem is to interact with the protected system and other subsystems to provide a complete computer security system. If the SRP is modularized, the interfaces between these modules shall be described.
There are no additional requirements for Design Documentation at the D2 class.
Accreditation - The offlcial authorization that is granted to an ADP system to process sensitive information in its operational environment, based upon , comprehensive security evaluation of the system's hardware, firmware, and software . security design, configuration and implementation of the other system procedural, administrative, physical, TEMPEST, personnel, and comrnunications controls.
Audit - The procedure of capturing, storing, maintaining, and managing data concerning security-relevant events that occur on a computer system. The data recorded are intended for use in detecting security violations and tracing thosc violations to the responsible individual.
Audit trail - A set of records that collectively provide documentary evidence of processing users to aid in tracing from original transactions forward to related records and reports, and/or backwards from records and reports to their component source transactions.
Authenticate - To establish the validity of a claimed identity.
Authorization - Permission which establishes right to access information.
Certification evaluation - The technical evaluation of a system's security features, made as part of and in support of the approval/accreditation process, that establishes " the extent to which a particular computer system's design and implementation meet a set of specified security requirements.
Computer security subsystem - Hardware, firmware and/or software which are added to a computer system to enhance the security of the overall system.
Group user - A user of a computer system whose system identification is the name of a defined group of users on that system.
Individual user - A user of a computer system whose system identification is unique, in that no other user on that system has that same identification.
Named object - An object which is directly manipulable at the TCB interface. Thc object must have meaning to more than one process.
Product evaluation - Thc technical evaluation of a product's security features to determine the level of trust that can be placed in that product as defined by thc NCSC. evaluation criteria for that type of product (e.g., operating system, database management system, computer network, computer security subsystem). Product evaluations do not consider the application of the product in the evaluation.
Protected system - The system being protected. In the context of computer security subsystems, a stand-alone computer system or a computer network to which a subsystem is attached to pronde some computer security function.
Security Relevant Portion (SRP) - The protection-critical mechanism of the subsystem, the subsystem's interface(s) to the protected system, and interfaces to the mechanisms providing required supporting functions. For most cases, the SRP encompasses the entire subsystem.
Subsystem - See "computer security subsystem."
System - The combination of the protected system and the computer security subsystem.
*U.S. GOVERNMENT PRINTING OFFICE: 1989-225-703