NCSC-TG-005 Library No. S228,526 Version 1 FOREWORD This publication is issued by the National Computer Security Center (NCSC) as part of its program to promulgate technical computer security guidelines. The interpretations extend the evaluation classes of the Trusted Systems Evalua- tion Criteria (DOD 5200.28-STD) to trusted network systems and components. 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 Trusted Network Interpreta- tion in several network evaluations. In addition, the NCSC will conduct a series of tutorials and workshops to educate the community on the details of the Trusted Network Interpretation and receive feedback. After this trial period, necessary changes to the document will be made and a revised version issued. Workshops and tutorials will be open to any member of the network security community interested in providing feed- back. Anyone wishing more information, or wishing to pro- vide comments on the usefulness or correctness of the Trusted Network Interpretation may contact: Chief, Techni- cal Guidelines Division, National Computer Security Center, Ft. George G. Meade, MD 20755-6000, ATTN: C11. The tele- phone number is (301) 859-4452. ______________________________________________ PATRICK R. GALLAGHER, JR. 31 July 1987 Director National Computer Security Center ACKNOWLEDGMENT ______________ Acknowledgment is extended to the members of the Work- ing Group who produced this Interpretation. Members were: Alfred Arsenault, National Computer Security Center (Chair); Dr. Roger Schell, Gemini Computers; Stephen Walker, Trusted Information Systems; Dr. Marshall Abrams, MITRE; Dr. Jonathan Millen, MITRE; Leonard LaPadula, MITRE; Robert Morris, NCSC; and Jack Moskowitz, NCSC. Also due ack- nowledgement for their many inputs to this interpretation are Steve Padilla and William Shockley, Gemini Computers. Introduction ____________ I.1. Scope _ _ _____ Part I of this document provides interpretations of the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) (DOD-5200.28-STD), for trusted computer/communications network systems. The specific secu- rity feature, the assurance requirements, and the rating structure of the TCSEC are extended to networks of computers ranging from isolated local area networks to wide-area internetwork systems. Part II of this document describes a number of addi- tional security services (e.g., communications integrity, denial of service, transmission security) that arise in con- junction with networks. Those services available in specific network offerings, while inappropriate for the rigorous evaluation applied to TCSEC related feature and assurance requirements, may receive qualitative ratings. The TCSEC related feature and assurance requirements, and the additional security services described herein are intended for the evaluation of trusted network systems designed to protect a range of sensitive information. As such, they require that physical, administrative, pro- cedural, and related protection measures adequate to the sensitivity of the information being handled are already in place. It is possible, and indeed common practice, to operate a network in a secure manner at a single system high sensitivity level without meeting any trust related feature or assurance requirements described herein. The full range of physical and administrative security measures appropriate to the highest sensitivity level of information on the net- work must be in place in order to operate a trusted network as described in this Interpretation. It is important to note that this Interpretation does not describe all the security requirements that may be imposed on a network. Depending upon the particular environment, there may be communications security (COMSEC), emanations security, physical security, and other measures required. An environmental evaluation process, such as that described in the ``Computer Security Requirements--Guidance for Applying the DoD TCSEC in Specific Environments'' (CSC- STD-003-85), can be used to determine the level of trust required by specific system environments. Similar analyses are applicable to networks evaluated under these Interpreta- tions. I.2. Purpose _ _ _______ As with the TCSEC itself, this Interpretation has been prepared for the following purposes: 1. To provide a standard to manufacturers as to what security features and assurance levels to build into their new and planned, commercial network products in order to provide widely available systems that satisfy trust requirements for sensitive applica- tions 2. To provide a metric by which to evaluate the degree of trust that can be placed in a given network sys- tem for processing sensitive information 3. To provide a basis for specifying security require- ments in acquisition specifications. With respect to the second purpose for development of the criteria, i.e., providing a security evaluation metric, evaluations can be delineated into two types: an evaluation can be performed on a network product from a perspective that excludes the application environment, or an evaluation can be done to assess whether appropriate security measures have been taken to permit the system to be used operation- ally in a specific environment. The former type of evalua- tion is done by the National Computer Security Center through the Commercial Product Evaluation Process. The latter type of evaluation, those done for the pur- pose of assessing a system's security attributes with respect to a specific operational mission, is known as a certification evaluation. It must be understood that the completion of a formal product evaluation does not consti- tute certification or accreditation for the system to be used in any specific application environment. On the con- trary, the evaluation report only provides a trusted network system's evaluation rating along with supporting data describing the product system's strengths and weaknesses from a computer security point of view. The system security certification and the formal approval/accreditation pro- cedure, done in accordance with the applicable policies of the issuing agencies, must still be followed before a net- work can be approved for use in processing or handling clas- sified information. Designated Approving Authorities (DAAs) remain ultimately responsible for specifying the security of systems they accredit. This Interpretation can be used directly and indirectly in the certification process. Along with applicable policy, it can be used directly as technical guidance for evaluation of the total system and for specifying system security and certification requirements for new acquisitions. Where a system being evaluated for certification employs a product that has undergone a Commercial Product Evaluation, reports from that process will be used as input to the certification evaluation. Technical data will be furnished to designers, evaluators, and the DAAs to support their needs for making decisions. The fundamental computer security requirements as defined in the TCSEC apply to this Interpretation. I.3. Background _ _ __________ The term ``sponsor'' is used throughout this document to represent the individual or entity responsible for presenting a component or network system for evaluation. The sponsor may be a manufacturer, vendor, architect, developer, program manager, or related entity. A network system is the entire collection of hardware, firmware, and software necessary to provide a desired func- tionality. A component is any part of a system that, taken by itself, provides all or a portion of the total functionality required of a system. A component is recursively defined to be an individual unit, not useful to further subdivide, or a collection of components up to and including the entire sys- tem. Because the term integrity has been used in various contexts to denote specific aspects of an overall issue, it is important for the reader to understand the context in which the term is used in this document. Within Part I, as in the TCSEC itself, the use of this term is limited to (1) the correct operation of NTCB hardware/firmware and (2) pro- tection against unauthorized modification of labels and data. Specifically, all NTCBs that support sensitivity labels (viz., Divisions A and B) must, as detailed in the Label Integrity section of the TCSEC, protect the labels that represent the sensitivity of information (contained in objects) and the corresponding authorizations of users (with subjects as surrogates). In addition, for network systems with a defined data integrity policy, the NTCB must control the accesses of users that modify information-. As part of the NTCB itself, such integrity policies will be supported by access control mechanisms based on the identity of indi- viduals (for discretionary integrity) and/or sensitivity levels (for mandatory integrity). In contrast, within Part II the term integrity relates to the mechanisms for informa- tion transfer between distinct components. This communica- tions integrity includes the issues for correctness of mes- sage transmission, authentication of source/destination, data/control/protocol communication field correctness and related areas. _________________________ - See, for example, K. J. Biba, Integrity Considera- _________ _________ tions for Secure Computer Systems, MTR-3153, The MITRE _____ ___ ______ ________ _______ Corporation, Bedford, MA, June 1975. In many network environments, encryption can play an essential role in protecting sensitive information. In Part I of this document, encryption is referenced as a basis for providing data and label integrity assurance. In Part II, encryption is described as a tool for protecting data from compromise or modification attacks. Encryption algorithms and their implementation are outside the scope of this docu- ment. This document was prepared from a DoD perspective and requires NSA approval relative to the use of encryption. In other contexts, alternate approval authority may exist. As with the TCSEC itself, this is a reference document and is not intended to be used as a tutorial. The reader is assumed to be familiar with the background literature on computer security and communications networks=. Part II assumes a familiarity with the terminology used within ISO Security Services documentation. _________________________ = See, for example, M. D. Abrams and H. J. Podell, Tutorial: Computer and Network Security, IEEE Computer ________ ________ ___ _______ ________ Society Press, 1987. * ISO 7498/Part 2 - Security Architecture, ISO / TC ___ ____ ____ _ ________ ____________ 97 / SC 21 / N1528 / WG 1 Ad hoc group on Security, Project 97.21.18, September 1986. I.3.1. Trusted Computer System Evaluation Criteria _ _ _ _______ ________ ______ __________ ________ The DoD TCSEC was published in December 1985 to provide a means of evaluating specific security features and assurance requirements available in ``trusted commercially available automatic data processing (ADP) systems,'' referred to in this document as Automated Information System (AIS). The rating scale of the TCSEC extends from a rating which represents a minimally useful level of trust to one for ``state of the art'' features and assurance measures. These technical criteria guide system builders and evalua- tors in determining the level of trust required for specific systems. When combined with environmental guidelines, minimum security protection requirements, and appropriate accreditation decisions for specific installations can be determined. The philosophy of protection embodied in the TCSEC requires that the access of subjects (i.e., human users or processes acting on their behalf) to objects (i.e., containers of sensitive information) be mediated in accor- dance with an explicit and well defined security policy. In order to ensure strict compatibility between TCSEC evaluated AIS and networks and their components, and to avoid the possible evolution of incompatible evaluation cri- teria, Part I of this document has been specifically prepared as an INTERPRETATION of the TCSEC for networks. It is based entirely on the principles of the TCSEC, uses all TCSEC basic definitions, and introduces new concepts only where essential to understanding the TCSEC in a network con- text. Unless otherwise stated, the TCSEC requirements apply as written. The approach of interpreting the TCSEC for net- works in general has already been successfully employed in a number of specific complex network and AIS applications. There are several security policy models that may be used with the reference monitor concept. The Bell-LaPadula model is commonly used but is not mandated. Similarly for integrity policy, models such as Biba have been proposed but are not mandated. For this network interpretation, no specific access control policy is required; however, it is necessary that either a secrecy policy, an integrity policy, or both be specified for enforcement by the reference moni- tor. In the context of network systems, there are a number of additional security services that do not normally arise in individual AIS, and are not appropriate to the detailed feature and assurance evaluation prescribed by the TCSEC. These security services, which may or may not be available in specific network offerings, include provisions for com- munications security, denial of service, transmission secu- rity, and supportive primitives, such as encryption mechan- isms and protocols. Part II of this document describes these services and provides a qualitative means of evaluat- ing their effectiveness when provided. Evaluation of Part II offered services is dependent upon the results of the system's Part I evaluation or component's Appendix A evaluation. A Part II evaluation rating of good in a component or system which has a low Part I trust rating is of limited value. The sponsor must iden- tify which security services are offered by a system or com- ponent for evaluation against Part II. The evaluators will normally give a none, minimum, fair or good rating for those services offered. In some cases, a rating of present is all that can be given or a quantitative measure of strength may be used as the basis for rating. A not applicable rating will be given for services not offered by the product. Part II services may be provided by mechanisms outside the NTCB. I.3.2. Two Network Views _ _ _ ___ _______ _____ DoD Directive 5200.28 (and similar policies elsewhere in government) establishes the concept of a DAA, an indivi- dual who is responsible for approving the use of an AIS for processing classified information. For stand-alone AIS, this approval process and the technical advisory role to the DAA provided by the TCSEC are well understood. The same approval process applies to networks of AIS and plays a key role in determining how and when networks can be evaluated using this Interpretation. Depending upon the operational and technical charac- teristics of the environment in which a network exists, either of two views for accreditation and evaluation pur- poses applies: as a collection of two or more intercon- nected separately accredited AIS or as a single unified sys- tem the security accreditation of which is the responsibil- ity of a single authority. The security feature and assurance requirements of a specified network, and hence its suitability for evaluation under this Interpretation, is greatly impacted by which view of the network is appropriate. I.3.2.1. Interconnected Accredited AIS View _ _ _ _ ______________ __________ ___ ____ The interconnected accredited AIS view is an opera- tional perspective that recognizes that parts of the network may be independently created, managed, and accredited. Where different accrediting jurisdictions are involved, the joint approval process is required, describing the handling practices and classification levels that will be exchanged between the components involved. Interconnected accredited AIS consist of multiple sys- tems (some of which may be trusted) that have been indepen- dently assigned operational sensitivity ranges (the highest and lowest sensitivity levels of information that may be simultaneously processed on that system). In this view, the individual AIS may be thought of as ``devices'' with which neighboring systems can send and receive information. Each AIS is accredited to handle sensitive information at a sin- gle level or over a range between a minimum and maximum level. The range of sensitive information that may be exchanged between two such AIS is a range, agreed upon by each system's approving authorities, which cannot exceed the maximum sensitivity levels in common between the two sys- tems. Because of the complex structure of a network consist- ing of interconnected accredited AIS, it may not be practi- cal to evaluate such a network using this Interpretation or to assign it a trusted system rating. In this case, the accreditor is forced to accept the risk of assessing the security of the network without the benefit of an evaluation against the principles of the TCSEC as interpreted in Part I of the document. Appendix C describes the rules for con- necting separately accredited AIS and the circumstances in which these rules apply. I.3.2.2. Single Trusted System View _ _ _ _ ______ _______ ______ ____ The policy enforcement by trusted components in a ``single trusted system'' exhibits a common level of trust throughout. A single trusted system is accredited as a sin- gle entity by a single accrediting authority. (In certain circumstances where a system will process information from multiple sensitive sources, more then one accrediting authority may be involved, but their responsibility will be for accrediting the whole system as a single entity for use processing the information for which they have authority.) Networks such as these can be evaluated against this Interpretation and given a rating compatible with trusted AIS evaluated by the TCSEC itself. A ``single trusted system'' network implements a refer- ence monitor to enforce the access of subjects to objects in accordance with an explicit and well defined network secu- rity policy. The network has a single trusted computing base, referred to as the Network Trusted Computing Base (NTCB), which is partitioned (see section I.4.2) among the network components in a manner that ensures the overall net- work security policy is enforced by the network as a whole. Every component that is trusted must enforce a component-level security policy that may contain elements of the overall network security policy. The sum of all component-level security policies must be shown to enforce the overall network security policy. There is no requirement that every component in the network have an NTCB partition nor that any such partition comprise a complete TCB (e.g., a network component could be dedicated to supporting the audit function and implement only that portion of the NTCB). Interaction among NTCB par- titions shall be via communications channels, operating at either single or multiple levels as appropriate. The net- work security architect must identify how the NTCB is parti- tioned and how all the trusted system requirements are satisfied. A given component that does not enforce the full imple- mentation of all polices (i.e., mandatory access control, discretionary access control, identification/ authentication and audit) must be evaluated as a component as specified in Appendix A. For example, a network architecture that does not operate above Level 3 of the ISO protocol model and typ- ically does not enforce discretionary access control must be evaluated as a component under Appendix A and not as a full system. I.3.2.2.1. Connection-Oriented Abstraction _ _ _ _ _ __________ ________ ___________ In many networking environments, the overall network security policy includes controlling the establishment of authorized connections across the network. The access con- trol mediation performed by the components of these networks enforces the establishment of connections between host com- puters on the network in accordance with some form of authorized connection list. While a connection-oriented policy may be suitable from an overall network perspective, specifying such a policy in terms of component level abstractions may be difficult but is required in order to evaluate the network. Individual trusted network components may employ a local mechanism to enforce mediation only between local sub- jects and objects, as described in the TCSEC. Some of these components may have no direct involvement with the enforce- ment of network connections. Others, however, will have an additional higher level network connection enforcement role. This higher level connection-oriented abstraction may be enforced solely within an individual component or may be distributed across many components (e.g., in the end-to-end encryption case, cryptographic front end devices enforce the network connection authorization decisions made by an access control/key management center.) With the connection-oriented abstraction, the role of the network as a whole in controlling information flow may be more easily understood, but there may be no simple way to extend this abstraction to the reference monitor require- ments of individual components in the network. The overall network security policy must be decomposed into policy ele- ments that are allocated to appropriate components and used as the basis for security policy models for these com- ponents. The reference monitor subject/object definitions as given in the TCSEC represent the fundamental security policy enforcement at the individual component level but may not directly describe the overall network security policy issues such as the network's connection policy. The connection- oriented abstraction may be essential to understanding the overall network security policy. The network architecture must demonstrate the linkage between the connection-oriented abstraction and its realization in the individual components of the network. I.3.2.2.2. Subjects and Objects _ _ _ _ _ ________ ___ _______ For purposes of this trusted network interpretation, the terms ``subject'' and ``object'' are defined as in the TCSEC. The subjects of a trusted network commonly fall into two classes: those that serve as direct surrogates for a user (where ``user'' is synonymous with ``human being''), and ``internal'' subjects that provide services for other subjects--typically representing software process rather than being made part of each user surrogate subject. There is a set of TCSEC requirements that are directed at users, rather than subjects. In the network context, services used to facilitate communications between users and AIS (e.g., protocol handlers) are usually provided by inter- nal subjects. Some components that provide only communica- tions facilitating services have only internal subjects. Examples of ``single trusted system'' networks or com- ponents could include- packet-switched communications sub- networks (as found in the Defense Data Network (DDN), end- to-end (or host-to-host) encryption systems (such as used in Blacker or ANSI X9.17 implementations), application level networks or closed user community systems (such as the Inter Service/Agency Automated Message Processing Exchange [I S/A AMPE] and SACDIN Programs), local area networks, digital PABX systems, private switched networks (such as circuit- switched telecommunications systems), future Integrated Ser- vices Digital Network (ISDN) implementations, and a Virtual Machine Monitor (VMM) on a single computer when analyzed as a network. I.4. Evaluation of Networks _ _ __________ __ ________ The TCSEC provides a means for evaluating the trustworthiness of a system and assigning an evaluation class based on its technical properties - independent of the particular use for or the sensitivity of information being processed on the system. In this Interpretation, a network as a whole with its various interconnected components is recognized as a special instance of a trusted system. The designer of a trusted system is unconstrained by the TCSEC on design and implementation choices as long as for the _________________________ - Examples are employed throughout this document to clarify the concepts presented. The naming of an exam- ple implies no judgement of the product or system named nor on its suitability for any particular purpose. system as a whole there is a clearly distinguished TCB with a definitive protection domain boundary. The features and assurance measures provided within the TCB perimeter will determine the evaluation class. The network must be viewed as PARTITIONED into a set of interconnected components, where each component may have an independent ``NTCB parti- tion.'' All interaction between such trusted components must be via ``communication channels or I/O devices'' as defined by the TCSEC. For Division A and B networks these will generally be ``multilevel devices.'' I.4.1. Network Security Architecture and Design _ _ _ _______ ________ ____________ ___ ______ Any network evaluated under this Interpretation must possess a coherent Network Security Architecture and Design. (Interconnection of components that do not adhere to such a Network Security Architecture is addressed in the Intercon- nection Rules, Appendix C.) The Network Security Architec- ture must address the security-relevant policies, objec- tives, and protocols. The Network Security Design specifies the interfaces and services that must be incorporated into the network so that it can be evaluated as a trusted entity. There may be multiple designs that conform to the same architecture but which are more or less incompatible and non-interoperable (except through the Interconnection Rules). Security related mechanisms that require coopera- tion among components are specified in the design in terms of their visible interfaces; mechanisms which have no visi- ble interfaces are not specified in this document but are left as implementation decisions. The Network Security Architecture and Design must be available from the network sponsor before evaluation of the network, or any component, can be undertaken. The Network Security Architecture and Design must be sufficiently com- plete, unambiguous, and free from obvious flaws to permit the construction or assembly of a trusted network based on the structure it specifies. When a component is being designed or presented for evaluation, or when a network assembled from components is assembled or presented for evaluation, there must be a priori evidence that the Network Security Architecture and Design are satisfied. That is, the components are assembl- able into a network that conforms in every way with the Net- work Security Architecture and Design to produce a physical realization which is trusted to the extent that its evalua- tion indicates. In order for a trusted network to be constructed from components that can be built independently, the Network Security Architecture and Design must completely and unambi- guously define the security functionality of components as well as the interfaces between or among components. The Network Security Architecture and Design must be evaluated to determine that a network constructed to its specifica- tions will in fact be trusted, that is, it will be evaluatable under these Interpretations. I.4.2. The Partitioned NTCB _ _ _ ___ ___________ ____ Like a stand-alone system, the network as a whole possesses a single TCB, referred to as the NTCB, consisting of the totality of security-relevant portions of the net- work. But, unlike a stand-alone system, the design and evaluation of the network rests on an understanding of how the security mechanisms are distributed and allocated to various components, in such a way that the security policy is supported reliably in spite of (1) the vulnerability of the communication paths and (2) the concurrent, asynchronous operation of the network components. Some distributed systems have reliable, protected com- munication paths and thus satisfy only the first charac- teristic of a network: the division into concurrently operating, communicating processing components. Although certain interpretations in this Interpretation will not apply to them, it may be beneficial to employ this Interpre- tation to evaluate them, and to take advantage of the interpretations relating to component properties and inter- faces. An NTCB that is distributed over a number of network components is referred to as partitioned, and that part of the NTCB residing in a given component is referred to as an NTCB partition. A network host may possess a TCB that has previously been evaluated as a stand-alone system. Such a TCB does not necessarily coincide with the NTCB partition in the host, in the sense of having the same security perime- ter. Whether it does or not depends on whether the security policy for which the host TCB was evaluated coincides with the network security policy, to the extent that it is allo- cated to that host. Even when a network host has a TCB that has been previ- ously evaluated at a given class, and the host's TCB coin- cides with the host's NTCB partition, there is still no a priori relationship between the evaluation class of the host and the evaluation class of the network. Some examples will be given below to illustrate this point. To evaluate a network at a given class, each require- ment in Part I for that class must be satisfied by the net- work as a whole. It is also necessary to understand how each requirement is allocated among the network's com- ponents. Some components, such as the hosts, may satisfy the entire security policy in isolation; others, such as packet switches and access control centers, may have more specialized functions that satisfy only a subset of the net- work security policy. In addition, distinct subsets of the network security policy may be allocated to different net- work components. Forcing every component to satisfy a specific Part I requirement is neither necessary nor sufficient to ensure that the network as a whole meets that requirement. To show that it is not sufficient, consider two trusted multilevel AIS that export and import labeled information to and from each other over a direct connection. Both satisfy the Label Integrity requirement that a sensitivity label be accurately and unambiguously associated with exported data. If they were to have different, incompatible label encodings for the same sensitive information, the network as a whole would fail to satisfy the label integrity requirement. As a result, these Interpretations require at the B1 level and above that there be uniform labeling of sensitive informa- tion throughout the network. To show that it is not necessary, consider the Manda- tory Access Control requirement that at least two sensi- tivity levels be supported. Suppose that the network con- sists of a number of untrusted hosts that are incapable of maintaining labels and are operating at different levels in a single-level mode. If they are interconnected through suitable multilevel interface units, the network as a whole can support the ``two or more levels'' requirement. The allocation of a requirement to a component does not simply mean that the component satisfies the requirement in isolation, but includes the possibility that it depends on other components to satisfy the requirement locally, or cooperates with other components to ensure that the require- ment is satisfied elsewhere in the network. Taken together, these examples illustrate the essential role of an overall network security architecture in design- ing and evaluating a trusted network. I.4.3. Component Evaluation _ _ _ _________ __________ Because network components are often supplied by dif- ferent vendors and are designed to support standardized or common functions in a variety of networks, significant advantages can accrue from a procedure for evaluating indi- vidual components. The purpose of component evaluation is to aid both the network designer and the evaluator by per- forming the evaluation process once and reusing the results whenever that component is incorporated into a network. There are four types of security policies that may be supported by a network component: 1. Mandatory Access Control 2. Discretionary Access Control 3. Supportive policies (e.g., Authentication, Audit) 4. Application policies (e.g., the policy supported by a DBMS that is distinct from that supported by the underlying system) Application level policies are user dependent and will not be considered further in these Interpretations. For a component to support a policy such as Mandatory Access Controls, it must support all the required features for that policy with all of the required assurances of the given class. I.5. Structure of the Document _ _ _________ __ ___ ________ The remainder of this document is divided into two parts, three appendices, a list of acronyms, a glossary, and a list of references. Part I presents TCSEC statements and detailed interpretations, which together constitute the requirements against which networks will be evaluated; and rationale for the network interpretation of the TCSEC. The TCSEC statement applies as modified by the Interpretation. Part II is a description of other Security Services not covered in the TCSEC interpretation which may be applicable to networks. Appendix A describes the evaluation of network components. Appendix B describes the rationale for network partitioning into individual components. Appendix C describes the interconnect rules for linking interconnected accredited AIS. Part I: Interpretations of the ____ _ _______________ __ ___ Trusted Computer System Evaluation Criteria _______ ________ ______ __________ ________ Highlighting (ALL CAPS) is used in Part I to indicate criteria not contained in a lower class or changes and additions to already defined criteria. Where there is no highlighting, requirements have been carried over from lower classes without addition or modification. 1.0 DIVISION D: MINIMAL PROTECTION _ _ ________ _ _______ __________ This division contains only one class. It is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class. 2.0 DIVISION C: DISCRETIONARY PROTECTION _ _ ________ _ _____________ __________ Classes in this division provide for discretionary (need- to-know) protection and, through the inclusion of audit capabilities, for accountability of subjects and the actions they initiate. 2.1 CLASS (C1): DISCRETIONARY SECURITY PROTECTION _ _ _____ __ _____________ ________ __________ THE NETWORK TRUSTED COMPUTING BASE (NTCB) OF A CLASS (C1) NETWORK SYSTEM NOMINALLY SATISFIES THE DISCRETIONARY SECURITY REQUIREMENTS BY PROVIDING SEPARATION OF USERS AND DATA. IT INCORPORATES SOME FORM OF CREDIBLE CONTROLS CAPABLE OF ENFORC- ING ACCESS LIMITATIONS ON AN INDIVIDUAL BASIS, I.E., OSTENSIBLY SUITABLE FOR ALLOWING USERS TO BE ABLE TO PROTECT PRIVATE OR PROJECT INFORMATION AND TO KEEP OTHER USERS FROM ACCIDENTALLY READING OR DESTROYING THEIR DATA. THE CLASS (C1) ENVIRONMENT IS EXPECTED TO BE ONE OF COOPERATING USERS PRO- CESSING DATA AT THE SAME LEVEL(S) OF SENSITIVITY. THE FOLLOWING ARE MINIMAL REQUIREMENTS FOR SYSTEMS ASSIGNED A CLASS (C1) RATING. 2.1.1 Security Policy + Statement from DoD 5200.28-STD Implied from the Introduction to the TCSEC. + Interpretation THE NETWORK SPONSOR SHALL DESCRIBE THE OVERALL NETWORK SECURITY POLICY ENFORCED BY THE NTCB. AT A MINIMUM, THIS POLICY SHALL INCLUDE THE DISCRETIONARY REQUIREMENTS APPLICA- BLE TO THIS CLASS. THE POLICY MAY REQUIRE DATA SECRECY, OR DATA INTEGRITY, OR BOTH. THE POLICY SHALL INCLUDE A DISCRE- TIONARY POLICY FOR PROTECTING THE INFORMATION BEING PRO- CESSED BASED ON THE AUTHORIZATIONS OF USERS OR GROUPS OF USERS. THIS ACCESS CONTROL POLICY STATEMENT SHALL DESCRIBE THE REQUIREMENTS ON THE NETWORK TO PREVENT OR DETECT "READ- ING OR DESTROYING" SENSITIVE INFORMATION BY UNAUTHORIZED USERS OR ERRORS. UNAUTHORIZED USERS INCLUDE BOTH THOSE THAT ARE NOT AUTHORIZED TO USE THE NETWORK AT ALL (E.G., A USER ATTEMPTING TO USE A PASSIVE OR ACTIVE WIRE TAP) OR A LEGITI- MATE USER OF THE NETWORK WHO IS NOT AUTHORIZED TO ACCESS A SPECIFIC PIECE OF INFORMATION BEING PROTECTED. NOTE THAT "USERS" DOES NOT INCLUDE "OPERATORS," "SYSTEM PROGRAMMERS," "TECHNICAL CONTROL OFFICERS," "SYSTEM SECURITY OFFICERS," AND OTHER SYSTEM SUPPORT PERSONNEL. THEY ARE DISTINCT FROM USERS AND ARE SUBJECT TO THE TRUSTED FACILITY MANUAL AND THE SYSTEM ARCHITECTURE REQUIREMENTS. SUCH INDI- VIDUALS MAY CHANGE THE SYSTEM PARAMETERS OF THE NETWORK SYS- TEM, FOR EXAMPLE, BY DEFINING MEMBERSHIP OF A GROUP. THESE INDIVIDUALS MAY ALSO HAVE THE SEPARATE ROLE OF USERS. SECRECY POLICY: THE NETWORK SPONSOR SHALL DEFINE THE FORM OF THE DISCRETIONARY SECRECY POLICY THAT IS ENFORCED IN THE NETWORK TO PREVENT UNAUTHORIZED USERS FROM READING THE SENSITIVE INFORMATION ENTRUSTED TO THE NETWORK. DATA INTEGRITY POLICY: THE NETWORK SPONSOR SHALL DEFINE THE DISCRETIONARY INTEGRITY POLICY TO PREVENT UNAUTHORIZED USERS FROM MODIFYING, VIZ., WRITING, SENSITIVE INFORMATION. THE DEFINITION OF DATA INTEGRITY PRESENTED BY THE NETWORK SPONSOR REFERS TO THE REQUIREMENT THAT THE INFORMATION HAS NOT BEEN SUBJECTED TO UNAUTHORIZED MODIFICATION IN THE NET- WORK. + Rationale THE WORD "SPONSOR" IS USED IN PLACE OF ALTERNATIVES (SUCH AS "VENDOR," "ARCHITECT," "MANUFACTURER," AND "DEVELOPER") BECAUSE THE ALTERNATIVES INDICATE PEOPLE WHO MAY NOT BE AVAILABLE, INVOLVED, OR RELEVANT AT THE TIME THAT A NETWORK SYSTEM IS PROPOSED FOR EVALUATION. A TRUSTED NETWORK IS ABLE TO CONTROL BOTH THE READING AND WRITING OF SHARED SENSITIVE INFORMATION. CONTROL OF WRITING IS USED TO PROTECT AGAINST DESTRUCTION OF INFORMA- TION. A NETWORK NORMALLY IS EXPECTED TO HAVE POLICY REQUIRE- MENTS TO PROTECT BOTH THE SECRECY AND INTEGRITY OF THE INFORMATION ENTRUSTED TO IT. IN A NETWORK THE INTEGRITY IS FREQUENTLY AS IMPORTANT OR MORE IMPORTANT THAN THE SECRECY REQUIREMENTS. THEREFORE THE SECRECY AND/OR INTEGRITY POLICY TO BE ENFORCED BY THE NETWORK MUST BE STATED FOR EACH NET- WORK REGARDLESS OF ITS EVALUATION CLASS. THE ASSURANCE THAT THE POLICY IS FAITHFULLY ENFORCED IS REFLECTED IN THE EVALUATION CLASS OF THE NETWORK. THIS CONTROL OVER MODIFICATION IS TYPICALLY USED TO PROTECT INFORMATION SO THAT IT MAY BE RELIED UPON AND TO CONTROL THE POTENTIAL HARM THAT WOULD RESULT IF THE INFORMA- TION WERE CORRUPTED. THE OVERALL NETWORK POLICY REQUIRE- MENTS FOR INTEGRITY INCLUDES THE PROTECTION FOR DATA BOTH WHILE BEING PROCESSED IN A COMPONENT AND WHILE BEING TRANSMITTED IN THE NETWORK. THE ACCESS CONTROL POLICY ENFORCED BY THE NTCB RELATES TO THE ACCESS OF SUBJECTS TO OBJECTS WITHIN EACH COMPONENT. COMMUNICATIONS INTEGRITY ADDRESSED WITHIN PART II RELATES TO INFORMATION WHILE BEING TRANSMITTED. 2.1.1.1 Discretionary Access Control + Statement from DoD 5200.28-STD THE TCB SHALL DEFINE AND CONTROL ACCESS BETWEEN NAMED USERS AND NAMED OBJECTS (E.G., FILES AND PROGRAMS) IN THE ADP SYS- TEM. 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 BOTH. + Interpretation THE DISCRETIONARY ACCESS CONTROL (DAC) MECHANISM(S) MAY BE DISTRIBUTED OVER THE PARTITIONED NTCB IN VARIOUS WAYS. SOME PART, ALL, OR NONE OF THE DAC MAY BE IMPLEMENTED IN A GIVEN COMPONENT OF THE NETWORK SYSTEM. IN PARTICULAR, COM- PONENTS THAT SUPPORT ONLY INTERNAL SUBJECTS (I.E., THAT HAVE NO SUBJECTS ACTING AS DIRECT SURROGATES FOR USERS), SUCH AS A PUBLIC NETWORK PACKET SWITCH, MIGHT NOT IMPLEMENT THE DAC MECHANISM(S) DIRECTLY (E.G., THEY ARE UNLIKELY TO CONTAIN ACCESS CONTROL LISTS). IDENTIFICATION OF USERS BY GROUPS MAY BE ACHIEVED IN VARIOUS WAYS IN THE NETWORKING ENVIRONMENT. FOR EXAMPLE, THE NETWORK IDENTIFIERS (E.G., INTERNET ADDRESSES) FOR VARI- OUS COMPONENTS (E.G., HOSTS, GATEWAYS) CAN BE USED AS IDEN- TIFIERS OF GROUPS OF INDIVIDUAL USERS (E.G., "ALL USERS AT HOST A," "ALL USERS OF NETWORK Q") WITHOUT EXPLICIT IDENTIF- ICATION OF INDIVIDUAL USERS, NOR EVEN AN EXPLICIT NUMBER OF USERS IMPLIED), IF THIS IS CONSISTENT WITH THE NETWORK SECU- RITY POLICY. FOR NETWORKS, INDIVIDUAL HOSTS WILL IMPOSE NEED-TO-KNOW CONTROLS OVER THEIR USERS - MUCH LIKE (IN FACT, PROBABLY THE SAME) CONTROLS USED WHEN THERE IS NO NETWORK CONNECTION. WHEN GROUP IDENTIFIERS ARE ACCEPTABLE FOR ACCESS CON- TROL, THE IDENTIFIER OF SOME OTHER HOST MAY BE EMPLOYED, TO ELIMINATE THE MAINTENANCE THAT WOULD BE REQUIRED IF INDIVI- DUAL IDENTIFICATION OF REMOTE USERS WAS EMPLOYED. THE DAC MECHANISM OF A NTCB PARTITION MAY BE IMPLE- MENTED AT THE INTERFACE OF THE REFERENCE MONITOR OR MAY BE DISTRIBUTED IN SUBJECTS THAT ARE PART OF THE NTCB IN THE SAME OR DIFFERENT COMPONENT. THE REFERENCE MONITOR MANAGES ALL THE PHYSICAL RESOURCES OF THE SYSTEM AND FROM THEM CREATES THE ABSTRACTION OF SUBJECTS AND OBJECTS THAT IT CON- TROLS. SOME OF THESE SUBJECTS AND OBJECTS MAY BE USED TO IMPLEMENT A PART OF THE NTCB. WHEN INTEGRITY IS INCLUDED AS PART OF THE NETWORK DIS- CRETIONARY SECURITY POLICY, THE ABOVE INTERPRETATIONS SHALL BE SPECIFICALLY APPLIED TO THE CONTROLS OVER MODIFICATION, VIZ, THE WRITE MODE OF ACCESS, WITHIN EACH COMPONENT BASED ON IDENTIFIED USERS OR GROUPS OF USERS. + Rationale IN THIS CLASS, THE SUPPORTING ELEMENTS OF THE OVERALL DAC MECHANISM ARE TREATED EXACTLY AS UNTRUSTED SUBJECTS ARE TREATED WITH RESPECT TO DAC IN AN ADP SYSTEM, WITH THE SAME RESULT AS NOTED IN THE INTERPRETATION. STRENGTHENING OF THE DAC MECHANISM IN THE NETWORK ENVIRONMENT IS PROVIDED IN CLASS (C2) (SEE THE DISCRETIONARY ACCESS CONTROL SECTION). A TYPICAL SITUATION FOR DAC IS THAT A SURROGATE PROCESS FOR A REMOTE USER WILL BE CREATED IN SOME HOST FOR ACCESS TO OBJECTS UNDER THE CONTROL OF THE NTCB PARTITION WITHIN THAT HOST. THE INTERPRETATION REQUIRES THAT A USER IDENTIFIER BE ASSIGNED AND MAINTAINED FOR EACH SUCH PROCESS BY THE NTCB, SO THAT ACCESS BY A SURROGATE PROCESS IS SUBJECT TO ESSEN- TIALLY THE SAME DISCRETIONARY CONTROLS AS ACCESS BY A PRO- CESS ACTING ON BEHALF OF A LOCAL USER WOULD BE. HOWEVER, WITHIN THIS INTERPRETATION A RANGE OF POSSIBLE INTERPRETA- TIONS OF THE ASSIGNED USER IDENTIFICATION IS PERMITTED. THE MOST OBVIOUS SITUATION WOULD EXIST IF A GLOBAL DATABASE OF NETWORK USERS WERE TO BE MADE PERMANENTLY AVAIL- ABLE ON DEMAND TO EVERY HOST, (I.E., A NAME SERVER EXISTED) SO THAT ALL USER IDENTIFICATIONS WERE GLOBALLY MEANINGFUL. IT IS ALSO ACCEPTABLE, HOWEVER, FOR SOME NTCB PARTI- TIONS TO MAINTAIN A DATABASE OF LOCALLY-REGISTERED USERS FOR ITS OWN USE. IN SUCH A CASE, ONE COULD CHOOSE TO INHIBIT THE CREATION OF SURROGATE PROCESSES FOR LOCALLY UNREGISTERED USERS, OR (IF PERMITTED BY THE LOCAL POLICY) ALTERNATIVELY, TO PERMIT THE CREATION OF SURROGATE PROCESSES WITH PRESELECTED USER AND GROUP IDENTIFIERS WHICH, IN EFFECT, IDENTIFY THE PROCESS AS EXECUTING ON BEHALF OF A MEMBER OF A GROUP OF USERS ON A PARTICULAR REMOTE HOST. THE INTENT OF THE WORDS CONCERNING AUDIT IN THE INTERPRETATION IS TO PRO- VIDE A MINIMALLY ACCEPTABLE DEGREE OF AUDITABILITY FOR CASES SUCH AS THE LAST DESCRIBED. WHAT IS REQUIRED IS THAT THERE BE A CAPABILITY, USING THE AUDIT FACILITIES PROVIDED BY THE NETWORK NTCB PARTITIONS INVOLVED, TO DETERMINE WHO WAS LOGGED IN AT THE ACTUAL HOST OF THE GROUP OF REMOTE USERS AT THE TIME THE SURROGATE PROCESSING OCCURED. ASSOCIATING THE PROPER USER ID WITH A SURROGATE PROCESS IS THE JOB OF IDENTIFICATION AND AUTHENTICATION. THIS MEANS THAT DAC IS APPLIED LOCALLY, WITH RESPECT TO THE USER ID OF THE SURROGATE PROCESS. THE TRANSMISSION OF THE DATA BACK ACROSS THE NETWORK TO THE USER'S HOST, AND THE CREATION OF A COPY OF THE DATA THERE, IS NOT THE BUSINESS OF DAC. COMPONENTS THAT SUPPORT ONLY INTERNAL SUBJECTS IMPACT THE IMPLEMENTATION OF THE DAC BY PROVIDING SERVICES BY WHICH INFORMATION (E.G., A USER-ID) IS MADE AVAILABLE TO A COM- PONENT THAT MAKES A DAC DECISION. AN EXAMPLE OF THE LATTER WOULD BE THE CASE THAT A USER AT HOST A ATTEMPTS TO ACCESS A FILE AT HOST B. THE DAC DECISION MIGHT BE (AND USUALLY WOULD BE) MADE AT HOST B ON THE BASIS OF A USER-ID TRANSMIT- TED FROM HOST A TO HOST B. UNIQUE USER IDENTIFICATION MAY BE ACHIEVED BY A VARIETY OF MECHANISMS, INCLUDING (A) A REQUIREMENT FOR UNIQUE IDEN- TIFICATION AND AUTHENTICATION ON THE HOST WHERE ACCESS TAKES PLACE; (B) RECOGNITION OF FULLY QUALIFIED NETWORK ADDRESSES AUTHENTICATED BY ANOTHER HOST AND FORWARDED TO THE HOST WHERE ACCESS TAKES PLACE; OR (C) ADMINISTRATIVE SUPPORT OF A NETWORK-WIDE UNIQUE PERSONNEL IDENTIFIER THAT COULD BE AUTHENTICATED AND FORWARDED BY ANOTHER HOST AS IN (B) ABOVE, OR COULD BE AUTHENTICATED AND FORWARDED BY A DEDICATED NET- WORK IDENTIFICATION AND AUTHENTICATION SERVER. THE PROTO- COLS WHICH IMPLEMENT (B) OR (C) ARE SUBJECT TO THE SYSTEM ARCHITECTURE REQUIREMENTS. NETWORK SUPPORT FOR DAC MIGHT BE HANDLED IN OTHER WAYS THAN THAT DESCRIBED AS "TYPICAL" ABOVE. IN PARTICULAR, SOME FORM OF CENTRALIZED ACCESS CONTROL IS OFTEN PROPOSED. AN ACCESS CONTROL CENTER MAY MAKE ALL DECISIONS FOR DAC, OR IT MAY SHARE THE BURDEN WITH THE HOSTS BY CONTROLLING HOST-TO- HOST CONNECTIONS, AND LEAVING THE HOSTS TO DECIDE ON ACCESS TO THEIR OBJECTS BY USERS AT A LIMITED SET OF REMOTE HOSTS. IN THIS CASE THE ACCESS CONTROL CENTER PROVIDES THE LINKAGE BETWEEN THE CONNECTION ORIENTED ABSTRACTION (AS DISCUSSED IN THE INTRODUCTION) AND THE OVERALL NETWORK SECURITY POLICY FOR DAC. IN ALL CASES THE ENFORCEMENT OF THE DECISION MUST BE PROVIDED BY THE HOST WHERE THE OBJECT RESIDES. 2.1.2 Accountability 2.1.2.1 Identification and Authentication + Statement from DoD 5200.28-STD 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. + Interpretation THE REQUIREMENT FOR IDENTIFICATION AND AUTHENTICATION OF USERS IS THE SAME FOR A NETWORK SYSTEM AS FOR AN ADP SYS- TEM. THE IDENTIFICATION AND AUTHENTICATION MAY BE DONE BY THE COMPONENT TO WHICH THE USER IS DIRECTLY CONNECTED OR SOME OTHER COMPONENT, SUCH AS AN IDENTIFICATION AND AUTHEN- TICATION SERVER. AVAILABLE TECHNIQUES, SUCH AS THOSE DESCRIBED IN THE PASSWORD GUIDELINE=, ARE GENERALLY ALSO APPLICABLE IN THE NETWORK CONTEXT. HOWEVER, IN CASES WHERE THE NTCB IS EXPECTED TO MEDIATE ACTIONS OF A HOST (OR OTHER NETWORK COMPONENT) THAT IS ACTING ON BEHALF OF A USER OR GROUP OF USERS, THE NTCB MAY EMPLOY IDENTIFICATION AND AUTHENTICATION OF THE HOST (OR OTHER COMPONENT) IN LIEU OF IDENTIFICATION AND AUTHENTICATION OF AN INDIVIDUAL USER. AUTHENTICATION INFORMATION, INCLUDING THE IDENTITY OF A USER (ONCE AUTHENTICATED) MAY BE PASSED FROM ONE COMPONENT TO ANOTHER WITHOUT REAUTHENTICATION, SO LONG AS THE NTCB PROTECTS (E.G., BY ENCRYPTION) THE INFORMATION FROM UNAU- THORIZED DISCLOSURE AND MODIFICATION. THIS PROTECTION SHALL PROVIDE AT LEAST A SIMILAR LEVEL OF ASSURANCE (OR STRENGTH OF MECHANISM) AS PERTAINS TO THE PROTECTION OF THE AUTHENTI- CATION MECHANISM AND AUTHENTICATION DATA. + Rationale THE NEED FOR ACCOUNTABILITY IS NOT CHANGED IN THE CON- TEXT OF A NETWORK SYSTEM. THE FACT THAT THE NTCB IS PARTI- TIONED OVER A SET OF COMPONENTS NEITHER REDUCES THE NEED NOR IMPOSES NEW REQUIREMENTS. THAT IS, INDIVIDUAL ACCOUNTABIL- ITY IS STILL THE OBJECTIVE. HOWEVER, IN THE CONTEXT OF A NETWORK SYSTEM AT THE (C1) LEVEL (WHEREIN EXPLICIT INDIVI- DUAL USER ACCOUNTABILITY IS NOT REQUIRED), "INDIVIDUAL ACCOUNTABILITY" CAN BE SATISFIED BY IDENTIFICATION OF A HOST (OR OTHER COMPONENT). IN ADDITION, THERE IS NO NEED IN A DISTRIBUTED PROCESSING SYSTEM LIKE A NETWORK TO REAUTHENTI- CATE A USER AT EACH POINT IN THE NETWORK WHERE A PROJECTION OF A USER (VIA THE SUBJECT OPERATING ON BEHALF OF THE USER) INTO ANOTHER REMOTE SUBJECT TAKES PLACE. THE PASSING OF IDENTIFIERS AND/OR AUTHENTICATION INFOR- MATION FROM ONE COMPONENT TO ANOTHER IS USUALLY DONE IN SUP- PORT TO THE IMPLEMENTATION OF THE DISCRETIONARY ACCESS CON- TROL (DAC). THIS SUPPORT RELATES DIRECTLY TO THE DAC REGARDING ACCESS BY A USER TO A STORAGE OBJECT IN A DIF- FERENT NTCB PARTITION THAN THE ONE WHERE THE USER WAS AUTHENTICATED. EMPLOYING A FORWARDED IDENTIFICATION IMPLIES ADDITIONAL RELIANCE ON THE SOURCE AND COMPONENTS ALONG THE PATH. 2.1.3 Assurance 2.1.3.1 Operational Assurance 2.1.3.1.1 System Architecture + Statement from DoD 5200.28-STD 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 CONTROLLED BY THE TCB MAY BE A DEFINED SUBSET OF THE SUB- JECTS AND OBJECTS IN THE ADP SYSTEM. + Interpretation THE SYSTEM ARCHITECTURE CRITERION MUST BE MET INDIVIDU- ALLY BY ALL NTCB PARTITIONS. IMPLEMENTATION OF THE REQUIRE- MENT THAT THE NTCB MAINTAIN A DOMAIN FOR ITS OWN EXECUTION IS ACHIEVED BY HAVING EACH NTCB PARTITION MAINTAIN A DOMAIN FOR ITS OWN EXECUTION. THE SUBSET OF NETWORK RESOURCES OVER WHICH THE NTCB HAS CONTROL ARE THE UNION OF THE SETS OF RESOURCES OVER WHICH THE NTCB PARTITIONS HAVE CONTROL. CODE AND DATA STRUCTURES BELONGING TO THE NTCB, TRANSFERRED AMONG NTCB SUBJECTS (I.E., SUBJECTS OUTSIDE THE REFERENCE MONITOR BUT INSIDE THE NTCB) BELONGING TO DIFFERENT NTCB PARTITIONS, MUST BE PRO- TECTED AGAINST EXTERNAL INTERFERENCE OR TAMPERING. FOR EXAMPLE, A CRYPTOGRAPHIC CHECKSUM OR PHYSICAL MEANS MAY BE EMPLOYED TO PROTECT USER AUTHENTICATION DATA EXCHANGED BETWEEN NTCB PARTITIONS. + Rationale THE REQUIREMENT FOR THE PROTECTION OF COMMUNICATIONS BETWEEN NTCB PARTITIONS IS SPECIFICALLY DIRECTED TO SUBJECTS THAT ARE PART OF THE NTCB PARTITIONS. ANY REQUIREMENTS FOR SUCH PROTECTION FOR THE SUBJECTS THAT ARE OUTSIDE THE NTCB PARTITIONS ARE ADDRESSED IN RESPONSE TO THE INTEGRITY REQUIREMENTS OF THE SECURITY POLICY. 2.1.3.1.2 System Integrity + Statement from DoD 5200.28-STD HARDWARE AND/OR SOFTWARE FEATURES SHALL BE PROVIDED THAT CAN BE USED TO PERIODICALLY VALIDATE THE CORRECT OPERATION OF THE ON-SITE HARDWARE AND FIRMWARE ELEMENTS OF THE TCB. + Interpretation IMPLEMENTATION OF THE REQUIREMENT IS PARTLY ACHIEVED BY HAVING HARDWARE AND/OR SOFTWARE FEATURES THAT CAN BE USED TO PERIODICALLY VALIDATE THE CORRECT OPERATION OF THE HARDWARE AND FIRMWARE ELEMENTS OF EACH COMPONENT'S NTCB PARTITION. FEATURES SHALL ALSO BE PROVIDED TO VALIDATE THE IDENTITY AND CORRECT OPERATION OF A COMPONENT PRIOR TO ITS INCORPORATION IN THE NETWORK SYSTEM AND THROUGHOUT SYSTEM OPERATION. FOR EXAMPLE, A PROTOCOL COULD BE DESIGNED THAT ENABLES THE COM- PONENTS OF THE PARTITIONED NTCB TO EXCHANGE MESSAGES PERIOD- ICALLY AND VALIDATE EACH OTHER'S CORRECT RESPONSE. THE PRO- TOCOL SHALL BE ABLE TO DETERMINE THE REMOTE ENTITY'S ABILITY TO RESPOND. NTCB PARTITIONS SHALL PROVIDE THE CAPABILITY TO REPORT TO NETWORK ADMINISTRATIVE PERSONNEL THE FAILURES DETECTED IN OTHER NTCB PARTITIONS. INTERCOMPONENT PROTOCOLS IMPLEMENTED WITHIN A NTCB SHALL BE DESIGNED IN SUCH A WAY AS TO PROVIDE CORRECT OPERA- TION IN THE CASE OF FAILURES OF NETWORK COMMUNICATIONS OR INDIVIDUAL COMPONENTS. THE ALLOCATION OF DISCRETIONARY ACCESS CONTROL POLICY IN A NETWORK MAY REQUIRE COMMUNICATION BETWEEN TRUSTED SUBJECTS THAT ARE PART OF THE NTCB PARTI- TIONS IN DIFFERENT COMPONENTS. THIS COMMUNICATION IS NOR- MALLY IMPLEMENTED WITH A PROTOCOL BETWEEN THE SUBJECTS AS PEER ENTITIES. INCORRECT ACCESS WITHIN A COMPONENT SHALL NOT RESULT FROM FAILURE OF AN NTCB PARTITION TO COMMUNICATE WITH OTHER COMPONENTS. + Rationale THE FIRST PARAGRAPH OF THE INTERPRETATION IS A STRAIGHTFORWARD EXTENSION OF THE REQUIREMENT INTO THE CON- TEXT OF A NETWORK SYSTEM AND PARTITIONED NTCB AS DEFINED FOR THESE NETWORK CRITERIA. NTCB PROTOCOLS SHOULD BE ROBUST ENOUGH SO THAT THEY PERMIT THE SYSTEM TO OPERATE CORRECTLY IN THE CASE OF LOCAL- IZED FAILURE. THE PURPOSE OF THIS PROTECTION IS TO PRESERVE THE INTEGRITY OF THE NTCB ITSELF. IT IS NOT UNUSUAL FOR ONE OR MORE COMPONENTS IN A NETWORK TO BE INOPERATIVE AT ANY TIME, SO IT IS IMPORTANT TO MINIMIZE THE EFFECTS OF SUCH FAILURES ON THE REST OF THE NETWORK. ADDITIONAL INTEGRITY AND DENIAL OF SERVICE ISSUES ARE ADDRESSED IN PART II. 2.1.3.2 Life-Cycle Assurance 2.1.3.2.1 Security Testing + Statement from DoD 5200.28-STD THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION. TESTING SHALL BE DONE TO ASSURE THAT THERE ARE NO OBVIOUS WAYS FOR AN UNAUTHORIZED USER TO BYPASS OR OTHERWISE DEFEAT THE SECURITY PROTECTION MECHANISMS OF THE TCB. (SEE THE SECURITY TESTING GUIDELINES.) + Interpretation TESTING OF A COMPONENT WILL REQUIRE A TESTBED THAT EXERCISES THE INTERFACES AND PROTOCOLS OF THE COMPONENT. THE TESTING OF A SECURITY MECHANISM OF THE NETWORK SYSTEM FOR MEETING THIS CRITERION SHALL BE AN INTEGRATED TESTING PROCEDURE INVOLVING ALL COMPONENTS CONTAINING AN NTCB PARTI- TION THAT IMPLEMENT THE GIVEN MECHANISM. THIS INTEGRATED TESTING IS ADDITIONAL TO ANY INDIVIDUAL COMPONENT TESTS INVOLVED IN THE EVALUATION OF THE NETWORK SYSTEM. THE SPON- SOR SHOULD IDENTIFY THE ALLOWABLE SET OF CONFIGURATIONS INCLUDING THE SIZES OF THE NETWORKS. ANALYSIS OR TESTING PROCEDURES AND TOOLS SHALL BE AVAILABLE TO TEST THE LIMITS OF THESE CONFIGURATIONS. A CHANGE IN CONFIGURATION WITHIN THE ALLOWABLE SET OF CONFIGURATIONS DOES NOT REQUIRE RETEST- ING. + Rationale TESTING IS THE PRIMARY METHOD AVAILABLE IN THIS EVALUA- TION DIVISION TO GAIN ANY ASSURANCE THAT THE SECURITY MECHANISMS PERFORM THEIR INTENDED FUNCTION. 2.1.4 Documentation 2.1.4.1 Security Features User's Guide + Statement from DoD 5200.28-STD A SINGLE SUMMARY, CHAPTER, OR MANUAL IN USER DOCUMENTATION SHALL DESCRIBE THE PROTECTION MECHANISMS PROVIDED BY THE TCB, INTERPRETATIONS ON THEIR USE, AND HOW THEY INTERACT WITH ONE ANOTHER. + Interpretation THIS USER DOCUMENTATION DESCRIBES USER VISIBLE PROTEC- TION MECHANISMS AT THE GLOBAL (NETWORK SYSTEM) LEVEL AND AT THE USER INTERFACE OF EACH COMPONENT, AND THE INTERACTION AMONG THESE. + Rationale THE INTERPRETATION IS AN EXTENSION OF THE REQUIREMENT INTO THE CONTEXT OF A NETWORK SYSTEM AS DEFINED FOR THESE NETWORK CRITERIA. DOCUMENTATION OF PROTECTION MECHANISMS PROVIDED BY INDIVIDUAL COMPONENTS IS REQUIRED BY THE CRI- TERIA FOR TRUSTED COMPUTER SYSTEMS THAT ARE APPLIED AS APPROPRIATE FOR THE INDIVIDUAL COMPONENTS. 2.1.4.2 Trusted Facility Manual + Statement from DoD 5200.28-STD A MANUAL ADDRESSED TO THE ADP SYSTEM ADMINISTRATOR SHALL PRESENT CAUTIONS ABOUT FUNCTIONS AND PRIVILEGES THAT SHOULD BE CONTROLLED WHEN RUNNING A SECURE FACILITY. + Interpretation THIS MANUAL SHALL CONTAIN SPECIFICATIONS AND PROCEDURES TO ASSIST THE SYSTEM ADMINISTRATOR(S) MAINTAIN COGNIZANCE OF THE NETWORK CONFIGURATION. THESE SPECIFICATIONS AND PRO- CEDURES SHALL ADDRESS THE FOLLOWING: 1.THE HARDWARE CONFIGURATION OF THE NETWORK ITSELF; 2.THE IMPLICATIONS OF ATTACHING NEW COMPONENTS TO THE NETWORK; 3.THE CASE WHERE CERTAIN COMPONENTS MAY PERIODICALLY LEAVE THE NETWORK (E.G., BY CRASHING, OR BY BEING DISCONNECTED) AND THEN REJOIN; 4.NETWORK CONFIGURATION ASPECTS THAT CAN IMPACT THE SECURITY OF THE NETWORK SYSTEM; (FOR EXAMPLE, THE MANUAL SHOULD DESCRIBE FOR THE NETWORK SYSTEM ADMINISTRATOR THE INTERCONNECTIONS AMONG COMPONENTS THAT ARE CONSISTENT WITH THE OVERALL NETWORK SYSTEM ARCHITECTURE.) 5.LOADING OR MODIFYING NTCB SOFTWARE OR FIRMWARE (E.G., DOWN-LINE LOADING). THE PHYSICAL AND ADMINISTRATIVE ENVIRONMENTAL CONTROLS SHALL BE SPECIFIED. ANY ASSUMPTIONS ABOUT SECURITY OF A GIVEN NETWORK SHOULD BE CLEARLY STATED (E.G., THE FACT THAT ALL COMMUNICATIONS LINKS MUST BE PHYSICALLY PROTECTED TO A CERTAIN LEVEL). + Rationale THERE MAY BE MULTIPLE SYSTEM ADMINISTRATORS WITH DIVERSE RESPONSIBILITIES. THE TECHNICAL SECURITY MEASURES DESCRIBED BY THESE CRITERIA MUST BE USED IN CONJUNCTION WITH OTHER FORMS OF SECURITY IN ORDER TO ACHIEVE SECURITY OF THE NETWORK. ADDITIONAL FORMS INCLUDE ADMINISTRATIVE SECURITY, PHYSICAL SECURITY, EMANATIONS SECURITY, ETC. EXTENSION OF THIS CRITERION TO COVER CONFIGURATION ASPECTS OF THE NETWORK IS NEEDED BECAUSE, FOR EXAMPLE, PROPER INTERCONNECTION OF COMPONENTS IS TYPICALLY ESSENTIAL TO ACHIEVE A CORRECT REALIZATION OF THE NETWORK ARCHITEC- TURE. CRYPTOGRAPHY IS ONE COMMON MECHANISM EMPLOYED TO PRO- TECT COMMUNICATION CIRCUITS. ENCRYPTION TRANSFORMS THE REPRESENTATION OF INFORMATION SO THAT IT IS UNINTELLIGIBLE TO UNAUTHORIZED SUBJECTS. REFLECTING THIS TRANSFORMATION, THE SENSITIVITY OF THE CIPHERTEXT IS GENERALLY LOWER THAN THE CLEARTEXT. IF ENCRYPTION METHODOLOGIES ARE EMPLOYED, THEY SHALL BE APPROVED BY THE NATIONAL SECURITY AGENCY (NSA). THE ENCRYPTION ALGORITHM AND ITS IMPLEMENTATION ARE OUTSIDE THE SCOPE OF THESE INTERPRETATIONS. THIS ALGORITHM AND IMPLEMENTATION MAY BE IMPLEMENTED IN A SEPARATE DEVICE OR MAY BE A FUNCTION OF A SUBJECT IN A COMPONENT NOT DEDI- CATED TO ENCRYPTION. WITHOUT PREJUDICE, EITHER IMPLEMENTA- TION PACKAGING IS REFERRED TO AS AN ENCRYPTION MECHANISM HEREIN. 2.1.4.3 Test Documentation + Statement from DoD 5200.28-STD THE SYSTEM DEVELOPER SHALL PROVIDE TO THE EVALUATORS A DOCU- MENT THAT DESCRIBES THE TEST PLAN, TEST PROCEDURES THAT SHOW HOW THE SECURITY MECHANISMS WERE TESTED, AND RESULTS OF THE SECURITY MECHANISMS' FUNCTIONAL TESTING. + Interpretation THE "SYSTEM DEVELOPER" IS INTERPRETED AS "THE NETWORK SYSTEM SPONSOR". THE DESCRIPTION OF THE TEST PLAN SHOULD ESTABLISH THE CONTEXT IN WHICH THE TESTING WAS OR SHOULD BE CONDUCTED. THE DESCRIPTION SHOULD IDENTIFY ANY ADDITIONAL TEST COMPONENTS THAT ARE NOT PART OF THE SYSTEM BEING EVALUATED. THIS INCLUDES A DESCRIPTION OF THE TEST-RELEVANT FUNCTIONS OF SUCH TEST COMPONENTS AND A DESCRIPTION OF THE INTERFACING OF THOSE TEST COMPONENTS TO THE SYSTEM BEING EVALUATED. THE DESCRIPTION OF THE TEST PLAN SHOULD ALSO DEMONSTRATE THAT THE TESTS ADEQUATELY COVER THE NETWORK SECURITY POLICY. THE TESTS SHOULD INCLUDE THE FEATURES DESCRIBED IN THE SYSTEM ARCHITECTURE AND THE SYSTEM INTEGRITY SECTIONS. THE TESTS SHOULD ALSO INCLUDE NETWORK CONFIGURATION AND SIZING. + Rationale THE ENTITY BEING EVALUATED MAY BE A NETWORKING SUBSYS- TEM (SEE APPENDIX A) TO WHICH OTHER COMPONENTS MUST BE ADDED TO MAKE A COMPLETE NETWORK SYSTEM. IN THAT CASE, THIS INTERPRETATION IS EXTENDED TO INCLUDE CONTEXTUAL DEFINITION BECAUSE, AT EVALUATION TIME, IT IS NOT POSSIBLE TO VALIDATE THE TEST PLANS WITHOUT THE DESCRIPTION OF THE CONTEXT FOR TESTING THE NETWORKING SUBSYSTEM. 2.1.4.4 Design Documentation + Statement from DoD 5200.28-STD DOCUMENTATION SHALL BE AVAILABLE THAT PROVIDES A DESCRIPTION OF THE MANUFACTURER'S PHILOSOPHY OF PROTECTION AND AN EXPLA- NATION 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. + Interpretation EXPLANATION OF HOW THE SPONSOR'S PHILOSOPHY OF PROTEC- TION IS TRANSLATED INTO THE NTCB SHALL INCLUDE A DESCRIPTION OF HOW THE NTCB IS PARTITIONED. THE SECURITY POLICY ALSO SHALL BE STATED. THE DESCRIPTION OF THE INTERFACES BETWEEN THE NTCB MODULES SHALL INCLUDE THE INTERFACE(S) BETWEEN NTCB PARTITIONS AND MODULES WITHIN THE PARTITIONS IF THE MODULES EXIST. THE SPONSOR SHALL DESCRIBE THE SECURITY ARCHITECTURE AND DESIGN, INCLUDING THE ALLOCATION OF SECURITY REQUIRE- MENTS AMONG COMPONENTS. APPENDIX A ADDRESSES COMPONENT EVALUATION ISSUES. + Rationale THE INTERPRETATION IS A STRAIGHTFORWARD EXTENSION OF THE REQUIREMENT INTO THE CONTEXT OF A NETWORK SYSTEM AS DEFINED FOR THIS NETWORK INTERPRETATION. OTHER DOCUMENTA- TION, SUCH AS DESCRIPTION OF COMPONENTS AND DESCRIPTION OF OPERATING ENVIRONMENT(S) IN WHICH THE NETWORKING SUBSYSTEM OR NETWORK SYSTEM IS DESIGNED TO FUNCTION, IS REQUIRED ELSE- WHERE, E.G., IN THE TRUSTED FACILITY MANUAL. IN ORDER TO BE EVALUATED, A NETWORK MUST POSSESS A COHERENT NETWORK SECURITY ARCHITECTURE AND DESIGN. (INTER- CONNECTION OF COMPONENTS THAT DO NOT ADHERE TO SUCH A SINGLE COHERENT NETWORK SECURITY ARCHITECTURE IS ADDRESSED IN THE INTERCONNECTION OF ACCREDITED AIS, APPENDIX C.) THE NETWORK SECURITY ARCHITECTURE MUST ADDRESS THE SECURITY-RELEVANT POLICIES, OBJECTIVES, AND PROTOCOLS. THE NETWORK SECURITY DESIGN SPECIFIES THE INTERFACES AND SERVICES THAT MUST BE INCORPORATED INTO THE NETWORK SO THAT IT CAN BE EVALUATED AS A TRUSTED ENTITY. THERE MAY BE MULTIPLE DESIGNS THAT CON- FORM TO THE SAME ARCHITECTURE BUT ARE MORE OR LESS INCOMPA- TIBLE AND NON-INTEROPERABLE (EXCEPT THROUGH THE INTERCONNEC- TION RULES). SECURITY RELATED MECHANISMS REQUIRING COOPERA- TION AMONG COMPONENTS ARE SPECIFIED IN THE DESIGN IN TERMS OF THEIR VISIBLE INTERFACES; MECHANISMS HAVING NO VISIBLE INTERFACES ARE NOT SPECIFIED IN THIS DOCUMENT BUT ARE LEFT AS IMPLEMENTATION DECISIONS. THE NETWORK SECURITY ARCHITECTURE AND DESIGN MUST BE AVAILABLE FROM THE NETWORK SPONSOR BEFORE EVALUATION OF THE NETWORK, OR ANY COMPONENT, CAN BE UNDERTAKEN. THE NETWORK SECURITY ARCHITECTURE AND DESIGN MUST BE SUFFICIENTLY COM- PLETE, UNAMBIGUOUS, AND FREE FROM OBVIOUS FLAWS TO PERMIT THE CONSTRUCTION OR ASSEMBLY OF A TRUSTED NETWORK BASED ON THE STRUCTURE IT SPECIFIES. WHEN A COMPONENT IS BEING DESIGNED OR PRESENTED FOR EVALUATION, OR WHEN A NETWORK ASSEMBLED FROM COMPONENTS IS ASSEMBLED OR PRESENTED FOR EVALUATION, THERE MUST BE A PRIORI EVIDENCE THAT THE NETWORK SECURITY ARCHITECTURE AND DESIGN ARE SATISFIED. THAT IS, THE COMPONENTS CAN BE ASSEM- BLED INTO A NETWORK THAT CONFORMS IN EVERY WAY WITH THE NET- WORK SECURITY ARCHITECTURE AND DESIGN TO PRODUCE A PHYSICAL REALIZATION THAT IS TRUSTED TO THE EXTENT THAT ITS EVALUA- TION INDICATES. IN ORDER FOR A TRUSTED NETWORK TO BE CONSTRUCTED FROM COMPONENTS THAT CAN BE BUILT INDEPENDENTLY, THE NETWORK SECURITY ARCHITECTURE AND DESIGN MUST COMPLETELY AND UNAMBI- GUOUSLY DEFINE THE SECURITY FUNCTIONALITY OF COMPONENTS AS WELL AS THE INTERFACES BETWEEN OR AMONG COMPONENTS. THE NETWORK SECURITY ARCHITECTURE AND DESIGN MUST BE EVALUATED TO DETERMINE THAT A NETWORK CONSTRUCTED TO ITS SPECIFICATIONS WILL IN FACT BE TRUSTED, THAT IS, IT WILL BE EVALUATABLE UNDER THESE INTERPRETATIONS. 2.2 CLASS (C2): CONTROLLED ACCESS PROTECTION _ _ _____ __ __________ ______ __________ NETWORK SYSTEMS IN THIS CLASS ENFORCE A MORE FINELY GRAINED DISCRETIONARY ACCESS CONTROL THAN (C1) NETWORK SYSTEMS, MAKING USERS INDIVIDUALLY ACCOUNTABLE FOR THEIR ACTIONS THROUGH LOGIN PRO- CEDURES, AUDITING OF SECURITY-RELEVANT EVENTS, AND RESOURCE ISOLATION. THE FOLLOWING ARE MINIMAL REQUIREMENTS FOR SYSTEMS ASSIGNED A CLASS (C2) RATING. 2.2.1 Security Policy _ _ _ ________ ______ + Statement from DoD 5200.28-STD Implied from the Introduction to the TCSEC. + Interpretation The network sponsor shall describe the overall network security policy enforced by the NTCB. At a minimum, this policy shall include the discretionary requirements applica- ble to this class. The policy may require data secrecy, or data integrity, or both. The policy shall include a discre- tionary policy for protecting the information being pro- cessed based on the authorizations of INDIVIDUALS, users, or groups of users. This access control policy statement shall describe the requirements on the network to prevent or detect "reading or destroying" sensitive information by unauthorized users or errors. Unauthorized users include both those that are not authorized to use the network at all (e.g., a user attempting to use a passive or active wire tap) or a legitimate user of the network who is not author- ized to access a specific piece of information being pro- tected. Note that "users" does not include "operators," "system programmers," "technical control officers," "system security officers," and other system support personnel. They are distinct from users and are subject to the Trusted Facility Manual and the System Architecture requirements. Such indi- viduals may change the system parameters of the network system, for example, by defining membership of a group. These individuals may also have the separate role of users. SECRECY POLICY: The network sponsor shall define the form of the discretionary secrecy policy that is enforced in the network to prevent unauthorized users from reading the sensitive information entrusted to the network. DATA INTEGRITY POLICY: The network sponsor shall define the discretionary integrity policy to prevent unauthorized users from modifying, viz., writing, sensitive information. The definition of data integrity presented by the network sponsor refers to the requirement that the information has not been subjected to unauthorized modification in the net- work. + Rationale The word "sponsor" is used in place of alternatives (such as "vendor," "architect," "manufacturer," and "developer") because the alternatives indicate people who may not be available, involved, or relevant at the time that a network system is proposed for evaluation. A trusted network is able to control both the reading and writing of shared sensitive information. Control of writing is used to protect against destruction of informa- tion. A network normally is expected to have policy require- ments to protect both the secrecy and integrity of the information entrusted to it. In a network the integrity is frequently as important or more important than the secrecy requirements. Therefore the secrecy and/or integrity policy to be enforced by the network must be stated for each net- work regardless of its evaluation class. The assurance that the policy is faithfully enforced is reflected in the evaluation class of the network. This control over modification is typically used to protect information so that it may be relied upon and to control the potential harm that would result if the informa- tion were corrupted. The overall network policy require- ments for integrity includes the protection for data both while being processed in a component and while being transmitted in the network. The access control policy enforced by the NTCB relates to the access of subjects to objects within each component. Communications integrity addressed within Part II relates to information while being transmitted. 2.2.1.1 Discretionary Access Control + Statement from DoD 5200.28-STD The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP sys- tem. 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 both, AND SHALL PROVIDE CONTROLS TO LIMIT PROPAGATION OF ACCESS RIGHTS. THE DISCRE- TIONARY ACCESS CONTROL MECHANISM SHALL, EITHER BY EXPLICIT USER ACTION OR BY DEFAULT, PROVIDE THAT OBJECTS ARE PRO- TECTED FROM UNAUTHORIZED ACCESS. THESE ACCESS CONTROLS SHALL BE CAPABLE OF INCLUDING OR EXCLUDING ACCESS TO THE GRANULARITY OF A SINGLE USER. ACCESS PERMISSION TO AN OBJECT BY USERS NOT ALREADY POSSESSING ACCESS PERMISSION SHALL ONLY BE ASSIGNED BY AUTHORIZED USERS. + Interpretation The discretionary access control (DAC) mechanism(s) may be distributed over the partitioned NTCB in various ways. Some part, all, or none of the DAC may be implemented in a given component of the network system. In particular, com- ponents that support only internal subjects (i.e., that have no subjects acting as direct surrogates for users), such as a public network packet switch, might not implement the DAC mechanism(s) directly (e.g., they are unlikely to contain access control lists). Identification of users by groups may be achieved in various ways in the networking environment. For example, the network identifiers (e.g., internet addresses) for vari- ous components (e.g., hosts, gateways) can be used as iden- tifiers of groups of individual users (e.g., "all users at Host A," "all users of network Q") SO LONG AS THE INDIVIDU- ALS INVOLVED IN THE GROUP ARE IMPLIED BY THE GROUP IDENTIF- IER. FOR EXAMPLE, HOST A MIGHT EMPLOY A PARTICULAR GROUP-ID, FOR WHICH IT MAINTAINS A LIST OF EXPLICIT USERS IN THAT GROUP, IN ITS NETWORK EXCHANGE WITH HOST B, WHICH ACCEPTS THE GROUP-ID UNDER THE CONDITIONS OF THIS INTERPRETATION. For networks, individual hosts will impose need-to-know controls over their users ON THE BASIS OF NAMED INDIVIDUALS - much like (in fact, probably the same) controls used when there is no network connection. When group identifiers are acceptable for access con- trol, the identifier of some other host may be employed, to eliminate the maintenance that would be required if indivi- dual identification of remote users was employed. IN CLASS C2 AND HIGHER, HOWEVER, IT MUST BE POSSIBLE FROM THAT AUDIT RECORD TO IDENTIFY (IMMEDIATELY OR AT SOME LATER TIME) EXACTLY THE INDIVIDUALS REPRESENTED BY A GROUP IDENTIFIER AT THE TIME OF THE USE OF THAT IDENTIFIER. THERE IS ALLOWED TO BE AN UNCERTAINTY BECAUSE OF ELAPSED TIME BETWEEN CHANGES IN THE GROUP MEMBERSHIP AND THE ENFORCEMENT IN THE ACCESS CON- TROL MECHANISMS. The DAC mechanism of a NTCB partition may be imple- mented at the interface of the reference monitor or may be distributed in subjects that are part of the NTCB in the same or different component. The reference monitor manages all the physical resources of the system and from them creates the abstraction of subjects and objects that it con- trols. Some of these subjects and objects may be used to implement a part of the NTCB. WHEN THE DAC MECHANISM IS DISTRIBUTED IN SUCH NTCB SUBJECTS (I.E., WHEN OUTSIDE THE REFERENCE MONITOR), THE ASSURANCE REQUIREMENTS (SEE THE ASSURANCE SECTION) FOR THE DESIGN AND IMPLEMENTATION OF THE DAC SHALL BE THOSE OF CLASS C2 FOR ALL NETWORKS OF CLASS C2 OR ABOVE. When integrity is included as part of the network dis- cretionary security policy, the above interpretations shall be specifically applied to the controls over modification, viz, the write mode of access, within each component based on identified users or groups of users. + Rationale In this class, THE SUPPORTING ELEMENTS OF THE OVERALL DAC MECHANISM ARE REQUIRED TO ISOLATE INFORMATION (OBJECTS) THAT SUPPORTS DAC SO THAT IT IS SUBJECT TO AUDITING REQUIRE- MENTS (SEE THE SYSTEM ARCHITECTURE SECTION). THE USE OF NETWORK IDENTIFIERS TO IDENTIFY GROUPS OF INDIVIDUAL USERS COULD BE IMPLEMENTED, FOR EXAMPLE, AS AN X.25 COMMUNITY OF INTEREST IN THE NETWORK PROTOCOL LAYER (LAYER 3). IN ALL OTHER RESPECTS, the supporting elements of the overall DAC mechanism are treated exactly as untrusted subjects are treated with respect to DAC in an ADP system, with the same result as noted in the interpretation. A typical situation for DAC is that a surrogate process for a remote user will be created in some host for access to objects under the control of the NTCB partition within that host. The interpretation requires that a user identifier be assigned and maintained for each such process by the NTCB, so that access by a surrogate process is subject to essen- tially the same discretionary controls as access by a pro- cess acting on behalf of a local user would be. However, within this interpretation a range of possible interpreta- tions of the assigned user identification is permitted. The most obvious situation would exist if a global database of network users were to be made permanently avail- able on demand to every host, (i.e., a name server existed) so that all user identifications were globally meaningful. It is also acceptable, however, for some NTCB parti- tions to maintain a database of locally-registered users for its own use. In such a case, one could choose to inhibit the creation of surrogate processes for locally unregistered users, or (if permitted by the local policy) alternatively, to permit the creation of surrogate processes with preselected user and group identifiers which, in effect, identify the process as executing on behalf of a member of a group of users on a particular remote host. The intent of the words concerning audit in the interpretation is to pro- vide a minimally acceptable degree of auditability for cases such as the last described. What is required is that there be a capability, using the audit facilities provided by the network NTCB partitions involved, to determine who was logged in at the actual host of the group of remote users at the time the surrogate processing occured. Associating the proper user id with a surrogate process is the job of identification and authentication. This means that DAC is applied locally, with respect to the user id of the surrogate process. The transmission of the data back across the network to the user's host, and the creation of a copy of the data there, is not the business of DAC. Components that support only internal subjects impact the implementation of the DAC by providing services by which information (e.g., a user-id) is made available to a com- ponent that makes a DAC decision. An example of the latter would be the case that a user at Host A attempts to access a file at Host B. The DAC decision might be (and usually would be) made at Host B on the basis of a user-id transmit- ted from Host A to Host B. Unique user identification may be achieved by a variety of mechanisms, including (a) a requirement for unique iden- tification and authentication on the host where access takes place; (b) recognition of fully qualified network addresses authenticated by another host and forwarded to the host where access takes place; or (c) administrative support of a network-wide unique personnel identifier that could be authenticated and forwarded by another host as in (b) above, or could be authenticated and forwarded by a dedicated net- work identification and authentication server. The proto- cols which implement (b) or (c) are subject to the System Architecture requirements. Network support for DAC might be handled in other ways than that described as "typical" above. In particular, some form of centralized access control is often proposed. An access control center may make all decisions for DAC, or it may share the burden with the hosts by controlling host-to- host connections, and leaving the hosts to decide on access to their objects by users at a limited set of remote hosts. In this case the access control center provides the linkage between the connection oriented abstraction (as discussed in the Introduction) and the overall network security policy for DAC. In all cases the enforcement of the decision must be provided by the host where the object resides. 2.2.1.2 Object Reuse + Statement from DoD 5200.28-STD 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. + Interpretation THE NTCB SHALL ENSURE THAT ANY STORAGE OBJECTS THAT IT CONTROLS (E.G., MESSAGE BUFFERS UNDER THE CONTROL OF A NTCB PARTITION IN A COMPONENT) CONTAIN NO INFORMATION FOR WHICH A SUBJECT IN THAT COMPONENT IS NOT AUTHORIZED BEFORE GRANTING ACCESS. THIS REQUIREMENT MUST BE ENFORCED BY EACH OF THE NTCB PARTITIONS. + Rationale IN A NETWORK SYSTEM, STORAGE OBJECTS OF INTEREST ARE THINGS THAT THE NTCB DIRECTLY CONTROLS, SUCH AS MESSAGE BUFFERS IN COMPONENTS. EACH COMPONENT OF THE NETWORK SYSTEM MUST ENFORCE THE OBJECT REUSE REQUIREMENT WITH RESPECT TO THE STORAGE OBJECTS OF INTEREST AS DETERMINED BY THE NETWORK SECURITY POLICY. FOR EXAMPLE, THE DAC REQUIREMENT IN THIS DIVISION LEADS TO THE REQUIREMENT HERE THAT MESSAGE BUFFERS BE UNDER THE CONTROL OF THE NTCB PARTITION. A BUFFER ASSIGNED TO AN INTERNAL SUBJECT MAY BE REUSED AT THE DISCRE- TION OF THAT SUBJECT WHICH IS RESPONSIBLE FOR PRESERVING THE INTEGRITY OF MESSAGE STREAMS. SUCH CONTROLLED OBJECTS MAY BE IMPLEMENTED IN PHYSICAL RESOURCES, SUCH AS BUFFERS, DISK SECTORS, TAPE SPACE, AND MAIN MEMORY, IN COMPONENTS SUCH AS NETWORK SWITCHES. 2.2.2 Accountability _ _ _ ______________ 2.2.2.1 Identification and Authentication + Statement from DoD 5200.28-STD 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 TCB SHALL BE ABLE TO ENFORCE INDIVIDUAL ACCOUNTABILITY BY PROVIDING THE CAPABILITY TO UNIQUELY IDENTIFY EACH INDIVI- DUAL ADP SYSTEM USER. THE TCB SHALL ALSO PROVIDE THE CAPA- BILITY OF ASSOCIATING THIS IDENTITY WITH ALL AUDITABLE ACTIONS TAKEN BY THAT INDIVIDUAL. + Interpretation The requirement for identification and authentication of users is the same for a network system as for an ADP sys- tem. The identification and authentication may be done by the component to which the user is directly connected or some other component, such as an identification and authen- tication server. Available techniques, such as those described in the Password Guideline=, are generally also applicable in the network context. However, in cases where the NTCB is expected to mediate actions of a host (or other network component) that is acting on behalf of a user or group of users, the NTCB may employ identification and authentication of the host (or other component) in lieu of identification and authentication of an individual user, SO LONG AS THE COMPONENT IDENTIFIER IMPLIES A LIST OF SPECIFIC USERS UNIQUELY ASSOCIATED WITH THE IDENTIFIER AT THE TIME OF ITS USE FOR AUTHENTICATION. THIS REQUIREMENT DOES NOT APPLY TO INTERNAL SUBJECTS. Authentication information, including the identity of a user (once authenticated) may be passed from one component to another without reauthentication, so long as the NTCB protects (e.g., by encryption) the information from unau- thorized disclosure and modification. This protection shall provide at least a similar level of assurance (or strength of mechanism) as pertains to the protection of the authenti- cation mechanism and authentication data. + Rationale The need for accountability is not changed in the con- text of a network system. The fact that the NTCB is parti- tioned over a set of components neither reduces the need nor imposes new requirements. That is, individual accountabil- ity is still the objective. ALSO, in the context of a net- work system at the (C2) LEVEL OR HIGHER "INDIVIDUAL ACCOUN- TABILITY" CAN BE SATISFIED BY IDENTIFICATION OF A HOST (OR OTHER COMPONENT) SO LONG AS THE REQUIREMENT FOR TRACEABILITY TO INDIVIDUAL USERS OR A SET OF SPECIFIC INDIVIDUAL USERS WITH ACTIVE SUBJECTS IS SATISFIED. THERE IS ALLOWED TO BE AN UNCERTAINTY IN TRACEABILITY BECAUSE OF ELAPSED TIME BETWEEN CHANGES IN THE GROUP MEMBERSHIP AND THE ENFORCEMENT IN THE ACCESS CONTROL MECHANISMS. In addition, there is no need in a distributed processing system like a network to reauthen- ticate a user at each point in the network where a projec- tion of a user (via the subject operating on behalf of the user) into another remote subject takes place. _________________________ = Department of Defense Password Management Guide- __________ __ _______ ________ __________ _____ line, CSC-STD-002-85 ____ The passing of identifiers and/or authentication infor- mation from one component to another is usually done in sup- port to the implementation of the discretionary access con- trol (DAC). This support relates directly to the DAC regarding access by a user to a storage object in a dif- ferent NTCB partition than the one where the user was authenticated. Employing a forwarded identification implies additional reliance on the source and components along the path. 2.2.2.2 Audit + Statement from DoD 5200.28-STD THE TCB SHALL 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 SHALL 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, INTRO- DUCTION 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 IDENTIFICATION/AUTHENTICATION EVENTS THE ORIGIN OF REQUEST (E.G., TERMINAL ID) SHALL 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. THE ADP SYSTEM ADMINISTRA- TOR SHALL BE ABLE TO SELECTIVELY AUDIT THE ACTIONS OF ANY ONE OR MORE USERS BASED ON INDIVIDUAL IDENTITY. + Interpretation THIS CRITERION APPLIES AS STATED. THE SPONSOR MUST SELECT WHICH EVENTS ARE AUDITABLE. IF ANY SUCH EVENTS ARE NOT DISTINGUISHABLE BY THE NTCB ALONE (FOR EXAMPLE THOSE IDENTIFIED IN PART II), THE AUDIT MECHANISM SHALL PROVIDE AN INTERFACE, WHICH AN AUTHORIZED SUBJECT CAN INVOKE WITH PARAMETERS SUFFICIENT TO PRODUCE AN AUDIT RECORD. THESE AUDIT RECORDS SHALL BE DISTINGUISHABLE FROM THOSE PROVIDED BY THE NTCB. IN THE CONTEXT OF A NETWORK SYSTEM, "OTHER SECURITY RELEVANT EVENTS" (DEPENDING ON NETWORK SYSTEM ARCHITECTURE AND NETWORK SECURITY POLICY) MIGHT BE AS FOL- LOWS: 1. IDENTIFICATION OF EACH ACCESS EVENT (E.G., ESTAB- LISHING A CONNECTION OR A CONNECTIONLESS ASSOCIATION BETWEEN PROCESSES IN TWO HOSTS OF THE NETWORK) AND ITS PRINCIPAL PARAMETERS (E.G., HOST IDENTIFIERS OF THE TWO HOSTS INVOLVED IN THE ACCESS EVENT AND USER IDENTIFIER OR HOST IDENTIFIER OF THE USER OR HOST THAT IS REQUESTING THE ACCESS EVENT) 2. IDENTIFICATION OF THE STARTING AND ENDING TIMES OF EACH ACCESS EVENT USING LOCAL TIME OR GLOBAL SYN- CHRONIZED TIME 3. IDENTIFICATION OF SECURITY-RELEVANT EXCEPTIONAL CON- DITIONS (E.G., POTENTIAL VIOLATION OF DATA INTEGRITY, SUCH AS MISROUTED DATAGRAMS) DETECTED DURING THE TRANSACTIONS BETWEEN TWO HOSTS 4. UTILIZATION OF CRYPTOGRAPHIC VARIABLES 5. CHANGING THE CONFIGURATION OF THE NETWORK (E.G., A COMPONENT LEAVING THE NETWORK AND REJOINING) IN ADDITION, IDENTIFICATION INFORMATION SHOULD BE INCLUDED IN APPROPRIATE AUDIT TRAIL RECORDS, AS NECESSARY, TO ALLOW ASSOCIATION OF ALL RELATED (E.G., INVOLVING THE SAME NETWORK EVENT) AUDIT TRAIL RECORDS (E.G., AT DIFFERENT HOSTS) WITH EACH OTHER. FURTHERMORE, A COMPONENT OF THE NETWORK SYSTEM MAY PROVIDE THE REQUIRED AUDIT CAPABILITY (E.G., STORAGE, RETRIEVAL, REDUCTION, ANALYSIS) FOR OTHER COMPONENTS THAT DO NOT INTERNALLY STORE AUDIT DATA BUT TRANSMIT THE AUDIT DATA TO SOME DESIGNATED COLLECTION COM- PONENT. PROVISIONS SHALL BE MADE TO CONTROL THE LOSS OF AUDIT DATA DUE TO UNAVAILABILITY OF RESOURCES. IN THE CONTEXT OF A NETWORK SYSTEM, THE "USER'S ADDRESS SPACE" IS EXTENDED, FOR OBJECT INTRODUCTION AND DELETION EVENTS, TO INCLUDE ADDRESS SPACES BEING EMPLOYED ON BEHALF OF A REMOTE USER (OR HOST). HOWEVER, THE FOCUS REMAINS ON USERS IN CONTRAST TO INTERNAL SUBJECTS AS DISCUSSED IN THE DAC CRITERION. IN ADDITION, AUDIT INFORMATION MUST BE STORED IN MACHINE-READABLE FORM. + Rationale FOR REMOTE USERS, THE NETWORK IDENTIFIERS (E.G., INTER- NET ADDRESS) CAN BE USED AS IDENTIFIERS OF GROUPS OF INDIVI- DUAL USERS (E.G., "ALL USERS AT HOST A") TO ELIMINATE THE MAINTENANCE THAT WOULD BE REQUIRED IF INDIVIDUAL IDENTIFICA- TION OF REMOTE USERS WAS EMPLOYED. IN THIS CLASS (C2), HOW- EVER, IT MUST BE POSSIBLE TO IDENTIFY (IMMEDIATELY OR AT SOME LATER TIME) THE INDIVIDUALS REPRESENTED BY A GROUP IDENTIFIER. IN ALL OTHER RESPECTS, THE INTERPRETATION IS A STRAIGHTFORWARD EXTENSION OF THE CRITERION INTO THE CONTEXT OF A NETWORK SYSTEM. 2.2.3 Assurance _ _ _ _________ 2.2.3.1 Operational Assurance 2.2.3.1.1 System Architecture + Statement from DoD 5200.28-STD 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 controlled by the TCB may be a defined subset of the sub- jects and objects in the ADP system. THE TCB SHALL ISOLATE THE RESOURCES TO BE PROTECTED SO THAT THEY ARE SUBJECT TO THE ACCESS CONTROL AND AUDITING REQUIREMENTS. + Interpretation The system architecture criterion must be met individu- ally by all NTCB partitions. Implementation of the require- ment that the NTCB maintain a domain for its own execution is achieved by having each NTCB partition maintain a domain for its own execution. The subset of network resources over which the NTCB has control are the union of the sets of resources over which the NTCB partitions have control. Code and data structures belonging to the NTCB, transferred among NTCB subjects (i.e., subjects outside the reference monitor but inside the NTCB) belonging to different NTCB partitions, must be pro- tected against external interference or tampering. For example, a cryptographic checksum or physical means may be employed to protect user authentication data exchanged between NTCB partitions. EACH NTCB PARTITION PROVIDES ISOLATION OF RESOURCES (WITHIN ITS COMPONENT) TO BE PROTECTED IN ACCORD WITH THE NETWORK SYSTEM ARCHITECTURE AND SECURITY POLICY. + Rationale The requirement for the protection of communications between NTCB partitions is specifically directed to subjects that are part of the NTCB partitions. Any requirements for such protection for the subjects that are outside the NTCB partitions are addressed in response to the integrity requirements of the security policy. ISOLATION OF THE RESOURCES TO BE PROTECTED PROVIDES ADDITIONAL PROTECTION, COMPARED TO CLASS (C1), THAT MECHAN- ISMS THAT DEPEND ON THE RESOURCE (E.G., DAC AND USER IDEN- TIFICATION) WILL OPERATE CORRECTLY. 2.2.3.1.2 System Integrity + Statement from DoD 5200.28-STD Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. + Interpretation Implementation of the requirement is partly achieved by having hardware and/or software features that can be used to periodically validate the correct operation of the hardware and firmware elements of each component's NTCB partition. Features shall also be provided to validate the identity and correct operation of a component prior to its incorporation in the network system and throughout system operation. For example, a protocol could be designed that enables the com- ponents of the partitioned NTCB to exchange messages period- ically and validate each other's correct response. The pro- tocol shall be able to determine the remote entity's ability to respond. NTCB partitions shall provide the capability to report to network administrative personnel the failures detected in other NTCB partitions. Intercomponent protocols implemented within a NTCB shall be designed in such a way as to provide correct opera- tion in the case of failures of network communications or individual components. The allocation of discretionary access control policy in a network may require communication between trusted subjects that are part of the NTCB parti- tions in different components. This communication is nor- mally implemented with a protocol between the subjects as peer entities. Incorrect access within a component shall not result from failure of an NTCB partition to communicate with other components. + Rationale The first paragraph of the interpretation is a straightforward extension of the requirement into the con- text of a network system and partitioned NTCB as defined for these network criteria. NTCB protocols should be robust enough so that they permit the system to operate correctly in the case of local- ized failure. The purpose of this protection is to preserve the integrity of the NTCB itself. It is not unusual for one or more components in a network to be inoperative at any time, so it is important to minimize the effects of such failures on the rest of the network. Additional integrity and denial of service issues are addressed in Part II. 2.2.3.2 Life-Cycle Assurance 2.2.3.2.1 Security Testing + Statement from DoD 5200.28-STD The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. TESTING SHALL ALSO INCLUDE A SEARCH FOR OBVIOUS FLAWS THAT WOULD ALLOW VIOLATION OF RESOURCE ISOLATION, OR THAT WOULD PERMIT UNAU- THORIZED ACCESS TO THE AUDIT OR AUTHENTICATION DATA. (See the Security Testing Guidelines.) + Interpretation Testing of a component will require a testbed that exercises the interfaces and protocols of the COMPONENT INCLUDING TESTS UNDER EXCEPTIONAL CONDITIONS. The testing of a security mechanism of the network system for meeting this criterion shall be an integrated testing procedure involving all components containing an NTCB partition that implement the given mechanism. This integrated testing is additional to any individual component tests involved in the evaluation of the network system. The sponsor should iden- tify the allowable set of configurations including the sizes of the networks. Analysis or testing procedures and tools shall be available to test the limits of these configura- tions. A change in configuration within the allowable set of configurations does not require retesting. + Rationale Testing is the primary method available in this evalua- tion division to gain any assurance that the security mechanisms perform their intended function. 2.2.4 Documentation _ _ _ _____________ 2.2.4.1 Security Features User's Guide + Statement from DoD 5200.28-STD A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, interpretations on their use, and how they interact with one another. + Interpretation This user documentation describes user visible protec- tion mechanisms at the global (network system) level and at the user interface of each component, and the interaction among these. + Rationale The interpretation is an extension of the requirement into the context of a network system as defined for these network criteria. Documentation of protection mechanisms provided by individual components is required by the cri- teria for trusted computer systems that are applied as appropriate for the individual components. 2.2.4.2 Trusted Facility Manual + Statement from DoD 5200.28-STD A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. THE PROCEDURES FOR EXAMINING AND MAINTAINING THE AUDIT FILES AS WELL AS THE DETAILED AUDIT RECORD STRUCTURE FOR EACH TYPE OF AUDIT EVENT SHALL BE GIVEN. + Interpretation This manual shall contain specifications and procedures to assist the system administrator(s) maintain cognizance of the network configuration. These specifications and pro- cedures shall address the following: 1. The hardware configuration of the network itself; 2. The implications of attaching new components to the network; 3. The case where certain components may periodically leave the network (e.g., by crashing, or by being disconnected) and then rejoin; 4. Network configuration aspects that can impact the security of the network system; (For example, the manual should describe for the network system administrator the interconnections among components that are consistent with the overall network system architecture.) 5. Loading or modifying NTCB software or firmware (e.g., down-line loading). The physical and administrative environmental controls shall be specified. Any assumptions about security of a given network should be clearly stated (e.g., the fact that all communications links must be physically protected to a certain level). + Rationale There may be multiple system administrators with diverse responsibilities. The technical security measures described by these criteria must be used in conjunction with other forms of security in order to achieve security of the network. Additional forms include administrative security, physical security, emanations security, etc. Extension of this criterion to cover configuration aspects of the network is needed because, for example, proper interconnection of components is typically essential to achieve a correct realization of the network architec- ture. Cryptography is one common mechanism employed to pro- tect communication circuits. Encryption transforms the representation of information so that it is unintelligible to unauthorized subjects. Reflecting this transformation, the sensitivity of the ciphertext is generally lower than the cleartext. If encryption methodologies are employed, they shall be approved by the National Security Agency (NSA). The encryption algorithm and its implementation are outside the scope of these interpretations. This algorithm and implementation may be implemented in a separate device or may be a function of a subject in a component not dedi- cated to encryption. Without prejudice, either implementa- tion packaging is referred to as an encryption mechanism herein. 2.2.4.3 Test Documentation + Statement from DoD 5200.28-STD The system developer shall provide to the evaluators a docu- ment that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing. + Interpretation The "system developer" is interpreted as "the network system sponsor". The description of the test plan should establish the context in which the testing was or should be conducted. The description should identify any additional test components that are not part of the system being evaluated. This includes a description of the test-relevant functions of such test components and a description of the interfacing of those test components to the system being evaluated. The description of the test plan should also demonstrate that the tests adequately cover the network security policy. The tests should include the features described in the System Architecture and the System Integrity sections. The tests should also include network configuration and sizing. + Rationale The entity being evaluated may be a networking subsys- tem (see Appendix A) to which other components must be added to make a complete network system. In that case, this interpretation is extended to include contextual definition because, at evaluation time, it is not possible to validate the test plans without the description of the context for testing the networking subsystem. 2.2.4.4 Design Documentation + Statement from DoD 5200.28-STD Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an expla- nation 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. + Interpretation Explanation of how the sponsor's philosophy of protec- tion is translated into the NTCB shall include a description of how the NTCB is partitioned. The security policy also shall be stated. The description of the interfaces between the NTCB modules shall include the interface(s) between NTCB partitions and modules within the partitions if the modules exist. The sponsor shall describe the security architecture and design, including the allocation of security require- ments among components. Appendix A addresses component evaluation issues. + Rationale The interpretation is a straightforward extension of the requirement into the context of a network system as defined for this network interpretation. Other documenta- tion, such as description of components and description of operating environment(s) in which the networking subsystem or network system is designed to function, is required else- where, e.g., in the Trusted Facility Manual. In order to be evaluated, a network must possess a coherent Network Security Architecture and Design. (Inter- connection of components that do not adhere to such a single coherent Network Security Architecture is addressed in the Interconnection of Accredited AIS, Appendix C.) The Network Security Architecture must address the security-relevant policies, objectives, and protocols. The Network Security Design specifies the interfaces and services that must be incorporated into the network so that it can be evaluated as a trusted entity. There may be multiple designs that con- form to the same architecture but are more or less incompa- tible and non-interoperable (except through the Interconnec- tion Rules). Security related mechanisms requiring coopera- tion among components are specified in the design in terms of their visible interfaces; mechanisms having no visible interfaces are not specified in this document but are left as implementation decisions. The Network Security Architecture and Design must be available from the network sponsor before evaluation of the network, or any component, can be undertaken. The Network Security Architecture and Design must be sufficiently com- plete, unambiguous, and free from obvious flaws to permit the construction or assembly of a trusted network based on the structure it specifies. When a component is being designed or presented for evaluation, or when a network assembled from components is assembled or presented for evaluation, there must be a priori evidence that the Network security Architecture and Design are satisfied. That is, the components can be assem- bled into a network that conforms in every way with the Net- work Security Architecture and Design to produce a physical realization that is trusted to the extent that its evalua- tion indicates. In order for a trusted network to be constructed from components that can be built independently, the Network Security Architecture and Design must completely and unambi- guously define the security functionality of components as well as the interfaces between or among components. The Network Security Architecture and Design must be evaluated to determine that a network constructed to its specifica- tions will in fact be trusted, that is, it will be evaluat- able under these interpretations. 3.0 DIVISION B: MANDATORY PROTECTION The notion of an NTCB that preserves the integrity of sensi- tivity labels and uses them to enforce a set of mandatory access control rules is a major requirement in this divi- sion. Network systems in this division must carry the sen- sitivity labels with major data structures in the system. The network system sponsor also provides the security policy model on which the NTCB is based and furnishes a specifica- tion of the NTCB. Evidence must be provided to demonstrate that the reference monitor concept has been implemented. 3.1 CLASS (B1): LABELED SECURITY PROTECTION _ _ _____ __ _______ ________ __________ CLASS (B1) NETWORK SYSTEMS REQUIRE ALL THE FEATURES REQUIRED FOR CLASS (C2). IN ADDITION, AN INFORMAL STATEMENT OF THE SECURITY POLICY MODEL, DATA LABELING, AND MANDATORY ACCESS CONTROL OVER SUBJECTS AND STORAGE OBJECTS MUST BE PRESENT. THE CAPABILITY MUST EXIST FOR ACCURATELY LABELING EXPORTED INFORMATION. ANY FLAWS IDENTIFIED BY TESTING MUST BE REMOVED. THE FOLLOWING ARE MINIMAL REQUIREMENTS FOR NETWORK SYSTEMS ASSIGNED A CLASS (B1) RATING: 3.1.1 Security Policy _ _ _ ________ ______ + Statement from DoD 5200.28-STD Implied from the Introduction to the TCSEC. + Interpretation The network sponsor shall describe the overall network security policy enforced by the NTCB. At a minimum, this policy shall include the discretionary AND MANDATORY requirements applicable to this class. The policy may require data secrecy, or data integrity, or both. THE POL- ICY IS AN ACCESS CONTROL POLICY HAVING TWO PRIMARY COM- PONENTS: MANDATORY AND DISCRETIONARY. The policy shall include a discretionary policy for protecting the informa- tion being processed based on the authorizations of indivi- duals, users, or groups of users. This access control pol- icy statement shall describe the requirements on the network to prevent or detect "reading or destroying" sensitive information by unauthorized users or errors. THE MANDATORY POLICY MUST DEFINE THE SET OF DISTINCT SENSITIVITY LEVELS THAT IT SUPPORTS. FOR THE CLASS B1 OR ABOVE THE MANDATORY POLICY SHALL BE BASED ON THE LABELS ASSOCIATED WITH THE INFORMATION THAT REFLECTS ITS SENSITIVITY WITH RESPECT TO SECRECY AND/OR INTEGRITY, WHERE APPLICABLE, AND LABELS ASSO- CIATED WITH USERS TO REFLECT THEIR AUTHORIZATION TO ACCESS SUCH INFORMATION. UNAUTHORIZED USERS INCLUDE BOTH THOSE that are not authorized to use the network at all (e.g., a user attempting to use a passive or active wire tap) or a legitimate user of the network who is not authorized to access a specific piece of information being protected. Note that "users" does not include "operators," "system programmers," "technical control officers," "system security officers," and other system support personnel. They are distinct from users and are subject to the Trusted Facility Manual and the System Architecture requirements. Such indi- viduals may change the system parameters of the network sys- tem, for example, by defining membership of a group. These individuals may also have the separate role of users. SECRECY POLICY: The network sponsor shall define the form of the discretionary AND MANDATORY secrecy policy that is enforced in the network to prevent unauthorized users from reading the sensitive infor- mation entrusted to the network. DATA INTEGRITY POLICY: The network sponsor shall define the discretionary AND MANDATORY integrity policy to prevent unauthorized users from modifying, viz., writing, sensitive information. The defini- tion of data integrity presented by the network sponsor refers to the requirement that the informa- tion has not been subjected to unauthorized modifi- cation in the network. THE MANDATORY INTEGRITY POL- ICY ENFORCED BY THE NTCB CANNOT, IN GENERAL, PREVENT MODIFICATION WHILE INFORMATION IS BEING TRANSMITTED BETWEEN COMPONENTS. HOWEVER, AN INTEGRITY SENSI- TIVITY LABEL MAY REFLECT THE CONFIDENCE THAT THE INFORMATION HAS NOT BEEN SUBJECTED TO TRANSMISSION ERRORS BECAUSE OF THE PROTECTION AFFORDED DURING TRANSMISSION. THIS REQUIREMENT IS DISTINCT FROM THE REQUIREMENT FOR LABEL INTEGRITY. + Rationale The word "sponsor" is used in place of alternatives (such as "vendor," "architect," "manufacturer," and "developer") because the alternatives indicate people who may not be available, involved, or relevant at the time that a network system is proposed for evaluation. A trusted network is able to control both the reading and writing of shared sensitive information. Control of writing is used to protect against destruction of informa- tion. A network normally is expected to have policy require- ments to protect both the secrecy and integrity of the information entrusted to it. In a network the integrity is frequently as important or more important than the secrecy requirements. Therefore the secrecy and/or integrity policy to be enforced by the network must be stated for each net- work regardless of its evaluation class. The assurance that the policy is faithfully enforced is reflected in the evaluation class of the network. This control over modification is typically used to protect information so that it may be relied upon and to control the potential harm that would result if the informa- tion were corrupted. The overall network policy require- ments for integrity includes the protection for data both while being processed in a component and while being transmitted in the network. The access control policy enforced by the NTCB relates to the access of subjects to objects within each component. Communications integrity addressed within Part II relates to information while being transmitted. THE MANDATORY INTEGRITY POLICY (AT CLASS B1 AND ABOVE) IN SOME ARCHITECTURES MAY BE USEFUL IN SUPPORTING THE LINK- AGE BETWEEN THE CONNECTION ORIENTED ABSTRACTION INTRODUCED IN THE INTRODUCTION AND THE INDIVIDUAL COMPONENTS OF THE NETWORK. FOR EXAMPLE, IN A KEY DISTRIBUTION CENTER FOR END-TO-END ENCRYPTION, A DISTINCT INTEGRITY CATEGORY MAY BE ASSIGNED TO ISOLATE THE KEY GENERATION CODE AND DATA FROM POSSIBLE MODIFICATION BY OTHER SUPPORTING PROCESSES IN THE SAME COMPONENT, SUCH AS OPERATOR INTERFACES AND AUDIT. THE MANDATORY INTEGRITY POLICY FOR SOME ARCHITECTURE MAY DEFINE AN INTEGRITY SENSITIVITY LABEL THAT REFLECTS THE SPECIFIC REQUIREMENTS FOR ENSURING THAT INFORMATION HAS NOT BEEN SUBJECT TO RANDOM ERRORS IN EXCESS OF A STATED LIMIT NOR TO UNAUTHORIZED MESSAGE STREAM MODIFICATION (MSM) -. THE SPECIFIC METRIC ASSOCIATED WITH AN INTEGRITY SENSITIVITY LABEL WILL GENERALLY REFLECT THE INTENDED APPLICATIONS OF THE NETWORK. 3.1.1.1 Discretionary Access Control + Statement from DoD 5200.28-STD The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP sys- tem. 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 both, and shall provide controls to limit propagation of access rights. The discre- tionary access control mechanism shall, either by explicit user action or by default, provide that objects are pro- tected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users. _________________________ - See Voydock, Victor L. and Stephen T. Kent, "Secu- rity Mechanisms in High-Level Network Protocols," Com- ___ puting Surveys, Vol. 15, No. 2, June 1983, pp 135-171. ______ _______ + Interpretation The discretionary access control (DAC) mechanism(s) may be distributed over the partitioned NTCB in various ways. Some part, all, or none of the DAC may be implemented in a given component of the network system. In particular, com- ponents that support only internal subjects (i.e., that have no subjects acting as direct surrogates for users), such as a public network packet switch, might not implement the DAC mechanism(s) directly (e.g., they are unlikely to contain access control lists). Identification of users by groups may be achieved in various ways in the networking environment. For example, the network identifiers (e.g., internet addresses) for vari- ous components (e.g., hosts, gateways) can be used as iden- tifiers of groups of individual users (e.g., "all users at Host A," "all users of network Q") so long as the individu- als involved in the group are implied by the group identif- ier. For example, Host A might employ a particular group-id, for which it maintains a list of explicit users in that group, in its network exchange with Host B, which accepts the group-id under the conditions of this interpretation. For networks, individual hosts will impose need-to-know controls over their users on the basis of named individuals - much like (in fact, probably the same) controls used when there is no network connection. When group identifiers are acceptable for access con- trol, the identifier of some other host may be employed, to eliminate the maintenance that would be required if indivi- dual identification of remote users was employed. In class C2 and higher, however, it must be possible from that audit record to identify (immediately or at some later time) exactly the individuals represented by a group identifier at the time of the use of that identifier. There is allowed to be an uncertainty because of elapsed time between changes in the group membership and the enforcement in the access con- trol mechanisms. The DAC mechanism of a NTCB partition may be imple- mented at the interface of the reference monitor or may be distributed in subjects that are part of the NTCB in the same or different component. The reference monitor manages all the physical resources of the system and from them creates the abstraction of subjects and objects that it con- trols. Some of these subjects and objects may be used to implement a part of the NTCB. When the DAC mechanism is distributed in such NTCB subjects (i.e., when outside the reference monitor), the assurance requirements (see the Assurance section) for the design and implementation of the DAC shall be those of class C2 for all networks of class C2 or above. When integrity is included as part of the network dis- cretionary security policy, the above interpretations shall be specifically applied to the controls over modification, viz, the write mode of access, within each component based on identified users or groups of users. + Rationale In this class, the supporting elements of the overall DAC mechanism are required to isolate information (objects) that supports DAC so that it is subject to auditing require- ments (see the System Architecture section). The use of network identifiers to identify groups of individual users could be implemented, for example, as an X.25 community of interest in the network protocol layer (layer 3). In all other respects, the supporting elements of the overall DAC mechanism are treated exactly as untrusted subjects are treated with respect to DAC in an ADP system, with the same result as noted in the interpretation. A typical situation for DAC is that a surrogate process for a remote user will be created in some host for access to objects under the control of the NTCB partition within that host. The interpretation requires that a user identifier be assigned and maintained for each such process by the NTCB, so that access by a surrogate process is subject to essen- tially the same discretionary controls as access by a pro- cess acting on behalf of a local user would be. However, within this interpretation a range of possible interpreta- tions of the assigned user identification is permitted. The most obvious situation would exist if a global database of network users were to be made permanently avail- able on demand to every host, (i.e., a name server existed) so that all user identifications were globally meaningful. It is also acceptable, however, for some NTCB parti- tions to maintain a database of locally-registered users for its own use. In such a case, one could choose to inhibit the creation of surrogate processes for locally unregistered users, or (if permitted by the local policy) alternatively, to permit the creation of surrogate processes with preselected user and group identifiers which, in effect, identify the process as executing on behalf of a member of a group of users on a particular remote host. The intent of the words concerning audit in the interpretation is to pro- vide a minimally acceptable degree of auditability for cases such as the last described. What is required is that there be a capability, using the audit facilities provided by the network NTCB partitions involved, to determine who was logged in at the actual host of the group of remote users at the time the surrogate processing occured. Associating the proper user id with a surrogate process is the job of identification and authentication. This means that DAC is applied locally, with respect to the user id of the surrogate process. The transmission of the data back across the network to the user's host, and the creation of a copy of the data there, is not the business of DAC. Components that support only internal subjects impact the implementation of the DAC by providing services by which information (e.g., a user-id) is made available to a com- ponent that makes a DAC decision. An example of the latter would be the case that a user at Host A attempts to access a file at Host B. The DAC decision might be (and usually would be) made at Host B on the basis of a user-id transmit- ted from Host A to Host B. Unique user identification may be achieved by a variety of mechanisms, including (a) a requirement for unique iden- tification and authentication on the host where access takes place; (b) recognition of fully qualified network addresses authenticated by another host and forwarded to the host where access takes place; or (c) administrative support of a network-wide unique personnel identifier that could be authenticated and forwarded by another host as in (b) above, or could be authenticated and forwarded by a dedicated net- work identification and authentication server. The proto- cols which implement (b) or (c) are subject to the System Architecture requirements. Network support for DAC might be handled in other ways than that described as "typical" above. In particular, some form of centralized access control is often proposed. An access control center may make all decisions for DAC, or it may share the burden with the hosts by controlling host-to- host connections, and leaving the hosts to decide on access to their objects by users at a limited set of remote hosts. In this case the access control center provides the linkage between the connection oriented abstraction (as discussed in the Introduction) and the overall network security policy for DAC. In all cases the enforcement of the decision must be provided by the host where the object resides. THERE ARE TWO FORMS OF DISTRIBUTION FOR THE DAC MECHAN- ISM: IMPLEMENTING PORTIONS OF THE DAC IN SEPARATE COM- PONENTS, AND SUPPORTING THE DAC IN SUBJECTS CONTAINED WITHIN THE NTCB PARTITION IN A COMPONENT. SINCE "THE ADP SYSTEM" IS UNDERSTOOD TO BE "THE COMPUTER NETWORK" AS A WHOLE, EACH NETWORK COMPONENT IS RESPONSIBLE FOR ENFORCING SECURITY IN THE MECHANISMS ALLOCATED TO IT TO ENSURE SECURE IMPLEMENTA- TION OF THE NETWORK SECURITY POLICY. FOR TRADITIONAL HOST SYSTEMS IT IS FREQUENTLY EASY TO ALSO ENFORCE THE DAC ALONG WITH THE MAC WITHIN THE REFERENCE MONITOR, PER SE, ALTHOUGH A FEW APPROACHES, SUCH AS VIRTUAL MACHINE MONITORS, SUPPORT DAC OUTSIDE THIS INTERFACE. IN CONTRAST TO THE UNIVERSALLY RIGID STRUCTURE OF MAN- DATORY POLICIES (SEE THE MANDATORY ACCESS CONTROL SECTION), DAC POLICIES TEND TO BE VERY NETWORK AND SYSTEM SPECIFIC, WITH FEATURES THAT REFLECT THE NATURAL USE OF THE SYSTEM. FOR NETWORKS IT IS COMMON THAT INDIVIDUAL HOSTS WILL IMPOSE CONTROLS OVER THEIR LOCAL USERS ON THE BASIS OF NAMED INDIVIDUALS-MUCH LIKE THE CONTROLS USED WHEN THERE IS NO NETWORK CONNECTION. HOWEVER, IT IS DIFFICULT TO MANAGE IN A CENTRALIZED MANNER ALL THE INDIVIDUALS USING A LARGE NET- WORK. THEREFORE, USERS ON OTHER HOSTS ARE COMMONLY GROUPED TOGETHER SO THAT THE CONTROLS REQUIRED BY THE NETWORK DAC POLICY ARE ACTUALLY BASED ON THE IDENTITY OF THE HOSTS OR OTHER COMPONENTS. A GATEWAY IS AN EXAMPLE OF SUCH A COM- PONENT. THE ASSURANCE REQUIREMENTS ARE AT THE VERY HEART OF THE CONCEPT OF A TRUSTED SYSTEM. IT IS THE ASSURANCE THAT DETERMINES IF A SYSTEM OR NETWORK IS APPROPRIATE FOR A GIVEN ENVIRONMENT, AS REFLECTED, FOR EXAMPLE, IN THE ENVIRONMENTS GUIDELINE-. IN THE CASE OF MONOLITHIC SYSTEMS THAT HAVE DAC INTEGRAL TO THE REFERENCE MONITOR, THE ASSURANCE REQUIRE- MENTS FOR DAC ARE INSEPARABLE FROM THOSE OF THE REST OF THE REFERENCE MONITOR. FOR NETWORKS THERE IS TYPICALLY A MUCH CLEARER DISTINCTION DUE TO DISTRIBUTED DAC. THE RATIONALE FOR MAKING THE DISTINCTION IN THIS NETWORK INTERPRETATION IS THAT IF MAJOR TRUSTED NETWORK COMPONENTS CAN BE MADE SIGNI- FICANTLY EASIER TO DESIGN AND IMPLEMENT WITHOUT REDUCING THE ABILITY TO MEET SECURITY POLICY, THEN TRUSTED NETWORKS WILL BE MORE EASILY AVAILABLE. 3.1.1.2 Object Reuse + Statement from DoD 5200.28-STD 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. + Interpretation The NTCB shall ensure that any storage objects that it controls (e.g., message buffers under the control of a NTCB partition in a component) contain no information for which a subject in that component is not authorized before granting access. This requirement must be enforced by each of the NTCB partitions. _________________________ - Guidance for Applying the Department of Defense ________ ___ ________ ___ __________ __ _______ Trusted Computer System Evaluation Criteria in Specific _______ ________ ______ __________ ________ __ ________ Environments, CSC-STD-003-85. ____________ + Rationale In a network system, storage objects of interest are things that the NTCB directly controls, such as message buffers in components. Each component of the network system must enforce the object reuse requirement with respect to the storage objects of interest as determined by the network security policy. For example, the DAC requirement in this division leads to the requirement here that message buffers be under the control of the NTCB partition. A buffer assigned to an internal subject may be reused at the discre- tion of that subject which is responsible for preserving the integrity of message streams. Such controlled objects may be implemented in physical resources, such as buffers, disk sectors, tape space, and main memory, in components such as network switches. 3.1.1.3 Labels + Statement from DoD 5200.28-STD SENSITIVITY LABELS ASSOCIATED WITH EACH SUBJECT AND STORAGE OBJECT UNDER ITS CONTROL (E.G., PROCESS, FILE, SEGMENT, DEV- ICE) SHALL BE MAINTAINED BY THE TCB. THESE LABELS SHALL BE USED AS THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS. IN ORDER TO IMPORT NON-LABELED DATA, THE TCB SHALL REQUEST AND RECEIVE FROM AN AUTHORIZED USER THE SENSITIVITY LEVEL OF THE DATA, AND ALL SUCH ACTIONS SHALL BE AUDITABLE BY THE TCB. + Interpretation NON-LABELED DATA IMPORTED UNDER THE CONTROL OF THE NTCB PARTITION WILL BE ASSIGNED A LABEL CONSTRAINED BY THE SINGLE-LEVEL DEVICE USED TO IMPORT IT. LABELS MAY INCLUDE SECRECY AND INTEGRITY- COMPONENTS IN ACCORDANCE WITH THE OVERALL NETWORK SECURITY POLICY DESCRIBED BY THE NETWORK SPONSOR. WHENEVER THE TERM "LABEL" IS USED THROUGHOUT THIS INTERPRETATION, IT IS UNDERSTOOD TO INCLUDE BOTH COMPONENTS AS APPLICABLE. SIMILARLY, THE TERMS "SINGLE-LEVEL" AND "MULTILEVEL" ARE UNDERSTOOD TO BE BASED ON BOTH THE SECRECY AND INTEGRITY COMPONENTS OF THE POLICY. THE MANDATORY INTEGRITY POLICY WILL TYPICALLY HAVE REQUIREMENTS, SUCH AS THE PROBABILITY OF UNDETECTED MESSAGE STREAM MODIFICATION, THAT WILL BE REFLECTED IN THE LABEL FOR THE DATA SO PRO- TECTED. FOR EXAMPLE, WHEN DATA IS IMPORTED ITS INTEGRITY LABEL MAY BE ASSIGNED BASED ON MECHANISMS, SUCH AS CRYPTOG- RAPHY, USED TO PROVIDE THE ASSURANCE REQUIRED BY THE POLICY. THE NTCB SHALL ASSURE THAT SUCH MECHANISM ARE PROTECTED FROM TAMPERING AND ARE ALWAYS INVOKED WHEN THEY ARE THE BASIS FOR _________________________ - See, for example, Biba, K.J., "Integrity Considera- tion for Secure Computer Systems," ESD-TR-76-372, MTR- 3153, The MITRE Corporation, Bedford, MA, April 1977. A LABEL. + Rationale THE INTERPRETATION IS AN EXTENSION OF THE REQUIREMENT INTO THE CONTEXT OF A NETWORK SYSTEM AND PARTITIONED NTCB AS DEFINED FOR THESE NETWORK INTERPRETATIONS. A SINGLE-LEVEL DEVICE MAY BE REGARDED EITHER AS A SUBJECT OR AN OBJECT. A MULTILEVEL DEVICE IS REGARDED AS A TRUSTED SUBJECT IN WHICH THE SECURITY RANGE OF THE SUBJECT IS THE MINIMUM-MAXIMUM RANGE OF THE DATA EXPECTED TO BE TRANSMITTED OVER THE DEV- ICE. THE SENSITIVITY LABELS FOR EITHER SECRECY OR INTEGRITY OR BOTH MAY REFLECT NON-HIERARCHICAL CATEGORIES OR HIERARCH- ICAL CLASSIFICATION OR BOTH. 3.1.1.3.1 Label Integrity + Statement from DoD 5200.28-STD SENSITIVITY LABELS SHALL ACCURATELY REPRESENT SENSITIVITY LEVELS OF THE SPECIFIC SUBJECTS OR OBJECTS WITH WHICH THEY ARE ASSOCIATED. WHEN EXPORTED BY THE TCB, SENSITIVITY LABELS SHALL ACCURATELY AND UNAMBIGUOUSLY REPRESENT THE INTERNAL LABELS AND SHALL BE ASSOCIATED WITH THE INFORMATION BEING EXPORTED. + Interpretation THE PHRASE "EXPORTED BY THE TCB" IS UNDERSTOOD TO INCLUDE TRANSMISSION OF INFORMATION FROM AN OBJECT IN ONE COMPONENT TO AN OBJECT IN ANOTHER COMPONENT. INFORMATION TRANSFERRED BETWEEN NTCB PARTITIONS IS ADDRESSED IN THE SYS- TEM INTEGRITY SECTION. THE FORM OF INTERNAL AND EXTERNAL (EXPORTED) SENSITIVITY LABELS MAY DIFFER, BUT THE MEANING SHA