| 4.B.5.a | A system operating at Protection Level 5 shall employ the following features: |
| 4.B.5.a(1) | Access control, including: |
| 4.B.5.a(1)(a) | Denial of physical access by unauthorized individuals unless under constant supervision of technically qualified, authorized personnel. |
| 4.B.5.a(1)(b) | Procedures for controlling access by users and maintainers to IS resources, including those that are at remote locations. |
| 4.B.5.a(2) | Access Control, including a Discretionary Access Control (DAC) Policy. A system has implemented DAC when the Security Support Structure defines and controls access between named users and named objects (e.g., files and programs) in the system. The DAC policy includes administrative procedures to support the policy and its mechanisms. The enforcement mechanisms (e.g., self/group/public controls, access control lists, communities of interest [COIs], encryption) shall allow users to specify and control sharing of those objects by named individuals, or by defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The DAC mechanism shall, either by explicit user action or by default, provide that objects are protected 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. |
| 4.B.5.a(3) | Access Control, including assurance that each user shall receive from the system only that information to which the user is authorized access. |
| 4.B.5.a(4) | Access Control, including a Mandatory Access Control (MAC) Policy that shall require: |
| 4.B.5.a(4)(a) | The Security Support Structure to enforce a mandatory access control policy over all subjects and storage objects under its control (e.g., processes, files, segments, devices). |
| 4.B.5.a(4)(b) | These subjects and objects to be assigned sensitivity labels that combine hierarchical classification levels and non-hierarchical categories; the labels shall be used as the basis for mandatory access control decisions. |
| 4.B.5.a(4)(c) | The Security Support Structure to be able to support two or more such security levels. |
| 4.B.5.a(4)(d) | Identification and authentication data to be used by the Security Support Structure to authenticate the user's identity and to assure that the security level and authorization of subjects external to the Security Support Structure that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user. |
| 4.B.5.a(4)(e) | Application of the following restrictions to all accesses between subjects and objects controlled by the Security Support Structure: |
| 4.B.5.a(4)(e)(1) | A subject can read an object only if the security level of the subject dominates* the security level of the object (i.e., a subject can "read down"). |
| 4.B.5.a(4)(e)(2) | A subject can write to an object only if two conditions are met: the security level of the object must dominate the security level of the subject, and the security level of the user's clearance* must dominate the security level of the object (i.e., a subject can "write up," but no higher than the user's clearance). |
| 4.B.5.a(5) | Account Management procedures that include: |
| 4.B.5.a(5)(a) | Identifying types of accounts (individual and group, conditions for group membership, associated privileges). |
| 4.B.5.a(5)(b) | Establishing an account (i.e., required paperwork and processes). |
| 4.B.5.a(5)(c) | Activating an account. |
| 4.B.5.a(5)(d) | Modifying an account (e.g., disabling an account, changing privilege level, group memberships, authenticators). |
| 4.B.5.a(5)(e) | Terminating an account (i.e., processes and assurances). |
| 4.B.5.a(6) | Auditing procedures, including: |
| 4.B.5.a(6)(a) | Providing the capability to ensure that all audit records include enough information to allow the ISSO to determine the date and time of action (e.g., common network time), the system locale of the action, the system entity that initiated or completed the action, the resources involved, and the action involved. |
| 4.B.5.a(6)(b) | Protecting the contents of audit trails against unauthorized access, modification, or deletion. |
| 4.B.5.a(6)(c) | Maintaining collected audit data at least 5 years and reviewing at least weekly. |
| 4.B.5.a(6)(d) | The system's creating and maintaining an audit trail that includes selected records of: |
| 4.B.5.a(6)(d)(1) | Successful and unsuccessful logons and logoffs. |
| 4.B.5.a(6)(d)(2) | Accesses to security-relevant objects and directories, including opens, closes, modifications, and deletions. |
| 4.B.5.a(6)(d)(3) | Activities at the system console (either physical or logical consoles), and other system-level accesses by privileged users. |
| 4.B.5.a(7) | Audit procedures that include the existence and use of audit reduction and analysis tools. |
| 4.B.5.a(8) | Auditing procedures, including: |
| 4.B.5.a(8)(a) | Enforcement of the capability to audit changes in security labels. |
| 4.B.5.a(8)(b) | Enforcement of the capability to audit accesses or attempted accesses to objects or data whose labels are inconsistent with user privileges. |
| 4.B.5.a(8)(c) | Enforcement of the capability to audit all program initiations, information downgrades and overrides, and all other security-relevant events (specifically including identified events that may be used in the exploitation of covert channels). |
| 4.B.5.a(8)(d) | In the event of an audit failure, system shutdown unless an alternate audit capability exists. |
| 4.B.5.a(9) | Auditing procedures, including: |
| 4.B.5.a(9)(a) | Individual accountability (i.e., unique identification of each user and association of that identity with all auditable actions taken by that individual). |
| 4.B.5.a(9)(b) | At least monthly testing by the ISSO or ISSM of the security posture of the IS by employing various intrusion/attack detection and monitoring tools. The ISSO/M shall not invoke such attack software without approval from the appropriate authorities and concurrence of legal counsel. The output of such tools shall be protected against unauthorized access, modification, or deletion. These tools shall build upon audit reduction and analysis tools to aid the ISSO or ISSM in the monitoring and detection of suspicious, intrusive, or attack-like behavior patterns. |
| 4.B.5.a(10) | Auditing procedures, including: |
| 4.B.5.a(10)(a) | The capability of the system to monitor, in real-time, occurrences of, or accumulation of, auditable events that may indicate an imminent violation of security policies. |
| 4.B.5.a(10)(b) | The capability of the system to notify the ISSO of suspicious events and taking the least-disruptive action to terminate the suspicious event. |
| 4.B.5.a(11) | An Identification and Authentication (I&A) management mechanism that ensures a unique identifier for each user and that associates that identifier with all auditable actions taken by the user. The following must be specified:* |
| 4.B.5.a(11)(a) | Initial authenticator content and administrative procedures for initial authenticator distribution. |
| 4.B.5.a(11)(b) | Individual and Group authenticators. (Group authenticators may only be used in conjunction with the use of an individual/unique authenticator, that is, individuals must be authenticated with an individual authenticator prior to use of a group authenticator). |
| 4.B.5.a(11)(c) | Length, composition, and generation of authenticators. |
| 4.B.5.a(11)(d) | Change Processes (periodic and in case of compromise). |
| 4.B.5.a(11)(e) | Aging of static authenticators (i.e., not one-time passwords or biometric patterns) |
| 4.B.5.a(11)(f) | History of static authenticator changes, with assurance of non-replication of individual authenticators, per direction in approved SSP. |
| 4.B.5.a(11)(g) | Protection of authenticators to preserve confidentiality and integrity. |
| 4.B.5.a(12) | Identification and Authentication. In those instances where the means of authentication is user-specified passwords, the ISSO or ISSM may employ (under the auspices of the DAA) automated tools to validate that the passwords are sufficiently strong to resist cracking and other attacks intended to discover a user's password. |
| 4.B.5.a(13) | Identification and Authentication. In those instances where the users are remotely accessing the system, the users shall employ a strong authentication mechanism (i.e., an I&A technique that is resistant to replay attacks). |
| 4.B.5.a(14) | Identification and Authentication (I&A) management mechanisms that include: |
| 4.B.5.a(14)(a) | Implementation and support of a trusted communications path between the user and the Security Support Structure of the desktop for login and authentication. Communication via this path shall be initiated exclusively by the user and shall be unmistakably distinguishable from other paths. |
| 4.B.5.a(14)(b) | In the case of communication between two or more systems (e.g. client server architecture), bi-directional authentication between the two systems. |
| 4.B.5.a(15) | Labeling procedures, including: |
| 4.B.5.a(15)(a) | Internal security labels that are an integral part of the electronic data or media. |
| 4.B.5.a(15)(b) | Procedures for managing content, generation, attachment, and persistence of internal labels that are documented in the SSP. |
| 4.B.5.a(15)(c) | Security labels that reflect the sensitivity (i.e., classification level, classification category, and handling caveats) of the information . |
| 4.B.5.a(15)(d) | Maintenance by the Security Support Structure of a record of the kind(s) of data allowed on each communications channel. |
| 4.B.5.a(15)(e) | A means for the system to ensure that labels a user associates with information provided to the system are consistent with the sensitivity levels that the user is allowed to access. |
| 4.B.5.a(16) | Labeling procedures, including internal and external labeling such as label integrity, exportation, subject-sensitivity labels, and device labels, as applicable. |
| 4.B.5.a(17) | Least Privilege procedures, including the assurance that each user or process is granted the most restrictive set of privileges or accesses needed for the performance of authorized tasks. |
| 4.B.5.a(18) | Parameter Transmission. Security parameters (e.g., labels, markings) that are reliably associated (either explicitly or implicitly) with information exchanged between systems. |
| 4.B.5.a(19) | Recovery procedures and technical system features to assure that system recovery is done in a trusted and secure manner. If any circumstances can cause an untrusted recovery, such circumstances shall be documented and appropriate mitigating procedures shall be put in place. |
| 4.B.5.a(20) | Resource Control. All authorizations to the information contained within an object shall be revoked prior to initial assignment, allocation, or reallocation to a subject from the Security Support Structure's pool of unused 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. There must be no residual data from the former object. |
| 4.B.5.a(21) | Screen Lock. Unless there is an overriding technical or operational problem, a terminal/desktop/laptop screen-lock functionality shall be associated with each terminal/desktop/laptop computer. When activated, a screen-lock function shall place an unclassified pattern onto the entire screen of the terminal/desktop/laptop, totally hiding what was previously visible on the screen. Such a capability shall: |
| 4.B.5.a(21)(a) | Be enabled either by explicit user action or if the terminal/desktop/laptop is left idle for a specified period of time (e.g., 15 minutes or more). |
| 4.B.5.a(21)(b) | Ensure that once the terminal/desktop/laptop security/screen-lock software is activated, access to the terminal/desktop/laptop requires knowledge of a unique authenticator. |
| 4.B.5.a(21)(c) | Not be considered a substitute for logging out (unless a mechanism actually logs out the user when the user idle time is exceeded). |
| 4.B.5.a(22) | Separation of Roles. The functions of the ISSO and the system manager/system administrator shall not be performed by the same person. |
| 4.B.5.a(23) | Session Controls, including: |
| 4.B.5.a(23)(a) | User notification such that all IS users shall be notified prior to gaining access to a system that system usage may be monitored, recorded, and subject to audit. Electronic means shall be employed where technically feasible. |
| 4.B.5.a(23)(b) | The user shall also be advised that use of the system indicates (1) the consent of the user to such monitoring and recording and (2) that unauthorized use is prohibited and subject to criminal and civil penalties. Electronic means shall be employed where technically feasible. |
| 4.B.5.a(24) | Enforcement of Session Controls, including: |
| 4.B.5.a(24)(a) | Procedures for controlling and auditing concurrent logons from different workstations. |
| 4.B.5.a(24)(b) | Station or session time-outs, as applicable. |
| 4.B.5.a(24)(c) | Limited retry on logon as technically feasible. |
| 4.B.5.a(24)(d) | System actions on unsuccessful logons (e.g., blacklisting of the terminal or user identifier). |
| 4.B.5.a(25) | Data Storage, implementing at least one of the following: |
| 4.B.5.a(25)(a) | Information stored in an area approved for open storage* of the information. |
| 4.B.5.a(25)(b) | Information stored in an area approved for continuous personnel access control (when continuous personnel access control is in effect), i.e., a 24-hour, 7-day-per week operational area. |
| 4.B.5.a(25)(c) | Information secured as appropriate for closed storage. |
| 4.B.5.a(25)(d) | Information encrypted using NSA-approved encryption mechanisms appropriate (see paragraph 1.G.1) for the classification of stored data. |
| 4.B.5.a(26) | Data Transmission. |
| 4.B.5.a(26)(a) | Data transmission that implements at least one of the following: |
| 4.B.5.a(26)(a)(1) | Information distributed only within an area approved for open storage of the information. |
| 4.B.5.a(26)(a)(2) | Information distributed via a Protected Distribution System* (PDS). |
| 4.B.5.a(26)(a)(3) | Information distributed using NSA-approved encryption mechanisms appropriate (see paragraph 1.G.1) for the classification of the information. |
| 4.B.5.a(26)(a)(4) | Information distributed using a trusted courier. |
| 4.B.5.a(26)(b) | Dial-up lines, other than those that are protected with nationally certified cryptographic devices or PDSs, shall not be used for gaining access to system resources that process intelligence information unless the DAA provides specific written authorization for a system to operate in this manner. |
| 4.B.5.a(27) | Separation of Data. Information transmissions of different security levels shall be segregated from each other (e.g., encryption, physical separation). |
| 4.B.5.b | Requirements for system assurance at Protection Level 5. |
| 4.B.5.b(1) | A thorough search for covert channels shall be conducted, and a determination shall be made of the maximum bandwidth of each identified channel. |
| 4.B.5.b(2) | Documentation shall include: |
| 4.B.5.b(2)(a) | A System Security Plan (see Appendix C). |
| 4.B.5.b(2)(b) | A Security Concept of Operations (CONOPS) (the Security CONOPS may be included in the System Security Plan). The CONOPS shall at a minimum include a description of the purpose of the system, a description of the system architecture, the system's accreditation schedule, the system's Protection Level, integrity Level-of-Concern, availability Level-of-Concern, and a description of the factors that determine the system's Protection Level, integrity Level-of-Concern, and availability Level-of-Concern. |
| 4.B.5.b(3) | Documentation shall include guide(s) or manual(s) for the system's privileged users. The manual(s) shall at a minimum provide information on (1) configuring, installing, and operating the system; (2) making optimum use of the system's security features; and (3) identifying known security vulnerabilities regarding the configuration and use of administrative functions. The documentation shall be updated as new vulnerabilities are identified. |
| 4.B.5.b(4) | Documentation shall include: |
| 4.B.5.b(4)(a) | Certification test plans and procedures detailing the implementation of the features and assurances for the required Protection Level. |
| 4.B.5.b(4)(b) | Reports of test results. |
| 4.B.5.b(4)(c) | A general user's guide that describes the protection mechanisms provided, and that supplies guidelines on how the mechanisms are to be used, and how they interact. |
| 4.B.5.b(4)(d) | Documentation, including System Design Documentation, if applicable. |
| 4.B.5.b(5) | System Assurance shall include: |
| 4.B.5.b(5)(a) | Features and procedures to validate the integrity and the expected operation of the security-relevant software, hardware, and firmware. |
| 4.B.5.b(5)(b) | Features or procedures for protection of the operating system from improper changes. |
| 4.B.5.b(6) | System Assurance shall include: |
| 4.B.5.b(6)(a) | Control of access to the Security Support Structure (i.e., the hardware, software, and firmware that perform operating system or security functions). |
| 4.B.5.b(6)(b) | Assurance of the integrity of the Security Support Structure. |
| 4.B.5.b(7) | System Assurance shall include: |
| 4.B.5.b(7)(a) | Isolating the Security Support Structure, by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions. |
| 4.B.5.b(7)(b) | Using up-to-date vulnerability assessment tools to validate the continued integrity of the Security Support Structure by ensuring that the system configuration does not contain any well-known security vulnerabilities. |
| 4.B.5.b(8) | System Assurance. The Security Support Structure shall maintain separate execution domains (e.g., address spaces) for each executing process. |
| 4.B.5.b(9) | The ISSM shall provide written verification to the DAA that the system operates in accordance with the approved SSP, and that the security features, including access controls, configuration management, and discretionary access controls, are implemented and operational. |
| 4.B.5.b(10) | Additional testing. |
| 4.B.5.b(10)(a) | Certification testing shall be conducted including verification that the features and assurances required for the Protection Level are functional. |
| 4.B.5.b(10)(b) | A test plan and procedures shall be developed and include: |
| 4.B.5.b(10)(b)(1) | A detailed description of the manner in which the system's Security Support Structure meets the technical requirements for the Protection Levels and Levels-of-Concern for integrity and availability. |
| 4.B.5.b(10)(b)(2) | A detailed description of the assurances that have been implemented, and how this implementation will be verified. |
| 4.B.5.b(10)(b)(3) | An outline of the inspection and test procedures used to verify this compliance. |
| 4.B.5.b(11) | Testing shall include: |
| 4.B.5.b(11)(a) | Security Penetration Testing to determine the level of difficulty in penetrating the security countermeasures of the system. |
| 4.B.5.b(11)(b) | Formation of an Independent Verification and Validation team that at least annually assists in security testing and performing validation and verification testing of the system. |
| 5 | INTEGRITY SYSTEM SECURITY FEATURES AND ASSURANCES |
| 5.A | Overview |
| 5.A.1 | This chapter provides the detailed integrity* technical security features and assurances. As noted in Chapter 3, the DAA must select the appropriate integrity technical security features and assurances for an IS based on the Integrity Level-of-Concern of the IS. |
| 5.A.2 | The chapter separately sets forth the integrity requirements for systems at each of the three Integrity Levels-of-Concern (Basic, Medium, and High). |
| 5.A.3 | The underscored terms in brackets preceding the sets of requirements (e.g., [Backup1]) indicate how they are identified in the tabular presentation in Appendix D. |
| 5.A.4 | The annotations in the upper outside margin are intended to aid the readers in quickly determining which Integrity Level-of-Concern they are examining. The notations INTEG-B, INTEG-M, and INTEG-H indicate integrity Basic, integrity Medium, and integrity High, respectively. |
| 5.A.5 | Requirements listed in boldface type are in addition to (or different from) the requirements for the previous Level-of-Concern. Entries for the Basic Level-of-Concern are in boldface type because the lowest level is the first entry for a given requirement. |
| 5.B | Integrity Requirements. Each IS shall implement security features that will ensure the degree of resistance to unauthorized modification of the information that is commensurate with its determined Integrity Level-of-Concern (see Chapter 3 for more information on Levels-of-Concern). For each IS, assurance commensurate with the Integrity Level-of-Concern shall be provided. Table 5.1 identifies factors used to select the appropriate Integrity Level-of-Concern and cites the paragraphs of this chapter where the relevant requirements can be located. |
| 5.B.1 | Integrity - Basic |
| 5.B.1.a | A system operating at the Basic Level-of-Concern for integrity shall implement the following features: |
| 5.B.1.a(1) | Backup procedures, including good engineering practice with regard to backup policies and procedures. |
| 5.B.1.a(2) | Configuration Management (CM) that includes: |
| 5.B.1.a(2)(a) | Policies that assure the effectiveness of storage integrity. |
| 5.B.1.a(2)(b) | Procedures to assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software, such as router tables, compilers, and other security-related system software. |
| 5.B.1.a(3) | Good engineering practice with regard to COTS integrity mechanisms, such as parity checks and Cyclical Redundancy Checks (CRCs). |
| 5.B.1.a(4) | Procedures to prevent the introduction of malicious code into the system, including the timely updating of those mechanisms intended to prevent the introduction of malicious code (e.g., updating anti-viral software). |
| 5.B.1.b | The following assurance shall be provided a system operating at a Basic Level-of-Concern for Integrity: |
| 5.B.1.b(1) | Verification by the ISSM that the necessary security procedures and mechanisms are in place; testing of them by the ISSM to ensure that they work appropriately. |
| 5.B.2 | Integrity - Medium |
| 5.B.2.a | A system operating at the Medium Level-of-Concern for integrity shall implement the following features: |
| 5.B.2.a(1) | Backup procedures to ensure both the existence of sufficient backup storage capability and effective restoration* of the backup data. |
| 5.B.2.a(2) | Backup storage that is located to allow the prompt restoration of data. If required by the DAA, there shall additionally be off-site backup storage of data, as per approved SSP; such storage is intended to enable recovery if a single event eliminates both the original data and the on-site backup data. If regular off-site backup is not feasible, such as on a ship at sea, alternative procedures, such as secure transmission of the data to an appropriate off-site location, should be considered. |
| 5.B.2.a(3) | Change Control that includes: |
| 5.B.2.a(3)(a) | Mechanisms that notify users of the time and date of the last change in data content. |
| 5.B.2.a(3)(b) | Procedures and technical system features to assure that changes to the data or to security-related items are: |
| 5.B.2.a(3)(b)(1) | Executed only by authorized personnel. |
| 5.B.2.a(3)(b)(2) | Properly implemented. |
| 5.B.2.a(4) | Configuration Management (CM) that includes: |
| 5.B.2.a(4)(a) | Policies that assure the effectiveness of storage integrity. |
| 5.B.2.a(4)(b) | Procedures to assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software, such as router tables, compilers, and other security-related system software. |
| 5.B.2.a(5) | Configuration Management that includes: |
| 5.B.2.a(5)(a) | A CM Plan, including: |
| 5.B.2.a(5)(a)(1) | Policies that assure storage integrity. |
| 5.B.2.a(5)(a)(2) | Procedures for identifying and documenting system connectivity, including any software, hardware, and firmware used for all communications (including, but not limited to wireless, IR, etc.). |
| 5.B.2.a(5)(a)(3) | Procedures for identifying and documenting the type, model, and brand of system or component, security relevant software, hardware, and firmware product names and version or release numbers, and physical locations. |
| 5.B.2.a(5)(b) | A CM process to implement the CM Plan. |
| 5.B.2.a(6) | Data and software storage integrity protection, including the use of strong integrity mechanisms (e.g., integrity locks, encryption). |
| 5.B.2.a(7) | Integrity, including the implementation of specific non-repudiation capabilities (e.g., digital signatures), if mission accomplishment requires non-repudiation. |
| 5.B.2.a(8) | Procedures to prevent the introduction of malicious code into the system, including the timely updating of those mechanisms intended to prevent the introduction of malicious code (e.g., updating anti-viral software). |
| 5.B.2.b | The following assurances shall be provided a system operating at a Medium Level-of-Concern for Integrity: |
| 5.B.2.b(1) | Security Support Structure Validation, including procedures or features to validate, periodically, the correct operation of the hardware, software, and firmware elements of the Security Support Structure. |
| 5.B.2.b(2) | Verification by the ISSM that the necessary security procedures and mechanisms are in place; testing of them by the ISSM to ensure that they work appropriately. |
| 5.B.3 | Integrity - High |
| 5.B.3.a | A system operating at the High Level-of-Concern for integrity shall implement the following features: |
| 5.B.3.a(1) | Backup procedures, including: |
| 5.B.3.a(1)(a) | A capability to conduct backup storage and restoration of data and access controls. |
| 5.B.3.a(1)(b) | Frequent backups of data.* |
| 5.B.3.a(1)(c) | At least annual restoration of backup data. |
| 5.B.3.a(1)(d) | Backup storage that is located to allow the immediate restoration of data. There shall additionally be off-site backup storage of the data, as per approved SSP; such storage is intended to enable recovery if a single event eliminates both the original data and the on-site backup data. If regular off-site backup is not feasible, such as on a ship at sea, alternative procedures, such as secure transmission of the data to an appropriate off-site location, should be considered. |
| 5.B.3.a(2) | Change Control that includes: |
| 5.B.3.a(2)(a) | Mechanisms that notify users of the time and date of the last change in data content. |
| 5.B.3.a(2)(b) | Procedures and technical system features to assure that changes to the data or to security-related items are: |
| 5.B.3.a(2)(b)(1) | Executed only by authorized personnel. |
| 5.B.3.a(2)(b)(2) | Properly implemented. |
| 5.B.3.a(3) | Change Control that includes: |
| 5.B.3.a(3)(a) | A secure, unchangeable audit trail that will facilitate the correction of improper data changes. |
| 5.B.3.a(3)(b) | Transaction-based systems (e.g., database management systems, transaction processing systems) that implement transaction roll-back and transaction journaling, or technical equivalents. |
| 5.B.3.a(4) | Configuration Management (CM) that includes: |
| 5.B.3.a(4)(a) | Policies that assure the effectiveness of storage integrity. |
| 5.B.3.a(4)(b) | Procedures to assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software, such as router tables, compilers, and other security-related system software. |
| 5.B.3.a(5) | Configuration Management that includes: |
| 5.B.3.a(5)(a) | A CM Plan, including: |
| 5.B.3.a(5)(a)(1) | Policies that assure storage integrity. |
| 5.B.3.a(5)(a)(2) | Procedures for identifying and documenting system connectivity, including any software, hardware, and firmware used for all communications (including, but not limited to wireless, IR, etc.). |
| 5.B.3.a(5)(a)(3) | Procedures for identifying and documenting the type, model, and brand of system or component, security relevant software, hardware, and firmware product names and version or release numbers, and physical locations. |
| 5.B.3.a(5)(b) | A CM process to implement the CM Plan. |
| 5.B.3.a(6) | Configuration management that includes: |
| 5.B.3.a(6)(a) | A CM process to test, and verify the CM Plan periodically. |
| 5.B.3.a(6)(b) | A CM control board, which includes the ISSM/ISSO as a member. |
| 5.B.3.a(6)(c) | A verification process that assures it is neither technically nor procedurally feasible to make changes to the Security Support Structure outside of the CM process. |
| 5.B.3.a(7) | Data and software storage integrity protection, including the use of strong integrity mechanisms (e.g., integrity locks, encryption). |
| 5.B.3.a(8) | Integrity, including the implementation of specific non-repudiation capabilities (e.g., digital signatures), if mission accomplishment requires non-repudiation. |
| 5.B.3.a(9) | Procedures to prevent the introduction of malicious code into the system, including the timely updating of those mechanisms intended to prevent the introduction of malicious code (e.g., updating anti-viral software). |
| 5.B.3.a(10) | Recovery procedures and technical system features that assure that system recovery is done in a trusted and secure manner. If any circumstances can cause an untrusted recovery, such circumstances shall be documented and appropriate mitigating procedures shall be put in place. |
| 5.B.3.a(11) | Data Transmission, including: |
| 5.B.3.a(11)(a) | Integrity mechanisms adequate to assure the integrity of all transmitted information (including labels and security parameters). |
| 5.B.3.a(11)(b) | Mechanisms to detect or prevent the hijacking of a communication session (e.g., encrypted communication channels). |
| 5.B.3.b | The following assurances shall be provided for a system operating at a High Level-of-Concern for Integrity: |
| 5.B.3.b(1) | System Integrity that includes the isolation of the Security Support Structure, by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions. |
| 5.B.3.b(2) | System Integrity, such that the Security Support Structure maintains separate execution domains (e.g., address spaces) for each executing process. |
| 5.B.3.b(3) | Security Support Structure Validation that includes procedures or features to validate, periodically, the correct operation of the hardware, software, and firmware elements of the Security Support Structure. |
| 5.B.3.b(4) | Verification by the DAA Rep that the necessary security procedures and mechanisms are in place; testing of them by the DAA Rep to ensure that they work appropriately. |
| 6 | AVAILABILITY SYSTEM SECURITY FEATURES AND ASSURANCES |
| 6.A | Overview |
| 6.A.1 | This chapter provides the detailed availability* technical security features and assurances. As noted in Chapter 3, the DAA must select the appropriate availability technical security features and assurances for an IS based on the Availability Level-of-Concern of the IS. |
| 6.A.2 | This chapter separately sets forth the availability requirements for systems at each of the three Availability Levels-of-Concern (Basic, Medium, and High). |
| 6.A.3 | The underscored terms in brackets preceding the sets of requirements (e.g., [Verif1]) indicate how they are identified in the tabular presentation in Appendix D. |
| 6.A.4 | The annotations in the upper outside margin are intended to aid the readers in quickly determining which Availability Level-of-Concern they are examining. The notations AVAIL-B, AVAIL-M and AVAIL-H indicate availability Basic, availability Medium, and availability High, respectively. |
| 6.A.5 | Requirements listed in boldface type are in addition to (or different from) the requirements for the previous Level-of-Concern. Entries for the Basic Level-of-Concern are all in boldface type because the lowest level is the first entry for a given requirement. |
| 6.B | Availability Requirements. Each IS shall implement security features that will ensure information is available for use when, where, and in the form required, commensurate with its determined Availability Level-of-Concern (see Chapter 3 for more information on Levels-of-Concern). For each IS, assurance commensurate with the Level-of-Concern for Availability shall be provided. Table 6.1 identifies factors used to select the appropriate Availability Level-of-Concern and cites the paragraphs of this chapter where the relevant requirements can be located. |
| 6.B.1 | Availability - Basic |
| 6.B.1.a | A system operating at the Basic Level-of-Concern for Availability shall implement the following features: |
| 6.B.1.a(1) | Processes and procedures to allow for the restoration* of the system. |
| 6.B.1.a(2) | Backup procedures, including good engineering practice with regard to backup policies and procedures. |
| 6.B.1.b | The following assurances shall be provided for a system operating at a Basic Level-of-Concern for Availability: |
| 6.B.1.b(1) | Verification by the ISSM that the necessary security procedures and mechanisms are in place; testing of them by the ISSM to ensure that they work appropriately. |
| 6.B.2 | Availability - Medium |
| 6.B.2.a | A system operating at the Medium Level-of-Concern for Availability shall implement the following features: |
| 6.B.2.a(1) | Processes and procedures to allow for the restoration* of the system. |
| 6.B.2.a(2) | Backup storage that is located to allow the prompt restoration of data. If required by the DAA, there shall additionally be off-site backup storage of the data, as per approved SSP; such storage is intended to enable recovery if a single event eliminates both the original data and the on-site backup data. If regular off-site backup is not feasible, as, for example, on a ship at sea, alternative procedures, such a secure transmission of the data to an appropriate off-site location, should be considered. |
| 6.B.2.a(3) | Backup procedures to allow the restoration of operational capabilities with minimal loss of service or data. These procedures shall require: |
| 6.B.2.a(3)(a) | Frequent backups of data. |
| 6.B.2.a(3)(b) | To the extent deemed necessary by the DAA, assurance that the system state after the restore will reflect the security-relevant changes to the system between the backup and the restore. |
| 6.B.2.a(3)(c) | Assurance that the availability of information in storage is adequate for all operational situations, and that catastrophic damage to any single storage entity will not result in system-wide loss of information. These policies shall include, among others, procedures for ensuring the physical protection of operational and backup media and equipment, and for ensuring the continued functionality of the operational and backup media and equipment. |
| 6.B.2.a(3)(d) | Restoration of any security-relevant segment of the system state (e.g., access control lists, cryptologic keys, deleted system status information) without requiring destruction of other system data. |
| 6.B.2.a(4) | Communications capability that provides adequate communications to accomplish the mission when the primary operations communications capabilities are unavailable. |
| 6.B.2.a(5) | Maintenance procedures that include preventive maintenance, scheduled to maximize the availability of the system, and thus to minimize interference with the operation of the system. Planning for maintenance shall include at least: |
| 6.B.2.a(5)(a) | On-call maintenance. |
| 6.B.2.a(5)(b) | On-site diagnostics. |
| 6.B.2.a(5)(c) | Control of Remote Diagnostics, where applicable. (See para. 8B.8.d, below, for a discussion of remote diagnostics.) |
| 6.B.2.a(6) | System Availability, including, by default for a multi-user system, conditioned, battery-backed power adequate to allow the system to be fail-soft. If the system is multi-user, the decision not to use an Uninterruptible Power Supply (UPS) for the system shall be explicit. |
| 6.B.2.a(7) | System Availability, including, as required by the DAA, procedures for graceful transfer of the system to an alternate power source; these procedures shall ensure that the transfer is completed within the timing requirements of the application(s) on the system. |
| 6.B.2.a(8) | Recovery procedures and technical system features that assure that system recovery is done in a trusted and secure manner. If any circumstances can cause an untrusted recovery, such circumstances shall be documented and appropriate mitigating procedures shall be put in place. |
| 6.B.2.b | The following assurances shall be provided for a system operating at a Medium Level-of-Concern for Availability: |
| 6.B.2.b(1) | Contingency Planning that includes a Contingency/Disaster Recovery Plan. |
| 6.B.2.b(2) | Verification by the ISSM that the necessary security procedures and mechanisms are in place; testing by the ISSM to ensure that they work appropriately. |
| 6.B.3 | Availability - High |
| 6.B.3.a | A system operating at the High Level-of-Concern for Availability shall implement the following features: |
| 6.B.3.a(1) | Processes and procedures to allow for the restoration* of the system. |
| 6.B.3.a(2) | Backup procedures, including: |
| 6.B.3.a(2)(a) | A capability to conduct backup storage and restoration of data. |
| 6.B.3.a(2)(b) | Frequent backups of data.* |
| 6.B.3.a(2)(c) | At least annual restoration of backup data. |
| 6.B.3.a(2)(d) | Backup storage that is located to allow the immediate restoration of data. There shall additionally be off-site backup storage of the data, as per approved SSP; such storage is intended to enable recovery if a single event eliminates both the original and the on-site, backup data. If regular off-site backup is not feasible, as, for example, on a ship at sea, alternative procedures such as secure transmission of the data to an appropriate off-site location, should be considered. |
| 6.B.3.a(3) | Backup procedures to allow the restoration of operational capabilities with minimal loss of service or data. These procedures shall require: |
| 6.B.3.a(3)(a) | Frequent backups of data. |
| 6.B.3.a(3)(b) | To the extent deemed necessary by the DAA, assurance that the system state after the restore will reflect security-relevant changes to the system between the backup and the restore. |
| 6.B.3.a(3)(c) | Assurance that the availability of information in storage is adequate for all operational situations, and that catastrophic damage to any single storage entity will not result in system-wide loss of information. These policies shall include, among others, procedures for ensuring the physical protection of operational and backup media and equipment, and for ensuring the continued functionality of the operational and backup media and equipment. |
| 6.B.3.a(3)(d) | Restoration of any security-relevant segment of the system state (e.g., access control lists, cryptologic keys, deleted system status information) without requiring destruction of other system data. |
| 6.B.3.a(4) | Backup procedures, including: |
| 6.B.3.a(4)(a) | Assurance that the system state after the restore will reflect security-relevant changes to the system between the backup and the restore. |
| 6.B.3.a(4)(b) | Consideration to the use of technical features that enhance data integrity and availability including, among others, remote journaling, Redundant Array of Inexpensive Disks (RAID) 1 and above, and similar techniques. |
| 6.B.3.a(5) | Communications capability that provides adequate communications to accomplish the mission when the primary operations communications capabilities are unavailable. |
| 6.B.3.a(6) | Prevention of Denial of Service Attacks.* Where technically feasible, procedures and mechanisms shall be in place to curtail or prevent well-known, detectable, and preventable denial of service attacks (e.g., SYN attack). |
| 6.B.3.a(7) | Maintenance procedures that include preventive maintenance, scheduled to maximize the availability of the system, and so minimize interference with the operation of the system. Planning for maintenance shall include at least: |
| 6.B.3.a(7)(a) | On-call maintenance. |
| 6.B.3.a(7)(b) | On-site diagnostics. |
| 6.B.3.a(7)(c) | Control of Remote Diagnostics, where applicable. (See para. 8B.8.d, below, for a discussion of remote diagnostics.) |
| 6.B.3.a(8) | Periodic testing by the ISSO or ISSM of the security posture of the IS by employing various intrusion/attack detection and monitoring tools. The ISSO/M shall not invoke such attack software without approval from the appropriate authorities and concurrence of legal counsel. The monitoring tools shall be used for the monitoring and detection of suspicious, intrusive, or attack-like behavior patterns. |
| 6.B.3.a(9) | System Availability, including, by default for a multi-user system, conditioned, battery-backed power adequate to allow the system to be fail-soft. If the system is multi-user, the decision not to use an Uninterruptible Power Supply (UPS) for the system shall be explicit. |
| 6.B.3.a(10) | System Availability, including procedures for graceful transfer of the system to an alternate power source; these procedures shall ensure that the transfer is completed within the timing requirements of the application(s) on the system. |
| 6.B.3.a(11) | Priority protection that includes no "Deny Up" (i.e., a lower-priority process shall not be able to interfere with the system's servicing of any higher-priority process). |
| 6.B.3.a(12) | Recovery procedures and technical system features that assure that system recovery is done in a trusted and secure manner. If any circumstances can cause an untrusted recovery, such circumstances shall be documented and appropriate mitigating procedures shall be put in place. |
| 6.B.3.b | The following assurances shall be provided for a system operating at a High Level-of-Concern for Availability: |
| 6.B.3.b(1) | Contingency Planning that includes a Contingency/Disaster Recovery Plan. |
| 6.B.3.b(2) | Contingency Planning, including: |
| 6.B.3.b(2)(a) | Adequate hardware, firmware, software, power, and cooling to accomplish the mission when the operational equipment is unavailable. Consideration shall be given to fault-tolerant or "hot-backup" operations. The decision whether or not to use these techniques shall be explicit. |
| 6.B.3.b(2)(b) | Regular exercising and testing of the contingency plans. The plans for the tests shall be documented in the Contingency/Disaster Recovery Plan. |
| 6.B.3.b(3) | Verification by the DAA Rep that the necessary security procedures and mechanisms are in place; testing by the DAA Rep to ensure that they work appropriately. |