MODULE 15
INFORMATION SYSTEMS SECURITY
(INFOSEC)
PROGRAM GUIDELINES
0515-LP-208-8285
Distribution: Submit requests for placement on distribution (including supporting justification), or amendment to the existing distribution, to:
Commanding Officer
Naval Electronic Systems Security Engineering Center
Code 011C
3801 Nebraska Avenue, N.W.
Washington, DC 20393-5270
Commercial (202) 282-0538
DSN 292-0538
Stocked: Additional copies of NAVSO P-5239-15 can be obtained from the Navy Aviation Supply Office (Code 03415), 5801 Tabor Avenue, Philadelphia PA 18120-5099, through normal supply channels in accordance with NPFC PUB 2002D, NAVSUP P-437 or NAVSUP P-485, using AUTODIN, DAMES, or MILSTRIP message format to DAAS, Dayton, OH.
Cite stock number 0515-LP-208-8285.
Local reproduction is authorized.
DEPARTMENT OF THE NAVY
NAVAL INFORMATION SYSTEMS MANAGEMENT CENTER
WASHINGTON, D.C. 20360-5000
NAVSO P-5239-15
AUGUST 1992
FOREWORD
This publication, Navy Staff Office Publication (NAVSO Pub) 5239, "Information Systems Security (INFOSEC) Program Guidelines" is issued by the Naval Information Systems Management Center. This publication consists of a series of modules providing procedural, technical, administrative and/or supplemental guidance for all information systems, whether business or tactical, used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission or reception of data. Each module will focus on a distinct program element, and will establish a standard methodology for planning, implementing and executing the INFOSEC program within the Department of the Navy (DON).
This module, "Controlled Access Protection (CAP) Guidebook", provides the Information Systems Security Manager (ISSM)/Automated Data Processing Security Officer (ADPSO) with guidance and procedures to be used for CAP implementation. CAP describes the minimum set of automated controls that should be provided to DON Automated Information Systems (AISs); the DON interpretation of the "Class C2" features/functionality requirement of DODDIR 5200.28 and SECNAVINST 5239.2.
Instructions herein are issued for the information and compliance of all persons in the DON and are effective upon receipt.
R. M. MOORE
Rear Admiral, SC, USN
TABLE OF CONTENTS
Topic Page
1. Purpose 1
2. Scope 1
3. Definitions 2
a. Controlled Access Protection (CAP) 2
b. "Class C2" 2
c. Information Sensitivity 2
d. Security Modes of Operation 2
(1) Dedicated Security Mode 3
(2) System High Security Mode 3
(3) Multilevel Security Mode 3
(4) Controlled Security Mode 3
4. CAP Requirement 3
a. Background 3
b. CAP Controls 3
c. "Class C2" Criteria 4
d. Summary 4
5. CAP Feature Waiver Criteria 5
a. Authority 5
b. Alternative Protection Requirements 6
c. Limitations 6
d. Annual Waiver Review 6
e. Submission of Waiver Requests 6
6. CAP Assessment 7
a. Types of Assessments 7
(1) Basic Assessment 7
(2) Detailed Assessment 7
(3) Recognized-Authority Assessment 8
b. Assessment Considerations 8
c. Security Mode Determination 9
(1) Dedicated Security Mode AISs 9
(2) Multilevel Security or Controlled Mode AISs 9
d. Inherent AIS Assessment Risks 10
e. Assessment Selection Guide 10
APPENDIX A TECHNICAL CONSIDERATIONS FOR CONTROLLED ACCESS PROTECTION (CAP) FEATURE IMPLEMENTATION A - 1
APPENDIX B CONTROLLED ACCESS PROTECTION (CAP) WAIVER APPROVING AUTHORITIES (WAAs) B - 1
DEPARTMENT OF THE NAVY
CONTROLLED ACCESS PROTECTION (CAP) GUIDEBOOK
Ref: (a) DODDIR 5200.28, Security Requirements for Automated Information Systems (AIS)
(b) SECNAVINST 5239.2, Department of the Navy Automated Information Systems (AIS) Security Program
(c) DOD 5200.28-STD, Trusted Computer Security Evaluation Criteria
(d) NCSC-TG-018, A Guide to Understanding Object Reuse in Trusted Systems
(e) NCSC-TG-005, Trusted Network Interpretation
(f) NCSC-TG-021, Trusted Database Interpretation
(g) FIPS PUB 102, Guideline for Computer Security Certification and Accreditation
(h) NCSC-TG-XXX, Guidance for Conducting a Technical Analysis of Controlled Access Protection (draft)
(i) NAVSO P-5239-10, Department of the Navy Information Systems Security Guidelines, Assessed Products List
(j) NCSC-TG-009 Version-1, Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria
1. Purpose. ; ;This document provides guidance and procedures for implementing Controlled Access Protection (CAP) in Department of the Navy (DON) Automated Information Systems (AISs). References (a) and (b) require implementation of "Class C2" features/functionality on all General Service (GENSER) classified and sensitive unclassified Automated Information Systems (AISs) by calendar year 1992. For purposes of DON implementation, this "Class C2" requirement has been interpreted in functional terms...a CAP requirement.
2. Scope. ; ;The CAP requirement applies to all DON AISs processing GENSER classified or sensitive unclassified information (this includes operational AISs, those under development, or in the acquisition pipeline). AISs accredited outside of the DON (i.e., AISs under the purview of the Chief of Naval Operations (N514), the Naval Security Group Command, and the Naval Intelligence Command) will comply with their respective CAP security requirements. The nature of the DON mission, accompanied by connectivity and data aggregation issues, has led to the determination that all DON unclassified systems are sensitive. This guideline applies to all platforms (e.g., tactical or mission support stand-alone microcomputer, Local Area Network (LAN), minicomputer system, mainframe system, or any other type of networked AISs). (Note: Dedicated mode systems do not necessarily require automated access and accountability controls; however, they still require protection.)
3. Definitions. The following terms are essential to understanding CAP concepts.
a. Controlled Access Protection (CAP). A term which describes the minimum set of automated controls that should be provided to DON AISs (i.e., discretionary access control (DAC), user identification and authentication (I&A), auditing of security-relevant events, and clearing of memory and storage before reuse. CAP applies to a system and shall be implemented to enforce the system-specific information protection policy; and, the level of assurance associated with the implementation shall correspond to the local risk.
b. "Class C2". A set of criteria for evaluating the security features and level of assurance provided by a product...defined in reference (c), it does not specify or address how to implement the required security features to support system-specific information protection policies. "Class C2" applies to products ... both commercially-available products (e.g., operating systems, database management systems, and the like) and custom-developed software, firmware and hardware products ... and the level of trust associated with their performance.
c. Information Sensitivity.
(1) Sensitivity of unclassified information shall be determined in accordance with applicable information protection policies regarding information sensitivity and requirements for its control. Sensitivity shall also be considered with respect to unauthorized disclosure and/or modification. For example, policies relating to the sensitivity of medically privileged information indicate that such data is highly sensitive to unauthorized disclosure and/or modification. However, policies pertaining to routine administrative or office correspondence information may indicate that such information has a relatively low sensitivity to unauthorized disclosure and/or modification.
(2) The effect of data aggregation and inference shall be considered when determining the sensitivity of information. Some elements, when considered separately, may each be of relatively low sensitivity; however, when considered collectively, these same elements become significantly more sensitive to unauthorized disclosure. These effects shall be considered in the process of choosing an appropriate assessment alternative.
d. Security Modes of Operation. ; ;Risks to the integrity, confidentiality, and availability of information are inherent to multi-user computing environments. This occurs since some, but not all, information and/or system capabilities will be shared by the users. These risks also vary, in part, depending on the security mode in which an AIS operates. Most DON AISs operate in one of the following security modes:
(1) Dedicated Security Mode. ; ;An AIS is operating in the dedicated mode when all of its users possess the proper security clearance and have need-to-know for accessing all data processed and stored by the AIS. AISs containing only unclassified information, as well as those containing both unclassified and classified information, can operate in the dedicated mode. All information is handled at the highest classification processed by the system.
(2) System High Security Mode. ; ;An AIS is operating in the system high mode when all of its users possess the proper security clearance, but do not necessarily have a need-to-know for accessing all data processed and stored by the AIS. AISs containing only unclassified information, as well as those containing both unclassified and classified information, can operate in the system high mode. All information is handled at the highest classification processed by the system.
(3) Multilevel Security Mode. ; ;An AIS is operating in the multilevel mode when one or more of its users do not possess the proper security clearance for accessing the most sensitive classified data processed and stored by the AIS. Data classification labels maintained by the system can be trusted.
(4) Controlled Security Mode. ; ;An AIS is operating in controlled mode, a reduced form of multilevel mode, when a more limited degree of trust is placed in the AIS and the classification and clearance levels are restricted.
4. CAP Requirement. All DON AISs shall be reviewed for compliance with the CAP requirement by 31 December 1992. Designated Approving Authorities (DAAs) shall ensure that all AISs under their jurisdiction are assessed for CAP compliance. DAAs shall document the system-specific information protection policy and corresponding CAP feature compliance for each AIS, and include such documentation as a permanent part of the AIS accreditation records.
a. Background. ; ;The DON is currently experiencing an information technology revolution, evidenced by increasingly sophisticated computer technology within virtually every DON activity. As advances in automation continue, coping with increased risks to information and systems is a critical aspect that must be addressed. Since these computer security risks are multi-faceted, reducing them to an acceptable level of risk requires solutions that effectively balance automated, procedural, physical, and personnel controls.
b. CAP Controls. ; Controls provided by an AIS to ensure a fundamental level of protection:
(1) Protection and control over who can log on to the system.
(2) Mechanisms that enable the AIS to make decisions regarding access to protected resources based upon the explicit permissions granted to or by its users (with no guarantees that concerted, malicious actions cannot circumvent these mechanisms).
(3) The capability to generate a reliable log of user actions and to assure its correctness to the extent that a discretionary access control policy is also adequately enforced (i.e., executing an ill-behaved or malicious program will not be identified as a security breach, since it does not violate the DAC policy rules).
(4) Mechanisms that enable the AIS to ensure that residual information left from one user's process will not be available to another user's process when the object containing that information is reused. Reference (d) should be consulted for more specific guidance on object reuse. Note, Appendix A describes CAP features in detail.
c. "Class C2" Criteria. ; ;
(1) Background. ; ;DOD recognized the general need for CAP features in AISs. One of DOD's most significant responses to this need was to establish a "Class C2" (Controlled Access Protection) policy (reference (a)). This policy is implemented within the DON by reference (b). An underlying objective of this policy was to spur the development and commercial availability of products which provide the necessary controls to enforce discretionary access control-based information protection principles.
(2) Criteria. ; ; The "Class C2" criteria of reference ;(c), commonly known as the "Orange Book", prescribes a set of product design and evaluation criteria, or "classes", that meet hierarchically-ordered requirements for the security features and assurance characteristics needed to satisfy a range of control objectives. The Orange Book criteria are satisfied through features implemented in software, firmware, and/or hardware, and rigorous assurances achieved through managed design practices, documentation, and testing.
d. Summary.
a. The fundamental CAP principles used in this guideline are based on "Class ;C2" criteria developed for multi-user single computers (reference (c)). Interpretations have been produced for networks and databases (references (e) and (f)). In each case, however, the focus is on the design, implementation, and evaluation of products, not application systems.
b. While "Class C2" products provide the necessary foundation for achieving CAP, using a "Class C2" product, by itself, does not necessarily ensure that its associated system, viewed in its entirety, has the required controls to enforce the specific information protection policies which may apply to the AIS. Additional CAP controls may be needed in the application software, the network architecture, or in other protection domains.
c. "Class C2" products can play a significant, but not necessarily complete, role in providing the security controls required to enforce the information protection policies for an AIS (e.g., the discretionary access control-based information protection policies).
For example, consider a microcomputer-based LAN that uses a file server. The LAN file server may be implemented using an operating system with CAP features. However, the file server cannot provide CAP for data processed on the end-user microcomputers that are part of the LAN ... it can only control the data while the data is centrally stored on the file server. Furthermore, if the file server contains database products which do not use the LAN operating system security features, then the file server operating system may have no role in enforcing applicable information protection policies over data handled by the database product. Instead, the database product may be entirely responsible for controlling access to database records (or fields or whatever type of data object requires protection in accordance with the specific information protection policies that apply).
In this example, the use of a product with CAP features would contribute significantly towards the ability to enforce CAP on the microcomputer-based LAN. By itself, however, the LAN operating system would be insufficient to enforce CAP. Additional controls within the database product would be needed to enforce the applicable information protection policies.
5. CAP Feature Waiver Criteria.
a. Authority. ; ;Where there is a compelling cost or technical reason why a CAP feature cannot be implemented, that feature requirement may be temporarily waived by the Waiver Approving Authorities (WAAs) authorized by the Secretary of the Navy (see Appendix B). Waivers do not alleviate the responsibility to achieve compliance with CAP policy. WAAs are responsible for formally granting a waiver, and for ensuring that local DAAs implement alternative mechanisms, develop plans for achieving compliance, and budget for resources required to procure automated controls. WAAs are also responsible for ensuring that local DAAs conduct an annual review of all waivers until such time as full compliance with the CAP policy is achieved.
Stipulations for DOS-based and Macintosh personal computers.
All AISs shall incorporate I&A; however, for DOS-based and Macintosh personal computers, WAAs may require implementation of only a subset of the other CAP features.
WAAs may delegate waiver authority only for DOS-based and Macintosh personal computers, as deemed appropriate.
b. Alternative Protection Requirements. ; ;In those instances where the CAP feature requirement is waived, a cost-effective approximation of CAP controls shall be implemented to enforce discretionary information protection and accountability policies which apply to the AIS. For example, one alternative strategy would be to use security products which provide controls in accordance with the set of criteria in reference (j) for computer security subsystems.
c. Limitations. ; ;Waivers do not alleviate the responsibility to achieve CAP safeguard features. The requirement to implement CAP remains in effect for all AISs within the scope of this document. A waiver is simply an acknowledgement that a sound basis exists to use features which do not fully comply with CAP, but which provide an appropriate level of security given the applicable cost-benefit considerations for the AIS.
d. Annual Waiver Review. ; ;WAAs will ensure an annual review of any waivers granted under these guidelines until CAP features have been implemented. Initial requests and all review documentation shall be maintained as part of the permanent accreditation records.
e. Submission of Waiver Requests. ; ;All requests shall be submitted to the appropriate WAA through the applicable chain of command. Initial requests must be submitted by 31 December 1992. (Requests should be clear and concise and not exceed three pages in length). The following elements constitute the minimum mandatory information for submission of a waiver request:
(1) A description of the AIS, including its system configuration and major hardware and software components. Identify any CAP features which are implemented.
(2) The information protection policy applicable to the AIS, based on the sensitivity and value of the data processed. Sensitivity shall be addressed from the standpoints of confidentiality, integrity, and availability.
(3) A description of the nature and size of the authorized user community.
(4) An explanation of significant risks and any interim mitigating factors which have the effect of reducing the risk for the AIS.
(5) A brief, concise cost-benefit analysis (in either qualitative or quantitative terms) which justifies the waiver request.
(6) A requested duration period for the waiver which corresponds to the justification provided (may be "indefinite" for specific DOS-based and Macintosh AIS CAP features).
(7) A plan for achieving compliance with the CAP policy, including relevant milestones and a time schedule (may not apply to DOS-based and Macintosh AIS waiver requests).
6. CAP Assessment. ; ;The degree of analysis and/or testing required to verify CAP feature compliance will be based on the sensitivity of the information, the risks to its security, and the cost of alternative assessment approaches. In this regard, assessment alternatives can be generally divided into the following three categories (hierarchically-ordered in terms of the anticipated rigor of analysis and testing):
a. Types of Assessments.
(1) Basic Assessment. ; ;A Basic Assessment is used to determine the existence of the set of CAP features within an AIS product. The existence of the set of CAP features can be determined through documentation reviews and analysis. However, a Basic Assessment does not encompass tests of specific features. A Basic Assessment is sufficient for AIS environments in which the information sensitivity to unauthorized disclosure or modification is low. Reference (g) should be consulted for more specific guidance concerning Basic Assessments. (NOTE: This assessment applies only to the verification that CAP features supposedly exist and are implemented in a manner that enforces the appropriate information protection policy...it in no way presumes any product evaluation.)
(2) Detailed Assessment. ; ;A Detailed Assessment is used to determine whether the CAP features within an AIS product actually function as described or claimed. A Detailed Assessment verifies the positive conclusions of a Basic Assessment. It provides a higher level of confidence than a Basic Assessment alone because it includes testing specific controls. A Detailed Assessment is required for AIS environments in which information sensitivity to unauthorized disclosure or modification is high, but the AIS assessment risks are considered to be relatively low. If it is cost-beneficial, a Detailed Assessment may also be done in conjunction with a Basic Assessment for AIS environments characterized by low information sensitivity. References (g) and (h) should be consulted for more specific guidance concerning Detailed Assessments. (NOTE: This assessment applies only to the verification that CAP features exist, function as described or claimed, and are implemented in a manner that enforces the appropriate information protection policy...it in no way presumes any product evaluation.)
(3) Recognized-Authority Assessment. ; ;A Recognized-Authority Assessment is similar in concept to the Detailed Assessment. However, it not only verifies the CAP features of the AIS, but also considers the product documentation and life cycle assurance. Its verification also provides greater confidence that a product meets the CAP criteria because the assessment is conducted by or authorized and reviewed by organizations with established credibility in systems security analysis and testing. At the current time, DON recognizes the credibility of the following organizations with respect to CAP or "Class C2"-compliance assessments for AIS products:
NCSC (National Computer Security Center)
NESSEC (Naval Electronic Systems Security
Engineering Center)
NRL (Naval Research Laboratory)
AFCSC (Air Force Cryptologic Support Center)
Information on products which have received Recognized-Authority Assessments may be found in reference (i). When using Recognized-Authority Assessments, consideration should be given to any disparities that exist between the version of the product evaluated by the Recognized Authority and the version of the product being planned for use or currently implemented. If the versions are not the same, the risks associated with inferring conclusions about unassessed versions, based upon the results of assessments of subsequent or preceding product versions, shall be considered. (NOTE: This assessment applies to the verification that the CAP product functions as described or claimed, and is implemented, with supporting assurances, in a manner that enforces a specific information protection policy.)
b. Assessment Considerations. ; ;While the CAP assessment approaches are identified in hierarchical order with respect to the degree of confidence they provide, this does not necessarily mean that the assessment costs (whether they be measured in dollars, operational impact, or otherwise) are always lowest for using a Basic Assessment and highest for a Recognized-Authority Assessment. For example, it would probably be more cost-effective for many mainframe systems to implement a Recognized-Authority assessed CAP featured or "Class C2" operating system or "add-on" security package combination (e.g., MVS with RACF, ACF2 or TOP SECRET) rather than attempt to conduct a Detailed Assessment using in-house resources. However, for other types of systems where the market for CAP-featured products is significantly less developed or the task of assessing is less complex, it may be more appropriate and/or more cost-beneficial to rely upon the Basic or Detailed Assessment alternatives.
c. Security Mode Determination. ; ;Each security mode determination must consider the AIS itself, its user community(ies), and the sensitivity of its data. An AIS must be considered to be as large as its network when determining its mode of operation, user community, and sensitivity level(s). That is, an AIS encompasses the full extent of electronic connection(s) among its component processors.
For example, a stand-alone microcomputer, not connected to any other processor through electronic communications, may be considered by itself when identifying the AIS's user communities and determining data sensitivity level(s). However, if this same microcomputer were connected to a LAN, then the AIS would be the combination of the microcomputer and each of the other processors on the LAN. In this case, the users and the data sensitivity of the entire LAN, including each connected microcomputer, shall be considered to determine the mode in which the AIS operates (i.e., which security clearance and need-to-know attributes apply).
(1) Dedicated Security Mode AISs. ; ;By definition, CAP controls are not necessarily required to be fully implemented for systems which operate in the dedicated mode. While such AISs do not necessarily require automated access and accountability controls, they still require protection.
For example, they need other protective measures to distinguish non-registered persons (i.e., those who are not authorized to access the system) from registered system users. They also require controls for restricting non-registered users from accessing data processed and stored by the AIS. Dedicated mode AISs may also require controls to ensure the integrity and availability of the information consistent with applicable information protection policies. Finally, they may require some types of accountability controls. While these controls are most often implemented using manual procedures, physical, and personnel controls, they can often be efficiently implemented by automated features.
(2) Multilevel Security or Controlled Mode AISs. ; ;For multilevel or controlled mode AISs, CAP controls represent only a subset of the required controls. CAP is inadequate to protect classified information from access by insufficiently cleared system users for two reasons. First, CAP systems do not include appropriate security features for enforcing mandatory (as opposed to discretionary) information protection policies. That is, discretionary information protection policies do not allow for security administrator domination in authorizing access. Second, CAP systems are not designed with a sufficient level of assurance to compensate for risks associated with having classified information and inappropriately cleared users on the same system. Thus, this document does not address the specific security features and the level of assurance required for AISs operating in the multilevel or controlled modes.
d. Inherent AIS Assessment Risks. ; ;The following are examples of factors to consider when evaluating inherent AIS assessment risks. It is not necessarily an all-inclusive list.
Complexity of the product to be assessed.
Nature and size of the authorized user community who accesses the AIS in which the product will reside.
Complexity and extent of the AIS configuration in which the product will reside.
Configuration differences from previously evaluated products.
Nature and extent of the product's interaction with other software and/or hardware of the AIS in which it will reside.
Extent to which the product will be relied upon to enforce the applicable policies mandated to protect information (e.g., classification guides, Privacy Act of 1974).
Consider, for example, the inherent AIS assessment risks associated with evaluating a general purpose operating system for mainframe or minicomputer systems. Such risk would almost always be considered high because such operating systems are typically very complex and often must be relied upon to enforce significant aspects of information security policies relevant to resident data and programs. It should be noted that almost all products or development efforts which claim "Class C2" compliance are likely to involve relatively complex technology and will often be used in areas involving high risk.
e. Assessment Selection Guide. ; ;The following table summarizes the acceptable approaches for assessing compliance with the CAP requirement, depending upon data sensitivity and AIS control risks. Where there is a choice of approaches, the most cost-beneficial approach shall be employed. It should be noted that the costs of the respective assessment approaches cannot necessarily be inferred by Table 1. Selection of the proper assessment approach shall be determined on a case-specific basis.
INHERENT AIS ASSESSMENT
RISKS
LOW HIGH
INFORMATION LOW Basic or Detailed or Basic or Detailed or
SENSITIVITY Recognized- Authority Recognized-Authority
HIGH Detailed or Recognized- Authority
Recognized-Authority
TABLE 1
THIS PAGE INTENTIONALLY BLANK
APPENDIX A
TECHNICAL CONSIDERATIONS FOR
CONTROLLED ACCESS PROTECTION (CAP)
FEATURE IMPLEMENTATION
Ref: (a) DOD 5200.28-STD, Department of Defense Trusted Computer System Evaluation Criteria
(b) NCSC-TG-017, A Guide to Understanding Identification and Authentication in Trusted Systems
(c) NCSC-TG-003, A Guide to Understanding Discretionary Access Control in Trusted Systems
(d) NCSC-TG-018, A Guide to Understanding Object Reuse in Trusted Systems
(e) NAVSO P-5239-26, Department of the Navy Information Systems Security Guidelines, Remanence Security Guidebook
(f) NCSC-TG-001, A Guide to Understanding Audit in Trusted Systems
1. CAP. CAP contains a fundamental set of security functions regardless of design, implementation, or platform selection. The Trusted Computing Base is the architectural foundation for these security functions. They include: Identification and Authentication, Discretionary Access Control, Object Reuse, and Audit. Since these functions are interrelated in ways where deficiencies in one area can adversely affect the others, both individual and combined performance shall be considered.
2. Definitions. The CAP feature descriptions in this enclosure are for education and illustration purposes. If exact semantics are required, reference (a) should be consulted. The two terms below are fundamental for understanding DOD trusted computer systems and CAP.
a. Object. Any passive entity that contains or receives information (e.g., files, directories, records, blocks, pages, segments, programs, video displays, printers). Access to an object implies access to the information it contains.
b. Subject. Any active entity in the system (e.g., person, process (i.e., an executing program), or device) that causes information to flow among objects or changes the system state (e.g., from operating on behalf of the system to operating on behalf of the user).
3. Trusted Computing Base. Controlled access protection features are contained in a Trusted Computing Base (TCB) (for purposes of this discussion, those modules of code containing the security function). The TCB enforces a security policy which, with some degree of assurance, makes sure the CAP features cannot be readily circumvented by higher level system features (application programs) or users. For any AIS, the TCB includes all software, firmware, and hardware components responsible for enforcing the security policy as well as components that may affect the correct operation of the security mechanisms. Thus, the TCB includes components that perform security functions required to enforce the security policy (e.g., programs that check file access control settings) and components that have no direct functionality relative to the security policy, but require privilege(s) to operate and therefore shall be trusted (e.g., an device driver dealing directly with the underlying hardware).
a. TCB Elements. ; ;As the basis of CAP, a "Class C2" TCB supporting CAP is typically large, dispersed, and generally unstructured. Although its elements are difficult to analyze, the TCB shall have these characteristics:
(1) The TCB shall maintain a domain (sometimes called a privileged address space) for its own execution that protects it from external interference or tampering.
(2) Protected resources controlled by the TCB may be a subset of subjects and objects in the system.
(3) The TCB shall isolate protected resources so that they are subject to access control and auditing.
b. TCB Element Scope. ; ;The scope for a TCB depends on the AIS being protected (network or single system) and the granularity of its protected entities (files, memory areas, or database fields). While in limited cases (e.g., where a database manager is the only user application interface), the TCB can reside solely in the application, normally, the TCB begins at the operating system (including the network level) and encompasses those trusted applications necessary to support the AIS's security policy. Thus, typical multi-user operating systems shall maintain privileged states (instruction and/or address capabilities) separate from those available to user programs.
4. Identification and Authentication (I&A). CAP mechanisms ultimately depend upon the trustworthiness inherent in the AIS's I&A mechanisms. Unless trust can be placed in the system's ability to accurately, consistently, and positively identify each user, and to maintain that positive identification throughout the user's log-on session, controlled access protection cannot be assured. Moreover, any audit data collected cannot be reliably used for personal accountability. For this reason, if the system lacks acceptable I&A mechanisms, it cannot be CAP compliant. Reference (b) discusses the I&A requirement at length and provides guidance on how to design and implement effective I&A mechanisms.
a. I&A Objectives. ; ;CAP seeks to control users' access to information in the AIS; specifically, information contained in objects to which users can refer by name (e.g., files). All forms of access control rely on the system's ability to identify users and to prove their identity when they log on to the system, and to maintain a positive association between each individual user and the actions for which he or she is responsible.
b. I&A Mechanisms. ; ;Identification is generally implemented by simply asking for a log-on name, usually associated in some way with the person's identity. This name is checked against the system's authorized users. Then, to protect against an unauthorized user's masquerading as the authorized user, the system asks for some "proof" (authentication) that the user is whom he or she claims to be. One or more of three types of "proof" is generally used for authentication: (1) something the user knows (e.g., a password); (2) something the user has (e.g., an authentication device); or, (3) something the user is (e.g., a retinal scan).
c. I&A Integrity Considerations. Most AISs implement I&A using the simple, but acceptable, log-on name and password technique. Other AISs strengthen their password mechanisms by enforcing rules such as aging and length requirements, or by providing random-password generators. However, as with any mechanism, the integrity of the password protection is only as strong as the integrity and responsibility of the users. In any event, passwords should be difficult to guess, protected (including during their passage through a network), and changed regularly.
5. Discretionary Access Control (DAC). Controlled Access Protection enforces a security policy principle known as "Discretionary Access Control." DAC features restrict access to named objects based upon the identity of subjects and/or groups to which they belong. In systems that have DAC features, a data "owner" can protect and control objects by specifying which users or user groups may have access to them.
a. DAC Mechanism Types. ; ;Five mechanisms have been used to implement DAC:
(1) Access Control Lists (ACL), which implement a matrix, where the columns represent users, the rows represent protected objects, and each cell indicates the type of access to granted for the associated subject-object pair.
(2) Protection Bits, which use a bit vector, where each bit represents a type of access. The most common example is the UNIX nine-bit vector reflecting read, write, and execute access to be a granted to the object's owner, a group, and everyone else.
(3) Capabilities, in which access to a protected object is granted if the requester possesses the appropriate "capability" that both identifies the object and specifies the access rights to be allowed to the user who possesses that capability.
(4) Profiles, which associate each user with a list of protected objects that the user may access.
(5) Passwords, which associate one password for all types of access or multiple passwords for different types of access.
b. DAC Precautions. ; ;These mechanisms are described in greater depth in reference ;(c). DAC provides individual users and groups the ability to specify whether other users and groups on the AIS should be given access to their objects (e.g., files and directories) and, if so, the kinds of access they should be given. However, while most DAC implementations can adequately protect objects in many circumstances, they do not defend against ill-behaved or malicious programs on the system. This occurs because as such programs run, they often assume the privileges associated with the user who invoked them. Subsequently, these programs may be able to transfer privileges to a third-party who would otherwise be forbidden to have them. Therefore, DAC-enforced access rules are insufficient for protecting objects with different classification levels or categories (strict or formal need-to-know separation).
6. Object Reuse. To meet the object reuse requirement, the AIS shall ensure that residual information left by one user's process will not be available to another user's process when the object containing that information is reused. The objective is to prevent information from being inadvertently (and by extension, deliberately) disclosed to unauthorized users. In contrast with the DAC mechanism, which seeks to protect the information containers themselves (i.e., named objects), the object reuse requirement seeks to protect the information contained in those objects. Several approaches for meeting the object reuse requirement exist and are specific to the object containers being considered. Whether the object reuse mechanisms operate "before" use or "after" use is a designer's choice -- either method is acceptable. References (d) and (e) provide detailed information about object reuse mechanisms.
7. Audit. Audit features support DOD policy requirements for assigning personal accountability for actions taken while accessing or using an AIS, its features, and/or information. While auditing can determine what went wrong, it is equally valuable for determining what went right. Importantly, audit policy requires that the AIS be capable of auditing, but not that it actually performs auditing. Determining which auditable events to select for the system is a DAA responsibility. The Information System Security Officer (ISSO) responsible for the AIS activates the specific mechanisms or functions accordingly.
a. Audit Mechanisms. ; ;Audit is the capability to record, examine, and review security-relevant activities for an AIS either as they occur or retrospectively. Real-time auditing capabilities are not required in order to meet CAP objectives. Rather, the AIS shall audit features that can be configured to record the set of events specified by the DAA, to present this information in a useful manner when needed, and to monitor users' actions in order to anticipate and potentially neutralize impending security attacks. Reference (f) discusses five objectives of an audit mechanism:
(1) For reviewing access patterns for individual objects, access histories for specific processes and users, and the use (or abuse) of various protection mechanisms and their effectiveness.
(2) For detecting repeated attempts to bypass protection mechanisms.
(3) For monitoring use of privileged functions or capabilities.
(4) For deterring habitual attempts to bypass the system protection mechanisms (i.e., users know that their actions can and may be audited).
(5) To provide additional assurance that the protection mechanisms are working as specified.
b. Audit Integrity Considerations. ; ;As stated earlier, audit mechanism integrity depends on I&A mechanism integrity. That is, unless users can be positively identified, actions cannot be correctly associated with them. As with all CAP mechanisms, audit features shall be implemented by the TCB. Moreover, only specially privileged System Administrators (or other Trusted Officials) should be able to invoke or curtail auditing as well as to configure the audit mechanism itself (e.g., events to be recorded). Furthermore, audit trail data shall be strictly protected by the TCB against unauthorized modification or loss (e.g., a circular file recording technique might overflow); only designated persons should be able to read audit trail data.
c. Audit Trail Events. ; ;The AIS shall be able to record the following types of events:
Use of identification and authentication mechanisms (i.e., log-on).
Introduction of objects into a user's address space (e.g., file open, file creation, program execution, file rename).
Deletion of objects from a user's address space (e.g., file close, completion of program execution, file deletion).
Actions taken by computer operators and system administrators (e.g., adding a user).
All security-relevant events (e.g., use of privileges, changes to DAC parameters).
Producing printed output.
d. Audit Trail Event Records. ; ;For each auditable event, the following information shall be recorded:
Date and time of the event.
Unique identifier of the user on whose behalf the program generating the event was operating.
Type of event (one of the above).
Success or failure of the event.
Origin of the request (e.g., terminal identifier) for identification and authentication events.
Name of the object that was introduced into or deleted from the user's address space.
Description of modifications that the system administrator makes to the security databases.
e. Audit Trail Tools. ; ;The System Administrator shall be able to audit on individual or object identity. Whether the system allows the System Administrator to pre-specify individuals and/or objects, or a post-processor is available to extract data associated with specified individuals and/or objects, is an implementation decision. Either approach is acceptable.
f. Audit Precautions. ; ;Based upon operational requirements the DAA may select a subset of the items and their attributes (e.g., granularity -- data set volume versus data set file) described above for implementation as audit capabilities in an AIS. While this is acceptable under DON CAP guidance, the DAA should understand that these reductions will be a deviation from historically effective auditing capabilities.
APPENDIX B
CONTROLLED ACCESS PROTECTION (CAP)
WAIVER APPROVING AUTHORITIES (WAAs)
Assistant for Administration, Office of the Under Secretary of the Navy
Chief, Bureau of Medicine and Surgery
Chief, Bureau of Naval Personnel
Chief of Naval Education and Training
Chief of Naval Operations (N65E (OP-094), N514 (OP-651E))
Chief of Naval Research
Commandant of the Marine Corps (C4I)
Commander-in-Chief, Atlantic Fleet
Commander-in-Chief, Pacific Fleet
Commander-in-Chief, U.S. Naval Forces, Europe
Commander, Marine Corps Air Bases, Eastern Area
Commander, Marine Corps Air Bases, Western Area
Commander, Marine Corps Bases, Atlantic
Commander, Marine Corps Bases, Pacific
Commander, Marine Corps Logistics Bases, Albany, GA
Commander, Naval Air Systems Command
Commander, Naval Computer and Telecommunications Command
Commander, Naval District Washington
Commander, Naval Facilities Engineering Command
Commander, Naval Information Systems Management Center
Commander, Naval Investigative Service Command
Commander, Naval Legal Services Command
Commander, Naval Oceanographic Command
Commander, Naval Reserve Force
Commander, Naval Sea Systems Command
Commander, Naval Supply Systems Command
Commander, Space and Naval Warfare Systems Command
Commanding General, Fleet Marine Force, Atlantic
Commanding General, Fleet Marine Force, Pacific
Commanding General, Fourth Division Wing Team, New Orleans, LA
Commanding General, Marine Corps Combat Development Command
Commanding General Marine Corps Recruit Depot, Eastern Recruiting Region,
Paris Island, SC
Commanding General, Marine Corps Recruit Depot, Western Recruiting
Region, San Diego, CA
Commanding General, Marine Corps Systems Command
Director, Strategic Systems Programs
Office of the Navy Comptroller