• Quick link to System and Services Acquisition Summary Table

• SA-1 POLICY AND PROCEDURES

Control:

a. Develop, document, and disseminate to [ Assignment: organization-defined personnel or roles ]:

1. [ Selection (one or more): organization-level; mission/business process-level; system- level ] system and services acquisition policy that: (a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls; b. Designate an [ Assignment: organization-defined official ] to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and c. Review and update the current system and services acquisition:
3. Policy [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]; and
4. Procedures [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]. Discussion: System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission-or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security or privacy incidents, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. Related Controls: PM-9 , PS-8 , SA-8 , SI-12. Control Enhancements: None. References: [OMB A-130 ], [SP 800-12 ], [SP 800-30 ], [SP 800-39 ], [SP 800-100 ], [SP 800-160-1 ].

• SA-2 ALLOCATION OF RESOURCES

Control: a. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;

b. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and c. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation. Discussion: Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle. Related Controls: PL-7 , PM-3 , PM-11 , SA-9 , SR-3 , SR-5. Control Enhancements: None. References: [OMB A-130 ], [SP 800-160-1 ].

• SA-3 SYSTEM DEVELOPMENT LIFE CYCLE

Control: a. Acquire, develop, and manage the system using [ Assignment: organization-defined system development life cycle ] that incorporates information security and privacy considerations;

b. Define and document information security and privacy roles and responsibilities throughout the system development life cycle; c. Identify individuals having information security and privacy roles and responsibilities; and d. Integrate the organizational information security and privacy risk management process into system development life cycle activities. Discussion: A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in SA-8 help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.

The effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition

and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle. Related Controls: AT-3 , PL-8 , PM-7 , SA-4 , SA-5 , SA-8 , SA-11 , SA-15 , SA-17 , SA-22 , SR-3 , SR-4 , SR- 5 , SR-9. Control Enhancements:

• (1) SYSTEM DEVELOPMENT LIFE CYCLE / MANAGE PREPRODUCTION ENVIRONMENT

Protect system preproduction environments commensurate with risk throughout the system development life cycle for the system, system component, or system service. Discussion: The preproduction environment includes development, test, and integration

• environments. The program protection planning processes established by the Department of

Defense are examples of managing the preproduction environment for defense contractors. Criticality analysis and the application of controls on developers also contribute to a more secure system development environment. Related Controls: CM-2 , CM-4 , RA-3 , RA-9 , SA-4.

• (2) SYSTEM DEVELOPMENT LIFE CYCLE / USE OF LIVE OR OPERATIONAL DATA

(a) Approve, document, and control the use of live data in preproduction environments for the system, system component, or system service; and (b) Protect preproduction environments for the system, system component, or system

• service at the same impact or classification level as any live data in use within the

preproduction environments. Discussion: Live data is also referred to as operational data. The use of live or operational data in preproduction (i.e., development, test, and integration) environments can result in significant risks to organizations. In addition, the use of personally identifiable information in testing, research, and training increases the risk of unauthorized disclosure or misuse of such information. Therefore, it is important for the organization to manage any additional risks that may result from the use of live or operational data. Organizations can minimize such risks by using test or dummy data during the design, development, and testing of systems,

• system components, and system services. Risk assessment techniques may be used to

determine if the risk of using live or operational data is acceptable. Related Controls: PM-25 , RA-3.

• (3) SYSTEM DEVELOPMENT LIFE CYCLE / TECHNOLOGY REFRESH

Plan for and implement a technology refresh schedule for the system throughout the system development life cycle. Discussion: Technology refresh planning may encompass hardware, software, firmware, processes, personnel skill sets, suppliers, service providers, and facilities. The use of obsolete or nearing obsolete technology may increase the security and privacy risks associated with unsupported components, counterfeit or repurposed components, components unable to implement security or privacy requirements, slow or inoperable components, components from untrusted sources, inadvertent personnel error, or increased complexity. Technology refreshes typically occur during the operations and maintenance stage of the system development life cycle. Related Controls: MA-6. References: [OMB A-130 ], [SP 800-30 ], [SP 800-37 ], [SP 800-160-1 ], [SP 800-171 ], [SP 800-172 ].

• SA-4 ACQUISITION PROCESS

Control: Include the following requirements, descriptions, and criteria, explicitly or by reference, using [ Selection (one or more): standardized contract language; [ Assignment: organization- defined contract language ]] in the acquisition contract for the system, system component, or system service: a. Security and privacy functional requirements; b. Strength of mechanism requirements; c. Security and privacy assurance requirements; d. Controls needed to satisfy the security and privacy requirements.

e. Security and privacy documentation requirements; f. Requirements for protecting security and privacy documentation; g. Description of the system development environment and environment in which the system is intended to operate; h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and i. Acceptance criteria. Discussion: Security and privacy functional requirements are typically derived from the high- level security and privacy requirements described in SA-2. The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-^160-^1 ] describes the process of requirements engineering as part of the system development life cycle. Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle. Security and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement. Related Controls: CM-6 , CM-8 , PS-7 , SA-3 , SA-5 , SA-8 , SA-11 , SA-15 , SA-16 , SA-17 , SA-21 , SR-3 , SR-5. Control Enhancements:

• (1) ACQUISITION PROCESS / FUNCTIONAL PROPERTIES OF CONTROLS

Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented. Discussion: Functional properties of security and privacy controls describe the functionality (i.e., security or privacy capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls. Related Controls: None.

• (2) ACQUISITION PROCESS / DESIGN AND IMPLEMENTATION INFORMATION FOR CONTROLS

Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [ Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [ Assignment: organization-defined design and implementation information ]] at [ Assignment: organization-defined level of detail ]. Discussion: Organizations may require different levels of detail in the documentation for the design and implementation of controls in organizational systems, system components, or system services based on mission and business requirements, requirements for resiliency and trustworthiness, and requirements for analysis and testing. Systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules and the interfaces between modules providing security-relevant functionality. Design and implementation documentation can include manufacturer, version, serial number, verification hash signature, software libraries used, date of purchase or download, and the vendor or download source. Source code and hardware schematics are referred to as the implementation representation of the system. Related Controls: None.

• (3) ACQUISITION PROCESS / DEVELOPMENT METHODS, TECHNIQUES, AND PRACTICES

Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes: (a) [ Assignment: organization-defined systems engineering methods ]; (b) [ Assignment: organization-defined [ Selection (one or more): systems security; privacy ] engineering methods ]; and (c) [ Assignment: organization-defined software development methods; testing, evaluation, assessment, verification, and validation methods; and quality control processes ]. Discussion: Following a system development life cycle that includes state-of-the-practice software development methods, systems engineering methods, systems security and privacy engineering methods, and quality control processes helps to reduce the number and severity of latent errors within systems, system components, and system services. Reducing the number and severity of such errors reduces the number of vulnerabilities in those systems, components, and services. Transparency in the methods and techniques that developers select and implement for systems engineering, systems security and privacy engineering, software development, component and system assessments, and quality control processes provides an increased level of assurance in the trustworthiness of the system, system component, or system service being acquired. Related Controls: None.

• (4) ACQUISITION PROCESS / ASSIGNMENT OF COMPONENTS TO SYSTEMS

[Withdrawn: Incorporated into CM-8(9).]

• (5) ACQUISITION PROCESS / SYSTEM, COMPONENT, AND SERVICE CONFIGURATIONS

Require the developer of the system, system component, or system service to: (a) Deliver the system, component, or service with [ Assignment: organization-defined security configurations ] implemented; and (b) Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade. Discussion: Examples of security configurations include the U.S. Government Configuration Baseline (USGCB), Security Technical Implementation Guides (STIGs), and any limitations on functions, ports, protocols, and services. Security characteristics can include requiring that default passwords have been changed. Related Controls: None.

• (6) ACQUISITION PROCESS / USE OF INFORMATION ASSURANCE PRODUCTS

(a) Employ only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and (b) Ensure that these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures. Discussion: Commercial off-the-shelf IA or IA-enabled information technology products used to protect classified information by cryptographic means may be required to use NSA- approved key management. See [NSA CSFC]. Related Controls: SC-8 , SC-12 , SC-13.

• (7) ACQUISITION PROCESS / NIAP-APPROVED PROTECTION PROFILES

(a) Limit the use of commercially provided information assurance and information assurance-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)- approved Protection Profile for a specific technology type, if such a profile exists; and (b) Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS- validated or NSA-approved. Discussion: See [NIAP CCEVS] for additional information on NIAP. See [NIST CMVP] for additional information on FIPS-validated cryptographic modules. Related Controls: IA-7 , SC-12 , SC-13.

• (8) ACQUISITION PROCESS / CONTINUOUS MONITORING PLAN FOR CONTROLS

Require the developer of the system, system component, or system service to produce a plan for continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization. Discussion: The objective of continuous monitoring plans is to determine if the planned, required, and deployed controls within the system, system component, or system service continue to be effective over time based on the inevitable changes that occur. Developer continuous monitoring plans include a sufficient level of detail such that the information can be incorporated into continuous monitoring programs implemented by organizations. Continuous monitoring plans can include the types of control assessment and monitoring

activities planned, frequency of control monitoring, and actions to be taken when controls fail or become ineffective. Related Controls: CA-7.

• (9) ACQUISITION PROCESS / FUNCTIONS, PORTS, PROTOCOLS, AND SERVICES IN USE

Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use. Discussion: The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design stages) allows organizations to influence the design of the system, system component, or system service. This early involvement in the system development life cycle helps organizations avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services or requiring system service providers to do so. Early identification of functions, ports, protocols, and services avoids costly retrofitting of controls after the system, component, or system service has been implemented. SA-9 describes the requirements for external system services. Organizations identify which functions, ports, protocols, and services are provided from external sources. Related Controls: CM-7 , SA-9.

• (10) ACQUISITION PROCESS / USE OF APPROVED PIV PRODUCTS

Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems. Discussion: Products on the FIPS 201-approved products list meet NIST requirements for Personal Identity Verification (PIV) of Federal Employees and Contractors. PIV cards are used for multi-factor authentication in systems and organizations. Related Controls: IA-2 , IA-8 , PM-9.

• (11) ACQUISITION PROCESS / SYSTEM OF RECORDS

Include [ Assignment: organization-defined Privacy Act requirements ] in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function. Discussion: When, by contract, an organization provides for the operation of a system of records to accomplish an organizational mission or function, the organization, consistent with its authority, causes the requirements of the [PRIVACT] to be applied to the system of records. Related Controls: PT-6.

• (12) ACQUISITION PROCESS / DATA OWNERSHIP

(a) Include organizational data ownership requirements in the acquisition contract; and (b) Require all data to be removed from the contractor’s system and returned to the organization within [ Assignment: organization-defined time frame ]. Discussion: Contractors who operate a system that contains data owned by an organization initiating the contract have policies and procedures in place to remove the data from their systems and/or return the data in a time frame defined by the contract. Related Controls: None. References: [PRIVACT], [OMB A-130 ], [ISO 15408-1 ], [ISO 15408-2 ], [ISO 15408-3 ], [FIPS 140-3 ], [FIPS 201-2 ], [SP 800-35 ], [SP 800-37 ], [SP 800-70 ], [SP 800-73-4 ], [SP 800-137 ], [SP 800-160-1 ],

• [SP 800-161 ], [IR 7539], [IR 7622], [IR 7676], [IR 7870], [IR 8062], [NIAP CCEVS], [NSA CSFC].

• SA-5 SYSTEM DOCUMENTATION

Control: a. Obtain or develop administrator documentation for the system, system component, or system service that describes:

1. Secure configuration, installation, and operation of the system, component, or service;
2. Effective use and maintenance of security and privacy functions and mechanisms; and
3. Known vulnerabilities regarding configuration and use of administrative or privileged functions; b. Obtain or develop user documentation for the system, system component, or system service that describes:
4. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;
5. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and
6. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals; c. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take [ Assignment: organization-defined actions ] in response; and

d. Distribute documentation to [ Assignment: organization-defined personnel or roles ]. Discussion: System documentation helps personnel understand the implementation and operation of controls. Organizations consider establishing specific measures to determine the quality and completeness of the content provided. System documentation may be used to support the management of supply chain risk, incident response, and other functions. Personnel or roles that require documentation include system owners, system security officers, and system administrators. Attempts to obtain documentation include contacting manufacturers or suppliers and conducting web-based searches. The inability to obtain documentation may occur due to the age of the system or component or the lack of support from developers and contractors. When documentation cannot be obtained, organizations may need to recreate the documentation if it is essential to the implementation or operation of the controls. The protection provided for the documentation is commensurate with the security category or classification of the system. Documentation that addresses system vulnerabilities may require an increased level of protection. Secure operation of the system includes initially starting the system and resuming secure system operation after a lapse in system operation. Related Controls: CM-4 , CM-6 , CM-7 , CM-8 , PL-2 , PL-4 , PL-8 , PS-2 , SA-3 , SA-4 , SA-8 , SA-9 , SA-10 , SA-11 , SA-15 , SA-16 , SA-17 , SI-12 , SR-3. Control Enhancements:

• (1) SYSTEM DOCUMENTATION / FUNCTIONAL PROPERTIES OF SECURITY CONTROLS

[Withdrawn: Incorporated into SA-4(1).]

• (2) SYSTEM DOCUMENTATION / SECURITY-RELEVANT EXTERNAL SYSTEM INTERFACES

[Withdrawn: Incorporated into SA-4(2).]

• (3) SYSTEM DOCUMENTATION / HIGH-LEVEL DESIGN

[Withdrawn: Incorporated into SA-4(2).]

• (4) SYSTEM DOCUMENTATION / LOW-LEVEL DESIGN

[Withdrawn: Incorporated into SA-4(2).]

• (5) SYSTEM DOCUMENTATION / SOURCE CODE

[Withdrawn: Incorporated into SA-4(2).] References: [SP 800-160-1 ].

• SA-6 SOFTWARE USAGE RESTRICTIONS

[Withdrawn: Incorporated into CM-10 and SI-7 .]

• SA-7 USER-INSTALLED SOFTWARE

[Withdrawn: Incorporated into CM-11 and SI-7 .]

• SA-8 SECURITY AND PRIVACY ENGINEERING PRINCIPLES

Control: Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: [ Assignment: organization-defined systems security and privacy engineering principles ]. Discussion: Systems security and privacy engineering principles are closely related to and implemented throughout the system development life cycle (see SA-3 ). Organizations can apply systems security and privacy engineering principles to new systems under development or to systems undergoing upgrades. For existing systems, organizations apply systems security and privacy engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems. The application of systems security and privacy engineering principles helps organizations develop trustworthy, secure, and resilient systems and reduces the susceptibility to disruptions, hazards, threats, and the creation of privacy problems for individuals. Examples of system security engineering principles include: developing layered protections; establishing security and privacy policies, architecture, and controls as the foundation for design and development; incorporating security and privacy requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; tailoring controls to meet organizational needs; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk. Organizations that apply systems security and privacy engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk management decisions. System security engineering principles can also be used to protect against certain supply chain risks, including incorporating tamper-resistant hardware into a design. Related Controls: PL-8 , PM-7 , RA-2 , RA-3 , RA-9 , SA-3 , SA-4 , SA-15 , SA-17 , SA-20 , SC-2 , SC-3 , SC- 32 , SC-39 , SR-2 , SR-3 , SR-4 , SR-5. Control Enhancements:

• (1) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / CLEAR ABSTRACTIONS

Implement the security design principle of clear abstractions. Discussion: The principle of clear abstractions states that a system has simple, well-defined interfaces and functions that provide a consistent and intuitive view of the data and how the data is managed. The clarity, simplicity, necessity, and sufficiency of the system interfaces—

combined with a precise definition of their functional behavior—promotes ease of analysis, inspection, and testing as well as the correct and secure use of the system. The clarity of an abstraction is subjective. Examples that reflect the application of this principle include avoidance of redundant, unused interfaces; information hiding; and avoidance of semantic overloading of interfaces or their parameters. Information hiding (i.e., representation- independent programming), is a design discipline used to ensure that the internal representation of information in one system component is not visible to another system

• component invoking or calling the first component, such that the published abstraction is

not influenced by how the data may be managed internally. Related Controls: None.

• (2) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / LEAST COMMON MECHANISM

Implement the security design principle of least common mechanism in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of least common mechanism states that the amount of mechanism common to more than one user and depended on by all users is minimized [POPEK74]. Mechanism minimization implies that different components of a system refrain from using the same mechanism to access a system resource. Every shared mechanism (especially a mechanism involving shared variables) represents a potential information path between users and is designed with care to ensure that it does not unintentionally compromise security [SALTZER75]. Implementing the principle of least common mechanism helps to reduce the adverse consequences of sharing the system state among different programs. A single program that corrupts a shared state (including shared variables) has the potential to corrupt other programs that are dependent on the state. The principle of least common mechanism also supports the principle of simplicity of design and addresses the issue of covert storage channels [LAMPSON73]. Related Controls: None.

• (3) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / MODULARITY AND LAYERING

Implement the security design principles of modularity and layering in [ Assignment: organization-defined systems or system components ]. Discussion: The principles of modularity and layering are fundamental across system engineering disciplines. Modularity and layering derived from functional decomposition are effective in managing system complexity by making it possible to comprehend the structure of the system. Modular decomposition, or refinement in system design, is challenging and resists general statements of principle. Modularity serves to isolate functions and related data structures into well-defined logical units. Layering allows the relationships of these units to be better understood so that dependencies are clear and undesired complexity can be avoided. The security design principle of modularity extends functional modularity to include considerations based on trust, trustworthiness, privilege, and security policy. Security-informed modular decomposition includes the allocation of policies to systems in a network, separation of system applications into processes with distinct address spaces, allocation of system policies to layers, and separation of processes into subjects with distinct privileges based on hardware-supported privilege domains. Related Controls: SC-2 , SC-3.

• (4) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / PARTIALLY ORDERED DEPENDENCIES

Implement the security design principle of partially ordered dependencies in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of partially ordered dependencies states that the synchronization, calling, and other dependencies in the system are partially ordered. A fundamental concept in system design is layering, whereby the system is organized into well-defined, functionally

related modules or components. The layers are linearly ordered with respect to inter-layer dependencies, such that higher layers are dependent on lower layers. While providing functionality to higher layers, some layers can be self-contained and not dependent on lower layers. While a partial ordering of all functions in a given system may not be possible, if circular dependencies are constrained to occur within layers, the inherent problems of circularity can be more easily managed. Partially ordered dependencies and system layering contribute significantly to the simplicity and coherency of the system design. Partially ordered dependencies also facilitate system testing and analysis. Related Controls: None.

• (5) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / EFFICIENTLY MEDIATED ACCESS

Implement the security design principle of efficiently mediated access in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of efficiently mediated access states that policy enforcement mechanisms utilize the least common mechanism available while satisfying stakeholder

• requirements within expressed constraints. The mediation of access to system resources

(i.e., CPU, memory, devices, communication ports, services, infrastructure, data, and information) is often the predominant security function of secure systems. It also enables the realization of protections for the capability provided to stakeholders by the system. Mediation of resource access can result in performance bottlenecks if the system is not designed correctly. For example, by using hardware mechanisms, efficiently mediated access can be achieved. Once access to a low-level resource such as memory has been obtained, hardware protection mechanisms can ensure that out-of-bounds access does not occur. Related Controls: AC-25.

• (6) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / MINIMIZED SHARING

Implement the security design principle of minimized sharing in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of minimized sharing states that no computer resource is shared between system components (e.g., subjects, processes, functions) unless it is absolutely necessary to do so. Minimized sharing helps to simplify system design and implementation. In order to protect user-domain resources from arbitrary active entities, no resource is shared unless that sharing has been explicitly requested and granted. The need for resource sharing can be motivated by the design principle of least common mechanism in the case of internal entities or driven by stakeholder requirements. However, internal sharing is carefully designed to avoid performance and covert storage and timing channel problems. Sharing via common mechanism can increase the susceptibility of data and information to unauthorized access, disclosure, use, or modification and can adversely affect the inherent capability provided by the system. To minimize sharing induced by common mechanisms, such mechanisms can be designed to be reentrant or virtualized to preserve separation. Moreover, the use of global data to share information is carefully scrutinized. The lack of encapsulation may obfuscate relationships among the sharing entities. Related Controls: SC-31.

• (7) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / REDUCED COMPLEXITY

Implement the security design principle of reduced complexity in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of reduced complexity states that the system design is as simple and small as possible. A small and simple design is more understandable, more analyzable, and less prone to error. The reduced complexity principle applies to any aspect of a system, but it has particular importance for security due to the various analyses performed to obtain evidence about the emergent security property of the system. For such analyses to be

successful, a small and simple design is essential. Application of the principle of reduced complexity contributes to the ability of system developers to understand the correctness and completeness of system security functions. It also facilitates the identification of potential vulnerabilities. The corollary of reduced complexity states that the simplicity of the system is directly related to the number of vulnerabilities it will contain; that is, simpler systems contain fewer vulnerabilities. An benefit of reduced complexity is that it is easier to understand whether the intended security policy has been captured in the system design and that fewer vulnerabilities are likely to be introduced during engineering development. An additional benefit is that any such conclusion about correctness, completeness, and the existence of vulnerabilities can be reached with a higher degree of assurance in contrast to conclusions reached in situations where the system design is inherently more complex. Transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6) may require implementing the older and newer technologies simultaneously during the transition period. This may result in a temporary increase in system complexity during the transition. Related Controls: None.

• (8) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SECURE EVOLVABILITY

Implement the security design principle of secure evolvability in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of secure evolvability states that a system is developed to facilitate the maintenance of its security properties when there are changes to the system’s structure, interfaces, interconnections (i.e., system architecture), functionality, or configuration (i.e., security policy enforcement). Changes include a new, enhanced, or upgraded system capability; maintenance and sustainment activities; and reconfiguration. Although it is not possible to plan for every aspect of system evolution, system upgrades and changes can be

• anticipated by analyses of mission or business strategic direction, anticipated changes in the

threat environment, and anticipated maintenance and sustainment needs. It is unrealistic to expect that complex systems remain secure in contexts not envisioned during development, whether such contexts are related to the operational environment or to usage. A system may be secure in some new contexts, but there is no guarantee that its emergent behavior will always be secure. It is easier to build trustworthiness into a system from the outset, and it follows that the sustainment of system trustworthiness requires planning for change as opposed to adapting in an ad hoc or non-methodical manner. The benefits of this principle include reduced vendor life cycle costs, reduced cost of ownership, improved system security, more effective management of security risk, and less risk uncertainty. Related Controls: CM-3.

• (9) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / TRUSTED COMPONENTS

Implement the security design principle of trusted components in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of trusted components states that a component is trustworthy to at least a level commensurate with the security dependencies it supports (i.e., how much it is trusted to perform its security functions by other components). This principle enables the composition of components such that trustworthiness is not inadvertently diminished and the trust is not consequently misplaced. Ultimately, this principle demands some metric by which the trust in a component and the trustworthiness of a component can be measured on the same abstract scale. The principle of trusted components is particularly relevant when considering systems and components in which there are complex chains of trust dependencies. A trust dependency is also referred to as a trust relationship and there may be chains of trust relationships.

The principle of trusted components also applies to a compound component that consists of subcomponents (e.g., a subsystem), which may have varying levels of trustworthiness. The conservative assumption is that the trustworthiness of a compound component is that of its least trustworthy subcomponent. It may be possible to provide a security engineering rationale that the trustworthiness of a particular compound component is greater than the conservative assumption. However, any such rationale reflects logical reasoning based on a clear statement of the trustworthiness objectives as well as relevant and credible evidence. The trustworthiness of a compound component is not the same as increased application of defense-in-depth layering within the component or a replication of components. Defense-in- depth techniques do not increase the trustworthiness of the whole above that of the least trustworthy component. Related Controls: None.

• (10) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / HIERARCHICAL TRUST

Implement the security design principle of hierarchical trust in [ Assignment: organization- defined systems or system components ]. Discussion: The principle of hierarchical trust for components builds on the principle of trusted components and states that the security dependencies in a system will form a partial ordering if they preserve the principle of trusted components. The partial ordering provides the basis for trustworthiness reasoning or an assurance case (assurance argument) when composing a secure system from heterogeneously trustworthy components. To analyze a system composed of heterogeneously trustworthy components for its trustworthiness, it is essential to eliminate circular dependencies with regard to the trustworthiness. If a more trustworthy component located in a lower layer of the system were to depend on a less trustworthy component in a higher layer, this would, in effect, put the components in the same “less trustworthy” equivalence class per the principle of trusted components. Trust relationships, or chains of trust, can have various manifestations. For example, the root certificate of a certificate hierarchy is the most trusted node in the hierarchy, whereas the leaves in the hierarchy may be the least trustworthy nodes. Another example occurs in a layered high-assurance system where the security kernel (including the hardware base), which is located at the lowest layer of the system, is the most trustworthy component. The principle of hierarchical trust, however, does not prohibit the use of overly trustworthy components. There may be cases in a system of low trustworthiness where it is reasonable to employ a highly trustworthy component rather than one that is less trustworthy (e.g., due

• to availability or other cost-benefit driver). For such a case, any dependency of the highly

trustworthy component upon a less trustworthy component does not degrade the trustworthiness of the resulting low-trust system. Related Controls: None.

• (11) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / INVERSE MODIFICATION THRESHOLD

Implement the security design principle of inverse modification threshold in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of inverse modification threshold builds on the principle of trusted components and the principle of hierarchical trust and states that the degree of protection provided to a component is commensurate with its trustworthiness. As the trust placed in a component increases, the protection against unauthorized modification of the component also increases to the same degree. Protection from unauthorized modification can come in the form of the component’s own self-protection and innate trustworthiness, or it can come from the protections afforded to the component from other elements or attributes of the security architecture (to include protections in the environment of operation). Related Controls: None.

• (12) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / HIERARCHICAL PROTECTION

Implement the security design principle of hierarchical protection in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of hierarchical protection states that a component need not be protected from more trustworthy components. In the degenerate case of the most trusted component, it protects itself from all other components. For example, if an operating system kernel is deemed the most trustworthy component in a system, then it protects itself from all untrusted applications it supports, but the applications, conversely, do not need to protect themselves from the kernel. The trustworthiness of users is a consideration for applying the principle of hierarchical protection. A trusted system need not protect itself from an equally trustworthy user, reflecting use of untrusted systems in “system high” environments where users are highly trustworthy and where other protections are put in place to bound and protect the “system high” execution environment. Related Controls: None.

• (13) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / MINIMIZED SECURITY ELEMENTS

Implement the security design principle of minimized security elements in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of minimized security elements states that the system does not have extraneous trusted components. The principle of minimized security elements has two aspects: the overall cost of security analysis and the complexity of security analysis. Trusted components are generally costlier to construct and implement, owing to the increased rigor of development processes. Trusted components require greater security analysis to qualify their trustworthiness. Thus, to reduce the cost and decrease the complexity of the security analysis, a system contains as few trustworthy components as possible. The analysis of the interaction of trusted components with other components of the system is one of the most important aspects of system security verification. If the interactions between components are unnecessarily complex, the security of the system will also be more difficult to ascertain than one whose internal trust relationships are simple and elegantly constructed. In general, fewer trusted components result in fewer internal trust relationships and a simpler system. Related Controls: None.

• (14) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / LEAST PRIVILEGE

Implement the security design principle of least privilege in [ Assignment: organization- defined systems or system components ]. Discussion: The principle of least privilege states that each system component is allocated sufficient privileges to accomplish its specified functions but no more. Applying the principle of least privilege limits the scope of the component’s actions, which has two desirable effects: the security impact of a failure, corruption, or misuse of the component will have a minimized security impact, and the security analysis of the component will be simplified. Least privilege is a pervasive principle that is reflected in all aspects of the secure system design. Interfaces used to invoke component capability are available to only certain subsets of the user population, and component design supports a sufficiently fine granularity of privilege decomposition. For example, in the case of an audit mechanism, there may be an interface for the audit manager, who configures the audit settings; an interface for the audit

• operator, who ensures that audit data is safely collected and stored; and, finally, yet another

interface for the audit reviewer, who only has need to view the audit data that has been collected but no need to perform operations on that data. In addition to its manifestations at the system interface, least privilege can be used as a guiding principle for the internal structure of the system itself. One aspect of internal least privilege is to construct modules so that only the elements encapsulated by the module are

directly operated on by the functions within the module. Elements external to a module that may be affected by the module’s operation are indirectly accessed through interaction (e.g., via a function call) with the module that contains those elements. Another aspect of internal least privilege is that the scope of a given module or component includes only those system elements that are necessary for its functionality and that the access modes for the elements (e.g., read, write) are minimal. Related Controls: AC-6 , CM-7.

• (15) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / PREDICATE PERMISSION

Implement the security design principle of predicate permission in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of predicate permission states that system designers consider requiring multiple authorized entities to provide consent before a highly critical operation or access to highly sensitive data, information, or resources is allowed to proceed. [SALTZER75] originally named predicate permission the separation of privilege. It is also equivalent to separation of duty. The division of privilege among multiple parties decreases the likelihood of abuse and provides the safeguard that no single accident, deception, or breach of trust is sufficient to enable an unrecoverable action that can lead to significantly damaging effects. The design options for such a mechanism may require simultaneous action (e.g., the firing of a nuclear weapon requires two different authorized individuals to give the correct command within a small time window) or a sequence of operations where each successive action is enabled by some prior action, but no single individual is able to enable more than one action. Related Controls: AC-5.

• (16) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SELF-RELIANT TRUSTWORTHINESS

Implement the security design principle of self-reliant trustworthiness in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of self-reliant trustworthiness states that systems minimize their reliance on other systems for their own trustworthiness. A system is trustworthy by default, and any connection to an external entity is used to supplement its function. If a system were required to maintain a connection with another external entity in order to maintain its trustworthiness, then that system would be vulnerable to malicious and non-malicious threats that could result in the loss or degradation of that connection. The benefit of the principle of self-reliant trustworthiness is that the isolation of a system will make it less vulnerable to attack. A corollary to this principle relates to the ability of the system (or system component) to operate in isolation and then resynchronize with other components when it is rejoined with them. Related Controls: None.

• (17) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SECURE DISTRIBUTED COMPOSITION

Implement the security design principle of secure distributed composition in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of secure distributed composition states that the composition of distributed components that enforce the same system security policy result in a system that enforces that policy at least as well as the individual components do. Many of the design principles for secure systems deal with how components can or should interact. The need to create or enable a capability from the composition of distributed components can magnify the relevancy of these principles. In particular, the translation of security policy from a stand-alone to a distributed system or a system-of-systems can have unexpected or emergent results. Communication protocols and distributed data consistency mechanisms help to ensure consistent policy enforcement across a distributed system. To ensure a

system-wide level of assurance of correct policy enforcement, the security architecture of a distributed composite system is thoroughly analyzed. Related Controls: None.

• (18) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / TRUSTED COMMUNICATIONS CHANNELS

Implement the security design principle of trusted communications channels in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of trusted communication channels states that when composing a system where there is a potential threat to communications between components (i.e., the interconnections between components), each communication channel is trustworthy to a level commensurate with the security dependencies it supports (i.e., how much it is trusted by other components to perform its security functions). Trusted communication channels are achieved by a combination of restricting access to the communication channel (to ensure an acceptable match in the trustworthiness of the endpoints involved in the communication) and employing end-to-end protections for the data transmitted over the communication channel (to protect against interception and modification and to further increase the assurance of proper end-to-end communication). Related Controls: SC-8 , SC-12 , SC-13.

• (19) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / CONTINUOUS PROTECTION

Implement the security design principle of continuous protection in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of continuous protection states that components and data used to enforce the security policy have uninterrupted protection that is consistent with the security policy and the security architecture assumptions. No assurances that the system can provide the confidentiality, integrity, availability, and privacy protections for its design capability can be made if there are gaps in the protection. Any assurances about the ability to secure a delivered capability require that data and information are continuously protected. That is, there are no periods during which data and information are left unprotected while under control of the system (i.e., during the creation, storage, processing, or communication of the data and information, as well as during system initialization, execution, failure, interruption, and shutdown). Continuous protection requires adherence to the precepts of the reference monitor concept (i.e., every request is validated by the reference monitor; the reference monitor is able to protect itself from tampering; and sufficient assurance of the correctness and completeness of the mechanism can be ascertained from analysis and testing) and the principle of secure failure and recovery (i.e., preservation of a secure state during error, fault, failure, and successful attack; preservation of a secure state during recovery to normal, degraded, or alternative operational modes). Continuous protection also applies to systems designed to operate in varying configurations, including those that deliver full operational capability and degraded-mode configurations that deliver partial operational capability. The continuous protection principle requires that changes to the system security policies be traceable to the operational need that drives the configuration and be verifiable (i.e., it is possible to verify that the proposed changes will not put the system into an insecure state). Insufficient traceability and verification may lead to inconsistent states or protection discontinuities due to the complex or undecidable nature of the problem. The use of pre-verified configuration definitions that reflect the new security policy enables analysis to determine that a transition from old to new policies is essentially atomic and that any residual effects from the old policy are guaranteed to not conflict with the new policy. The ability to demonstrate continuous protection is rooted in the clear articulation of life cycle protection needs as stakeholder security requirements. Related Controls: AC-25.

• (20) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SECURE METADATA MANAGEMENT

Implement the security design principle of secure metadata management in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of secure metadata management states that metadata are “first class” objects with respect to security policy when the policy requires either complete protection of information or that the security subsystem be self-protecting. The principle of secure metadata management is driven by the recognition that a system, subsystem, or component cannot achieve self-protection unless it protects the data it relies on for correct execution. Data is generally not interpreted by the system that stores it. It may have semantic value (i.e., it comprises information) to users and programs that process the data. In contrast, metadata is information about data, such as a file name or the date when the file was created. Metadata is bound to the target data that it describes in a way that the system can interpret, but it need not be stored inside of or proximate to its target data. There may be metadata whose target is itself metadata (e.g., the classification level or impact level of a file name), including self-referential metadata. The apparent secondary nature of metadata can lead to neglect of its legitimate need for protection, resulting in a violation of the security policy that includes the exfiltration of information. A particular concern associated with insufficient protections for metadata is associated with multilevel secure (MLS) systems. MLS systems mediate access by a subject to an object based on relative sensitivity levels. It follows that all subjects and objects in the scope of control of the MLS system are either directly labeled or indirectly attributed with sensitivity levels. The corollary of labeled metadata for MLS systems states that objects containing metadata are labeled. As with protection needs assessments for data, attention is given to ensure that the confidentiality and integrity protections are individually assessed, specified, and allocated to metadata, as would be done for mission, business, and system data. Related Controls: None.

• (21) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SELF-ANALYSIS

Implement the security design principle of self-analysis in [ Assignment: organization- defined systems or system components ]. Discussion: The principle of self-analysis states that a system component is able to assess its internal state and functionality to a limited extent at various stages of execution, and that this self-analysis capability is commensurate with the level of trustworthiness invested in the system. At the system level, self-analysis can be achieved through hierarchical assessments of trustworthiness established in a bottom-up fashion. In this approach, the lower-level components check for data integrity and correct functionality (to a limited extent) of higher- level components. For example, trusted boot sequences involve a trusted lower-level component that attests to the trustworthiness of the next higher-level components so that a transitive chain of trust can be established. At the root, a component attests to itself, which usually involves an axiomatic or environmentally enforced assumption about its integrity. Results of the self-analyses can be used to guard against externally induced errors, internal malfunction, or transient errors. By following this principle, some simple malfunctions or errors can be detected without allowing the effects of the error or malfunction to propagate outside of the component. Further, the self-test can be used to attest to the configuration of the component, detecting any potential conflicts in configuration with respect to the expected configuration. Related Controls: CA-7.

• (22) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / ACCOUNTABILITY AND TRACEABILITY

Implement the security design principle of accountability and traceability in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of accountability and traceability states that it is possible to trace security-relevant actions (i.e., subject-object interactions) to the entity on whose behalf the action is being taken. The principle of accountability and traceability requires a trustworthy infrastructure that can record details about actions that affect system security (e.g., an audit subsystem). To record the details about actions, the system is able to uniquely identify the entity on whose behalf the action is being carried out and also record the relevant sequence of actions that are carried out. The accountability policy also requires that audit trail itself be protected from unauthorized access and modification. The principle of least privilege assists in tracing the actions to particular entities, as it increases the granularity of accountability. Associating specific actions with system entities, and ultimately with users, and making the audit trail secure against unauthorized access and modifications provide non-repudiation because once an action is recorded, it is not possible to change the audit trail. Another important function that accountability and traceability serves is in the routine and forensic analysis of events associated with the violation of security policy. Analysis of audit logs may provide additional information that may be helpful in determining the path or component that allowed the violation of the security policy and the actions of individuals associated with the violation of the security policy.

• Related Controls: AC-6 , AU-2 , AU-3 , AU-6 , AU-9 , AU-10 , AU-12 , IA-2 , IR-4.

• (23) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SECURE DEFAULTS

Implement the security design principle of secure defaults in [ Assignment: organization- defined systems or system components ]. Discussion: The principle of secure defaults states that the default configuration of a system (including its constituent subsystems, components, and mechanisms) reflects a restrictive and conservative enforcement of security policy. The principle of secure defaults applies to the initial (i.e., default) configuration of a system as well as to the security engineering and design of access control and other security functions that follow a “deny unless explicitly authorized” strategy. The initial configuration aspect of this principle requires that any “as shipped” configuration of a system, subsystem, or system component does not aid in the violation of the security policy and can prevent the system from operating in the default configuration for those cases where the security policy itself requires configuration by the operational user.

Restrictive defaults mean that the system will operate “as-shipped” with adequate self- protection and be able to prevent security breaches before the intended security policy and system configuration is established. In cases where the protection provided by the “as- shipped” product is inadequate, stakeholders assess the risk of using it prior to establishing a secure initial state. Adherence to the principle of secure defaults guarantees that a system is established in a secure state upon successfully completing initialization. In situations where the system fails to complete initialization, either it will perform a requested operation using secure defaults or it will not perform the operation. Refer to the principles of continuous protection and secure failure and recovery that parallel this principle to provide the ability to detect and recover from failure.

The security engineering approach to this principle states that security mechanisms deny requests unless the request is found to be well-formed and consistent with the security policy. The insecure alternative is to allow a request unless it is shown to be inconsistent with the policy. In a large system, the conditions that are satisfied to grant a request that is denied by default are often far more compact and complete than those that would need to be checked in order to deny a request that is granted by default. Related Controls: CM-2 , CM-6 , SA-4.

• (24) SECURITY AND PRIVACY ENGINEERING PRINCIPLES /SECURE FAILURE AND RECOVERY

Implement the security design principle of secure failure and recovery in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of secure failure and recovery states that neither a failure in a system function or mechanism nor any recovery action in response to failure leads to a violation of security policy. The principle of secure failure and recovery parallels the principle of continuous protection to ensure that a system is capable of detecting (within limits) actual and impending failure at any stage of its operation (i.e., initialization, normal operation, shutdown, and maintenance) and to take appropriate steps to ensure that security policies are not violated. In addition, when specified, the system is capable of recovering from impending or actual failure to resume normal, degraded, or alternative secure operations while ensuring that a secure state is maintained such that security policies are not violated. Failure is a condition in which the behavior of a component deviates from its specified or expected behavior for an explicitly documented input. Once a failed security function is detected, the system may reconfigure itself to circumvent the failed component while maintaining security and provide all or part of the functionality of the original system, or it may completely shut itself down to prevent any further violation of security policies. For this to occur, the reconfiguration functions of the system are designed to ensure continuous enforcement of security policy during the various phases of reconfiguration.

Another technique that can be used to recover from failures is to perform a rollback to a secure state (which may be the initial state) and then either shutdown or replace the service or component that failed such that secure operations may resume. Failure of a component may or may not be detectable to the components using it. The principle of secure failure indicates that components fail in a state that denies rather than grants access. For example, a nominally “atomic” operation interrupted before completion does not violate security policy and is designed to handle interruption events by employing higher-level atomicity and rollback mechanisms (e.g., transactions). If a service is being used, its atomicity properties are well-documented and characterized so that the component availing itself of that service can detect and handle interruption events appropriately. For example, a system is designed to gracefully respond to disconnection and support resynchronization and data consistency after disconnection. Failure protection strategies that employ replication of policy enforcement mechanisms, sometimes called defense in depth, can allow the system to continue in a secure state even when one mechanism has failed to protect the system. If the mechanisms are similar, however, the additional protection may be illusory, as the adversary can simply attack in series. Similarly, in a networked system, breaking the security on one system or service may enable an attacker to do the same on other similar replicated systems and services. By employing multiple protection mechanisms whose features are significantly different, the possibility of attack replication or repetition can be reduced. Analyses are conducted to weigh the costs and benefits of such redundancy techniques against increased resource usage and adverse effects on the overall system performance. Additional analyses are conducted as the complexity of these mechanisms increases, as could be the case for dynamic behaviors. Increased complexity generally reduces trustworthiness. When a resource cannot be continuously protected, it is critical to detect and repair any security breaches before the resource is once again used in a secure context. Related Controls: CP-10 , CP-12 , SC-7 , SC-8 , SC-24 , SI-13.

• (25) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / ECONOMIC SECURITY

Implement the security design principle of economic security in [ Assignment: organization- defined systems or system components ].

800

5

Discussion: The principle of economic security states that security mechanisms are not costlier than the potential damage that could occur from a security breach. This is the security-relevant form of the cost-benefit analyses used in risk management. The cost assumptions of cost-benefit analysis prevent the system designer from incorporating security mechanisms of greater strength than necessary, where strength of mechanism is proportional to cost. The principle of economic security also requires analysis of the benefits of assurance relative to the cost of that assurance in terms of the effort expended to obtain relevant and credible evidence as well as the necessary analyses to assess and draw trustworthiness and risk conclusions from the evidence. Related Controls: RA-3.

• (26) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / PERFORMANCE SECURITY

Implement the security design principle of performance security in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of performance security states that security mechanisms are constructed so that they do not degrade system performance unnecessarily. Stakeholder and system design requirements for performance and security are precisely articulated and prioritized. For the system implementation to meet its design requirements and be found acceptable to stakeholders (i.e., validation against stakeholder requirements), the designers adhere to the specified constraints that capability performance needs place on protection

• needs. The overall impact of computationally intensive security services (e.g., cryptography)

are assessed and demonstrated to pose no significant impact to higher-priority performance considerations or are deemed to provide an acceptable trade-off of performance for trustworthy protection. The trade-off considerations include less computationally intensive security services unless they are unavailable or insufficient. The insufficiency of a security service is determined by functional capability and strength of mechanism. The strength of mechanism is selected with respect to security requirements, performance-critical overhead issues (e.g., cryptographic key management), and an assessment of the capability of the threat. The principle of performance security leads to the incorporation of features that help in the enforcement of security policy but incur minimum overhead, such as low-level hardware mechanisms upon which higher-level services can be built. Such low-level mechanisms are usually very specific, have very limited functionality, and are optimized for performance. For example, once access rights to a portion of memory is granted, many systems use hardware mechanisms to ensure that all further accesses involve the correct memory address and access mode. Application of this principle reinforces the need to design security into the system from the ground up and to incorporate simple mechanisms at the lower layers that can be used as building blocks for higher-level mechanisms. Related Controls: SC-12 , SC-13 , SI-2 , SI-7.

• (27) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / HUMAN FACTORED SECURITY

Implement the security design principle of human factored security in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of human factored security states that the user interface for security functions and supporting services is intuitive, user-friendly, and provides feedback for user actions that affect such policy and its enforcement. The mechanisms that enforce security policy are not intrusive to the user and are designed not to degrade user efficiency. Security policy enforcement mechanisms also provide the user with meaningful, clear, and relevant feedback and warnings when insecure choices are being made. Particular attention is given to interfaces through which personnel responsible for system administration and operation configure and set up the security policies. Ideally, these personnel are able to

800

5

understand the impact of their choices. Personnel with system administrative and operational responsibilities are able to configure systems before start-up and administer them during runtime with confidence that their intent is correctly mapped to the system’s mechanisms. Security services, functions, and mechanisms do not impede or unnecessarily complicate the intended use of the system. There is a trade-off between system usability and the strictness necessary for security policy enforcement. If security mechanisms are frustrating or difficult to use, then users may disable them, avoid them, or use them in ways inconsistent with the security requirements and protection needs that the mechanisms were designed to satisfy. Related Controls: None.

• (28) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / ACCEPTABLE SECURITY

Implement the security design principle of acceptable security in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of acceptable security requires that the level of privacy and performance that the system provides is consistent with the users’ expectations. The perception of personal privacy may affect user behavior, morale, and effectiveness. Based on the organizational privacy policy and the system design, users should be able to restrict their actions to protect their privacy. When systems fail to provide intuitive interfaces or meet privacy and performance expectations, users may either choose to completely avoid the system or use it in ways that may be inefficient or even insecure. Related Controls: None.

• (29) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / REPEATABLE AND DOCUMENTED PROCEDURES

Implement the security design principle of repeatable and documented procedures in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of repeatable and documented procedures states that the techniques and methods employed to construct a system component permit the same component to be completely and correctly reconstructed at a later time. Repeatable and documented procedures support the development of a component that is identical to the component created earlier, which may be in widespread use. In the case of other system artifacts (e.g., documentation and testing results), repeatability supports consistency and the ability to inspect the artifacts. Repeatable and documented procedures can be introduced at various stages within the system development life cycle and contribute to the ability to evaluate assurance claims for the system. Examples include systematic procedures for code development and review, procedures for the configuration management of development tools and system artifacts, and procedures for system delivery. Related Controls: CM-1 , SA-1 , SA-10 , SA-11 , SA-15 , SA-17 , SC-1 , SI-1.

• (30) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / PROCEDURAL RIGOR

Implement the security design principle of procedural rigor in [ Assignment: organization- defined systems or system components ]. Discussion: The principle of procedural rigor states that the rigor of a system life cycle process is commensurate with its intended trustworthiness. Procedural rigor defines the scope, depth, and detail of the system life cycle procedures. Rigorous system life cycle procedures contribute to the assurance that the system is correct and free of unintended functionality in several ways. First, the procedures impose checks and balances on the life cycle process such that the introduction of unspecified functionality is prevented. Second, rigorous procedures applied to systems security engineering activities that produce specifications and other system design documents contribute to the ability to understand

800

5

the system as it has been built rather than trusting that the component, as implemented, is the authoritative (and potentially misleading) specification. Finally, modifications to an existing system component are easier when there are detailed specifications that describe its current design instead of studying source code or schematics to try to understand how it works. Procedural rigor helps ensure that security functional and assurance requirements have been satisfied, and it contributes to a better-informed basis for the determination of trustworthiness and risk posture. Procedural rigor is commensurate with the degree of assurance desired for the system. If the required trustworthiness of the system is low, a high level of procedural rigor may add unnecessary cost, whereas when high trustworthiness is critical, the cost of high procedural rigor is merited. Related Controls: None.

• (31) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SECURE SYSTEM MODIFICATION

Implement the security design principle of secure system modification in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of secure system modification states that system modification maintains system security with respect to the security requirements and risk tolerance of stakeholders. Upgrades or modifications to systems can transform secure systems into systems that are not secure. The procedures for system modification ensure that if the system is to maintain its trustworthiness, the same rigor that was applied to its initial development is applied to any system changes. Because modifications can affect the ability of the system to maintain its secure state, a careful security analysis of the modification is needed prior to its implementation and deployment. This principle parallels the principle of secure evolvability. Related Controls: CM-3 , CM-4.

• (32) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / SUFFICIENT DOCUMENTATION

Implement the security design principle of sufficient documentation in [ Assignment: organization-defined systems or system components ]. Discussion: The principle of sufficient documentation states that organizational personnel with responsibilities to interact with the system are provided with adequate documentation and other information such that the personnel contribute to rather than detract from system security. Despite attempts to comply with principles such as human factored security and acceptable security, systems are inherently complex, and the design intent for the use of

• security mechanisms and the ramifications of the misuse or misconfiguration of security

mechanisms are not always intuitively obvious. Uninformed and insufficiently trained users can introduce vulnerabilities due to errors of omission and commission. The availability of documentation and training can help to ensure a knowledgeable cadre of personnel, all of whom have a critical role in the achievement of principles such as continuous protection. Documentation is written clearly and supported by training that provides security awareness and understanding of security-relevant responsibilities. Related Controls: AT-2 , AT-3 , SA-5.

• (33) SECURITY AND PRIVACY ENGINEERING PRINCIPLES / MINIMIZATION

Implement the privacy principle of minimization using [ Assignment: organization-defined processes ]. Discussion: The principle of minimization states that organizations should only process personally identifiable information that is directly relevant and necessary to accomplish an authorized purpose and should only maintain personally identifiable information for as long as is necessary to accomplish the purpose. Organizations have processes in place, consistent with applicable laws and policies, to implement the principle of minimization.

800

5

Related Controls: PE-8 , PM-25 , SC-42 , SI-12. References: [PRIVACT], [OMB A-130 ], [FIPS 199], [FIPS 200], [SP 800-37 ], [SP 800-53A], [SP 800- 60-1 ], [SP 800-60-2 ], [SP 800-160-1 ], [IR 8062].

• SA-9 EXTERNAL SYSTEM SERVICES

Control: a. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: [ Assignment: organization-defined controls ]; b. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and

• c. Employ the following processes, methods, and techniques to monitor control compliance by

external service providers on an ongoing basis: [ Assignment: organization-defined processes, methods, and techniques ]. Discussion: External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust vary based on relationships between organizations and the external providers. Organizations document the basis for the trust relationships so that the relationships can be monitored. External system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define the expectations of performance for implemented controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance. Related Controls: AC-20 , CA-3 , CP-2 , IR-4 , IR-7 , PL-10 , PL-11 , PS-7 , SA-2 , SA-4 , SR-3 , SR-5. Control Enhancements:

• (1) EXTERNAL SYSTEM SERVICES / RISK ASSESSMENTS AND ORGANIZATIONAL APPROVALS

(a) Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and (b) Verify that the acquisition or outsourcing of dedicated information security services is approved by [ Assignment: organization-defined personnel or roles ]. Discussion: Information security services include the operation of security devices, such as firewalls or key management services as well as incident monitoring, analysis, and response. Risks assessed can include system, mission or business, security, privacy, or supply chain risks. Related Controls: CA-6 , RA-3 , RA-8.

• (2) EXTERNAL SYSTEM SERVICES / IDENTIFICATION OF FUNCTIONS, PORTS, PROTOCOLS, AND SERVICES

Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: [ Assignment: organization-defined external system services ].

800

5

Discussion: Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be useful when the need arises to understand the trade-offs involved in restricting certain functions and services or blocking certain ports and protocols. Related Controls: CM-6 , CM-7.

• (3) EXTERNAL SYSTEM SERVICES / ESTABLISH AND MAINTAIN TRUST RELATIONSHIP WITH PROVIDERS

Establish, document, and maintain trust relationships with external service providers based on the following requirements, properties, factors, or conditions: [ Assignment: organization-defined security and privacy requirements, properties, factors, or conditions defining acceptable trust relationships ]. Discussion: Trust relationships between organizations and external service providers reflect the degree of confidence that the risk from using external services is at an acceptable level. Trust relationships can help organizations gain increased levels of confidence that service providers are providing adequate protection for the services rendered and can also be useful when conducting incident response or when planning for upgrades or obsolescence. Trust relationships can be complicated due to the potentially large number of entities participating in the consumer-provider interactions, subordinate relationships and levels of trust, and types of interactions between the parties. In some cases, the degree of trust is based on the level of control that organizations can exert on external service providers regarding the controls necessary for the protection of the service, information, or individual privacy and the evidence brought forth as to the effectiveness of the implemented controls. The level of control is established by the terms and conditions of the contracts or service-level agreements. Related Controls: SR-2.

• (4) EXTERNAL SYSTEM SERVICES /CONSISTENT INTERESTS OF CONSUMERS AND PROVIDERS

• Take the following actions to verify that the interests of [ Assignment: organization-

defined external service providers ] are consistent with and reflect organizational interests: [ Assignment: organization-defined actions ]. Discussion: As organizations increasingly use external service providers, it is possible that the interests of the service providers may diverge from organizational interests. In such situations, simply having the required technical, management, or operational controls in place may not be sufficient if the providers that implement and manage those controls are not operating in a manner consistent with the interests of the consuming organizations. Actions that organizations take to address such concerns include requiring background checks for selected service provider personnel; examining ownership records; employing only trustworthy service providers, such as providers with which organizations have had successful trust relationships; and conducting routine, periodic, unscheduled visits to service provider facilities. Related Controls: None.

• (5) EXTERNAL SYSTEM SERVICES / PROCESSING, STORAGE, AND SERVICE LOCATION

Restrict the location of [ Selection (one or more): information processing; information or data; system services ] to [ Assignment: organization-defined locations ] based on [ Assignment: organization-defined requirements or conditions ]. Discussion: The location of information processing, information and data storage, or system services can have a direct impact on the ability of organizations to successfully execute their mission and business functions. The impact occurs when external providers control the location of processing, storage, or services. The criteria that external providers use for the selection of processing, storage, or service locations may be different from the criteria that organizations use. For example, organizations may desire that data or information storage

800

5

locations be restricted to certain locations to help facilitate incident response activities in case of information security or privacy incidents. Incident response activities, including forensic analyses and after-the-fact investigations, may be adversely affected by the governing laws, policies, or protocols in the locations where processing and storage occur and/or the locations from which system services emanate. Related Controls: SA-5 , SR-4.

• (6) EXTERNAL SYSTEM SERVICES / ORGANIZATION-CONTROLLED CRYPTOGRAPHIC KEYS

Maintain exclusive control of cryptographic keys for encrypted material stored or transmitted through an external system. Discussion: Maintaining exclusive control of cryptographic keys in an external system prevents decryption of organizational data by external system staff. Organizational control of cryptographic keys can be implemented by encrypting and decrypting data inside the organization as data is sent to and received from the external system or by employing a component that permits encryption and decryption functions to be local to the external system but allows exclusive organizational access to the encryption keys. Related Controls: SC-12 , SC-13 , SI-4.

• (7) EXTERNAL SYSTEM SERVICES / ORGANIZATION-CONTROLLED INTEGRITY CHECKING

Provide the capability to check the integrity of information while it resides in the external system. Discussion: Storage of organizational information in an external system could limit visibility into the security status of its data. The ability of the organization to verify and validate the integrity of its stored data without transferring it out of the external system provides such visibility. Related Controls: SI-7.

• (8) EXTERNAL SYSTEM SERVICES / PROCESSING AND STORAGE LOCATION — U.S. JURISDICTION

Restrict the geographic location of information processing and data storage to facilities located within in the legal jurisdictional boundary of the United States. Discussion: The geographic location of information processing and data storage can have a direct impact on the ability of organizations to successfully execute their mission and business functions. A compromise or breach of high impact information and systems can have severe or catastrophic adverse impacts on organizational assets and operations, individuals, other organizations, and the Nation. Restricting the processing and storage of high-impact information to facilities within the legal jurisdictional boundary of the United States provides greater control over such processing and storage. Related Controls: SA-5 , SR-4. References: [OMB A-130 ], [SP 800-35 ], [SP 800-160-1 ], [SP 800-161 ], [SP 800-171 ].

• SA-10 DEVELOPER CONFIGURATION MANAGEMENT

Control: Require the developer of the system, system component, or system service to: a. Perform configuration management during system, component, or service [ Selection (one or more): design; development; implementation; operation; disposal ]; b. Document, manage, and control the integrity of changes to [ Assignment: organization- defined configuration items under configuration management ]; c. Implement only organization-approved changes to the system, component, or service;

800

5

d. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and e. Track security flaws and flaw resolution within the system, component, or service and report findings to [ Assignment: organization-defined personnel ]. Discussion: Organizations consider the quality and completeness of configuration management activities conducted by developers as direct evidence of applying effective security controls. Controls include protecting the master copies of material used to generate security-relevant portions of the system hardware, software, and firmware from unauthorized modification or destruction. Maintaining the integrity of changes to the system, system component, or system service requires strict configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes. The configuration items that are placed under configuration management include the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the current running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and source code with previous versions; and test fixtures and documentation. Depending on the mission and business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance stage of the system development life cycle. Related Controls: CM-2 , CM-3 , CM-4 , CM-7 , CM-9 , SA-4 , SA-5 , SA-8 , SA-15 , SI-2 , SR-3 , SR-4 , SR-5 , SR-6. Control Enhancements:

• (1) DEVELOPER CONFIGURATION MANAGEMENT / SOFTWARE AND FIRMWARE INTEGRITY VERIFICATION

Require the developer of the system, system component, or system service to enable integrity verification of software and firmware components. Discussion: Software and firmware integrity verification allows organizations to detect unauthorized changes to software and firmware components using developer-provided tools, techniques, and mechanisms. The integrity checking mechanisms can also address counterfeiting of software and firmware components. Organizations verify the integrity of software and firmware components, for example, through secure one-way hashes provided by developers. Delivered software and firmware components also include any updates to such components. Related Controls: SI-7 , SR-11.

• (2) DEVELOPER CONFIGURATION MANAGEMENT / ALTERNATIVE CONFIGURATION MANAGEMENT

Provide an alternate configuration management process using organizational personnel in the absence of a dedicated developer configuration management team. Discussion: Alternate configuration management processes may be required when organizations use commercial off-the-shelf information technology products. Alternate configuration management processes include organizational personnel who review and approve proposed changes to systems, system components, and system services and conduct security and privacy impact analyses prior to the implementation of changes to systems, components, or services. Related Controls: None.

• (3) DEVELOPER CONFIGURATION MANAGEMENT / HARDWARE INTEGRITY VERIFICATION

Require the developer of the system, system component, or system service to enable integrity verification of hardware components.

800

5

Discussion: Hardware integrity verification allows organizations to detect unauthorized changes to hardware components using developer-provided tools, techniques, methods, and mechanisms. Organizations may verify the integrity of hardware components with hard-to- copy labels, verifiable serial numbers provided by developers, and by requiring the use of anti-tamper technologies. Delivered hardware components also include hardware and firmware updates to such components. Related Controls: SI-7.

• (4) DEVELOPER CONFIGURATION MANAGEMENT / TRUSTED GENERATION

Require the developer of the system, system component, or system service to employ tools for comparing newly generated versions of security-relevant hardware descriptions, source code, and object code with previous versions. Discussion: The trusted generation of descriptions, source code, and object code addresses authorized changes to hardware, software, and firmware components between versions during development. The focus is on the efficacy of the configuration management process by the developer to ensure that newly generated versions of security-relevant hardware descriptions, source code, and object code continue to enforce the security policy for the system, system component, or system service. In contrast, SA-10(1) and SA-10(3) allow organizations to detect unauthorized changes to hardware, software, and firmware components using tools, techniques, or mechanisms provided by developers. Related Controls: None.

• (5) DEVELOPER CONFIGURATION MANAGEMENT / MAPPING INTEGRITY FOR VERSION CONTROL

Require the developer of the system, system component, or system service to maintain the integrity of the mapping between the master build data describing the current version of security-relevant hardware, software, and firmware and the on-site master copy of the data for the current version. Discussion: Mapping integrity for version control addresses changes to hardware, software, and firmware components during both initial development and system development life cycle updates. Maintaining the integrity between the master copies of security-relevant hardware, software, and firmware (including designs, hardware drawings, source code) and the equivalent data in master copies in operational environments is essential to ensuring the availability of organizational systems that support critical mission and business functions. Related Controls: None.

• (6) DEVELOPER CONFIGURATION MANAGEMENT / TRUSTED DISTRIBUTION

Require the developer of the system, system component, or system service to execute procedures for ensuring that security-relevant hardware, software, and firmware updates distributed to the organization are exactly as specified by the master copies. Discussion: The trusted distribution of security-relevant hardware, software, and firmware updates help to ensure that the updates are correct representations of the master copies maintained by the developer and have not been tampered with during distribution. Related Controls: None.

• (7) DEVELOPER CONFIGURATION MANAGEMENT / SECURITY AND PRIVACY REPRESENTATIVES

Require [ Assignment: organization-defined security and privacy representatives] to be included in the [ Assignment: organization-defined configuration change management and

• control process ].

Discussion: Information security and privacy representatives can include system security officers, senior agency information security officers, senior agency officials for privacy, and system privacy officers. Representation by personnel with information security and privacy

800

5

expertise is important because changes to system configurations can have unintended side effects, some of which may be security-or privacy-relevant. Detecting such changes early in the process can help avoid unintended, negative consequences that could ultimately affect the security and privacy posture of systems. The configuration change management and control process in this control enhancement refers to the change management and control process defined by organizations in SA-10b. Related Controls: None. References: [FIPS 140-3 ], [FIPS 180-4 ], [FIPS 202], [SP 800-128 ], [SP 800-160-1 ].

• SA-11 DEVELOPER TESTING AND EVALUATION

Control: Require the developer of the system, system component, or system service, at all post- design stages of the system development life cycle, to: a. Develop and implement a plan for ongoing security and privacy assessments; b. Perform [ Selection (one or more): unit; integration; system; regression ] testing/evaluation [ Assignment: organization-defined frequency ] at [ Assignment: organization-defined depth and coverage ]; c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during testing and evaluation.

Discussion: Developmental testing and evaluation confirms that the required controls are implemented correctly, operating as intended, enforcing the desired security and privacy policies, and meeting established security and privacy requirements. Security properties of systems and the privacy of individuals may be affected by the interconnection of system components or changes to those components. The interconnections or changes—including upgrading or replacing applications, operating systems, and firmware—may adversely affect previously implemented controls. Ongoing assessment during development allows for additional types of testing and evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as manual code review, security architecture review, and penetration testing, as well as and static analysis, dynamic analysis, binary analysis, or a hybrid of the three analysis approaches. Developers can use the analysis approaches, along with security instrumentation and fuzzing, in a variety of tools and in source code reviews. The security and privacy assessment plans include the specific activities that developers plan to carry out, including the types of analyses, testing, evaluation, and reviews of software and firmware components; the degree of rigor to be applied; the frequency of the ongoing testing and evaluation; and the types of artifacts produced during those processes. The depth of testing and evaluation refers to the rigor and level of detail associated with the assessment process. The coverage of testing and evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security and privacy assessment plans, flaw remediation processes, and the evidence that the plans and processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the system. Contracts may specify protection requirements for documentation.

Related Controls: CA-2 , CA-7 , CM-4 , SA-3 , SA-4 , SA-5 , SA-8 , SA-15 , SA-17 , SI-2 , SR-5 , SR-6 , SR-7. Control Enhancements:

800

5

• (1) DEVELOPER TESTING AND EVALUATION / STATIC CODE ANALYSIS

Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis. Discussion: Static code analysis provides a technology and methodology for security reviews and includes checking for weaknesses in the code as well as for the incorporation of libraries or other included code with known vulnerabilities or that are out-of-date and not supported. Static code analysis can be used to identify vulnerabilities and enforce secure coding practices. It is most effective when used early in the development process, when each code change can automatically be scanned for potential weaknesses. Static code analysis can provide clear remediation guidance and identify defects for developers to fix. Evidence of the correct implementation of static analysis can include aggregate defect density for critical defect types, evidence that defects were inspected by developers or security professionals, and evidence that defects were remediated. A high density of ignored findings, commonly referred to as false positives, indicates a potential problem with the analysis process or the analysis tool. In such cases, organizations weigh the validity of the evidence against evidence from other sources. Related Controls: None.

• (2) DEVELOPER TESTING AND EVALUATION / THREAT MODELING AND VULNERABILITY ANALYSES

Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that: (a) Uses the following contextual information: [ Assignment: organization-defined information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels ]; (b) Employs the following tools and methods: [ Assignment: organization-defined tools and methods ]; (c) Conducts the modeling and analyses at the following level of rigor: [ Assignment: organization-defined breadth and depth of modeling and analyses ]; and (d) Produces evidence that meets the following acceptance criteria: [ Assignment: organization-defined acceptance criteria ]. Discussion: Systems, system components, and system services may deviate significantly from the functional and design specifications created during the requirements and design stages of the system development life cycle. Therefore, updates to threat modeling and vulnerability analyses of those systems, system components, and system services during development and prior to delivery are critical to the effective operation of those systems, components, and services. Threat modeling and vulnerability analyses at this stage of the system development life cycle ensure that design and implementation changes have been accounted for and that vulnerabilities created because of those changes have been reviewed and mitigated. Related Controls: PM-15 , RA-3 , RA-5.

• (3) DEVELOPER TESTING AND EVALUATION / INDEPENDENT VERIFICATION OF ASSESSMENT PLANS AND

• EVIDENCE

(a) Require an independent agent satisfying [ Assignment: organization-defined independence criteria ] to verify the correct implementation of the developer security and privacy assessment plans and the evidence produced during testing and evaluation; and

800

5

(b) Verify that the independent agent is provided with sufficient information to complete the verification process or granted the authority to obtain such information. Discussion: Independent agents have the qualifications—including the expertise, skills, training, certifications, and experience—to verify the correct implementation of developer security and privacy assessment plans. Related Controls: AT-3 , RA-5.

• (4) DEVELOPER TESTING AND EVALUATION / MANUAL CODE REVIEWS

Require the developer of the system, system component, or system service to perform a manual code review of [ Assignment: organization-defined specific code ] using the following processes, procedures, and/or techniques: [ Assignment: organization-defined processes, procedures, and/or techniques ]. Discussion: Manual code reviews are usually reserved for the critical software and firmware components of systems. Manual code reviews are effective at identifying weaknesses that require knowledge of the application’s requirements or context that, in most cases, is unavailable to automated analytic tools and techniques, such as static and dynamic analysis. The benefits of manual code review include the ability to verify access control matrices against application controls and review detailed aspects of cryptographic implementations and controls. Related Controls: None.

• (5) DEVELOPER TESTING AND EVALUATION / PENETRATION TESTING

Require the developer of the system, system component, or system service to perform penetration testing: (a) At the following level of rigor: [ Assignment: organization-defined breadth and depth of testing ]; and (b) Under the following constraints: [ Assignment: organization-defined constraints ]. Discussion: Penetration testing is an assessment methodology in which assessors, using all available information technology product or system documentation and working under specific constraints, attempt to circumvent the implemented security and privacy features of information technology products and systems. Useful information for assessors who conduct penetration testing includes product and system design specifications, source code, and administrator and operator manuals. Penetration testing can include white-box, gray-box, or black-box testing with analyses performed by skilled professionals who simulate adversary actions. The objective of penetration testing is to discover vulnerabilities in systems, system components, and services that result from implementation errors, configuration faults, or other operational weaknesses or deficiencies. Penetration tests can be performed in conjunction with automated and manual code reviews to provide a greater level of analysis

• than would ordinarily be possible. When user session information and other personally

identifiable information is captured or recorded during penetration testing, such information is handled appropriately to protect privacy.

• Related Controls: CA-8 , PM-14 , PM-25 , PT-2 , SA-3 , SI-2 , SI-6.

• (6) DEVELOPER TESTING AND EVALUATION / ATTACK SURFACE REVIEWS

Require the developer of the system, system component, or system service to perform attack surface reviews. Discussion: Attack surfaces of systems and system components are exposed areas that make those systems more vulnerable to attacks. Attack surfaces include any accessible areas where weaknesses or deficiencies in the hardware, software, and firmware components provide opportunities for adversaries to exploit vulnerabilities. Attack surface reviews ensure that developers analyze the design and implementation changes to systems and

800

5

mitigate attack vectors generated as a result of the changes. The correction of identified flaws includes deprecation of unsafe functions. Related Controls: SA-15.

• (7) DEVELOPER TESTING AND EVALUATION / VERIFY SCOPE OF TESTING AND EVALUATION

Require the developer of the system, system component, or system service to verify that the scope of testing and evaluation provides complete coverage of the required controls at the following level of rigor: [ Assignment: organization-defined breadth and depth of testing and evaluation ]. Discussion: Verifying that testing and evaluation provides complete coverage of required controls can be accomplished by a variety of analytic techniques ranging from informal to formal. Each of these techniques provides an increasing level of assurance that corresponds to the degree of formality of the analysis. Rigorously demonstrating control coverage at the highest levels of assurance can be achieved using formal modeling and analysis techniques, including correlation between control implementation and corresponding test cases. Related Controls: SA-15.

• (8) DEVELOPER TESTING AND EVALUATION / DYNAMIC CODE ANALYSIS

Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis. Discussion: Dynamic code analysis provides runtime verification of software programs using tools capable of monitoring programs for memory corruption, user privilege issues, and other potential security problems. Dynamic code analysis employs runtime tools to ensure that security functionality performs in the way it was designed. A type of dynamic analysis, known as fuzz testing, induces program failures by deliberately introducing malformed or random data into software programs. Fuzz testing strategies are derived from the intended use of applications and the functional and design specifications for the applications. To understand the scope of dynamic code analysis and the assurance provided, organizations may also consider conducting code coverage analysis (i.e., checking the degree to which the code has been tested using metrics such as percent of subroutines tested or percent of program statements called during execution of the test suite) and/or concordance analysis (i.e., checking for words that are out of place in software code, such as non-English language words or derogatory terms). Related Controls: None.

• (9) DEVELOPER TESTING AND EVALUATION / INTERACTIVE APPLICATION SECURITY TESTING

Require the developer of the system, system component, or system service to employ interactive application security testing tools to identify flaws and document the results. Discussion: Interactive (also known as instrumentation-based) application security testing is a method of detecting vulnerabilities by observing applications as they run during testing. The use of instrumentation relies on direct measurements of the actual running applications and uses access to the code, user interaction, libraries, frameworks, backend connections, and configurations to directly measure control effectiveness. When combined with analysis techniques, interactive application security testing can identify a broad range of potential vulnerabilities and confirm control effectiveness. Instrumentation-based testing works in real time and can be used continuously throughout the system development life cycle. Related Controls: None. References: [ISO 15408-3 ], [SP 800-30 ], [SP 800-53A], [SP 800-154 ], [SP 800-160-1 ].

800

5

• SA-12 SUPPLY CHAIN PROTECTION

• [Withdrawn: Incorporated into SR Family.]

Control Enhancements:

• (1) SUPPLY CHAIN PROTECTION / ACQUISITION STRATEGIES / TOOLS / METHODS

[Withdrawn: Moved to SR-5 .]

• (2) SUPPLY CHAIN PROTECTION / SUPPLIER REVIEWS

[Withdrawn: Moved to SR-6 .]

• (3) SUPPLY CHAIN PROTECTION / TRUSTED SHIPPING AND WAREHOUSING

[Withdrawn: Incorporated into SR-3 .]

• (4) SUPPLY CHAIN PROTECTION / DIVERSITY OF SUPPLIERS

[Withdrawn: Moved to SR-3(1).]

• (5) SUPPLY CHAIN PROTECTION / LIMITATION OF HARM

• [Withdrawn: Moved to SR-3(2).]

• (6) SUPPLY CHAIN PROTECTION / MINIMIZING PROCUREMENT TIME

[Withdrawn: Incorporated into SR-5(1).]

• (7) SUPPLY CHAIN PROTECTION / ASSESSMENTS PRIOR TO SELECTION / ACCEPTANCE / UPDATE

[Withdrawn: Moved to SR-5(2).]

• (8) SUPPLY CHAIN PROTECTION / USE OF ALL-SOURCE INTELLIGENCE

• [Withdrawn: Incorporated into RA-3(2).]

• (9) SUPPLY CHAIN PROTECTION / OPERATIONS SECURITY

• [Withdrawn: Moved to SR-7 .]

• (10) SUPPLY CHAIN PROTECTION / VALIDATE AS GENUINE AND NOT ALTERED

• [Withdrawn: Moved to SR-4(3).]

• (11) SUPPLY CHAIN PROTECTION / PENETRATION TESTING / ANALYSIS OF ELEMENTS, PROCESSES, AND

• ACTORS

• [Withdrawn: Moved to SR-6(1).]

• (12) SUPPLY CHAIN PROTECTION / INTER-ORGANIZATIONAL AGREEMENTS

• [Withdrawn: Moved to SR-8 .]

• (13) SUPPLY CHAIN PROTECTION / CRITICAL INFORMATION SYSTEM COMPONENTS

• [Withdrawn: Incorporated into MA-6 , RA-9 .]

• (14) SUPPLY CHAIN PROTECTION / IDENTITY AND TRACEABILITY

• [Withdrawn: Moved to SR-4(1), SR-4(2).]

• (15) SUPPLY CHAIN PROTECTION / PROCESSES TO ADDRESS WEAKNESSES OR DEFICIENCIES

• [Withdrawn: Incorporated into SR-3 .]

• SA-13 TRUSTWORTHINESS

[Withdrawn: Incorporated into SA-8 .]

800

5

• SA-14 CRITICALITY ANALYSIS

[Withdrawn: Incorporated into RA-9 .] Control Enhancements:

• (1) CRITICALITY ANALYSIS / CRITICAL COMPONENTS WITH NO VIABLE ALTERNATIVE SOURCING

[Withdrawn: Incorporated into SA-20 .]

• SA-15 DEVELOPMENT PROCESS, STANDARDS, AND TOOLS

Control:

a. Require the developer of the system, system component, or system service to follow a documented development process that:

1. Explicitly addresses security and privacy requirements;
2. Identifies the standards and tools used in the development process;
3. Documents the specific tool options and tool configurations used in the development process; and
4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and b. Review the development process, standards, tools, tool options, and tool configurations [ Assignment: organization-defined frequency ] to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: [ Assignment: organization-defined security and privacy requirements ]. Discussion: Development tools include programming languages and computer-aided design systems. Reviews of development processes include the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes facilitates effective supply chain risk assessment and mitigation. Such integrity requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.

Related Controls: MA-6 , SA-3 , SA-4 , SA-8 , SA-10 , SA-11 , SR-3 , SR-4 , SR-5 , SR-6 , SR-9. Control Enhancements:

• (1) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / QUALITY METRICS

Require the developer of the system, system component, or system service to: (a) Define quality metrics at the beginning of the development process; and (b) Provide evidence of meeting the quality metrics [ Selection (one or more): [ Assignment: organization-defined frequency ] ; [ Assignment: organization-defined program review milestones ] ; upon delivery ]. Discussion: Organizations use quality metrics to establish acceptable levels of system quality. Metrics can include quality gates, which are collections of completion criteria or sufficiency standards that represent the satisfactory execution of specific phases of the system development project. For example, a quality gate may require the elimination of all compiler warnings or a determination that such warnings have no impact on the effectiveness of required security or privacy capabilities. During the execution phases of development projects, quality gates provide clear, unambiguous indications of progress. Other metrics apply to the entire development project. Metrics can include defining the severity thresholds of vulnerabilities in accordance with organizational risk tolerance, such

800

5

as requiring no known vulnerabilities in the delivered system with a Common Vulnerability Scoring System (CVSS) severity of medium or high. Related Controls: None.

• (2) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / SECURITY AND PRIVACY TRACKING TOOLS

Require the developer of the system, system component, or system service to select and employ security and privacy tracking tools for use during the development process. Discussion: System development teams select and deploy security and privacy tracking tools, including vulnerability or work item tracking systems that facilitate assignment, sorting, filtering, and tracking of completed work items or tasks associated with development processes. Related Controls: SA-11.

• (3) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / CRITICALITY ANALYSIS

Require the developer of the system, system component, or system service to perform a criticality analysis: (a) At the following decision points in the system development life cycle: [ Assignment: organization-defined decision points in the system development life cycle ]; and (b) At the following level of rigor: [ Assignment: organization-defined breadth and depth of criticality analysis ]. Discussion: Criticality analysis performed by the developer provides input to the criticality analysis performed by organizations. Developer input is essential to organizational criticality analysis because organizations may not have access to detailed design documentation for system components that are developed as commercial off-the-shelf products. Such design documentation includes functional specifications, high-level designs, low-level designs, source code, and hardware schematics. Criticality analysis is important for organizational systems that are designated as high value assets. High value assets can be moderate-or high-impact systems due to heightened adversarial interest or potential adverse effects on the federal enterprise. Developer input is especially important when organizations conduct supply chain criticality analyses. Related Controls: RA-9.

• (4) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / THREAT MODELING AND VULNERABILITY

• ANALYSIS

[Withdrawn: Incorporated into SA-11(2).]

• (5) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / ATTACK SURFACE REDUCTION

Require the developer of the system, system component, or system service to reduce attack surfaces to [ Assignment: organization-defined thresholds ]. Discussion: Attack surface reduction is closely aligned with threat and vulnerability analyses and system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within systems, system components, and system services. Attack surface reduction includes implementing the concept of layered defenses, applying the principles of least privilege and least functionality, applying secure software development practices, deprecating unsafe functions, reducing entry points available to unauthorized users, reducing the amount of code that executes, and eliminating application programming interfaces (APIs) that are vulnerable to attacks. Related Controls: AC-6 , CM-7 , RA-3 , SA-11.

• (6) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / CONTINUOUS IMPROVEMENT

800

5

Require the developer of the system, system component, or system service to implement an explicit process to continuously improve the development process. Discussion: Developers of systems, system components, and system services consider the effectiveness and efficiency of their development processes for meeting quality objectives and addressing the security and privacy capabilities in current threat environments. Related Controls: None.

• (7) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / AUTOMATED VULNERABILITY ANALYSIS

Require the developer of the system, system component, or system service [ Assignment: organization-defined frequency ] to: (a) Perform an automated vulnerability analysis using [ Assignment: organization-defined tools ]; (b) Determine the exploitation potential for discovered vulnerabilities; (c) Determine potential risk mitigations for delivered vulnerabilities; and (d) Deliver the outputs of the tools and results of the analysis to [ Assignment: organization-defined personnel or roles ]. Discussion: Automated tools can be more effective at analyzing exploitable weaknesses or deficiencies in large and complex systems, prioritizing vulnerabilities by severity, and providing recommendations for risk mitigations. Related Controls: RA-5 , SA-11.

• (8) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / REUSE OF THREAT AND VULNERABILITY

• INFORMATION

Require the developer of the system, system component, or system service to use threat modeling and vulnerability analyses from similar systems, components, or services to inform the current development process. Discussion: Analysis of vulnerabilities found in similar software applications can inform potential design and implementation issues for systems under development. Similar systems or system components may exist within developer organizations. Vulnerability information is available from a variety of public and private sector sources, including the NIST National Vulnerability Database. Related Controls: None.

• (9) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / USE OF LIVE DATA

[Withdrawn: Incorporated into SA-3(2).]

• (10) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / INCIDENT RESPONSE PLAN

Require the developer of the system, system component, or system service to provide, implement, and test an incident response plan. Discussion: The incident response plan provided by developers may provide information not readily available to organizations and be incorporated into organizational incident response plans. Developer information may also be extremely helpful, such as when organizations respond to vulnerabilities in commercial off-the-shelf products. Related Controls: IR-8.

• (11) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / ARCHIVE SYSTEM OR COMPONENT

Require the developer of the system or system component to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security and privacy review.

800

5

Discussion: Archiving system or system components requires the developer to retain key development artifacts, including hardware specifications, source code, object code, and relevant documentation from the development process that can provide a readily available configuration baseline for system and component upgrades or modifications. Related Controls: CM-2.

• (12) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS / MINIMIZE PERSONALLY IDENTIFIABLE

• INFORMATION

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments. Discussion: Organizations can minimize the risk to an individual’s privacy by using techniques such as de-identification or synthetic data. Limiting the use of personally identifiable information in development and test environments helps reduce the level of privacy risk created by a system.

• Related Controls: PM-25 , SA-3 , SA-8.

References: [SP 800-160-1 ], [IR 8179].

• SA-16 DEVELOPER-PROVIDED TRAINING

Control: Require the developer of the system, system component, or system service to provide the following training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms: [ Assignment: organization-defined training ]. Discussion: Developer-provided training applies to external and internal (in-house) developers. Training personnel is essential to ensuring the effectiveness of the controls implemented within organizational systems. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Organizations can also request training materials from developers to conduct in-house training or offer self-training to organizational personnel. Organizations determine the type of training necessary and may require different types of training for different security and privacy functions, controls, and mechanisms. Related Controls: AT-2 , AT-3 , PE-3 , SA-4 , SA-5. Control Enhancements: None. References: None.

• SA-17 DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN

Control: Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that: a. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;

b. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and c. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection. Discussion: Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, PL-8 is directed at internal developers to ensure that organizations develop a security and privacy

800

5

architecture that is integrated with the enterprise architecture. The distinction between SA-17 and PL-8 is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. [ISO 15408-2 ], [ISO 15408-3 ], and [SP 800-160-1 ] provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing.

• Related Controls: PL-2 , PL-8 , PM-7 , SA-3 , SA-4 , SA-8 , SC-7.

Control Enhancements:

• (1) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / FORMAL POLICY MODEL

Require the developer of the system, system component, or system service to: (a) Produce, as an integral part of the development process, a formal policy model describing the [ Assignment: organization-defined elements of organizational security and privacy policy ] to be enforced; and (b) Prove that the formal policy model is internally consistent and sufficient to enforce the defined elements of the organizational security and privacy policy when implemented. Discussion: Formal models describe specific behaviors or security and privacy policies using formal languages, thus enabling the correctness of those behaviors and policies to be formally proven. Not all components of systems can be modeled. Generally, formal specifications are scoped to the behaviors or policies of interest, such as nondiscretionary access control policies. Organizations choose the formal modeling language and approach based on the nature of the behaviors and policies to be described and the available tools. Related Controls: AC-3 , AC-4 , AC-25.

• (2) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / SECURITY-RELEVANT

• COMPONENTS

Require the developer of the system, system component, or system service to: (a) Define security-relevant hardware, software, and firmware; and (b) Provide a rationale that the definition for security-relevant hardware, software, and firmware is complete. Discussion: The security-relevant hardware, software, and firmware represent the portion of the system, component, or service that is trusted to perform correctly to maintain required security properties. Related Controls: AC-25 , SA-5.

• (3) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / FORMAL CORRESPONDENCE

Require the developer of the system, system component, or system service to: (a) Produce, as an integral part of the development process, a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects; (b) Show via proof to the extent feasible with additional informal demonstration as necessary, that the formal top-level specification is consistent with the formal policy model; (c) Show via informal demonstration, that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;

800

5

(d) Show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware; and (e) Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the formal top-level specification but strictly internal to the security- relevant hardware, software, and firmware. Discussion: Correspondence is an important part of the assurance gained through modeling. It demonstrates that the implementation is an accurate transformation of the model, and that any additional code or implementation details that are present have no impact on the behaviors or policies being modeled. Formal methods can be used to show that the high- level security properties are satisfied by the formal system description, and that the formal system description is correctly implemented by a description of some lower level, including a hardware description. Consistency between the formal top-level specification and the formal policy models is generally not amenable to being fully proven. Therefore, a combination of formal and informal methods may be needed to demonstrate such consistency. Consistency between the formal top-level specification and the actual implementation may require the use of an informal demonstration due to limitations on the applicability of formal methods to prove that the specification accurately reflects the implementation. Hardware, software, and firmware mechanisms internal to security-relevant components include mapping registers and direct memory input and output. Related Controls: AC-3 , AC-4 , AC-25 , SA-4 , SA-5.

• (4) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / INFORMAL CORRESPONDENCE

Require the developer of the system, system component, or system service to: (a) Produce, as an integral part of the development process, an informal descriptive top- level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects; (b) Show via [ Selection: informal demonstration, convincing argument with formal methods as feasible ] that the descriptive top-level specification is consistent with the formal policy model; (c) Show via informal demonstration, that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware; (d) Show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware; and (e) Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive top-level specification but strictly internal to the security- relevant hardware, software, and firmware. Discussion: Correspondence is an important part of the assurance gained through modeling. It demonstrates that the implementation is an accurate transformation of the model, and that additional code or implementation detail has no impact on the behaviors or policies being modeled. Consistency between the descriptive top-level specification (i.e., high- level/low-level design) and the formal policy model is generally not amenable to being fully proven. Therefore, a combination of formal and informal methods may be needed to show such consistency. Hardware, software, and firmware mechanisms strictly internal to security-relevant hardware, software, and firmware include mapping registers and direct memory input and output. Related Controls: AC-3 , AC-4 , AC-25 , SA-4 , SA-5.

• (5) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / CONCEPTUALLY SIMPLE DESIGN

Require the developer of the system, system component, or system service to:

800

5

(a) Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and (b) Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism. Discussion: The principle of reduced complexity states that the system design is as simple and small as possible (see SA-8(7)). A small and simple design is easier to understand and analyze and is also less prone to error (see AC-25 , SA-8(13)). The principle of reduced complexity applies to any aspect of a system, but it has particular importance for security due to the various analyses performed to obtain evidence about the emergent security property of the system. For such analyses to be successful, a small and simple design is essential. Application of the principle of reduced complexity contributes to the ability of system developers to understand the correctness and completeness of system security functions and facilitates the identification of potential vulnerabilities. The corollary of reduced complexity states that the simplicity of the system is directly related to the number of vulnerabilities it will contain. That is, simpler systems contain fewer vulnerabilities. An important benefit of reduced complexity is that it is easier to understand whether the security policy has been captured in the system design and that fewer vulnerabilities are likely to be introduced during engineering development. An additional benefit is that any such conclusion about correctness, completeness, and existence of vulnerabilities can be reached with a higher degree of assurance in contrast to conclusions reached in situations where the system design is inherently more complex. Related Controls: AC-25 , SA-8 , SC-3.

• (6) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / STRUCTURE FOR TESTING

Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing. Discussion: Applying the security design principles in [SP 800-160-1 ] promotes complete, consistent, and comprehensive testing and evaluation of systems, system components, and services. The thoroughness of such testing contributes to the evidence produced to generate an effective assurance case or argument as to the trustworthiness of the system, system component, or service. Related Controls: SA-5 , SA-11.

• (7) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / STRUCTURE FOR LEAST PRIVILEGE

Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege. Discussion: The principle of least privilege states that each component is allocated sufficient privileges to accomplish its specified functions but no more (see SA-8(14)). Applying the principle of least privilege limits the scope of the component’s actions, which has two desirable effects. First, the security impact of a failure, corruption, or misuse of the system component results in a minimized security impact. Second, the security analysis of the component is simplified. Least privilege is a pervasive principle that is reflected in all aspects of the secure system design. Interfaces used to invoke component capability are available to only certain subsets of the user population, and component design supports a sufficiently fine granularity of privilege decomposition. For example, in the case of an audit mechanism, there may be an interface for the audit manager, who configures the audit settings; an interface for the audit operator, who ensures that audit data is safely collected and stored; and, finally, yet another interface for the audit reviewer, who only has a need to view the audit data that has been collected but no need to perform operations on that data.

800

5

In addition to its manifestations at the system interface, least privilege can be used as a guiding principle for the internal structure of the system itself. One aspect of internal least privilege is to construct modules so that only the elements encapsulated by the module are directly operated upon by the functions within the module. Elements external to a module that may be affected by the module’s operation are indirectly accessed through interaction (e.g., via a function call) with the module that contains those elements. Another aspect of internal least privilege is that the scope of a given module or component includes only those system elements that are necessary for its functionality, and the access modes to the elements (e.g., read, write) are minimal. Related Controls: AC-5 , AC-6 , SA-8.

• (8) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / ORCHESTRATION

Design [ Assignment: organization-defined critical systems or system components ] with coordinated behavior to implement the following capabilities: [ Assignment: organization- defined capabilities, by system or component ]. Discussion: Security resources that are distributed, located at different layers or in different system elements, or are implemented to support different aspects of trustworthiness can interact in unforeseen or incorrect ways. Adverse consequences can include cascading failures, interference, or coverage gaps. Coordination of the behavior of security resources (e.g., by ensuring that one patch is installed across all resources before making a configuration change that assumes that the patch is propagated) can avert such negative interactions. Related Controls: None.

• (9) DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN / DESIGN DIVERSITY

Use different designs for [ Assignment: organization-defined critical systems or system components ] to satisfy a common set of requirements or to provide equivalent functionality. Discussion: Design diversity is achieved by supplying the same requirements specification to multiple developers, each of whom is responsible for developing a variant of the system or system component that meets the requirements. Variants can be in software design, in hardware design, or in both hardware and a software design. Differences in the designs of the variants can result from developer experience (e.g., prior use of a design pattern), design style (e.g., when decomposing a required function into smaller tasks, determining what constitutes a separate task and how far to decompose tasks into sub-tasks), selection of libraries to incorporate into the variant, and the development environment (e.g., different design tools make some design patterns easier to visualize). Hardware design diversity includes making different decisions about what information to keep in analog form and what information to convert to digital form, transmitting the same information at different times, and introducing delays in sampling (temporal diversity). Design diversity is commonly used to support fault tolerance. Related Controls: None. References: [ISO 15408-2 ], [ISO 15408-3 ], [SP 800-160-1 ].

• SA-18 TAMPER RESISTANCE AND DETECTION

[Withdrawn: Moved to SR-9 .] Control Enhancements:

• (1) TAMPER RESISTANCE AND DETECTION / MULTIPLE PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE

[Withdrawn: Moved to SR-9(1).]

800

5

• (2) TAMPER RESISTANCE AND DETECTION / INSPECTION OF SYSTEMS OR COMPONENTS

[Withdrawn: Moved to SR-10 .]

• SA-19 COMPONENT AUTHENTICITY

[Withdrawn: Moved to SR-11 .] Control Enhancements:

• (1) COMPONENT AUTHENTICITY / ANTI-COUNTERFEIT TRAINING

[Withdrawn: Moved to SR-11(1).]

• (2) COMPONENT AUTHENTICITY / CONFIGURATION CONTROL FOR COMPONENT SERVICE AND REPAIR

[Withdrawn: Moved to SR-11(2).]

• (3) COMPONENT AUTHENTICITY / COMPONENT DISPOSAL

[Withdrawn: Moved to SR-12 .]

• (4) COMPONENT AUTHENTICITY / ANTI-COUNTERFEIT SCANNING

[Withdrawn: Moved to SR-11(3).]

• SA-20 CUSTOMIZED DEVELOPMENT OF CRITICAL COMPONENTS

Control: Reimplement or custom develop the following critical system components: [ Assignment: organization-defined critical system components ]. Discussion: Organizations determine that certain system components likely cannot be trusted due to specific threats to and vulnerabilities in those components for which there are no viable security controls to adequately mitigate risk. Reimplementation or custom development of such components may satisfy requirements for higher assurance and is carried out by initiating changes to system components (including hardware, software, and firmware) such that the standard attacks by adversaries are less likely to succeed. In situations where no alternative sourcing is available and organizations choose not to reimplement or custom develop critical system components, additional controls can be employed. Controls include enhanced auditing, restrictions on source code and system utility access, and protection from deletion of system and application files. Related Controls: CP-2 , RA-9 , SA-8.

Control Enhancements: None. References: [SP 800-160-1 ].

• SA-21 DEVELOPER SCREENING

Control: Require that the developer of [ Assignment: organization-defined system, system component, or system service ]: a. Has appropriate access authorizations as determined by assigned [ Assignment: organization- defined official government duties ]; and b. Satisfies the following additional personnel screening criteria: [ Assignment: organization- defined additional personnel screening criteria ]. Discussion: Developer screening is directed at external developers. Internal developer screening is addressed by PS-3. Because the system, system component, or system service may be used in critical activities essential to the national or economic security interests of the United States, organizations have a strong interest in ensuring that developers are trustworthy. The degree of

800

5

trust required of developers may need to be consistent with that of the individuals who access the systems, system components, or system services once deployed. Authorization and personnel screening criteria include clearances, background checks, citizenship, and nationality. Developer trustworthiness may also include a review and analysis of company ownership and relationships that the company has with entities that may potentially affect the quality and reliability of the systems, components, or services being developed. Satisfying the required access authorizations and personnel screening criteria includes providing a list of all individuals who are authorized to perform development activities on the selected system, system component, or system service so that organizations can validate that the developer has satisfied the authorization and screening requirements.

Related Controls: PS-2 , PS-3 , PS-6 , PS-7 , SA-4 , SR-6. Control Enhancements:

• (1) DEVELOPER SCREENING / VALIDATION OF SCREENING

[Withdrawn: Incorporated into SA-21 .]

References: None.

• SA-22 UNSUPPORTED SYSTEM COMPONENTS

Control: a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or b. Provide the following options for alternative sources for continued support for unsupported components [ Selection (one or more): in-house support; [ Assignment: organization-defined support from external providers ]]. Discussion: Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option. Alternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation. Related Controls: PL-2 , SA-3. Control Enhancements:

• (1) UNSUPPORTED SYSTEM COMPONENTS / ALTERNATIVE SOURCES FOR CONTINUED SUPPORT

[Withdrawn: Incorporated into SA-22 .] References: None.

800

5

• SA-23 SPECIALIZATION

Control: Employ [ Selection (one or more): design modification, augmentation, reconfiguration ] on [ Assignment: organization-defined systems or system components ] supporting mission essential services or functions to increase the trustworthiness in those systems or components.

Discussion: It is often necessary for a system or system component that supports mission- essential services or functions to be enhanced to maximize the trustworthiness of the resource. Sometimes this enhancement is done at the design level. In other instances, it is done post- design, either through modifications of the system in question or by augmenting the system with additional components. For example, supplemental authentication or non-repudiation functions may be added to the system to enhance the identity of critical resources to other resources that depend on the organization-defined resources. Related Controls: RA-9 , SA-8. Control Enhancements: None. References: [SP 800-160-1 ], [SP 800-160-2 ].

800

5

Quick link to System and Communications Protection Summary Table

• SC-1 POLICY AND PROCEDURES

Control: a. Develop, document, and disseminate to [ Assignment: organization-defined personnel or roles ]:

1. [ Selection (one or more): organization-level; mission/business process-level; system- level ] system and communications protection policy that: (a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls; b. Designate an [ Assignment: organization-defined official ] to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and c. Review and update the current system and communications protection:
3. Policy [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]; and
4. Procedures [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]. Discussion: System and communications protection policy and procedures address the controls in the SC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and communications protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission-or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and communications protection policy and procedures include assessment or audit findings, security or privacy incidents, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. Related Controls: PM-9 , PS-8 , SA-8 , SI-12. Control Enhancements: None. References: [OMB A-130 ], [SP 800-12 ], [SP 800-100 ].

800

5

• SC-2 SEPARATION OF SYSTEM AND USER FUNCTIONALITY

Control: Separate user functionality, including user interface services, from system management functionality. Discussion: System management functionality includes functions that are necessary to administer databases, network components, workstations, or servers. These functions typically require privileged user access. The separation of user functions from system management functions is physical or logical. Organizations may separate system management functions from user functions by using different computers, instances of operating systems, central processing units, or network addresses; by employing virtualization techniques; or some combination of these or other methods. Separation of system management functions from user functions includes web administrative interfaces that employ separate authentication methods for users of any other system resources. Separation of system and user functions may include isolating administrative interfaces on different domains and with additional access controls. The separation of system and user functionality can be achieved by applying the systems security engineering design principles in SA-8 , including SA-8(1), SA-8(3), SA-8(4), SA-8(10), SA-8(12), SA- 8(13), SA-8(14), and SA-8(18). Related Controls: AC-6 , SA-4 , SA-8 , SC-3 , SC-7 , SC-22 , SC-32 , SC-39. Control Enhancements:

• (1) SEPARATION OF SYSTEM AND USER FUNCTIONALITY / INTERFACES FOR NON-PRIVILEGED USERS

Prevent the presentation of system management functionality at interfaces to non- privileged users. Discussion: Preventing the presentation of system management functionality at interfaces to non-privileged users ensures that system administration options, including administrator privileges, are not available to the general user population. Restricting user access also prohibits the use of the grey-out option commonly used to eliminate accessibility to such information. One potential solution is to withhold system administration options until users establish sessions with administrator privileges. Related Controls: AC-3.

• (2) SEPARATION OF SYSTEM AND USER FUNCTIONALITY / DISASSOCIABILITY

• Store state information from applications and software separately.

Discussion: If a system is compromised, storing applications and software separately from state information about users’ interactions with an application may better protect individuals’ privacy. Related Controls: None. References: None.

• SC-3 SECURITY FUNCTION ISOLATION

Control: Isolate security functions from nonsecurity functions. Discussion: Security functions are isolated from nonsecurity functions by means of an isolation boundary implemented within a system via partitions and domains. The isolation boundary controls access to and protects the integrity of the hardware, software, and firmware that perform system security functions. Systems implement code separation in many ways, such as through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that protect the code on disk and address space protections that protect executing code. Systems can restrict access to security functions using access control mechanisms and by implementing least privilege

800

5

capabilities. While the ideal is for all code within the defined security function isolation boundary to only contain security-relevant code, it is sometimes necessary to include nonsecurity functions as an exception. The isolation of security functions from nonsecurity functions can be achieved by applying the systems security engineering design principles in SA-8 , including SA-8(1), SA-8(3), SA-8(4), SA-8(10), SA-8(12), SA-8(13), SA-8(14), and SA-8(18). Related Controls: AC-3 , AC-6 , AC-25 , CM-2 , CM-4 , SA-4 , SA-5 , SA-8 , SA-15 , SA-17 , SC-2 , SC-7 , SC- 32 , SC-39 , SI-16. Control Enhancements:

• (1) SECURITY FUNCTION ISOLATION / HARDWARE SEPARATION

Employ hardware separation mechanisms to implement security function isolation. Discussion: Hardware separation mechanisms include hardware ring architectures that are implemented within microprocessors and hardware-enforced address segmentation used to support logically distinct storage objects with separate attributes (i.e., readable, writeable). Related Controls: None.

• (2) SECURITY FUNCTION ISOLATION / ACCESS AND FLOW CONTROL FUNCTIONS

Isolate security functions enforcing access and information flow control from nonsecurity functions and from other security functions. Discussion: Security function isolation occurs because of implementation. The functions can still be scanned and monitored. Security functions that are potentially isolated from access and flow control enforcement functions include auditing, intrusion detection, and malicious code protection functions. Related Controls: None.

• (3) SECURITY FUNCTION ISOLATION / MINIMIZE NONSECURITY FUNCTIONALITY

Minimize the number of nonsecurity functions included within the isolation boundary containing security functions. Discussion: Where it is not feasible to achieve strict isolation of nonsecurity functions from security functions, it is necessary to take actions to minimize nonsecurity-relevant functions within the security function boundary. Nonsecurity functions contained within the isolation boundary are considered security-relevant because errors or malicious code in the software can directly impact the security functions of systems. The fundamental design objective is that the specific portions of systems that provide information security are of minimal size and complexity. Minimizing the number of nonsecurity functions in the security-relevant system components allows designers and implementers to focus only on those functions which are necessary to provide the desired security capability (typically access enforcement). By minimizing the nonsecurity functions within the isolation boundaries, the amount of code that is trusted to enforce security policies is significantly reduced, thus contributing to understandability. Related Controls: None.

• (4) SECURITY FUNCTION ISOLATION / MODULE COUPLING AND COHESIVENESS

Implement security functions as largely independent modules that maximize internal cohesiveness within modules and minimize coupling between modules. Discussion: The reduction of inter-module interactions helps to constrain security functions and manage complexity. The concepts of coupling and cohesion are important with respect to modularity in software design. Coupling refers to the dependencies that one module has on other modules. Cohesion refers to the relationship between functions within a module. Best practices in software engineering and systems security engineering rely on layering,

800

5

minimization, and modular decomposition to reduce and manage complexity. This produces software modules that are highly cohesive and loosely coupled. Related Controls: None.

• (5) SECURITY FUNCTION ISOLATION / LAYERED STRUCTURES

Implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. Discussion: The implementation of layered structures with minimized interactions among security functions and non-looping layers (i.e., lower-layer functions do not depend on higher-layer functions) enables the isolation of security functions and the management of complexity. Related Controls: None. References: None.

• SC-4 INFORMATION IN SHARED SYSTEM RESOURCES

Control: Prevent unauthorized and unintended information transfer via shared system resources. Discussion: Preventing unauthorized and unintended information transfer via shared system resources stops information produced by the actions of prior users or roles (or the actions of processes acting on behalf of prior users or roles) from being available to current users or roles (or current processes acting on behalf of current users or roles) that obtain access to shared system resources after those resources have been released back to the system. Information in shared system resources also applies to encrypted representations of information. In other contexts, control of information in shared system resources is referred to as object reuse and residual information protection. Information in shared system resources does not address information remanence, which refers to the residual representation of data that has been nominally deleted; covert channels (including storage and timing channels), where shared system resources are manipulated to violate information flow restrictions; or components within systems for which there are only single users or roles. Related Controls: AC-3 , AC-4 , SA-8. Control Enhancements:

• (1) INFORMATION IN SHARED SYSTEM RESOURCES / SECURITY LEVELS

[Withdrawn: Incorporated into SC-4 .]

• (2) INFORMATION IN SHARED SYSTEM RESOURCES / MULTILEVEL OR PERIODS PROCESSING

Prevent unauthorized information transfer via shared resources in accordance with [ Assignment: organization-defined procedures ] when system processing explicitly switches between different information classification levels or security categories. Discussion: Changes in processing levels can occur during multilevel or periods processing with information at different classification levels or security categories. It can also occur during serial reuse of hardware components at different classification levels. Organization- defined procedures can include approved sanitization processes for electronically stored information. Related Controls: None. References: None.

800

5

• SC-5 DENIAL-OF-SERVICE PROTECTION

Control: a. [ Selection: Protect against; Limit ] the effects of the following types of denial-of-service events: [ Assignment: organization-defined types of denial-of-service events ]; and

b. Employ the following controls to achieve the denial-of-service objective: [ Assignment: organization-defined controls by type of denial-of-service event ]. Discussion: Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events. Related Controls: CP-2 , IR-4 , SC-6 , SC-7 , SC-40. Control Enhancements:

• (1) DENIAL-OF-SERVICE PROTECTION / RESTRICT ABILITY TO ATTACK OTHER SYSTEMS

• Restrict the ability of individuals to launch the following denial-of-service attacks against

other systems: [ Assignment: organization-defined denial-of-service attacks ]. Discussion: Restricting the ability of individuals to launch denial-of-service attacks requires the mechanisms commonly used for such attacks to be unavailable. Individuals of concern include hostile insiders or external adversaries who have breached or compromised the system and are using it to launch a denial-of-service attack. Organizations can restrict the ability of individuals to connect and transmit arbitrary information on the transport medium (i.e., wired networks, wireless networks, spoofed Internet protocol packets). Organizations can also limit the ability of individuals to use excessive system resources. Protection against individuals having the ability to launch denial-of-service attacks may be implemented on specific systems or boundary devices that prohibit egress to potential target systems. Related Controls: None.

• (2) DENIAL-OF-SERVICE PROTECTION / CAPACITY, BANDWIDTH, AND REDUNDANCY

Manage capacity, bandwidth, or other redundancy to limit the effects of information flooding denial-of-service attacks. Discussion: Managing capacity ensures that sufficient capacity is available to counter flooding attacks. Managing capacity includes establishing selected usage priorities, quotas, partitioning, or load balancing. Related Controls: None.

• (3) DENIAL-OF-SERVICE PROTECTION / DETECTION AND MONITORING

(a) Employ the following monitoring tools to detect indicators of denial-of-service attacks against, or launched from, the system: [ Assignment: organization-defined monitoring tools ]; and (b) Monitor the following system resources to determine if sufficient resources exist to prevent effective denial-of-service attacks: [ Assignment: organization-defined system resources ].

800

5

Discussion: Organizations consider the utilization and capacity of system resources when managing risk associated with a denial of service due to malicious attacks. Denial-of-service attacks can originate from external or internal sources. System resources that are sensitive to denial of service include physical disk storage, memory, and CPU cycles. Techniques used to prevent denial-of-service attacks related to storage utilization and capacity include instituting disk quotas, configuring systems to automatically alert administrators when specific storage capacity thresholds are reached, using file compression technologies to maximize available storage space, and imposing separate partitions for system and user data. Related Controls: CA-7 , SI-4.

References: [SP 800-189 ].

• SC-6 RESOURCE AVAILABILITY

Control: Protect the availability of resources by allocating [ Assignment: organization-defined resources ] by [ Selection (one or more); priority; quota; [ Assignment: organization-defined controls ]]. Discussion: Priority protection prevents lower-priority processes from delaying or interfering with the system that services higher-priority processes. Quotas prevent users or processes from obtaining more than predetermined amounts of resources. Related Controls: SC-5.

Control Enhancements: None. References: [OMB M-08-05 ], [DHS TIC].

• SC-7 BOUNDARY PROTECTION

Control: a. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system; b. Implement subnetworks for publicly accessible system components that are [ Selection: physically; logically ] separated from internal organizational networks; and

c. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture. Discussion: Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary).

800

5

Related Controls: AC-4 , AC-17 , AC-18 , AC-19 , AC-20 , AU-13 , CA-3 , CM-2 , CM-4 , CM-7 , CM-10 , CP- 8 , CP-10 , IR-4 , MA-4 , PE-3 , PL-8 , PM-12 , SA-8 , SA-17 , SC-5 , SC-26 , SC-32 , SC-35 , SC-43. Control Enhancements:

• (1) BOUNDARY PROTECTION / PHYSICALLY SEPARATED SUBNETWORKS

[Withdrawn: Incorporated into SC-7 .]

• (2) BOUNDARY PROTECTION / PUBLIC ACCESS

[Withdrawn: Incorporated into SC-7 .]

• (3) BOUNDARY PROTECTION / ACCESS POINTS

Limit the number of external network connections to the system. Discussion: Limiting the number of external network connections facilitates monitoring of inbound and outbound communications traffic. The Trusted Internet Connection [DHS TIC] initiative is an example of a federal guideline that requires limits on the number of external network connections. Limiting the number of external network connections to the system is important during transition periods from older to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols). Such transitions may require implementing the older and newer technologies simultaneously during the transition period and thus increase the number of access points to the system. Related Controls: None.

• (4) BOUNDARY PROTECTION / EXTERNAL TELECOMMUNICATIONS SERVICES

(a) Implement a managed interface for each external telecommunication service; (b) Establish a traffic flow policy for each managed interface; (c) Protect the confidentiality and integrity of the information being transmitted across each interface; (d) Document each exception to the traffic flow policy with a supporting mission or business need and duration of that need; (e) Review exceptions to the traffic flow policy [ Assignment: organization-defined frequency ] and remove exceptions that are no longer supported by an explicit mission or business need; (f) Prevent unauthorized exchange of control plane traffic with external networks; (g) Publish information to enable remote networks to detect unauthorized control plane traffic from internal networks; and (h) Filter unauthorized control plane traffic from external networks. Discussion: External telecommunications services can provide data and/or voice communications services. Examples of control plane traffic include routing, Domain Name System (DNS), and management. Unauthorized control plane traffic can occur through a technique known as “spoofing.” Related Controls: AC-3 , SC-8.

• (5) BOUNDARY PROTECTION / DENY BY DEFAULT — ALLOW BY EXCEPTION

Deny network communications traffic by default and allow network communications traffic by exception [ Selection (one or more); at managed interfaces; for [ Assignment: organization-defined systems ]]. Discussion: Denying by default and allowing by exception applies to inbound and outbound network communications traffic. A deny-all, permit-by-exception network communications traffic policy ensures that only those system connections that are essential and approved are

800

5

allowed. Deny by default, allow by exception also applies to a system that is connected to an external system. Related Controls: None.

• (6) BOUNDARY PROTECTION / RESPONSE TO RECOGNIZED FAILURES

• [Withdrawn: Incorporated into SC-7(18).]

• (7) BOUNDARY PROTECTION / SPLIT TUNNELING FOR REMOTE DEVICES

Prevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using [ Assignment: organization-defined safeguards ]. Discussion: Split tunneling is the process of allowing a remote user or device to establish a non-remote connection with a system and simultaneously communicate via some other connection to a resource in an external network. This method of network access enables a user to access remote devices and simultaneously, access uncontrolled networks. Split tunneling might be desirable by remote users to communicate with local system resources, such as printers or file servers. However, split tunneling can facilitate unauthorized external connections, making the system vulnerable to attack and to exfiltration of organizational information. Split tunneling can be prevented by disabling configuration settings that allow such capability in remote devices and by preventing those configuration settings from being configurable by users. Prevention can also be achieved by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling. A virtual private network (VPN) can be used to securely provision a split tunnel. A securely provisioned VPN includes locking connectivity to exclusive, managed, and named environments, or to a specific set of pre- approved addresses, without user control. Related Controls: None.

• (8) BOUNDARY PROTECTION / ROUTE TRAFFIC TO AUTHENTICATED PROXY SERVERS

Route [ Assignment: organization-defined internal communications traffic ] to [ Assignment: organization-defined external networks ] through authenticated proxy servers at managed interfaces. Discussion: External networks are networks outside of organizational control. A proxy server is a server (i.e., system or application) that acts as an intermediary for clients requesting system resources from non-organizational or other organizational servers. System resources that may be requested include files, connections, web pages, or services. Client requests established through a connection to a proxy server are assessed to manage complexity and provide additional protection by limiting direct connectivity. Web content filtering devices are one of the most common proxy servers that provide access to the Internet. Proxy servers can support the logging of Transmission Control Protocol sessions and the blocking of specific Uniform Resource Locators, Internet Protocol addresses, and domain names. Web proxies can be configured with organization-defined lists of authorized and unauthorized websites. Note that proxy servers may inhibit the use of virtual private networks (VPNs) and create the potential for “man-in-the-middle” attacks (depending on the implementation). Related Controls: AC-3.

• (9) BOUNDARY PROTECTION / RESTRICT THREATENING OUTGOING COMMUNICATIONS TRAFFIC

(a) Detect and deny outgoing communications traffic posing a threat to external systems; and (b) Audit the identity of internal users associated with denied communications. Discussion: Detecting outgoing communications traffic from internal actions that may pose threats to external systems is known as extrusion detection. Extrusion detection is carried out within the system at managed interfaces. Extrusion detection includes the analysis of

800

5

incoming and outgoing communications traffic while searching for indications of internal threats to the security of external systems. Internal threats to external systems include traffic indicative of denial-of-service attacks, traffic with spoofed source addresses, and

• traffic that contains malicious code. Organizations have criteria to determine, update, and

manage identified threats related to extrusion detection. Related Controls: AU-2 , AU-6 , SC-5 , SC-38 , SC-44 , SI-3 , SI-4.

• (10) BOUNDARY PROTECTION / PREVENT EXFILTRATION

(a) Prevent the exfiltration of information; and (b) Conduct exfiltration tests [ Assignment: organization-defined frequency ]. Discussion: Prevention of exfiltration applies to both the intentional and unintentional exfiltration of information. Techniques used to prevent the exfiltration of information from systems may be implemented at internal endpoints, external boundaries, and across managed interfaces and include adherence to protocol formats, monitoring for beaconing activity from systems, disconnecting external network interfaces except when explicitly needed, employing traffic profile analysis to detect deviations from the volume and types of traffic expected, call backs to command and control centers, conducting penetration testing, monitoring for steganography, disassembling and reassembling packet headers, and using data loss and data leakage prevention tools. Devices that enforce strict adherence to protocol formats include deep packet inspection firewalls and Extensible Markup Language (XML) gateways. The devices verify adherence to protocol formats and specifications at the application layer and identify vulnerabilities that cannot be detected by devices that operate at the network or transport layers. The prevention of exfiltration is similar to data loss prevention or data leakage prevention and is closely associated with cross-domain solutions and system guards that enforce information flow requirements. Related Controls: AC-2 , CA-8 , SI-3.

• (11) BOUNDARY PROTECTION / RESTRICT INCOMING COMMUNICATIONS TRAFFIC

Only allow incoming communications from [ Assignment: organization-defined authorized sources ] to be routed to [ Assignment: organization-defined authorized destinations ]. Discussion: General source address validation techniques are applied to restrict the use of illegal and unallocated source addresses as well as source addresses that should only be used within the system. The restriction of incoming communications traffic provides determinations that source and destination address pairs represent authorized or allowed communications. Determinations can be based on several factors, including the presence of such address pairs in the lists of authorized or allowed communications, the absence of such address pairs in lists of unauthorized or disallowed pairs, or meeting more general rules for

• authorized or allowed source and destination pairs. Strong authentication of network

addresses is not possible without the use of explicit security protocols, and thus, addresses can often be spoofed. Further, identity-based incoming traffic restriction methods can be employed, including router access control lists and firewall rules. Related Controls: AC-3.

• (12) BOUNDARY PROTECTION / HOST-BASED PROTECTION

Implement [ Assignment: organization-defined host-based boundary protection mechanisms ] at [ Assignment: organization-defined system components ]. Discussion: Host-based boundary protection mechanisms include host-based firewalls. System components that employ host-based boundary protection mechanisms include servers, workstations, notebook computers, and mobile devices. Related Controls: None.

800

5

• (13) BOUNDARY PROTECTION / ISOLATION OF SECURITY TOOLS, MECHANISMS, AND SUPPORT

• COMPONENTS

Isolate [ Assignment: organization-defined information security tools, mechanisms, and support components ] from other internal system components by implementing physically separate subnetworks with managed interfaces to other components of the system. Discussion: Physically separate subnetworks with managed interfaces are useful in isolating computer network defenses from critical operational processing networks to prevent adversaries from discovering the analysis and forensics techniques employed by organizations. Related Controls: SC-2 , SC-3.

• (14) BOUNDARY PROTECTION / PROTECT AGAINST UNAUTHORIZED PHYSICAL CONNECTIONS

Protect against unauthorized physical connections at [ Assignment: organization-defined managed interfaces ]. Discussion: Systems that operate at different security categories or classification levels may share common physical and environmental controls, since the systems may share space within the same facilities. In practice, it is possible that these separate systems may share common equipment rooms, wiring closets, and cable distribution paths. Protection against unauthorized physical connections can be achieved by using clearly identified and physically separated cable trays, connection frames, and patch panels for each side of managed interfaces with physical access controls that enforce limited authorized access to these items. Related Controls: PE-4 , PE-19.

• (15) BOUNDARY PROTECTION / NETWORKED PRIVILEGED ACCESSES

Route networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing. Discussion: Privileged access provides greater accessibility to system functions, including security functions. Adversaries attempt to gain privileged access to systems through remote access to cause adverse mission or business impacts, such as by exfiltrating information or

• bringing down a critical system capability. Routing networked, privileged access requests

through a dedicated, managed interface further restricts privileged access for increased access control and auditing. Related Controls: AC-2 , AC-3 , AU-2 , SI-4.

• (16) BOUNDARY PROTECTION / PREVENT DISCOVERY OF SYSTEM COMPONENTS

Prevent the discovery of specific system components that represent a managed interface. Discussion: Preventing the discovery of system components representing a managed interface helps protect network addresses of those components from discovery through common tools and techniques used to identify devices on networks. Network addresses are not available for discovery and require prior knowledge for access. Preventing the discovery of components and devices can be accomplished by not publishing network addresses, using network address translation, or not entering the addresses in domain name systems. Another prevention technique is to periodically change network addresses. Related Controls: None.

• (17) BOUNDARY PROTECTION / AUTOMATED ENFORCEMENT OF PROTOCOL FORMATS

Enforce adherence to protocol formats. Discussion: System components that enforce protocol formats include deep packet inspection firewalls and XML gateways. The components verify adherence to protocol

800

5

formats and specifications at the application layer and identify vulnerabilities that cannot be detected by devices operating at the network or transport layers. Related Controls: SC-4.

• (18) BOUNDARY PROTECTION / FAIL SECURE

Prevent systems from entering unsecure states in the event of an operational failure of a boundary protection device. Discussion: Fail secure is a condition achieved by employing mechanisms to ensure that in the event of operational failures of boundary protection devices at managed interfaces, systems do not enter into unsecure states where intended security properties no longer hold. Managed interfaces include routers, firewalls, and application gateways that reside on protected subnetworks (commonly referred to as demilitarized zones). Failures of boundary protection devices cannot lead to or cause information external to the devices to enter the devices nor can failures permit unauthorized information releases. Related Controls: CP-2 , CP-12 , SC-24.

• (19) BOUNDARY PROTECTION / BLOCK COMMUNICATION FROM NON-ORGANIZATIONALLY CONFIGURED

• HOSTS

Block inbound and outbound communications traffic between [ Assignment: organization- defined communication clients ] that are independently configured by end users and external service providers. Discussion: Communication clients independently configured by end users and external

• service providers include instant messaging clients and video conferencing software and

applications. Traffic blocking does not apply to communication clients that are configured by organizations to perform authorized functions. Related Controls: None.

• (20) BOUNDARY PROTECTION / DYNAMIC ISOLATION AND SEGREGATION

Provide the capability to dynamically isolate [ Assignment: organization-defined system components ] from other system components. Discussion: The capability to dynamically isolate certain internal system components is useful when it is necessary to partition or separate system components of questionable origin from components that possess greater trustworthiness. Component isolation reduces the attack surface of organizational systems. Isolating selected system components can also limit the damage from successful attacks when such attacks occur. Related Controls: None.

• (21) BOUNDARY PROTECTION / ISOLATION OF SYSTEM COMPONENTS

Employ boundary protection mechanisms to isolate [ Assignment: organization-defined system components ] supporting [ Assignment: organization-defined missions and/or business functions ]. Discussion: Organizations can isolate system components that perform different mission or business functions. Such isolation limits unauthorized information flows among system components and provides the opportunity to deploy greater levels of protection for selected system components. Isolating system components with boundary protection mechanisms provides the capability for increased protection of individual system components and to more effectively control information flows between those components. Isolating system components provides enhanced protection that limits the potential harm from hostile cyber- attacks and errors. The degree of isolation varies depending upon the mechanisms chosen. Boundary protection mechanisms include routers, gateways, and firewalls that separate system components into physically separate networks or subnetworks; cross-domain devices

800

5

that separate subnetworks; virtualization techniques; and the encryption of information flows among system components using distinct encryption keys. Related Controls: CA-9.

• (22) BOUNDARY PROTECTION / SEPARATE SUBNETS FOR CONNECTING TO DIFFERENT SECURITY DOMAINS

Implement separate network addresses to connect to systems in different security domains. Discussion: The decomposition of systems into subnetworks (i.e., subnets) helps to provide the appropriate level of protection for network connections to different security domains that contain information with different security categories or classification levels. Related Controls: None.

• (23) BOUNDARY PROTECTION / DISABLE SENDER FEEDBACK ON PROTOCOL VALIDATION FAILURE

Disable feedback to senders on protocol format validation failure. Discussion: Disabling feedback to senders when there is a failure in protocol validation format prevents adversaries from obtaining information that would otherwise be unavailable. Related Controls: None.

• (24) BOUNDARY PROTECTION / PERSONALLY IDENTIFIABLE INFORMATION

For systems that process personally identifiable information: (a) Apply the following processing rules to data elements of personally identifiable information: [ Assignment: organization-defined processing rules ]; (b) Monitor for permitted processing at the external interfaces to the system and at key internal boundaries within the system; (c) Document each processing exception; and (d) Review and remove exceptions that are no longer supported. Discussion: Managing the processing of personally identifiable information is an important aspect of protecting an individual’s privacy. Applying, monitoring for, and documenting exceptions to processing rules ensure that personally identifiable information is processed only in accordance with established privacy requirements. Related Controls: PT-2 , SI-15.

• (25) BOUNDARY PROTECTION / UNCLASSIFIED NATIONAL SECURITY SYSTEM CONNECTIONS

Prohibit the direct connection of [ Assignment: organization-defined unclassified national security system ] to an external network without the use of [ Assignment: organization- defined boundary protection device ]. Discussion: A direct connection is a dedicated physical or virtual connection between two or more systems. Organizations typically do not have complete control over external networks, including the Internet. Boundary protection devices (e.g., firewalls, gateways, and routers) mediate communications and information flows between unclassified national security systems and external networks. Related Controls: None.

• (26) BOUNDARY PROTECTION / CLASSIFIED NATIONAL SECURITY SYSTEM CONNECTIONS

Prohibit the direct connection of a classified national security system to an external network without the use of [ Assignment: organization-defined boundary protection device ]. Discussion: A direct connection is a dedicated physical or virtual connection between two or more systems. Organizations typically do not have complete control over external networks,

800

5

including the Internet. Boundary protection devices (e.g., firewalls, gateways, and routers) mediate communications and information flows between classified national security systems and external networks. In addition, approved boundary protection devices (typically managed interface or cross-domain systems) provide information flow enforcement from systems to external networks. Related Controls: None.

• (27) BOUNDARY PROTECTION / UNCLASSIFIED NON-NATIONAL SECURITY SYSTEM CONNECTIONS

Prohibit the direct connection of [ Assignment: organization-defined unclassified non- national security system ] to an external network without the use of [ Assignment: organization-defined boundary protection device ]. Discussion: A direct connection is a dedicated physical or virtual connection between two or more systems. Organizations typically do not have complete control over external networks, including the Internet. Boundary protection devices (e.g., firewalls, gateways, and routers) mediate communications and information flows between unclassified non-national security systems and external networks. Related Controls: None.

• (28) BOUNDARY PROTECTION / CONNECTIONS TO PUBLIC NETWORKS

Prohibit the direct connection of [ Assignment: organization-defined system ] to a public network. Discussion: A direct connection is a dedicated physical or virtual connection between two or more systems. A public network is a network accessible to the public, including the Internet and organizational extranets with public access. Related Controls: None.

• (29) BOUNDARY PROTECTION / SEPARATE SUBNETS TO ISOLATE FUNCTIONS

Implement [ Selection: physically; logically ] separate subnetworks to isolate the following critical system components and functions: [ Assignment: organization-defined critical system components and functions ]. Discussion: Separating critical system components and functions from other noncritical system components and functions through separate subnetworks may be necessary to reduce susceptibility to a catastrophic or debilitating breach or compromise that results in system failure. For example, physically separating the command and control function from the in-flight entertainment function through separate subnetworks in a commercial aircraft provides an increased level of assurance in the trustworthiness of critical system functions. Related Controls: None. References: [OMB A-130 ], [FIPS 199], [SP 800-37 ], [SP 800-41 ], [SP 800-77 ], [SP 800-189 ].

• SC-8 TRANSMISSION CONFIDENTIALITY AND INTEGRITY

Control: Protect the [ Selection (one or more): confidentiality; integrity ] of transmitted information. Discussion: Protecting the confidentiality and integrity of transmitted information applies to internal and external networks as well as any system components that can transmit information, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of information can be accomplished by physical or logical means. Physical protection can be achieved by using protected distribution systems. A protected distribution system is a wireline or fiber-optics telecommunications system that includes terminals and adequate electromagnetic,

800

5

acoustical, electrical, and physical controls to permit its use for the unencrypted transmission of classified information. Logical protection can be achieved by employing encryption techniques. Organizations that rely on commercial providers who offer transmission services as commodity services rather than as fully dedicated services may find it difficult to obtain the necessary assurances regarding the implementation of needed controls for transmission confidentiality and integrity. In such situations, organizations determine what types of confidentiality or integrity services are available in standard, commercial telecommunications service packages. If it is not feasible to obtain the necessary controls and assurances of control effectiveness through appropriate contracting vehicles, organizations can implement appropriate compensating controls.

Related Controls: AC-17 , AC-18 , AU-10 , IA-3 , IA-8 , IA-9 , MA-4 , PE-4 , SA-4 , SA-8 , SC-7 , SC-16 , SC- 20 , SC-23 , SC-28. Control Enhancements:

• (1) TRANSMISSION CONFIDENTIALITY AND INTEGRITY / CRYPTOGRAPHIC PROTECTION

Implement cryptographic mechanisms to [ Selection (one or more): prevent unauthorized disclosure of information; detect changes to information ] during transmission. Discussion: Encryption protects information from unauthorized disclosure and modification during transmission. Cryptographic mechanisms that protect the confidentiality and integrity of information during transmission include TLS and IPSec. Cryptographic mechanisms used to protect information integrity include cryptographic hash functions that have applications in digital signatures, checksums, and message authentication codes. Related Controls: SC-12 , SC-13.

• (2) TRANSMISSION CONFIDENTIALITY AND INTEGRITY / PRE-AND POST-TRANSMISSION HANDLING

Maintain the [ Selection (one or more): confidentiality; integrity ] of information during preparation for transmission and during reception. Discussion: Information can be unintentionally or maliciously disclosed or modified during preparation for transmission or during reception, including during aggregation, at protocol transformation points, and during packing and unpacking. Such unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. Related Controls: None.

• (3) TRANSMISSION CONFIDENTIALITY AND INTEGRITY / CRYPTOGRAPHIC PROTECTION FOR MESSAGE

• EXTERNALS

Implement cryptographic mechanisms to protect message externals unless otherwise protected by [ Assignment: organization-defined alternative physical controls ]. Discussion: Cryptographic protection for message externals addresses protection from the unauthorized disclosure of information. Message externals include message headers and routing information. Cryptographic protection prevents the exploitation of message externals and applies to internal and external networks or links that may be visible to individuals who are not authorized users. Header and routing information is sometimes transmitted in clear text (i.e., unencrypted) because the information is not identified by organizations as having significant value or because encrypting the information can result in lower network performance or higher costs. Alternative physical controls include protected distribution systems. Related Controls: SC-12 , SC-13.

• (4) TRANSMISSION CONFIDENTIALITY AND INTEGRITY / CONCEAL OR RANDOMIZE COMMUNICATIONS

800

5

Implement cryptographic mechanisms to conceal or randomize communication patterns unless otherwise protected by [ Assignment: organization-defined alternative physical controls ]. Discussion: Concealing or randomizing communication patterns addresses protection from unauthorized disclosure of information. Communication patterns include frequency, periods, predictability, and amount. Changes to communications patterns can reveal information with intelligence value, especially when combined with other available information related to the mission and business functions of the organization. Concealing or randomizing communications prevents the derivation of intelligence based on communications patterns and applies to both internal and external networks or links that may be visible to individuals who are not authorized users. Encrypting the links and transmitting in continuous, fixed, or random patterns prevents the derivation of intelligence from the system communications patterns. Alternative physical controls include protected distribution systems. Related Controls: SC-12 , SC-13.

• (5) TRANSMISSION CONFIDENTIALITY AND INTEGRITY / PROTECTED DISTRIBUTION SYSTEM

Implement [ Assignment: organization-defined protected distribution system ] to [ Selection (one or more): prevent unauthorized disclosure of information; detect changes to information ] during transmission. Discussion: The purpose of a protected distribution system is to deter, detect, and/or make difficult physical access to the communication lines that carry national security information. Related Controls: None. References: [FIPS 140-3 ], [FIPS 197], [SP 800-52 ], [SP 800-77 ], [SP 800-81-2 ], [SP 800-113 ], [SP 800-177 ], [IR 8023].

• SC-9 TRANSMISSION CONFIDENTIALITY

[Withdrawn: Incorporated into SC-8 .]

• SC-10 NETWORK DISCONNECT

Control: Terminate the network connection associated with a communications session at the end of the session or after [ Assignment: organization-defined time period ] of inactivity. Discussion: Network disconnect applies to internal and external networks. Terminating network connections associated with specific communications sessions includes de-allocating TCP/IP address or port pairs at the operating system level and de-allocating the networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. Periods of inactivity may be established by organizations and include time periods by type of network access or for specific network accesses. Related Controls: AC-17 , SC-23. Control Enhancements: None.

References: None.

• SC-11 TRUSTED PATH

Control: a. Provide a [ Selection: physically; logically ] isolated trusted communications path for communications between the user and the trusted components of the system; and

800

5

b. Permit users to invoke the trusted communications path for communications between the user and the following security functions of the system, including at a minimum, authentication and re-authentication: [ Assignment: organization-defined security functions ]. Discussion: Trusted paths are mechanisms by which users can communicate (using input devices such as keyboards) directly with the security functions of systems with the requisite assurance to support security policies. Trusted path mechanisms can only be activated by users or the security functions of organizational systems. User responses that occur via trusted paths are protected from modification by and disclosure to untrusted applications. Organizations employ trusted paths for trustworthy, high-assurance connections between security functions of systems and users, including during system logons. The original implementations of trusted paths employed an out-of-band signal to initiate the path, such as using the key, which does not transmit characters that can be spoofed. In later implementations, a key combination that could not be hijacked was used (e.g., the + + keys). Such key combinations, however, are platform-specific and may not provide a trusted path implementation in every case. The enforcement of trusted communications paths is provided by a specific implementation that meets the reference monitor concept. Related Controls: AC-16 , AC-25 , SC-12 , SC-23. Control Enhancements:

• (1) TRUSTED PATH / IRREFUTABLE COMMUNICATIONS PATH

(a) Provide a trusted communications path that is irrefutably distinguishable from other communications paths; and (b) Initiate the trusted communications path for communications between the [ Assignment: organization-defined security functions ] of the system and the user. Discussion: An irrefutable communications path permits the system to initiate a trusted path, which necessitates that the user can unmistakably recognize the source of the communication as a trusted system component. For example, the trusted path may appear in an area of the display that other applications cannot access or be based on the presence of an identifier that cannot be spoofed. Related Controls: None. References: [OMB A-130 ].

• SC-12 CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT

Control: Establish and manage cryptographic keys when cryptography is employed within the

• system in accordance with the following key management requirements: [ Assignment:

organization-defined requirements for key generation, distribution, storage, access, and destruction ]. Discussion: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment. Related Controls: AC-17 , AU-9 , AU-10 , CM-3 , IA-3 , IA-7 , SA-4 , SA-8 , SA-9 , SC-8 , SC-11 , SC-12 , SC- 13 , SC-17 , SC-20 , SC-37 , SC-40 , SI-3 , SI-7.

800

5

Control Enhancements:

• (1) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT / AVAILABILITY

Maintain availability of information in the event of the loss of cryptographic keys by users. Discussion: Escrowing of encryption keys is a common practice for ensuring availability in the event of key loss. A forgotten passphrase is an example of losing a cryptographic key. Related Controls: None.

• (2) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT / SYMMETRIC KEYS

Produce, control, and distribute symmetric cryptographic keys using [ Selection: NIST FIPS- validated; NSA-approved ] key management technology and processes. Discussion: [SP 800-56A], [SP 800-56B], and [SP 800-56C] provide guidance on cryptographic key establishment schemes and key derivation methods. [SP 800-57-1 ], [SP 800-57-2 ], and [SP 800-57-3 ] provide guidance on cryptographic key management. Related Controls: None.

• (3) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT / ASYMMETRIC KEYS

Produce, control, and distribute asymmetric cryptographic keys using [ Selection: NSA- approved key management technology and processes; prepositioned keying material; DoD-approved or DoD-issued Medium Assurance PKI certificates; DoD-approved or DoD- issued Medium Hardware Assurance PKI certificates and hardware security tokens that protect the user’s private key; certificates issued in accordance with organization-defined

• requirements ].

Discussion: [SP 800-56A], [SP 800-56B], and [SP 800-56C] provide guidance on cryptographic key establishment schemes and key derivation methods. [SP 800-57-1 ], [SP 800-57-2 ], and [SP 800-57-3 ] provide guidance on cryptographic key management. Related Controls: None.

• (4) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT / PKI CERTIFICATES

[Withdrawn: Incorporated into SC-12 (3).]

• (5) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT / PKI CERTIFICATES / HARDWARE TOKENS

[Withdrawn: Incorporated into SC-12 (3).]

• (6) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT / PHYSICAL CONTROL OF KEYS

Maintain physical control of cryptographic keys when stored information is encrypted by external service providers. Discussion: For organizations that use external service providers (e.g., cloud service or data center providers), physical control of cryptographic keys provides additional assurance that information stored by such external providers is not subject to unauthorized disclosure or modification. Related Controls: None. References: [FIPS 140-3 ], [SP 800-56A], [SP 800-56B], [SP 800-56C], [SP 800-57-1 ], [SP 800-57-2 ], [SP 800-57-3 ], [SP 800-63-3 ], [IR 7956], [IR 7966].

• SC-13 CRYPTOGRAPHIC PROTECTION

Control: a. Determine the [ Assignment: organization-defined cryptographic uses ]; and

800

5

• b. Implement the following types of cryptography required for each specified cryptographic

use: [ Assignment: organization-defined types of cryptography for each specified cryptographic use ]. Discussion: Cryptography can be employed to support a variety of security solutions, including the protection of classified information and controlled unclassified information, the provision and implementation of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances but lack the necessary formal access approvals. Cryptography can also be used to support random number and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA- approved cryptography. For example, organizations that need to protect classified information may specify the use of NSA-approved cryptography. Organizations that need to provision and implement digital signatures may specify the use of FIPS-validated cryptography. Cryptography is implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Related Controls: AC-2 , AC-3 , AC-7 , AC-17 , AC-18 , AC-19 , AU-9 , AU-10 , CM-11 , CP-9 , IA-3 , IA-5 , IA-7 , MA-4 , MP-2 , MP-4 , MP-5 , SA-4 , SA-8 , SA-9 , SC-8 , SC-12 , SC-20 , SC-23 , SC-28 , SC-40 , SI-3 , SI- 7. Control Enhancements: None.

• (1) CRYPTOGRAPHIC PROTECTION / FIPS-VALIDATED CRYPTOGRAPHY

[Withdrawn: Incorporated into SC-13 .]

• (2) CRYPTOGRAPHIC PROTECTION / NSA-APPROVED CRYPTOGRAPHY

[Withdrawn: Incorporated into SC-13 .]

• (3) CRYPTOGRAPHIC PROTECTION / INDIVIDUALS WITHOUT FORMAL ACCESS APPROVALS

[Withdrawn: Incorporated into SC-13 .]

• (4) CRYPTOGRAPHIC PROTECTION / DIGITAL SIGNATURES

[Withdrawn: Incorporated into SC-13 .] References: [FIPS 140-3 ].

• SC-14 PUBLIC ACCESS PROTECTIONS

[Withdrawn: Incorporated into AC-2 , AC-3 , AC-5 , AC-6 , SI-3 , SI-4 , SI-5 , SI-7 , SI-10 .]

• SC-15 COLLABORATIVE COMPUTING DEVICES AND APPLICATIONS

Control: a. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: [ Assignment: organization-defined exceptions where remote activation is to be allowed ]; and b. Provide an explicit indication of use to users physically present at the devices. Discussion: Collaborative computing devices and applications include remote meeting devices and applications, networked white boards, cameras, and microphones. The explicit indication of use includes signals to users when collaborative computing devices and applications are activated. Related Controls: AC-21 , SC-42. Control Enhancements:

800

5

• (1) COLLABORATIVE COMPUTING DEVICES / PHYSICAL OR LOGICAL DISCONNECT

Provide [ Selection (one or more): physical; logical ] disconnect of collaborative computing devices in a manner that supports ease of use. Discussion: Failing to disconnect from collaborative computing devices can result in subsequent compromises of organizational information. Providing easy methods to disconnect from such devices after a collaborative computing session ensures that participants carry out the disconnect activity without having to go through complex and

• tedious procedures. Disconnect from collaborative computing devices can be manual or

automatic. Related Controls: None.

• (2) COLLABORATIVE COMPUTING DEVICES / BLOCKING INBOUND AND OUTBOUND COMMUNICATIONS

• TRAFFIC

[Withdrawn: Incorporated into SC-7 .]

• (3) COLLABORATIVE COMPUTING DEVICES / DISABLING AND REMOVAL IN SECURE WORK AREAS

Disable or remove collaborative computing devices and applications from [ Assignment: organization-defined systems or system components ] in [ Assignment: organization-defined secure work areas ]. Discussion: Failing to disable or remove collaborative computing devices and applications from systems or system components can result in compromises of information, including

• eavesdropping on conversations. A Sensitive Compartmented Information Facility (SCIF) is

an example of a secure work area. Related Controls: None.

• (4) COLLABORATIVE COMPUTING DEVICES / EXPLICITLY INDICATE CURRENT PARTICIPANTS

Provide an explicit indication of current participants in [ Assignment: organization-defined online meetings and teleconferences ]. Discussion: Explicitly indicating current participants prevents unauthorized individuals from participating in collaborative computing sessions without the explicit knowledge of other participants. Related Controls: None.

References: None.

• SC-16 TRANSMISSION OF SECURITY AND PRIVACY ATTRIBUTES

Control: Associate [ Assignment: organization-defined security and privacy attributes ] with information exchanged between systems and between system components.

Discussion: Security and privacy attributes can be explicitly or implicitly associated with the information contained in organizational systems or system components. Attributes are abstractions that represent the basic properties or characteristics of an entity with respect to protecting information or the management of personally identifiable information. Attributes are typically associated with internal data structures, including records, buffers, and files within the system. Security and privacy attributes are used to implement access control and information flow control policies; reflect special dissemination, management, or distribution instructions, including permitted uses of personally identifiable information; or support other aspects of the information security and privacy policies. Privacy attributes may be used independently or in conjunction with security attributes. Related Controls: AC-3 , AC-4 , AC-16. Control Enhancements:

800

5

• (1) TRANSMISSION OF SECURITY AND PRIVACY ATTRIBUTES / INTEGRITY VERIFICATION

Verify the integrity of transmitted security and privacy attributes. Discussion: Part of verifying the integrity of transmitted information is ensuring that security and privacy attributes that are associated with such information have not been modified in an unauthorized manner. Unauthorized modification of security or privacy attributes can result in a loss of integrity for transmitted information. Related Controls: AU-10 , SC-8.

• (2) TRANSMISSION OF SECURITY AND PRIVACY ATTRIBUTES / ANTI-SPOOFING MECHANISMS

Implement anti-spoofing mechanisms to prevent adversaries from falsifying the security attributes indicating the successful application of the security process. Discussion: Some attack vectors operate by altering the security attributes of an information system to intentionally and maliciously implement an insufficient level of security within the system. The alteration of attributes leads organizations to believe that a greater number of security functions are in place and operational than have actually been implemented. Related Controls: SI-3 , SI-4 , SI-7.

• (3) TRANSMISSION OF SECURITY AND PRIVACY ATTRIBUTES / CRYPTOGRAPHIC BINDING

Implement [ Assignment: organization-defined mechanisms or techniques ] to bind security and privacy attributes to transmitted information. Discussion: Cryptographic mechanisms and techniques can provide strong security and privacy attribute binding to transmitted information to help ensure the integrity of such information. Related Controls: AC-16 , SC-12 , SC-13. References: [OMB A-130 ].

• SC-17 PUBLIC KEY INFRASTRUCTURE CERTIFICATES

Control:

a. Issue public key certificates under an [ Assignment: organization-defined certificate policy ] or obtain public key certificates from an approved service provider; and

• b. Include only approved trust anchors in trust stores or certificate stores managed by the

organization. Discussion: Public key infrastructure certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates.

Related Controls: AU-10 , IA-5 , SC-12. Control Enhancements: None. References: [SP 800-32 ], [SP 800-57-1 ], [SP 800-57-2 ], [SP 800-57-3 ], [SP 800-63-3 ].

• SC-18 MOBILE CODE

Control: a. Define acceptable and unacceptable mobile code and mobile code technologies; and b. Authorize, monitor, and control the use of mobile code within the system.

800

5

Discussion: Mobile code includes any program, application, or content that can be transmitted across a network (e.g., embedded in an email, document, or website) and executed on a remote system. Decisions regarding the use of mobile code within organizational systems are based on the potential for the code to cause damage to the systems if used maliciously. Mobile code technologies include Java applets, JavaScript, HTML5, WebGL, and VBScript. Usage restrictions and implementation guidelines apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices, including notebook computers and smart phones. Mobile code policy and procedures address specific actions taken to prevent the development, acquisition, and introduction of unacceptable mobile code within organizational systems, including requiring mobile code to be digitally signed by a trusted source. Related Controls: AU-2 , AU-12 , CM-2 , CM-6 , SI-3. Control Enhancements:

• (1) MOBILE CODE / IDENTIFY UNACCEPTABLE CODE AND TAKE CORRECTIVE ACTIONS

Identify [ Assignment: organization-defined unacceptable mobile code ] and take [ Assignment: organization-defined corrective actions ]. Discussion: Corrective actions when unacceptable mobile code is detected include blocking, quarantine, or alerting administrators. Blocking includes preventing the transmission of word processing files with embedded macros when such macros have been determined to be unacceptable mobile code. Related Controls: None.

• (2) MOBILE CODE / ACQUISITION, DEVELOPMENT, AND USE

Verify that the acquisition, development, and use of mobile code to be deployed in the system meets [ Assignment: organization-defined mobile code requirements ]. Discussion: None. Related Controls: None.

• (3) MOBILE CODE / PREVENT DOWNLOADING AND EXECUTION

Prevent the download and execution of [ Assignment: organization-defined unacceptable mobile code ]. Discussion: None. Related Controls: None.

• (4) MOBILE CODE / PREVENT AUTOMATIC EXECUTION

Prevent the automatic execution of mobile code in [ Assignment: organization-defined software applications ] and enforce [ Assignment: organization-defined actions ] prior to executing the code. Discussion: Actions enforced before executing mobile code include prompting users prior to opening email attachments or clicking on web links. Preventing the automatic execution of mobile code includes disabling auto-execute features on system components that employ portable storage devices, such as compact discs, digital versatile discs, and universal serial bus devices. Related Controls: None.

• (5) MOBILE CODE / ALLOW EXECUTION ONLY IN CONFINED ENVIRONMENTS

Allow execution of permitted mobile code only in confined virtual machine environments.

800

5

Discussion: Permitting the execution of mobile code only in confined virtual machine environments helps prevent the introduction of malicious code into other systems and system components. Related Controls: SC-44 , SI-7. References: [SP 800-28 ].

• SC-19 VOICE OVER INTERNET PROTOCOL

[Withdrawn: Technology-specific; addressed as any other technology or protocol.]

• SC-20 SECURE NAME/ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE)

Control: a. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and b. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace. Discussion: Providing authoritative source information enables external clients, including remote Internet clients, to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Systems that provide name and address resolution services include domain name system (DNS) servers. Additional artifacts include DNS Security Extensions (DNSSEC) digital signatures and cryptographic keys. Authoritative data includes DNS resource records. The means for indicating the security status of child zones include the use of delegation signer resource records in the DNS. Systems that use technologies other than the DNS to map between host and service names and network addresses provide other means to assure the authenticity and integrity of response data. Related Controls: AU-10 , SC-8 , SC-12 , SC-13 , SC-21 , SC-22. Control Enhancements:

• (1) SECURE NAME/ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE) / CHILD SUBSPACES

[Withdrawn: Incorporated into SC-20 .]

• (2) SECURE NAME/ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE) / DATA ORIGIN AND

• INTEGRITY

Provide data origin and integrity protection artifacts for internal name/address resolution queries. Discussion: None. Related Controls: None. References: [FIPS 140-3 ], [FIPS 186-4 ], [SP 800-81-2 ].

• SC-21 SECURE NAME/ADDRESS RESOLUTION SERVICE (RECURSIVE OR CACHING RESOLVER)

Control: Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources. Discussion: Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Systems that provide name and

800

5

address resolution services for local clients include recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Systems that use technologies other than the DNS to map between host and service names and network addresses provide some other means to enable clients to verify the authenticity and integrity of response data. Related Controls: SC-20 , SC-22. Control Enhancements: None.

• (1) SECURE NAME/ADDRESS RESOLUTION SERVICE (RECURSIVE OR CACHING RESOLVER) / DATA ORIGIN

• AND INTEGRITY

[Withdrawn: Incorporated into SC-21 .] References: [SP 800-81-2 ].

• SC-22 ARCHITECTURE AND PROVISIONING FOR NAME/ADDRESS RESOLUTION SERVICE

Control: Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation. Discussion: Systems that provide name and address resolution services include domain name system (DNS) servers. To eliminate single points of failure in systems and enhance redundancy, organizations employ at least two authoritative domain name system servers—one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks, including the Internet). Organizations specify clients that can access authoritative DNS servers in certain roles (e.g., by address ranges and explicit lists).

Related Controls: SC-2 , SC-20 , SC-21 , SC-24. Control Enhancements: None. References: [SP 800-81-2 ].

• SC-23 SESSION AUTHENTICITY

Control: Protect the authenticity of communications sessions. Discussion: Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of communications sessions in the ongoing identities of other parties and the validity of transmitted information. Authenticity protection includes protecting against “man-in-the-middle” attacks, session hijacking, and the insertion of false information into sessions. Related Controls: AU-10 , SC-8 , SC-10 , SC-11. Control Enhancements:

• (1) SESSION AUTHENTICITY / INVALIDATE SESSION IDENTIFIERS AT LOGOUT

Invalidate session identifiers upon user logout or other session termination. Discussion: Invalidating session identifiers at logout curtails the ability of adversaries to capture and continue to employ previously valid session IDs.

800

5

Related Controls: None.

• (2) SESSION AUTHENTICITY / USER-INITIATED LOGOUTS AND MESSAGE DISPLAYS

• [Withdrawn: Incorporated into AC-12(1).]

• (3) SESSION AUTHENTICITY / UNIQUE SYSTEM-GENERATED SESSION IDENTIFIERS

Generate a unique session identifier for each session with [ Assignment: organization- defined randomness requirements ] and recognize only session identifiers that are system- generated. Discussion: Generating unique session identifiers curtails the ability of adversaries to reuse previously valid session IDs. Employing the concept of randomness in the generation of unique session identifiers protects against brute-force attacks to determine future session identifiers. Related Controls: AC-10 , SC-12 , SC-13.

• (4) SESSION AUTHENTICITY / UNIQUE SESSION IDENTIFIERS WITH RANDOMIZATION

[Withdrawn: Incorporated into SC-23(3).]

• (5) SESSION AUTHENTICITY / ALLOWED CERTIFICATE AUTHORITIES

Only allow the use of [ Assignment: organization-defined certificate authorities ] for verification of the establishment of protected sessions. Discussion: Reliance on certificate authorities for the establishment of secure sessions includes the use of Transport Layer Security (TLS) certificates. These certificates, after verification by their respective certificate authorities, facilitate the establishment of protected sessions between web clients and web servers. Related Controls: SC-12 , SC-13. References: [SP 800-52 ], [SP 800-77 ], [SP 800-95 ], [SP 800-113 ].

• SC-24 FAIL IN KNOWN STATE

Control: Fail to a [ Assignment: organization-defined known system state ] for the following failures on the indicated components while preserving [ Assignment: organization-defined system state information ] in failure: [ Assignment: list of organization-defined types of system failures on organization-defined system components ]. Discussion: Failure in a known state addresses security concerns in accordance with the mission and business needs of organizations. Failure in a known state prevents the loss of confidentiality, integrity, or availability of information in the event of failures of organizational systems or system components. Failure in a known safe state helps to prevent systems from failing to a state that may cause injury to individuals or destruction to property. Preserving system state information facilitates system restart and return to the operational mode with less disruption of mission and business processes. Related Controls: CP-2 , CP-4 , CP-10 , CP-12 , SA-8 , SC-7 , SC-22 , SI-13. Control Enhancements: None. References: None.

• SC-25 THIN NODES

Control: Employ minimal functionality and information storage on the following system components: [ Assignment: organization-defined system components ].

800

5

Discussion: The deployment of system components with minimal functionality reduces the need to secure every endpoint and may reduce the exposure of information, systems, and services to attacks. Reduced or minimal functionality includes diskless nodes and thin client technologies. Related Controls: SC-30 , SC-44. Control Enhancements: None.

References: None.

• SC-26 DECOYS

Control: Include components within organizational systems specifically designed to be the target of malicious attacks for detecting, deflecting, and analyzing such attacks.

Discussion: Decoys (i.e., honeypots, honeynets, or deception nets) are established to attract adversaries and deflect attacks away from the operational systems that support organizational mission and business functions. Use of decoys requires some supporting isolation measures to ensure that any deflected malicious code does not infect organizational systems. Depending on the specific usage of the decoy, consultation with the Office of the General Counsel before deployment may be needed. Related Controls: RA-5 , SC-7 , SC-30 , SC-35 , SC-44 , SI-3 , SI-4. Control Enhancements: None.

• (1) DECOYS / DETECTION OF MALICIOUS CODE

[Withdrawn: Incorporated into SC-35 .] References: None.

• SC-27 PLATFORM-INDEPENDENT APPLICATIONS

Control: Include within organizational systems the following platform independent applications: [ Assignment: organization-defined platform-independent applications ]. Discussion: Platforms are combinations of hardware, firmware, and software components used to execute software applications. Platforms include operating systems, the underlying computer architectures, or both. Platform-independent applications are applications with the capability to execute on multiple platforms. Such applications promote portability and reconstitution on different platforms. Application portability and the ability to reconstitute on different platforms increase the availability of mission-essential functions within organizations in situations where systems with specific operating systems are under attack. Related Controls: SC-29.

Control Enhancements: None. References: None.

• SC-28 PROTECTION OF INFORMATION AT REST

Control: Protect the [ Selection (one or more): confidentiality; integrity ] of the following information at rest: [ Assignment: organization-defined information at rest ]. Discussion: Information at rest refers to the state of information when it is not in process or in transit and is located on system components. Such components include internal or external hard disk drives, storage area network devices, or databases. However, the focus of protecting information at rest is not on the type of storage device or frequency of access but rather on the state of the information. Information at rest addresses the confidentiality and integrity of

800

5

information and covers user information and system information. System-related information that requires protection includes configurations or rule sets for firewalls, intrusion detection and prevention systems, filtering routers, and authentication information. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing write-once-read-many (WORM) technologies. When adequate protection of information at rest cannot otherwise be achieved, organizations may employ other controls, including frequent scanning to identify malicious code at rest and secure offline storage in lieu of online storage. Related Controls: AC-3 , AC-4 , AC-6 , AC-19 , CA-7 , CM-3 , CM-5 , CM-6 , CP-9 , MP-4 , MP-5 , PE-3 , SC- 8 , SC-12 , SC-13 , SC-34 , SI-3 , SI-7 , SI-16. Control Enhancements:

• (1) PROTECTION OF INFORMATION AT REST / CRYPTOGRAPHIC PROTECTION

Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on [ Assignment: organization-defined system components or media ]: [ Assignment: organization-defined information ]. Discussion: The selection of cryptographic mechanisms is based on the need to protect the confidentiality and integrity of organizational information. The strength of mechanism is commensurate with the security category or classification of the information. Organizations have the flexibility to encrypt information on system components or media or encrypt data structures, including files, records, or fields.

• Related Controls: AC-19 , SC-12 , SC-13.

• (2) PROTECTION OF INFORMATION AT REST / OFFLINE STORAGE

Remove the following information from online storage and store offline in a secure location: [ Assignment: organization-defined information ]. Discussion: Removing organizational information from online storage to offline storage eliminates the possibility of individuals gaining unauthorized access to the information through a network. Therefore, organizations may choose to move information to offline storage in lieu of protecting such information in online storage. Related Controls: None.

• (3) PROTECTION OF INFORMATION AT REST / CRYPTOGRAPHIC KEYS

Provide protected storage for cryptographic keys [ Selection: [ Assignment: organization- defined safeguards ]; hardware-protected key store ]. Discussion: A Trusted Platform Module (TPM) is an example of a hardware-protected data store that can be used to protect cryptographic keys. Related Controls: SC-12 , SC-13.

References: [OMB A-130 ], [SP 800-56A], [SP 800-56B], [SP 800-56C], [SP 800-57-1 ], [SP 800-57- 2 ], [SP 800-57-3 ], [SP 800-111 ], [SP 800-124 ].

• SC-29 HETEROGENEITY

Control: Employ a diverse set of information technologies for the following system components in the implementation of the system: [ Assignment: organization-defined system components ]. Discussion: Increasing the diversity of information technologies within organizational systems reduces the impact of potential exploitations or compromises of specific technologies. Such diversity protects against common mode failures, including those failures induced by supply chain attacks. Diversity in information technologies also reduces the likelihood that the means

800

5

adversaries use to compromise one system component will be effective against other system components, thus further increasing the adversary work factor to successfully complete planned attacks. An increase in diversity may add complexity and management overhead that could ultimately lead to mistakes and unauthorized configurations. Related Controls: AU-9 , PL-8 , SC-27 , SC-30 , SR-3.

Control Enhancements:

• (1) HETEROGENEITY / VIRTUALIZATION TECHNIQUES

Employ virtualization techniques to support the deployment of a diversity of operating systems and applications that are changed [ Assignment: organization-defined frequency ]. Discussion: While frequent changes to operating systems and applications can pose significant configuration management challenges, the changes can result in an increased work factor for adversaries to conduct successful attacks. Changing virtual operating systems or applications, as opposed to changing actual operating systems or applications, provides virtual changes that impede attacker success while reducing configuration management efforts. Virtualization techniques can assist in isolating untrustworthy software or software of dubious provenance into confined execution environments. Related Controls: None. References: None.

• SC-30 CONCEALMENT AND MISDIRECTION

Control: Employ the following concealment and misdirection techniques for [ Assignment: organization-defined systems ] at [ Assignment: organization-defined time periods ] to confuse and mislead adversaries: [ Assignment: organization-defined concealment and misdirection techniques ]. Discussion: Concealment and misdirection techniques can significantly reduce the targeting capabilities of adversaries (i.e., window of opportunity and available attack surface) to initiate and complete attacks. For example, virtualization techniques provide organizations with the ability to disguise systems, potentially reducing the likelihood of successful attacks without the cost of having multiple platforms. The increased use of concealment and misdirection techniques and methods—including randomness, uncertainty, and virtualization—may sufficiently confuse and mislead adversaries and subsequently increase the risk of discovery and/or exposing tradecraft. Concealment and misdirection techniques may provide additional time to perform core mission and business functions. The implementation of concealment and misdirection techniques may add to the complexity and management overhead required for the system. Related Controls: AC-6 , SC-25 , SC-26 , SC-29 , SC-44 , SI-14. Control Enhancements:

• (1) CONCEALMENT AND MISDIRECTION / VIRTUALIZATION TECHNIQUES

[Withdrawn: Incorporated into SC-29(1).]

• (2) CONCEALMENT AND MISDIRECTION / RANDOMNESS

Employ [ Assignment: organization-defined techniques ] to introduce randomness into organizational operations and assets. Discussion: Randomness introduces increased levels of uncertainty for adversaries regarding the actions that organizations take to defend their systems against attacks. Such actions may impede the ability of adversaries to correctly target information resources of organizations that support critical missions or business functions. Uncertainty may also cause adversaries to hesitate before initiating or continuing attacks. Misdirection techniques that involve

800

5

randomness include performing certain routine actions at different times of day, employing different information technologies, using different suppliers, and rotating roles and responsibilities of organizational personnel. Related Controls: None.

• (3) CONCEALMENT AND MISDIRECTION / CHANGE PROCESSING AND STORAGE LOCATIONS

Change the location of [ Assignment: organization-defined processing and/or storage ] [ Selection: [ Assignment: organization-defined time frequency ] ; at random time intervals ]]. Discussion: Adversaries target critical mission and business functions and the systems that support those mission and business functions while also trying to minimize the exposure of their existence and tradecraft. The static, homogeneous, and deterministic nature of organizational systems targeted by adversaries make such systems more susceptible to attacks with less adversary cost and effort to be successful. Changing processing and storage locations (also referred to as moving target defense) addresses the advanced persistent threat using techniques such as virtualization, distributed processing, and replication. This enables organizations to relocate the system components (i.e., processing, storage) that support critical mission and business functions. Changing the locations of processing activities and/or storage sites introduces a degree of uncertainty into the targeting activities of adversaries. The targeting uncertainty increases the work factor of adversaries and makes compromises or breaches of the organizational systems more difficult and time-consuming. It also increases the chances that adversaries may inadvertently disclose certain aspects of their tradecraft while attempting to locate critical organizational resources. Related Controls: None.

• (4) CONCEALMENT AND MISDIRECTION / MISLEADING INFORMATION

Employ realistic, but misleading information in [ Assignment: organization-defined system components ] about its security state or posture. Discussion: Employing misleading information is intended to confuse potential adversaries regarding the nature and extent of controls deployed by organizations. Thus, adversaries may employ incorrect and ineffective attack techniques. One technique for misleading adversaries is for organizations to place misleading information regarding the specific controls deployed in external systems that are known to be targeted by adversaries. Another technique is the use of deception nets that mimic actual aspects of organizational systems but use, for example, out-of-date software configurations. Related Controls: SC-26.

• (5) CONCEALMENT AND MISDIRECTION / CONCEALMENT OF SYSTEM COMPONENTS

Employ the following techniques to hide or conceal [ Assignment: organization-defined system components ]: [ Assignment: organization-defined techniques ]. Discussion: By hiding, disguising, or concealing critical system components, organizations may be able to decrease the probability that adversaries target and successfully compromise those assets. Potential means to hide, disguise, or conceal system components include the configuration of routers or the use of encryption or virtualization techniques. Related Controls: None.

References: None.

• SC-31 COVERT CHANNEL ANALYSIS

Control:

800

5

a. Perform a covert channel analysis to identify those aspects of communications within the system that are potential avenues for covert [ Selection (one or more): storage; timing ] channels; and b. Estimate the maximum bandwidth of those channels. Discussion: Developers are in the best position to identify potential areas within systems that might lead to covert channels. Covert channel analysis is a meaningful activity when there is the potential for unauthorized information flows across security domains, such as in the case of systems that contain export-controlled information and have connections to external networks (i.e., networks that are not controlled by organizations). Covert channel analysis is also useful for multilevel secure systems, multiple security level systems, and cross-domain systems.

Related Controls: AC-3 , AC-4 , SA-8 , SI-11. Control Enhancements:

• (1) COVERT CHANNEL ANALYSIS / TEST COVERT CHANNELS FOR EXPLOITABILITY

Test a subset of the identified covert channels to determine the channels that are exploitable. Discussion: None. Related Controls: None.

• (2) COVERT CHANNEL ANALYSIS / MAXIMUM BANDWIDTH

Reduce the maximum bandwidth for identified covert [ Selection (one or more); storage; timing ] channels to [ Assignment: organization-defined values ]. Discussion: The complete elimination of covert channels, especially covert timing channels, is usually not possible without significant performance impacts. Related Controls: None.

• (3) COVERT CHANNEL ANALYSIS / MEASURE BANDWIDTH IN OPERATIONAL ENVIRONMENTS

Measure the bandwidth of [ Assignment: organization-defined subset of identified covert channels ] in the operational environment of the system. Discussion: Measuring covert channel bandwidth in specified operational environments helps organizations determine how much information can be covertly leaked before such leakage adversely affects mission or business functions. Covert channel bandwidth may be significantly different when measured in settings that are independent of the specific environments of operation, including laboratories or system development environments. Related Controls: None. References: None.

• SC-32 SYSTEM PARTITIONING

Control: Partition the system into [ Assignment: organization-defined system components ] residing in separate [ Selection: physical; logical ] domains or environments based on [ Assignment: organization-defined circumstances for physical or logical separation of components ]. Discussion: System partitioning is part of a defense-in-depth protection strategy. Organizations determine the degree of physical separation of system components. Physical separation options include physically distinct components in separate racks in the same room, critical components in separate rooms, and geographical separation of critical components. Security categorization can guide the selection of candidates for domain partitioning. Managed interfaces restrict or prohibit network access and information flow among partitioned system components. Related Controls: AC-4 , AC-6 , SA-8 , SC-2 , SC-3 , SC-7 , SC-36.

800

5

Control Enhancements:

• (1) SYSTEM PARTITIONING / SEPARATE PHYSICAL DOMAINS FOR PRIVILEGED FUNCTIONS

Partition privileged functions into separate physical domains. Discussion: Privileged functions that operate in a single physical domain may represent a single point of failure if that domain becomes compromised or experiences a denial of service. Related Controls: None. References: [FIPS 199], [IR 8179].

• SC-33 TRANSMISSION PREPARATION INTEGRITY

[Withdrawn: Incorporated into SC-8 .]

• SC-34 NON-MODIFIABLE EXECUTABLE PROGRAMS

Control: For [ Assignment: organization-defined system components ], load and execute:

a. The operating environment from hardware-enforced, read-only media; and b. The following applications from hardware-enforced, read-only media: [ Assignment: organization-defined applications ]. Discussion: The operating environment for a system contains the code that hosts applications, including operating systems, executives, or virtual machine monitors (i.e., hypervisors). It can also include certain applications that run directly on hardware platforms. Hardware-enforced, read-only media include Compact Disc-Recordable (CD-R) and Digital Versatile Disc-Recordable (DVD-R) disk drives as well as one-time, programmable, read-only memory. The use of non- modifiable storage ensures the integrity of software from the point of creation of the read-only image. The use of reprogrammable, read-only memory can be accepted as read-only media provided that integrity can be adequately protected from the point of initial writing to the insertion of the memory into the system, and there are reliable hardware protections against reprogramming the memory while installed in organizational systems. Related Controls: AC-3 , SI-7 , SI-14.

Control Enhancements:

• (1) NON-MODIFIABLE EXECUTABLE PROGRAMS / NO WRITABLE STORAGE

Employ [ Assignment: organization-defined system components ] with no writeable storage that is persistent across component restart or power on/off. Discussion: Disallowing writeable storage eliminates the possibility of malicious code insertion via persistent, writeable storage within the designated system components. The restriction applies to fixed and removable storage, with the latter being addressed either directly or as specific restrictions imposed through access controls for mobile devices. Related Controls: AC-19 , MP-7.

• (2) NON-MODIFIABLE EXECUTABLE PROGRAMS / INTEGRITY PROTECTION ON READ-ONLY MEDIA

Protect the integrity of information prior to storage on read-only media and control the media after such information has been recorded onto the media. Discussion: Controls prevent the substitution of media into systems or the reprogramming of programmable read-only media prior to installation into the systems. Integrity protection controls include a combination of prevention, detection, and response. Related Controls: CM-3 , CM-5 , CM-9 , MP-2 , MP-4 , MP-5 , SC-28 , SI-3.

800

5

• (3) NON-MODIFIABLE EXECUTABLE PROGRAMS / HARDWARE-BASED PROTECTION

[Withdrawn: Moved to SC-51 .]

• SC-35 EXTERNAL MALICIOUS CODE IDENTIFICATION

Control: Include system components that proactively seek to identify network-based malicious code or malicious websites. Discussion: External malicious code identification differs from decoys in SC-26 in that the components actively probe networks, including the Internet, in search of malicious code contained on external websites. Like decoys, the use of external malicious code identification techniques requires some supporting isolation measures to ensure that any malicious code discovered during the search and subsequently executed does not infect organizational systems. Virtualization is a common technique for achieving such isolation. Related Controls: SC-7 , SC-26 , SC-44 , SI-3 , SI-4. Control Enhancements: None.

References: None.

• SC-36 DISTRIBUTED PROCESSING AND STORAGE

Control: Distribute the following processing and storage components across multiple [ Selection: physical locations; logical domains ]: [ Assignment: organization-defined processing and storage components ]. Discussion: Distributing processing and storage across multiple physical locations or logical domains provides a degree of redundancy or overlap for organizations. The redundancy and overlap increase the work factor of adversaries to adversely impact organizational operations, assets, and individuals. The use of distributed processing and storage does not assume a single primary processing or storage location. Therefore, it allows for parallel processing and storage. Related Controls: CP-6 , CP-7 , PL-8 , SC-32. Control Enhancements:

• (1) DISTRIBUTED PROCESSING AND STORAGE / POLLING TECHNIQUES

(a) Employ polling techniques to identify potential faults, errors, or compromises to the following processing and storage components: [ Assignment: organization-defined distributed processing and storage components ]; and (b) Take the following actions in response to identified faults, errors, or compromises: [ Assignment: organization-defined actions ]. Discussion: Distributed processing and/or storage may be used to reduce opportunities for adversaries to compromise the confidentiality, integrity, or availability of organizational information and systems. However, the distribution of processing and storage components does not prevent adversaries from compromising one or more of the components. Polling compares the processing results and/or storage content from the distributed components and subsequently votes on the outcomes. Polling identifies potential faults, compromises, or errors in the distributed processing and storage components. Related Controls: SI-4.

• (2) DISTRIBUTED PROCESSING AND STORAGE / SYNCHRONIZATION

Synchronize the following duplicate systems or system components: [ Assignment: organization-defined duplicate systems or system components ].

800

5

Discussion: SC-36 and CP-9(6) require the duplication of systems or system components in distributed locations. The synchronization of duplicated and redundant services and data helps to ensure that information contained in the distributed locations can be used in the mission or business functions of organizations, as needed. Related Controls: CP-9.

References: [SP 800-160-2 ].

• SC-37 OUT-OF-BAND CHANNELS

Control: Employ the following out-of-band channels for the physical delivery or electronic transmission of [ Assignment: organization-defined information, system components, or devices ] to [ Assignment: organization-defined individuals or systems ]: [ Assignment: organization-defined out-of-band channels ]. Discussion: Out-of-band channels include local, non-network accesses to systems; network paths physically separate from network paths used for operational traffic; or non-electronic paths, such as the U.S. Postal Service. The use of out-of-band channels is contrasted with the use of in-band channels (i.e., the same channels) that carry routine operational traffic. Out-of-band channels do not have the same vulnerability or exposure as in-band channels. Therefore, the confidentiality, integrity, or availability compromises of in-band channels will not compromise or adversely affect the out-of-band channels. Organizations may employ out-of-band channels in the delivery or transmission of organizational items, including authenticators and credentials; cryptographic key management information; system and data backups; configuration management changes for hardware, firmware, or software; security updates; maintenance information; and malicious code protection updates. Related Controls: AC-2 , CM-3 , CM-5 , CM-7 , IA-2 , IA-4 , IA-5 , MA-4 , SC-12 , SI-3 , SI-4 , SI-7.

Control Enhancements: (1) OUT-OF-BAND CHANNELS / ENSURE DELIVERY AND TRANSMISSION Employ [ Assignment: organization-defined controls ] to ensure that only [ Assignment: organization-defined individuals or systems ] receive the following information, system components, or devices: [ Assignment: organization-defined information, system components, or devices ]. Discussion: Techniques employed by organizations to ensure that only designated systems or individuals receive certain information, system components, or devices include sending authenticators via an approved courier service but requiring recipients to show some form of government-issued photographic identification as a condition of receipt. Related Controls: None. References: [SP 800-57-1 ], [SP 800-57-2 ], [SP 800-57-3 ].

• SC-38 OPERATIONS SECURITY

• Control: Employ the following operations security controls to protect key organizational

information throughout the system development life cycle: [ Assignment: organization-defined operations security controls ]. Discussion: Operations security (OPSEC) is a systematic process by which potential adversaries can be denied information about the capabilities and intentions of organizations by identifying, controlling, and protecting generally unclassified information that specifically relates to the planning and execution of sensitive organizational activities. The OPSEC process involves five steps: identification of critical information, analysis of threats, analysis of vulnerabilities, assessment of risks, and the application of appropriate countermeasures. OPSEC controls are

800

5

applied to organizational systems and the environments in which those systems operate. OPSEC controls protect the confidentiality of information, including limiting the sharing of information with suppliers, potential suppliers, and other non-organizational elements and individuals. Information critical to organizational mission and business functions includes user identities, element uses, suppliers, supply chain processes, functional requirements, security requirements, system design specifications, testing and evaluation protocols, and security control implementation details. Related Controls: CA-2 , CA-7 , PL-1 , PM-9 , PM-12 , RA-2 , RA-3 , RA-5 , SC-7 , SR-3 , SR-7. Control Enhancements: None. References: None.

• SC-39 PROCESS ISOLATION

Control: Maintain a separate execution domain for each executing system process. Discussion: Systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. Process isolation technologies, including sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. Process isolation helps limit the access of potentially untrusted software to other system resources. The capability to maintain separate execution domains is available in commercial operating systems that employ multi-state processor technologies. Related Controls: AC-3 , AC-4 , AC-6 , AC-25 , SA-8 , SC-2 , SC-3 , SI-16.

Control Enhancements:

• (1) PROCESS ISOLATION / HARDWARE SEPARATION

Implement hardware separation mechanisms to facilitate process isolation. Discussion: Hardware-based separation of system processes is generally less susceptible to compromise than software-based separation, thus providing greater assurance that the separation will be enforced. Hardware separation mechanisms include hardware memory management. Related Controls: None.

• (2) PROCESS ISOLATION / SEPARATE EXECUTION DOMAIN PER THREAD

Maintain a separate execution domain for each thread in [ Assignment: organization- defined multi-threaded processing ]. Discussion: None. Related Controls: None.

References: [SP 800-160-1 ].

• SC-40 WIRELESS LINK PROTECTION

Control: Protect external and internal [ Assignment: organization-defined wireless links ] from the following signal parameter attacks: [ Assignment: organization-defined types of signal parameter attacks or references to sources for such attacks ]. Discussion: Wireless link protection applies to internal and external wireless communication links that may be visible to individuals who are not authorized system users. Adversaries can

800

5

exploit the signal parameters of wireless links if such links are not adequately protected. There are many ways to exploit the signal parameters of wireless links to gain intelligence, deny service, or spoof system users. Protection of wireless links reduces the impact of attacks that are unique to wireless systems. If organizations rely on commercial service providers for transmission services as commodity items rather than as fully dedicated services, it may not be possible to implement wireless link protections to the extent necessary to meet organizational security requirements. Related Controls: AC-18 , SC-5. Control Enhancements:

• (1) WIRELESS LINK PROTECTION / ELECTROMAGNETIC INTERFERENCE

Implement cryptographic mechanisms that achieve [ Assignment: organization-defined level of protection ] against the effects of intentional electromagnetic interference. Discussion: The implementation of cryptographic mechanisms for electromagnetic interference protects systems against intentional jamming that might deny or impair communications by ensuring that wireless spread spectrum waveforms used to provide anti- jam protection are not predictable by unauthorized individuals. The implementation of cryptographic mechanisms may also coincidentally mitigate the effects of unintentional jamming due to interference from legitimate transmitters that share the same spectrum. Mission requirements, projected threats, concept of operations, and laws, executive orders, directives, regulations, policies, and standards determine levels of wireless link availability, cryptography needed, and performance. Related Controls: PE-21 , SC-12 , SC-13.

• (2) WIRELESS LINK PROTECTION / REDUCE DETECTION POTENTIAL

Implement cryptographic mechanisms to reduce the detection potential of wireless links to [ Assignment: organization-defined level of reduction ]. Discussion: The implementation of cryptographic mechanisms to reduce detection potential is used for covert communications and to protect wireless transmitters from geo-location. It also ensures that the spread spectrum waveforms used to achieve a low probability of detection are not predictable by unauthorized individuals. Mission requirements, projected threats, concept of operations, and applicable laws, executive orders, directives, regulations, policies, and standards determine the levels to which wireless links are undetectable. Related Controls: SC-12 , SC-13.

• (3) WIRELESS LINK PROTECTION / IMITATIVE OR MANIPULATIVE COMMUNICATIONS DECEPTION

Implement cryptographic mechanisms to identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. Discussion: The implementation of cryptographic mechanisms to identify and reject imitative or manipulative communications ensures that the signal parameters of wireless transmissions are not predictable by unauthorized individuals. Such unpredictability reduces the probability of imitative or manipulative communications deception based on signal parameters alone. Related Controls: SC-12 , SC-13 , SI-4.

• (4) WIRELESS LINK PROTECTION / SIGNAL PARAMETER IDENTIFICATION

Implement cryptographic mechanisms to prevent the identification of [ Assignment: organization-defined wireless transmitters ] by using the transmitter signal parameters. Discussion: The implementation of cryptographic mechanisms to prevent the identification of wireless transmitters protects against the unique identification of wireless transmitters

800

5

for the purposes of intelligence exploitation by ensuring that anti-fingerprinting alterations to signal parameters are not predictable by unauthorized individuals. It also provides anonymity when required. Radio fingerprinting techniques identify the unique signal parameters of transmitters to fingerprint such transmitters for purposes of tracking and mission or user identification. Related Controls: SC-12 , SC-13. References: None.

• SC-41 PORT AND I/O DEVICE ACCESS

Control: [ Selection: Physically; Logically ] disable or remove [ Assignment: organization-defined

• connection ports or input/output devices ] on the following systems or system components:

[ Assignment: organization-defined systems or system components ]. Discussion: Connection ports include Universal Serial Bus (USB), Thunderbolt, and Firewire (IEEE 1394). Input/output (I/O) devices include compact disc and digital versatile disc drives. Disabling or removing such connection ports and I/O devices helps prevent the exfiltration of information from systems and the introduction of malicious code from those ports or devices. Physically disabling or removing ports and/or devices is the stronger action. Related Controls: AC-20 , MP-7. Control Enhancements: None. References: None.

• SC-42 SENSOR CAPABILITY AND DATA

Control: a. Prohibit [ Selection (one or more): the use of devices possessing [ Assignment: organization- defined environmental sensing capabilities ] in [ Assignment: organization-defined facilities, areas, or systems ]; the remote activation of environmental sensing capabilities on organizational systems or system components with the following exceptions: [ Assignment: organization-defined exceptions where remote activation of sensors is allowed ]]; and b. Provide an explicit indication of sensor use to [ Assignment: organization-defined class of users ]. Discussion: Sensor capability and data applies to types of systems or system components characterized as mobile devices, such as cellular telephones, smart phones, and tablets. Mobile devices often include sensors that can collect and record data regarding the environment where the system is in use. Sensors that are embedded within mobile devices include microphones, cameras, Global Positioning System (GPS) mechanisms, and accelerometers. While the sensors on mobiles devices provide an important function, if activated covertly, such devices can potentially provide a means for adversaries to learn valuable information about individuals and organizations. For example, remotely activating the GPS function on a mobile device could provide an adversary with the ability to track the movements of an individual. Organizations may prohibit individuals from bringing cellular telephones or digital cameras into certain designated facilities or controlled areas within facilities where classified information is stored or sensitive conversations are taking place. Related Controls: SC-15. Control Enhancements:

• (1) SENSOR CAPABILITY AND DATA / REPORTING TO AUTHORIZED INDIVIDUALS OR ROLES

800

5

Verify that the system is configured so that data or information collected by the [ Assignment: organization-defined sensors ] is only reported to authorized individuals or roles. Discussion: In situations where sensors are activated by authorized individuals, it is still possible that the data or information collected by the sensors will be sent to unauthorized entities. Related Controls: None.

• (2) SENSOR CAPABILITY AND DATA / AUTHORIZED USE

Employ the following measures so that data or information collected by [ Assignment: organization-defined sensors ] is only used for authorized purposes: [ Assignment: organization-defined measures ]. Discussion: Information collected by sensors for a specific authorized purpose could be misused for some unauthorized purpose. For example, GPS sensors that are used to support traffic navigation could be misused to track the movements of individuals. Measures to mitigate such activities include additional training to help ensure that authorized individuals do not abuse their authority and, in the case where sensor data is maintained by external parties, contractual restrictions on the use of such data. Related Controls: PT-2.

• (3) SENSOR CAPABILITY AND DATA / PROHIBIT USE OF DEVICES

[Withdrawn: Incorporated into SC-42 .]

• (4) SENSOR CAPABILITY AND DATA / NOTICE OF COLLECTION

Employ the following measures to facilitate an individual’s awareness that personally identifiable information is being collected by [ Assignment: organization-defined sensors ]: [ Assignment: organization-defined measures ]. Discussion: Awareness that organizational sensors are collecting data enables individuals to more effectively engage in managing their privacy. Measures can include conventional written notices and sensor configurations that make individuals directly or indirectly aware through other devices that the sensor is collecting information. The usability and efficacy of the notice are important considerations. Related Controls: PT-1 , PT-4 , PT-5.

• (5) SENSOR CAPABILITY AND DATA / COLLECTION MINIMIZATION

Employ [ Assignment: organization-defined sensors ] that are configured to minimize the collection of information about individuals that is not needed. Discussion: Although policies to control for authorized use can be applied to information once it is collected, minimizing the collection of information that is not needed mitigates privacy risk at the system entry point and mitigates the risk of policy control failures. Sensor configurations include the obscuring of human features, such as blurring or pixelating flesh tones. Related Controls: SA-8 , SI-12. References: [OMB A-130 ], [SP 800-124 ].

• SC-43 USAGE RESTRICTIONS

Control:

• a. Establish usage restrictions and implementation guidelines for the following system

components: [ Assignment: organization-defined system components ]; and

800

5

b. Authorize, monitor, and control the use of such components within the system. Discussion: Usage restrictions apply to all system components including but not limited to mobile code, mobile devices, wireless access, and wired and wireless peripheral components (e.g., copiers, printers, scanners, optical devices, and other similar technologies). The usage restrictions and implementation guidelines are based on the potential for system components to cause damage to the system and help to ensure that only authorized system use occurs. Related Controls: AC-18 , AC-19 , CM-6 , SC-7 , SC-18. Control Enhancements: None. References: [OMB A-130 ], [SP 800-124 ].

• SC-44 DETONATION CHAMBERS

• Control: Employ a detonation chamber capability within [ Assignment: organization-defined

system, system component, or location ]. Discussion: Detonation chambers, also known as dynamic execution environments, allow organizations to open email attachments, execute untrusted or suspicious applications, and execute Universal Resource Locator requests in the safety of an isolated environment or a virtualized sandbox. Protected and isolated execution environments provide a means of determining whether the associated attachments or applications contain malicious code. While related to the concept of deception nets, the employment of detonation chambers is not intended to maintain a long-term environment in which adversaries can operate and their actions can be observed. Rather, detonation chambers are intended to quickly identify malicious code and either reduce the likelihood that the code is propagated to user environments of operation or prevent such propagation completely. Related Controls: SC-7 , SC-18 , SC-25 , SC-26 , SC-30 , SC-35 , SC-39 , SI-3 , SI-7.

Control Enhancements: None. References: [SP 800-177 ].

• SC-45 SYSTEM TIME SYNCHRONIZATION

Control: Synchronize system clocks within and between systems and system components.

Discussion: Time synchronization of system clocks is essential for the correct execution of many system services, including identification and authentication processes that involve certificates and time-of-day restrictions as part of access control. Denial of service or failure to deny expired credentials may result without properly synchronized clocks within and between systems and system components. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, such as clocks synchronizing within hundreds of milliseconds or tens of milliseconds. Organizations may define different time granularities for system components. Time service can be critical to other security capabilities—such as access control and identification and authentication—depending on the nature of the mechanisms used to support the capabilities. Related Controls: AC-3 , AU-8 , IA-2 , IA-8. Control Enhancements:

• (1) SYSTEM TIME SYNCHRONIZATION / SYNCHRONIZATION WITH AUTHORITATIVE TIME SOURCE

(a) Compare the internal system clocks [ Assignment: organization-defined frequency ] with [ Assignment: organization-defined authoritative time source ]; and

800

5

(b) Synchronize the internal system clocks to the authoritative time source when the time difference is greater than [ Assignment: organization-defined time period ]. Discussion: Synchronization of internal system clocks with an authoritative source provides uniformity of time stamps for systems with multiple system clocks and systems connected over a network. Related Controls: None.

• (2) SYSTEM TIME SYNCHRONIZATION / SECONDARY AUTHORITATIVE TIME SOURCE

(a) Identify a secondary authoritative time source that is in a different geographic region than the primary authoritative time source; and (b) Synchronize the internal system clocks to the secondary authoritative time source if the primary authoritative time source is unavailable. Discussion: It may be necessary to employ geolocation information to determine that the secondary authoritative time source is in a different geographic region. Related Controls: None.

References: [IETF 5905].

• SC-46 CROSS DOMAIN POLICY ENFORCEMENT

Control: Implement a policy enforcement mechanism [ Selection: physically; logically ] between the physical and/or network interfaces for the connecting security domains.

Discussion: For logical policy enforcement mechanisms, organizations avoid creating a logical path between interfaces to prevent the ability to bypass the policy enforcement mechanism. For physical policy enforcement mechanisms, the robustness of physical isolation afforded by the physical implementation of policy enforcement to preclude the presence of logical covert channels penetrating the security domain may be needed. Contact [email protected]^ for more information. Related Controls: AC-4 , SC-7. Control Enhancements: None. References: [SP 800-160-1 ].

• SC-47 ALTERNATE COMMUNICATIONS PATHS

Control: Establish [ Assignment: organization-defined alternate communications paths ] for system operations organizational command and control. Discussion: An incident, whether adversarial-or nonadversarial-based, can disrupt established communications paths used for system operations and organizational command and control. Alternate communications paths reduce the risk of all communications paths being affected by the same incident. To compound the problem, the inability of organizational officials to obtain timely information about disruptions or to provide timely direction to operational elements after a communications path incident, can impact the ability of the organization to respond to such incidents in a timely manner. Establishing alternate communications paths for command and control purposes, including designating alternative decision makers if primary decision makers are unavailable and establishing the extent and limitations of their actions, can greatly facilitate the organization’s ability to continue to operate and take appropriate actions during an incident. Related Controls: CP-2 , CP-8.

Control Enhancements: None. References: [SP 800-34 ], [SP 800-61 ], [SP 800-160-2 ].

800

5

• SC-48 SENSOR RELOCATION

Control: Relocate [ Assignment: organization-defined sensors and monitoring capabilities ] to [ Assignment: organization-defined locations ] under the following conditions or circumstances: [ Assignment: organization-defined conditions or circumstances ].

Discussion: Adversaries may take various paths and use different approaches as they move laterally through an organization (including its systems) to reach their target or as they attempt to exfiltrate information from the organization. The organization often only has a limited set of monitoring and detection capabilities, and they may be focused on the critical or likely infiltration or exfiltration paths. By using communications paths that the organization typically does not monitor, the adversary can increase its chances of achieving its desired goals. By relocating its sensors or monitoring capabilities to new locations, the organization can impede the adversary’s ability to achieve its goals. The relocation of the sensors or monitoring capabilities might be done based on threat information that the organization has acquired or randomly to confuse the adversary and make its lateral transition through the system or organization more challenging.

Related Controls: AU-2 , SC-7 , SI-4. Control Enhancements:

• (1) SENSOR RELOCATION / DYNAMIC RELOCATION OF SENSORS OR MONITORING CAPABILITIES

Dynamically relocate [ Assignment: organization-defined sensors and monitoring capabilities ] to [ Assignment: organization-defined locations ] under the following conditions or circumstances: [ Assignment: organization-defined conditions or circumstances ]. Discussion: None. Related Controls: None. References: [SP 800-160-2 ].

• SC-49 HARDWARE-ENFORCED SEPARATION AND POLICY ENFORCEMENT

Control: Implement hardware-enforced separation and policy enforcement mechanisms between [ Assignment: organization-defined security domains ]. Discussion: System owners may require additional strength of mechanism and robustness to ensure domain separation and policy enforcement for specific types of threats and environments of operation. Hardware-enforced separation and policy enforcement provide greater strength of mechanism than software-enforced separation and policy enforcement.

Related Controls: AC-4 , SA-8 , SC-50. Control Enhancements: None. References: [SP 800-160-1 ].

• SC-50 SOFTWARE-ENFORCED SEPARATION AND POLICY ENFORCEMENT

Control: Implement software-enforced separation and policy enforcement mechanisms between [ Assignment: organization-defined security domains ]. Discussion: System owners may require additional strength of mechanism to ensure domain separation and policy enforcement for specific types of threats and environments of operation. Related Controls: AC-3 , AC-4 , SA-8 , SC-2 , SC-3 , SC-49.

Control Enhancements: None. References: [SP 800-160-1 ].

800

5

• SC-51 HARDWARE-BASED PROTECTION

Control: a. Employ hardware-based, write-protect for [ Assignment: organization-defined system firmware components ]; and

b. Implement specific procedures for [ Assignment: organization-defined authorized individuals ] to manually disable hardware write-protect for firmware modifications and re-enable the write-protect prior to returning to operational mode. Discussion: None. Related Controls: None.

Control Enhancements: None. References: None.

800

5

Quick link to System and Information Integrity Summary Table

• SI-1 POLICY AND PROCEDURES

Control: a. Develop, document, and disseminate to [ Assignment: organization-defined personnel or roles ]:

1. [ Selection (one or more): organization-level; mission/business process-level; system- level ] system and information integrity policy that: (a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the system and information integrity policy and the associated system and information integrity controls; b. Designate an [ Assignment: organization-defined official ] to manage the development, documentation, and dissemination of the system and information integrity policy and procedures; and c. Review and update the current system and information integrity:
3. Policy [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]; and
4. Procedures [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]. Discussion: System and information integrity policy and procedures address the controls in the SI family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and information integrity policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission-or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and information integrity policy and procedures include assessment or audit findings, security or privacy incidents, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. Related Controls: PM-9 , PS-8 , SA-8 , SI-12. Control Enhancements: None. References: [OMB A-130 ], [SP 800-12 ], [SP 800-100 ].

800

5

• SI-2 FLAW REMEDIATION

Control: a. Identify, report, and correct system flaws; b. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation; c. Install security-relevant software and firmware updates within [ Assignment: organization- defined time period ] of the release of the updates; and d. Incorporate flaw remediation into the organizational configuration management process. Discussion: The need to remediate system flaws applies to all types of software and firmware. Organizations identify systems affected by software flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security and privacy responsibilities. Security-relevant updates include patches, service packs, and malicious code signatures. Organizations also address flaws discovered during assessments, continuous monitoring, incident response activities, and system error handling. By incorporating flaw remediation into configuration management processes, required remediation actions can be tracked and verified. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of risk factors, including the security category of the system, the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw), the organizational risk tolerance, the mission supported by the system, or the threat environment. Some types of flaw remediation may require more testing than other types. Organizations determine the type of testing needed for the specific type of flaw remediation activity under consideration and the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software or firmware updates is not necessary or practical, such as when implementing simple malicious code signature updates. In testing decisions, organizations consider whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related Controls: CA-5 , CM-3 , CM-4 , CM-5 , CM-6 , CM-8 , MA-2 , RA-5 , SA-8 , SA-10 , SA-11 , SI-3 , SI- 5 , SI-7 , SI-11. Control Enhancements:

• (1) FLAW REMEDIATION / CENTRAL MANAGEMENT

[Withdrawn: Incorporated into PL-9 .]

• (2) FLAW REMEDIATION / AUTOMATED FLAW REMEDIATION STATUS

Determine if system components have applicable security-relevant software and firmware updates installed using [ Assignment: organization-defined automated mechanisms ] [ Assignment: organization-defined frequency ]. Discussion: Automated mechanisms can track and determine the status of known flaws for system components. Related Controls: CA-7 , SI-4.

• (3) FLAW REMEDIATION / TIME TO REMEDIATE FLAWS AND BENCHMARKS FOR CORRECTIVE ACTIONS

(a) Measure the time between flaw identification and flaw remediation; and (b) Establish the following benchmarks for taking corrective actions: [ Assignment: organization-defined benchmarks ]. Discussion: Organizations determine the time it takes on average to correct system flaws after such flaws have been identified and subsequently establish organizational benchmarks

800

5

(i.e., time frames) for taking corrective actions. Benchmarks can be established by the type of flaw or the severity of the potential vulnerability if the flaw can be exploited. Related Controls: None.

• (4) FLAW REMEDIATION / AUTOMATED PATCH MANAGEMENT TOOLS

Employ automated patch management tools to facilitate flaw remediation to the following system components: [ Assignment: organization-defined system components ]. Discussion: Using automated tools to support patch management helps to ensure the timeliness and completeness of system patching operations. Related Controls: None.

• (5) FLAW REMEDIATION / AUTOMATIC SOFTWARE AND FIRMWARE UPDATES

Install [ Assignment: organization-defined security-relevant software and firmware updates ] automatically to [ Assignment: organization-defined system components ]. Discussion: Due to system integrity and availability concerns, organizations consider the methodology used to carry out automatic updates. Organizations balance the need to ensure that the updates are installed as soon as possible with the need to maintain configuration management and control with any mission or operational impacts that automatic updates might impose. Related Controls: None.

• (6) FLAW REMEDIATION / REMOVAL OF PREVIOUS VERSIONS OF SOFTWARE AND FIRMWARE

Remove previous versions of [ Assignment: organization-defined software and firmware components ] after updated versions have been installed. Discussion: Previous versions of software or firmware components that are not removed from the system after updates have been installed may be exploited by adversaries. Some products may automatically remove previous versions of software and firmware from the system. Related Controls: None.

References: [OMB A-130 ], [FIPS 140-3 ], [FIPS 186-4 ], [SP 800-39 ], [SP 800-40 ], [SP 800-128 ], [IR 7788 ].

• SI-3 MALICIOUS CODE PROTECTION

Control:

a. Implement [ Selection (one or more): signature based; non-signature based ] malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code; b. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures;

c. Configure malicious code protection mechanisms to:

1. Perform periodic scans of the system [ Assignment: organization-defined frequency ] and real-time scans of files from external sources at [ Selection (one or more); endpoint; network entry and exit points ] as the files are downloaded, opened, or executed in accordance with organizational policy; and
2. [ Selection (one or more): block malicious code; quarantine malicious code; take [ Assignment: organization-defined action ]]; and send alert to [ Assignment: organization- defined personnel or roles ] in response to malicious code detection; and

800

5

d. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system. Discussion: System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world-wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code.

Malicious code protection mechanisms include both signature-and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions. In situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files.

• Related Controls: AC-4 , AC-19 , CM-3 , CM-8 , IR-4 , MA-3 , MA-4 , PL-9 , RA-5 , SC-7 , SC-23 , SC-26 , SC-

*# 28 , SC-44 , SI-2 , SI-4 , SI-7 , SI-8 , SI-15.

Control Enhancements:

• (1) MALICIOUS CODE PROTECTION / CENTRAL MANAGEMENT

[Withdrawn: Incorporated into PL-9 .]

• (2) MALICIOUS CODE PROTECTION / AUTOMATIC UPDATES

[Withdrawn: Incorporated into SI-3 .]

• (3) MALICIOUS CODE PROTECTION / NON-PRIVILEGED USERS

[Withdrawn: Incorporated into AC-6(10).]

• (4) MALICIOUS CODE PROTECTION / UPDATES ONLY BY PRIVILEGED USERS

Update malicious code protection mechanisms only when directed by a privileged user. Discussion: Protection mechanisms for malicious code are typically categorized as security- related software and, as such, are only updated by organizational personnel with appropriate access privileges. Related Controls: CM-5.

• (5) MALICIOUS CODE PROTECTION / PORTABLE STORAGE DEVICES

800

5

[Withdrawn: Incorporated into MP-7 .]

• (6) MALICIOUS CODE PROTECTION / TESTING AND VERIFICATION

(a) Test malicious code protection mechanisms [ Assignment: organization-defined frequency ] by introducing known benign code into the system; and (b) Verify that the detection of the code and the associated incident reporting occur. Discussion: None. Related Controls: CA-2 , CA-7 , RA-5.

• (7) MALICIOUS CODE PROTECTION / NONSIGNATURE-BASED DETECTION

[Withdrawn: Incorporated into SI-3 .]

• (8) MALICIOUS CODE PROTECTION / DETECT UNAUTHORIZED COMMANDS

(a) Detect the following unauthorized operating system commands through the kernel application programming interface on [ Assignment: organization-defined system hardware components ]: [ Assignment: organization-defined unauthorized operating system commands ]; and (b) [ Selection (one or more): issue a warning; audit the command execution; prevent the execution of the command ]. Discussion: Detecting unauthorized commands can be applied to critical interfaces other than kernel-based interfaces, including interfaces with virtual machines and privileged applications. Unauthorized operating system commands include commands for kernel functions from system processes that are not trusted to initiate such commands as well as commands for kernel functions that are suspicious even though commands of that type are reasonable for processes to initiate. Organizations can define the malicious commands to be detected by a combination of command types, command classes, or specific instances of commands. Organizations can also define hardware components by component type, component, component location in the network, or a combination thereof. Organizations may select different actions for different types, classes, or instances of malicious commands. Related Controls: AU-2 , AU-6 , AU-12.

• (9) MALICIOUS CODE PROTECTION / AUTHENTICATE REMOTE COMMANDS

[Withdrawn: Moved to AC-17(10).]

• (10) MALICIOUS CODE PROTECTION / MALICIOUS CODE ANALYSIS

• (a) Employ the following tools and techniques to analyze the characteristics and behavior

of malicious code: [ Assignment: organization-defined tools and techniques ]; and (b) Incorporate the results from malicious code analysis into organizational incident response and flaw remediation processes. Discussion: The use of malicious code analysis tools provides organizations with a more in- depth understanding of adversary tradecraft (i.e., tactics, techniques, and procedures) and the functionality and purpose of specific instances of malicious code. Understanding the characteristics of malicious code facilitates effective organizational responses to current and future threats. Organizations can conduct malicious code analyses by employing reverse engineering techniques or by monitoring the behavior of executing code. Related Controls: None. References: [SP 800-83 ], [SP 800-125B], [SP 800-177 ].

• SI-4 SYSTEM MONITORING

Control:

800

5

a. Monitor the system to detect:

1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [ Assignment: organization-defined monitoring objectives ]; and
2. Unauthorized local, network, and remote connections;

• b. Identify unauthorized use of the system through the following techniques and methods:

[ Assignment: organization-defined techniques and methods ]; c. Invoke internal monitoring capabilities or deploy monitoring devices:

1. Strategically within the system to collect organization-determined essential information; and
2. At ad hoc locations within the system to track specific types of transactions of interest to the organization; d. Analyze detected events and anomalies; e. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation; f. Obtain legal opinion regarding system monitoring activities; and

g. Provide [ Assignment: organization-defined system monitoring information ] to [ Assignment: organization-defined personnel or roles ] [ Selection (one or more): as needed; [ Assignment: organization-defined frequency ]]. Discussion: System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at external interfaces to the system. Internal monitoring includes the observation of events occurring within the system. Organizations monitor systems by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives guide and inform the determination of the events. System monitoring capabilities are achieved through a variety of tools and techniques, including intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software. Depending on the security architecture, the distribution and configuration of monitoring devices may impact throughput at key internal and external boundaries as well as at other locations across a network due to the introduction of network throughput latency. If throughput management is needed, such devices are strategically located and deployed as part of an established organization-wide security architecture. Strategic locations for monitoring devices include selected perimeter locations and near key servers and server farms that support critical applications. Monitoring devices are typically employed at the managed interfaces associated with controls SC-7 and AC-17. The information collected is a function of the organizational monitoring objectives and the capability of systems to support such objectives. Specific types of transactions of interest include Hypertext Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring is an integral part of organizational continuous monitoring and incident response programs, and output from system monitoring serves as input to those programs. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other controls (e.g., AC-2g, AC-2(7), AC-2(12)(a), AC-17(1), AU- 13 , AU-13(1), AU-13(2), CM-3f, CM-6d, MA-3a, MA-4a, SC-5(3)(b), SC-7a, SC-7(24)(b), SC-18 b, SC- 43b). Adjustments to levels of system monitoring are based on law enforcement information, intelligence information, or other sources of information. The legality of system monitoring activities is based on applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.

800

5

Related Controls: AC-2 , AC-3 , AC-4 , AC-8 , AC-17 , AU-2 , AU-6 , AU-7 , AU-9 , AU-12 , AU-13 , AU-14 , CA-7 , CM-3 , CM-6 , CM-8 , CM-11 , IA-10 , IR-4 , MA-3 , MA-4 , PL-9 , PM-12 , RA-5 , RA-10 , SC-5 , SC-7 , SC-18 , SC-26 , SC-31 , SC-35 , SC-36 , SC-37 , SC-43 , SI-3 , SI-6 , SI-7 , SR-9 , SR-10. Control Enhancements:

• (1) SYSTEM MONITORING / SYSTEM-WIDE INTRUSION DETECTION SYSTEM

Connect and configure individual intrusion detection tools into a system-wide intrusion detection system. Discussion: Linking individual intrusion detection tools into a system-wide intrusion detection system provides additional coverage and effective detection capabilities. The information contained in one intrusion detection tool can be shared widely across the organization, making the system-wide detection capability more robust and powerful. Related Controls: None.

• (2) SYSTEM MONITORING / AUTOMATED TOOLS AND MECHANISMS FOR REAL-TIME ANALYSIS

Employ automated tools and mechanisms to support near real-time analysis of events. Discussion: Automated tools and mechanisms include host-based, network-based, transport-based, or storage-based event monitoring tools and mechanisms or security information and event management (SIEM) technologies that provide real-time analysis of

• alerts and notifications generated by organizational systems. Automated monitoring

techniques can create unintended privacy risks because automated controls may connect to external or otherwise unrelated systems. The matching of records between these systems may create linkages with unintended consequences. Organizations assess and document these risks in their privacy impact assessment and make determinations that are in alignment with their privacy program plan. Related Controls: PM-23 , PM-25.

• (3) SYSTEM MONITORING / AUTOMATED TOOL AND MECHANISM INTEGRATION

Employ automated tools and mechanisms to integrate intrusion detection tools and mechanisms into access control and flow control mechanisms. Discussion: Using automated tools and mechanisms to integrate intrusion detection tools and mechanisms into access and flow control mechanisms facilitates a rapid response to attacks by enabling the reconfiguration of mechanisms in support of attack isolation and elimination. Related Controls: PM-23 , PM-25.

• (4) SYSTEM MONITORING / INBOUND AND OUTBOUND COMMUNICATIONS TRAFFIC

(a) Determine criteria for unusual or unauthorized activities or conditions for inbound and outbound communications traffic; (b) Monitor inbound and outbound communications traffic [ Assignment: organization- defined frequency ] for [ Assignment: organization-defined unusual or unauthorized activities or conditions ]. Discussion: Unusual or unauthorized activities or conditions related to system inbound and outbound communications traffic includes internal traffic that indicates the presence of malicious code or unauthorized use of legitimate code or credentials within organizational systems or propagating among system components, signaling to external systems, and the unauthorized exporting of information. Evidence of malicious code or unauthorized use of legitimate code or credentials is used to identify potentially compromised systems or system components. Related Controls: None.

800

5

• (5) SYSTEM MONITORING / SYSTEM-GENERATED ALERTS

Alert [ Assignment: organization-defined personnel or roles ] when the following system- generated indications of compromise or potential compromise occur: [ Assignment: organization-defined compromise indicators ]. Discussion: Alerts may be generated from a variety of sources, including audit records or inputs from malicious code protection mechanisms, intrusion detection or prevention mechanisms, or boundary protection devices such as firewalls, gateways, and routers. Alerts can be automated and may be transmitted telephonically, by electronic mail messages, or by text messaging. Organizational personnel on the alert notification list can include system administrators, mission or business owners, system owners, information owners/stewards, senior agency information security officers, senior agency officials for privacy, system security officers, or privacy officers. In contrast to alerts generated by the system, alerts generated by organizations in SI-4(12) focus on information sources external to the system, such as suspicious activity reports and reports on potential insider threats. Related Controls: AU-4 , AU-5 , PE-6.

• (6) SYSTEM MONITORING / RESTRICT NON-PRIVILEGED USERS

[Withdrawn: Incorporated into AC-6(10).]

• (7) SYSTEM MONITORING / AUTOMATED RESPONSE TO SUSPICIOUS EVENTS

(a) Notify [ Assignment: organization-defined incident response personnel (identified by name and/or by role) ] of detected suspicious events; and

• (b) Take the following actions upon detection: [ Assignment: organization-defined least-

disruptive actions to terminate suspicious events ]. Discussion: Least-disruptive actions include initiating requests for human responses. Related Controls: None.

• (8) SYSTEM MONITORING / PROTECTION OF MONITORING INFORMATION

[Withdrawn: Incorporated into SI-4 .]

• (9) SYSTEM MONITORING / TESTING OF MONITORING TOOLS AND MECHANISMS

Test intrusion-monitoring tools and mechanisms [ Assignment: organization-defined frequency ]. Discussion: Testing intrusion-monitoring tools and mechanisms is necessary to ensure that the tools and mechanisms are operating correctly and continue to satisfy the monitoring objectives of organizations. The frequency and depth of testing depends on the types of tools and mechanisms used by organizations and the methods of deployment. Related Controls: None.

• (10) SYSTEM MONITORING / VISIBILITY OF ENCRYPTED COMMUNICATIONS

Make provisions so that [ Assignment: organization-defined encrypted communications traffic ] is visible to [ Assignment: organization-defined system monitoring tools and mechanisms ]. Discussion: Organizations balance the need to encrypt communications traffic to protect data confidentiality with the need to maintain visibility into such traffic from a monitoring perspective. Organizations determine whether the visibility requirement applies to internal encrypted traffic, encrypted traffic intended for external destinations, or a subset of the traffic types. Related Controls: None.

• (11) SYSTEM MONITORING / ANALYZE COMMUNICATIONS TRAFFIC ANOMALIES

800

5

Analyze outbound communications traffic at the external interfaces to the system and selected [ Assignment: organization-defined interior points within the system ] to discover anomalies. Discussion: Organization-defined interior points include subnetworks and subsystems. Anomalies within organizational systems include large file transfers, long-time persistent connections, attempts to access information from unexpected locations, the use of unusual protocols and ports, the use of unmonitored network protocols (e.g., IPv6 usage during IPv4 transition), and attempted communications with suspected malicious external addresses. Related Controls: None.

• (12) SYSTEM MONITORING / AUTOMATED ORGANIZATION-GENERATED ALERTS

Alert [ Assignment: organization-defined personnel or roles ] using [ Assignment: organization-defined automated mechanisms ] when the following indications of inappropriate or unusual activities with security or privacy implications occur: [ Assignment: organization-defined activities that trigger alerts ]. Discussion: Organizational personnel on the system alert notification list include system administrators, mission or business owners, system owners, senior agency information security officer, senior agency official for privacy, system security officers, or privacy officers. Automated organization-generated alerts are the security alerts generated by organizations and transmitted using automated means. The sources for organization-generated alerts are focused on other entities such as suspicious activity reports and reports on potential insider threats. In contrast to alerts generated by the organization, alerts generated by the system in SI-4(5) focus on information sources that are internal to the systems, such as audit records. Related Controls: None.

• (13) SYSTEM MONITORING / ANALYZE TRAFFIC AND EVENT PATTERNS

(a) Analyze communications traffic and event patterns for the system; (b) Develop profiles representing common traffic and event patterns; and (c) Use the traffic and event profiles in tuning system-monitoring devices. Discussion: Identifying and understanding common communications traffic and event patterns help organizations provide useful information to system monitoring devices to more effectively identify suspicious or anomalous traffic and events when they occur. Such information can help reduce the number of false positives and false negatives during system monitoring. Related Controls: None.

• (14) SYSTEM MONITORING / WIRELESS INTRUSION DETECTION

Employ a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises or breaches to the system. Discussion: Wireless signals may radiate beyond organizational facilities. Organizations proactively search for unauthorized wireless connections, including the conduct of thorough scans for unauthorized wireless access points. Wireless scans are not limited to those areas within facilities containing systems but also include areas outside of facilities to verify that unauthorized wireless access points are not connected to organizational systems. Related Controls: AC-18 , IA-3.

• (15) SYSTEM MONITORING / WIRELESS TO WIRELINE COMMUNICATIONS

Employ an intrusion detection system to monitor wireless communications traffic as the traffic passes from wireless to wireline networks.

800

5

Discussion: Wireless networks are inherently less secure than wired networks. For example, wireless networks are more susceptible to eavesdroppers or traffic analysis than wireline networks. When wireless to wireline communications exist, the wireless network could become a port of entry into the wired network. Given the greater facility of unauthorized network access via wireless access points compared to unauthorized wired network access from within the physical boundaries of the system, additional monitoring of transitioning traffic between wireless and wired networks may be necessary to detect malicious activities. Employing intrusion detection systems to monitor wireless communications traffic helps to ensure that the traffic does not contain malicious code prior to transitioning to the wireline network. Related Controls: AC-18.

• (16) SYSTEM MONITORING / CORRELATE MONITORING INFORMATION

Correlate information from monitoring tools and mechanisms employed throughout the system. Discussion: Correlating information from different system monitoring tools and mechanisms can provide a more comprehensive view of system activity. Correlating system monitoring tools and mechanisms that typically work in isolation—including malicious code protection software, host monitoring, and network monitoring—can provide an organization-wide monitoring view and may reveal otherwise unseen attack patterns. Understanding the capabilities and limitations of diverse monitoring tools and mechanisms and how to maximize the use of information generated by those tools and mechanisms can help organizations develop, operate, and maintain effective monitoring programs. The correlation of monitoring information is especially important during the transition from older to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols). Related Controls: AU-6.

• (17) SYSTEM MONITORING / INTEGRATED SITUATIONAL AWARENESS

Correlate information from monitoring physical, cyber, and supply chain activities to achieve integrated, organization-wide situational awareness. Discussion: Correlating monitoring information from a more diverse set of information sources helps to achieve integrated situational awareness. Integrated situational awareness from a combination of physical, cyber, and supply chain monitoring activities enhances the capability of organizations to more quickly detect sophisticated attacks and investigate the methods and techniques employed to carry out such attacks. In contrast to SI-4(16), which correlates the various cyber monitoring information, integrated situational awareness is intended to correlate monitoring beyond the cyber domain. Correlation of monitoring information from multiple activities may help reveal attacks on organizations that are operating across multiple attack vectors. Related Controls: AU-16 , PE-6 , SR-2 , SR-4 , SR-6.

• (18) SYSTEM MONITORING / ANALYZE TRAFFIC AND COVERT EXFILTRATION

Analyze outbound communications traffic at external interfaces to the system and at the following interior points to detect covert exfiltration of information: [ Assignment: organization-defined interior points within the system ]. Discussion: Organization-defined interior points include subnetworks and subsystems. Covert means that can be used to exfiltrate information include steganography. Related Controls: None.

• (19) SYSTEM MONITORING / RISK FOR INDIVIDUALS

800

5

Implement [ Assignment: organization-defined additional monitoring ] of individuals who have been identified by [ Assignment: organization-defined sources ] as posing an increased level of risk. Discussion: Indications of increased risk from individuals can be obtained from different sources, including personnel records, intelligence agencies, law enforcement organizations, and other sources. The monitoring of individuals is coordinated with the management, legal, security, privacy, and human resource officials who conduct such monitoring. Monitoring is conducted in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Related Controls: None.

• (20) SYSTEM MONITORING / PRIVILEGED USERS

• Implement the following additional monitoring of privileged users: [ Assignment:

organization-defined additional monitoring ]. Discussion: Privileged users have access to more sensitive information, including security- related information, than the general user population. Access to such information means that privileged users can potentially do greater damage to systems and organizations than non-privileged users. Therefore, implementing additional monitoring on privileged users helps to ensure that organizations can identify malicious activity at the earliest possible time and take appropriate actions. Related Controls: AC-18.

• (21) SYSTEM MONITORING / PROBATIONARY PERIODS

• Implement the following additional monitoring of individuals during [ Assignment:

organization-defined probationary period ]: [ Assignment: organization-defined additional monitoring ]. Discussion: During probationary periods, employees do not have permanent employment status within organizations. Without such status or access to information that is resident on the system, additional monitoring can help identify any potentially malicious activity or inappropriate behavior. Related Controls: AC-18.

• (22) SYSTEM MONITORING / UNAUTHORIZED NETWORK SERVICES

(a) Detect network services that have not been authorized or approved by [ Assignment: organization-defined authorization or approval processes ]; and (b) [ Selection (one or more): Audit; Alert [ Assignment: organization-defined personnel or

• roles ]] when detected.

Discussion: Unauthorized or unapproved network services include services in service- oriented architectures that lack organizational verification or validation and may therefore be unreliable or serve as malicious rogues for valid services. Related Controls: CM-7.

• (23) SYSTEM MONITORING / HOST-BASED DEVICES

• Implement the following host-based monitoring mechanisms at [ Assignment:

organization-defined system components ]: [ Assignment: organization-defined host-based monitoring mechanisms ]. Discussion: Host-based monitoring collects information about the host (or system in which it resides). System components in which host-based monitoring can be implemented include servers, notebook computers, and mobile devices. Organizations may consider employing host-based monitoring mechanisms from multiple product developers or vendors. Related Controls: AC-18 , AC-19.

800

5

• (24) SYSTEM MONITORING / INDICATORS OF COMPROMISE

Discover, collect, and distribute to [ Assignment: organization-defined personnel or roles ],

• indicators of compromise provided by [ Assignment: organization-defined sources ].

Discussion: Indicators of compromise (IOC) are forensic artifacts from intrusions that are identified on organizational systems at the host or network level. IOCs provide valuable information on systems that have been compromised. IOCs can include the creation of registry key values. IOCs for network traffic include Universal Resource Locator or protocol elements that indicate malicious code command and control servers. The rapid distribution and adoption of IOCs can improve information security by reducing the time that systems

• and organizations are vulnerable to the same exploit or attack. Threat indicators, signatures,

tactics, techniques, procedures, and other indicators of compromise may be available via government and non-government cooperatives, including the Forum of Incident Response and Security Teams, the United States Computer Emergency Readiness Team, the Defense Industrial Base Cybersecurity Information Sharing Program, and the CERT Coordination Center. Related Controls: AC-18.

• (25) SYSTEM MONITORING / OPTIMIZE NETWORK TRAFFIC ANALYSIS

Provide visibility into network traffic at external and key internal system interfaces to optimize the effectiveness of monitoring devices. Discussion: Encrypted traffic, asymmetric routing architectures, capacity and latency limitations, and transitioning from older to newer technologies (e.g., IPv4 to IPv6 network protocol transition) may result in blind spots for organizations when analyzing network traffic. Collecting, decrypting, pre-processing, and distributing only relevant traffic to monitoring devices can streamline the efficiency and use of devices and optimize traffic analysis. Related Controls: None. References: [OMB A-130 ], [FIPS 140-3 ], [SP 800-61 ], [SP 800-83 ], [SP 800-92 ], [SP 800-94 ], [SP 800-137 ].

• SI-5 SECURITY ALERTS, ADVISORIES, AND DIRECTIVES

Control: a. Receive system security alerts, advisories, and directives from [ Assignment: organization- defined external organizations ] on an ongoing basis; b. Generate internal security alerts, advisories, and directives as deemed necessary; c. Disseminate security alerts, advisories, and directives to: [ Selection (one or more): [ Assignment: organization-defined personnel or roles ]; [ Assignment: organization-defined elements within the organization ]; [ Assignment: organization-defined external organizations ]]; and d. Implement security directives in accordance with established time frames, or notify the issuing organization of the degree of noncompliance. Discussion: The Cybersecurity and Infrastructure Security Agency (CISA) generates security alerts and advisories to maintain situational awareness throughout the Federal Government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance with security directives is essential due to the critical nature of many of these directives and the potential (immediate) adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include supply chain

800

5

partners, external mission or business partners, external service providers, and other peer or supporting organizations. Related Controls: PM-15 , RA-5 , SI-2. Control Enhancements:

• (1) SECURITY ALERTS, ADVISORIES, AND DIRECTIVES / AUTOMATED ALERTS AND ADVISORIES

Broadcast security alert and advisory information throughout the organization using [ Assignment: organization-defined automated mechanisms ]. Discussion: The significant number of changes to organizational systems and environments of operation requires the dissemination of security-related information to a variety of organizational entities that have a direct interest in the success of organizational mission and business functions. Based on information provided by security alerts and advisories, changes may be required at one or more of the three levels related to the management of risk, including the governance level, mission and business process level, and the information system level. Related Controls: None. References: [SP 800-40 ].

• SI-6 SECURITY AND PRIVACY FUNCTION VERIFICATION

Control:

a. Verify the correct operation of [ Assignment: organization-defined security and privacy functions ]; b. Perform the verification of the functions specified in SI-6a [ Selection (one or more): [ Assignment: organization-defined system transitional states ] ; upon command by user with appropriate privilege; [ Assignment: organization-defined frequency ]]; c. Alert [ Assignment: organization-defined personnel or roles ] to failed security and privacy verification tests; and d. [ Selection (one or more): Shut the system down; Restart the system; [ Assignment: organization-defined alternative action(s) ]] when anomalies are discovered.

Discussion: Transitional states for systems include system startup, restart, shutdown, and abort. System notifications include hardware indicator lights, electronic alerts to system administrators, and messages to local computer consoles. In contrast to security function verification, privacy function verification ensures that privacy functions operate as expected and are approved by the senior agency official for privacy or that privacy attributes are applied or used as expected.

Related Controls: CA-7 , CM-4 , CM-6 , SI-7. Control Enhancements:

• (1) SECURITY AND PRIVACY FUNCTION VERIFICATION / NOTIFICATION OF FAILED SECURITY TESTS

[Withdrawn: Incorporated into SI-6 .]

• (2) SECURITY AND PRIVACY FUNCTION VERIFICATION / AUTOMATION SUPPORT FOR DISTRIBUTED

• TESTING

Implement automated mechanisms to support the management of distributed security and privacy function testing.

800

5

Discussion: The use of automated mechanisms to support the management of distributed function testing helps to ensure the integrity, timeliness, completeness, and efficacy of such testing.

• Related Controls: SI-2.

• (3) SECURITY AND PRIVACY FUNCTION VERIFICATION / REPORT VERIFICATION RESULTS

Report the results of security and privacy function verification to [ Assignment: organization-defined personnel or roles ]. Discussion: Organizational personnel with potential interest in the results of the verification of security and privacy functions include systems security officers, senior agency information security officers, and senior agency officials for privacy. Related Controls: SI-4 , SR-4 , SR-5. References: [OMB A-130 ].

• SI-7 SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY

Control:

• a. Employ integrity verification tools to detect unauthorized changes to the following software,

firmware, and information: [ Assignment: organization-defined software, firmware, and information ]; and

• b. Take the following actions when unauthorized changes to the software, firmware, and

information are detected: [ Assignment: organization-defined actions ]. Discussion: Unauthorized changes to software, firmware, and information can occur due to errors or malicious activity. Software includes operating systems (with key internal components, such as kernels or drivers), middleware, and applications. Firmware interfaces include Unified Extensible Firmware Interface (UEFI) and Basic Input/Output System (BIOS). Information includes personally identifiable information and metadata that contains security and privacy attributes associated with information. Integrity-checking mechanisms—including parity checks, cyclical redundancy checks, cryptographic hashes, and associated tools—can automatically monitor the integrity of systems and hosted applications.

Related Controls: AC-4 , CM-3 , CM-7 , CM-8 , MA-3 , MA-4 , RA-5 , SA-8 , SA-9 , SA-10 , SC-8 , SC-12 , SC-13 , SC-28 , SC-37 , SI-3 , SR-3 , SR-4 , SR-5 , SR-6 , SR-9 , SR-10 , SR-11. Control Enhancements:

• (1) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / INTEGRITY CHECKS

Perform an integrity check of [ Assignment: organization-defined software, firmware, and information ] [ Selection (one or more): at startup; at [ Assignment: organization-defined transitional states or security-relevant events ]; [ Assignment: organization-defined frequency ]]. Discussion: Security-relevant events include the identification of new threats to which organizational systems are susceptible and the installation of new hardware, software, or firmware. Transitional states include system startup, restart, shutdown, and abort. Related Controls: None.

• (2) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / AUTOMATED NOTIFICATIONS OF INTEGRITY

• VIOLATIONS

Employ automated tools that provide notification to [ Assignment: organization-defined personnel or roles ] upon discovering discrepancies during integrity verification.

800

5

Discussion: The employment of automated tools to report system and information integrity violations and to notify organizational personnel in a timely matter is essential to effective risk response. Personnel with an interest in system and information integrity violations include mission and business owners, system owners, senior agency information security official, senior agency official for privacy, system administrators, software developers, systems integrators, information security officers, and privacy officers. Related Controls: None.

• (3) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / CENTRALLY MANAGED INTEGRITY TOOLS

Employ centrally managed integrity verification tools. Discussion: Centrally managed integrity verification tools provides greater consistency in the application of such tools and can facilitate more comprehensive coverage of integrity verification actions. Related Controls: AU-3 , SI-2 , SI-8.

• (4) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / TAMPER-EVIDENT PACKAGING

[Withdrawn: Incorporated into SR-9 .]

• (5) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / AUTOMATED RESPONSE TO INTEGRITY

• VIOLATIONS

Automatically [ Selection (one or more): shut the system down; restart the system; implement [ Assignment: organization-defined controls ]] when integrity violations are discovered. Discussion: Organizations may define different integrity-checking responses by type of information, specific information, or a combination of both. Types of information include firmware, software, and user data. Specific information includes boot firmware for certain types of machines. The automatic implementation of controls within organizational systems includes reversing the changes, halting the system, or triggering audit alerts when unauthorized modifications to critical security files occur. Related Controls: None.

• (6) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / CRYPTOGRAPHIC PROTECTION

Implement cryptographic mechanisms to detect unauthorized changes to software, firmware, and information. Discussion: Cryptographic mechanisms used to protect integrity include digital signatures and the computation and application of signed hashes using asymmetric cryptography, protecting the confidentiality of the key used to generate the hash, and using the public key to verify the hash information. Organizations that employ cryptographic mechanisms also consider cryptographic key management solutions. Related Controls: SC-12 , SC-13.

• (7) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / INTEGRATION OF DETECTION AND

• RESPONSE

Incorporate the detection of the following unauthorized changes into the organizational incident response capability: [ Assignment: organization-defined security-relevant changes to the system ]. Discussion: Integrating detection and response helps to ensure that detected events are tracked, monitored, corrected, and available for historical purposes. Maintaining historical records is important for being able to identify and discern adversary actions over an extended time period and for possible legal actions. Security-relevant changes include

800

5

unauthorized changes to established configuration settings or the unauthorized elevation of system privileges. Related Controls: AU-2 , AU-6 , IR-4 , IR-5 , SI-4.

• (8) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / AUDITING CAPABILITY FOR SIGNIFICANT

• EVENTS

Upon detection of a potential integrity violation, provide the capability to audit the event and initiate the following actions: [ Selection (one or more): generate an audit record; alert current user; alert [ Assignment: organization-defined personnel or roles ]; [ Assignment: organization-defined other actions ]]. Discussion: Organizations select response actions based on types of software, specific software, or information for which there are potential integrity violations. Related Controls: AU-2 , AU-6 , AU-12.

• (9) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / VERIFY BOOT PROCESS

• Verify the integrity of the boot process of the following system components: [ Assignment:

organization-defined system components ]. Discussion: Ensuring the integrity of boot processes is critical to starting system components in known, trustworthy states. Integrity verification mechanisms provide a level of assurance that only trusted code is executed during boot processes. Related Controls: SI-6.

• (10) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / PROTECTION OF BOOT FIRMWARE

Implement the following mechanisms to protect the integrity of boot firmware in [ Assignment: organization-defined system components ]: [ Assignment: organization- defined mechanisms ]. Discussion: Unauthorized modifications to boot firmware may indicate a sophisticated, targeted attack. These types of targeted attacks can result in a permanent denial of service or a persistent malicious code presence. These situations can occur if the firmware is corrupted or if the malicious code is embedded within the firmware. System components can protect the integrity of boot firmware in organizational systems by verifying the integrity and authenticity of all updates to the firmware prior to applying changes to the system component and preventing unauthorized processes from modifying the boot firmware. Related Controls: SI-6.

• (11) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / CONFINED ENVIRONMENTS WITH LIMITED

• PRIVILEGES

[Withdrawn: Moved to CM-7(6).]

• (12) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / INTEGRITY VERIFICATION

Require that the integrity of the following user-installed software be verified prior to execution: [ Assignment: organization-defined user-installed software ]. Discussion: Organizations verify the integrity of user-installed software prior to execution to reduce the likelihood of executing malicious code or programs that contains errors from unauthorized modifications. Organizations consider the practicality of approaches to verifying software integrity, including the availability of trustworthy checksums from software developers and vendors. Related Controls: CM-11.

• (13) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / CODE EXECUTION IN PROTECTED

• ENVIRONMENTS

800

5

• [Withdrawn: Moved to CM-7(7).]

• (14) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / BINARY OR MACHINE EXECUTABLE CODE

• [Withdrawn: Moved to CM-7(8).]

• (15) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / CODE AUTHENTICATION

• Implement cryptographic mechanisms to authenticate the following software or firmware

components prior to installation: [ Assignment: organization-defined software or firmware components ]. Discussion: Cryptographic authentication includes verifying that software or firmware components have been digitally signed using certificates recognized and approved by organizations. Code signing is an effective method to protect against malicious code. Organizations that employ cryptographic mechanisms also consider cryptographic key management solutions. Related Controls: CM-5 , SC-12 , SC-13.

• (16) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / TIME LIMIT ON PROCESS EXECUTION

• WITHOUT SUPERVISION

Prohibit processes from executing without supervision for more than [ Assignment: organization-defined time period ]. Discussion: Placing a time limit on process execution without supervision is intended to apply to processes for which typical or normal execution periods can be determined and situations in which organizations exceed such periods. Supervision includes timers on operating systems, automated responses, and manual oversight and response when system process anomalies occur. Related Controls: None.

• (17) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY / RUNTIME APPLICATION SELF-PROTECTION

Implement [ Assignment: organization-defined controls ] for application self-protection at runtime. Discussion: Runtime application self-protection employs runtime instrumentation to detect and block the exploitation of software vulnerabilities by taking advantage of information from the software in execution. Runtime exploit prevention differs from traditional perimeter-based protections such as guards and firewalls which can only detect and block attacks by using network information without contextual awareness. Runtime application self-protection technology can reduce the susceptibility of software to attacks by monitoring its inputs and blocking those inputs that could allow attacks. It can also help protect the runtime environment from unwanted changes and tampering. When a threat is detected, runtime application self-protection technology can prevent exploitation and take other actions (e.g., sending a warning message to the user, terminating the user's session, terminating the application, or sending an alert to organizational personnel). Runtime application self-protection solutions can be deployed in either a monitor or protection mode. Related Controls: SI-16. References: [OMB A-130 ], [FIPS 140-3 ], [FIPS 180-4 ], [FIPS 186-4 ], [FIPS 202], [SP 800-70 ], [SP 800-147 ].

• SI-8 SPAM PROTECTION

Control:

800

5

a. Employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages; and b. Update spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures. Discussion: System entry and exit points include firewalls, remote-access servers, electronic mail servers, web servers, proxy servers, workstations, notebook computers, and mobile devices. Spam can be transported by different means, including email, email attachments, and web accesses. Spam protection mechanisms include signature definitions. Related Controls: PL-9 , SC-5 , SC-7 , SC-38 , SI-3 , SI-4. Control Enhancements:

• (1) SPAM PROTECTION / CENTRAL MANAGEMENT

[Withdrawn: Incorporated into PL-9 .]

• (2) SPAM PROTECTION / AUTOMATIC UPDATES

Automatically update spam protection mechanisms [ Assignment: organization-defined frequency ]. Discussion: Using automated mechanisms to update spam protection mechanisms helps to ensure that updates occur on a regular basis and provide the latest content and protection capabilities. Related Controls: None.

• (3) SPAM PROTECTION /CONTINUOUS LEARNING CAPABILITY

Implement spam protection mechanisms with a learning capability to more effectively identify legitimate communications traffic. Discussion: Learning mechanisms include Bayesian filters that respond to user inputs that identify specific traffic as spam or legitimate by updating algorithm parameters and thereby more accurately separating types of traffic. Related Controls: None.

References: [SP 800-45 ], [SP 800-177 ].

• SI-9 INFORMATION INPUT RESTRICTIONS

[Withdrawn: Incorporated into AC-2 , AC-3 , AC-5 , AC-6 .]

• SI-10 INFORMATION INPUT VALIDATION

Control: Check the validity of the following information inputs: [ Assignment: organization- defined information inputs to the system ]. Discussion: Checking the valid syntax and semantics of system inputs—including character set, length, numerical range, and acceptable values—verifies that inputs match specified definitions for format and content. For example, if the organization specifies that numerical values between 1-100 are the only acceptable inputs for a field in a given application, inputs of “387,” “abc,” or “%K%” are invalid inputs and are not accepted as input to the system. Valid inputs are likely to vary from field to field within a software application. Applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker- supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data

800

5

to be interpreted as control information or metadata. Consequently, the module or component that receives the corrupted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing them to interpreters prevents the content from being unintentionally interpreted as commands. Input validation ensures accurate and correct inputs and prevents attacks such as cross-site scripting and a variety of injection attacks.

Related Controls: None. Control Enhancements:

• (1) INFORMATION INPUT VALIDATION / MANUAL OVERRIDE CAPABILITY

• (a) Provide a manual override capability for input validation of the following information

inputs: [ Assignment: organization-defined inputs defined in the base control (SI-10) ]; (b) Restrict the use of the manual override capability to only [ Assignment: organization- defined authorized individuals ]; and (c) Audit the use of the manual override capability. Discussion: In certain situations, such as during events that are defined in contingency plans, a manual override capability for input validation may be needed. Manual overrides are used only in limited circumstances and with the inputs defined by the organization. Related Controls: AC-3 , AU-2 , AU-12.

• (2) INFORMATION INPUT VALIDATION / REVIEW AND RESOLVE ERRORS

Review and resolve input validation errors within [ Assignment: organization-defined time period ]. Discussion: Resolution of input validation errors includes correcting systemic causes of errors and resubmitting transactions with corrected input. Input validation errors are those related to the information inputs defined by the organization in the base control (SI-10 ). Related Controls: None.

• (3) INFORMATION INPUT VALIDATION / PREDICTABLE BEHAVIOR

Verify that the system behaves in a predictable and documented manner when invalid inputs are received. Discussion: A common vulnerability in organizational systems is unpredictable behavior when invalid inputs are received. Verification of system predictability helps ensure that the system behaves as expected when invalid inputs are received. This occurs by specifying system responses that allow the system to transition to known states without adverse, unintended side effects. The invalid inputs are those related to the information inputs defined by the organization in the base control (SI-10 ). Related Controls: None.

• (4) INFORMATION INPUT VALIDATION / TIMING INTERACTIONS

Account for timing interactions among system components in determining appropriate responses for invalid inputs. Discussion: In addressing invalid system inputs received across protocol interfaces, timing interactions become relevant, where one protocol needs to consider the impact of the error response on other protocols in the protocol stack. For example, 802.11 standard wireless network protocols do not interact well with Transmission Control Protocols (TCP) when packets are dropped (which could be due to invalid packet input). TCP assumes packet losses are due to congestion, while packets lost over 802.11 links are typically dropped due to noise or collisions on the link. If TCP makes a congestion response, it takes the wrong action in response to a collision event. Adversaries may be able to use what appear to be acceptable individual behaviors of the protocols in concert to achieve adverse effects through suitable

800

5

construction of invalid input. The invalid inputs are those related to the information inputs defined by the organization in the base control (SI-10 ). Related Controls: None.

• (5) INFORMATION INPUT VALIDATION / RESTRICT INPUTS TO TRUSTED SOURCES AND APPROVED

• FORMATS

Restrict the use of information inputs to [ Assignment: organization-defined trusted sources ] and/or [ Assignment: organization-defined formats ]. Discussion: Restricting the use of inputs to trusted sources and in trusted formats applies the concept of authorized or permitted software to information inputs. Specifying known trusted sources for information inputs and acceptable formats for such inputs can reduce the probability of malicious activity. The information inputs are those defined by the organization in the base control (SI-10 ). Related Controls: AC-3 , AC-6.

• (6) INFORMATION INPUT VALIDATION / INJECTION PREVENTION

Prevent untrusted data injections. Discussion: Untrusted data injections may be prevented using a parameterized interface or output escaping (output encoding). Parameterized interfaces separate data from code so that injections of malicious or unintended data cannot change the semantics of commands being sent. Output escaping uses specified characters to inform the interpreter’s parser whether data is trusted. Prevention of untrusted data injections are with respect to the information inputs defined by the organization in the base control (SI-10 ). Related Controls: AC-3 , AC-6. References: [OMB A-130, Appendix II].

• SI-11 ERROR HANDLING

Control:

a. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and b. Reveal error messages only to [ Assignment: organization-defined personnel or roles ]. Discussion: Organizations consider the structure and content of error messages. The extent to which systems can handle error conditions is guided and informed by organizational policy and operational requirements. Exploitable information includes stack traces and implementation details; erroneous logon attempts with passwords mistakenly entered as the username; mission or business information that can be derived from, if not stated explicitly by, the information recorded; and personally identifiable information, such as account numbers, social security numbers, and credit card numbers. Error messages may also provide a covert channel for transmitting information. Related Controls: AU-2 , AU-3 , SC-31 , SI-2 , SI-15. Control Enhancements: None. References: None.

• SI-12 INFORMATION MANAGEMENT AND RETENTION

Control: Manage and retain information within the system and information output from the system in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements.

800

5

Discussion: Information management and retention requirements cover the full life cycle of information, in some cases extending beyond system disposal. Information to be retained may also include policies, procedures, plans, reports, data output from control implementation, and other types of administrative information. The National Archives and Records Administration

• (NARA) provides federal policy and guidance on records retention and schedules. If organizations

have a records management office, consider coordinating with records management personnel. Records produced from the output of implemented controls that may require management and retention include, but are not limited to: All XX-1 , AC-6(9), AT-4 , AU-12 , CA-2 , CA-3 , CA-5 , CA-6 , CA-7 , CA-8 , CA-9 , CM-2 , CM-3 , CM-4 , CM-6 , CM-8 , CM-9 , CM-12 , CM-13 , CP-2 , IR-6 , IR-8 , MA-2 , MA-4 , PE-2 , PE-8 , PE-16 , PE-17 , PL-2 , PL-4 , PL-7 , PL-8 , PM-5 , PM-8 , PM-9 , PM-18 , PM-21 , PM-27 , PM-28 , PM-30 , PM-31 , PS-2 , PS-6 , PS-7 , PT-2 , PT-3 , PT-7 , RA-2 , RA-3 , RA-5 , RA-8 , SA-4 , SA-5 , SA-8 , SA-10 , SI-4 , SR-2 , SR-4 , SR-8. Related Controls: All XX-1 Controls, AC-16 , AU-5 , AU-11 , CA-2 , CA-3 , CA-5 , CA-6 , CA-7 , CA-9 , CM- 5 , CM-9 , CP-2 , IR-8 , MP-2 , MP-3 , MP-4 , MP-6 , PL-2 , PL-4 , PM-4 , PM-8 , PM-9 , PS-2 , PS-6 , PT-2 , PT- 3 , RA-2 , RA-3 , SA-5 , SA-8 , SR-2.

Control Enhancements:

• (1) INFORMATION MANAGEMENT AND RETENTION / LIMIT PERSONALLY IDENTIFIABLE INFORMATION

• ELEMENTS

• Limit personally identifiable information being processed in the information life cycle to

the following elements of PII: [ Assignment: organization-defined elements of personally identifiable information ]. Discussion: Limiting the use of personally identifiable information throughout the information life cycle when the information is not needed for operational purposes helps to reduce the level of privacy risk created by a system. The information life cycle includes information creation, collection, use, processing, storage, maintenance, dissemination,

• disclosure, and disposition. Risk assessments as well as applicable laws, regulations, and

policies can provide useful inputs to determining which elements of personally identifiable information may create risk. Related Controls: PM-25 , PT-2 , PT-3 , RA-3.

• (2) INFORMATION MANAGEMENT AND RETENTION / MINIMIZE PERSONALLY IDENTIFIABLE

• INFORMATION IN TESTING, TRAINING, AND RESEARCH

• Use the following techniques to minimize the use of personally identifiable information for

research, testing, or training: [ Assignment: organization-defined techniques ]. Discussion: Organizations can minimize the risk to an individual’s privacy by employing techniques such as de-identification or synthetic data. Limiting the use of personally identifiable information throughout the information life cycle when the information is not needed for research, testing, or training helps reduce the level of privacy risk created by a

• system. Risk assessments as well as applicable laws, regulations, and policies can provide

useful inputs to determining the techniques to use and when to use them. Related Controls: PM-22 , PM-25 , SI-19.

• (3) INFORMATION MANAGEMENT AND RETENTION / INFORMATION DISPOSAL

Use the following techniques to dispose of, destroy, or erase information following the retention period: [ Assignment: organization-defined techniques ]. Discussion: Organizations can minimize both security and privacy risks by disposing of information when it is no longer needed. The disposal or destruction of information applies to originals as well as copies and archived records, including system logs that may contain personally identifiable information.

800

5

Related Controls: MP-6. References: [USC 2901], [OMB A-130, Appendix II].

• SI-13 PREDICTABLE FAILURE PREVENTION

Control:

a. Determine mean time to failure (MTTF) for the following system components in specific environments of operation: [ Assignment: organization-defined system components ]; and b. Provide substitute system components and a means to exchange active and standby components in accordance with the following criteria: [ Assignment: organization-defined MTTF substitution criteria ].

Discussion: While MTTF is primarily a reliability issue, predictable failure prevention is intended to address potential failures of system components that provide security capabilities. Failure rates reflect installation-specific consideration rather than the industry-average. Organizations define the criteria for the substitution of system components based on the MTTF value with consideration for the potential harm from component failures. The transfer of responsibilities between active and standby components does not compromise safety, operational readiness, or security capabilities. The preservation of system state variables is also critical to help ensure a successful transfer process. Standby components remain available at all times except for maintenance issues or recovery failures in progress. Related Controls: CP-2 , CP-10 , CP-13 , MA-2 , MA-6 , SA-8 , SC-6.

Control Enhancements:

• (1) PREDICTABLE FAILURE PREVENTION / TRANSFERRING COMPONENT RESPONSIBILITIES

Take system components out of service by transferring component responsibilities to substitute components no later than [ Assignment: organization-defined fraction or percentage ] of mean time to failure. Discussion: Transferring primary system component responsibilities to other substitute components prior to primary component failure is important to reduce the risk of degraded or debilitated mission or business functions. Making such transfers based on a percentage of mean time to failure allows organizations to be proactive based on their risk tolerance. However, the premature replacement of system components can result in the increased cost of system operations. Related Controls: None.

• (2) PREDICTABLE FAILURE PREVENTION / TIME LIMIT ON PROCESS EXECUTION WITHOUT SUPERVISION

[Withdrawn: Incorporated into SI-7(16).]

• (3) PREDICTABLE FAILURE PREVENTION / MANUAL TRANSFER BETWEEN COMPONENTS

Manually initiate transfers between active and standby system components when the use of the active component reaches [ Assignment: organization-defined percentage ] of the mean time to failure. Discussion: For example, if the MTTF for a system component is 100 days and the MTTF percentage defined by the organization is 90 percent, the manual transfer would occur after 90 days. Related Controls: None.

• (4) PREDICTABLE FAILURE PREVENTION / STANDBY COMPONENT INSTALLATION AND NOTIFICATION

If system component failures are detected:

800

5

(a) Ensure that the standby components are successfully and transparently installed within [ Assignment: organization-defined time period ]; and (b) [ Selection (one or more): Activate [ Assignment: organization-defined alarm ]; Automatically shut down the system; [ Assignment: organization-defined action ]]. Discussion: Automatic or manual transfer of components from standby to active mode can occur upon the detection of component failures. Related Controls: None.

• (5) PREDICTABLE FAILURE PREVENTION / FAILOVER CAPABILITY

Provide [ Selection: real-time; near real-time ] [ Assignment: organization-defined failover capability ] for the system. Discussion: Failover refers to the automatic switchover to an alternate system upon the failure of the primary system. Failover capability includes incorporating mirrored system operations at alternate processing sites or periodic data mirroring at regular intervals defined by the recovery time periods of organizations. Related Controls: CP-6 , CP-7 , CP-9. References: None.

• SI-14 NON-PERSISTENCE

Control: Implement non-persistent [ Assignment: organization-defined system components and services ] that are initiated in a known state and terminated [ Selection (one or more): upon end of session of use; periodically at [ Assignment: organization-defined frequency ]]. Discussion: Implementation of non-persistent components and services mitigates risk from advanced persistent threats (APTs) by reducing the targeting capability of adversaries (i.e., window of opportunity and available attack surface) to initiate and complete attacks. By implementing the concept of non-persistence for selected system components, organizations can provide a trusted, known state computing resource for a specific time period that does not give adversaries sufficient time to exploit vulnerabilities in organizational systems or operating environments. Since the APT is a high-end, sophisticated threat with regard to capability, intent, and targeting, organizations assume that over an extended period, a percentage of attacks will be successful. Non-persistent system components and services are activated as required using protected information and terminated periodically or at the end of sessions. Non-persistence increases the work factor of adversaries attempting to compromise or breach organizational systems.

Non-persistence can be achieved by refreshing system components, periodically reimaging components, or using a variety of common virtualization techniques. Non-persistent services can be implemented by using virtualization techniques as part of virtual machines or as new instances of processes on physical machines (either persistent or non-persistent). The benefit of periodic refreshes of system components and services is that it does not require organizations to first determine whether compromises of components or services have occurred (something that may often be difficult to determine). The refresh of selected system components and services occurs with sufficient frequency to prevent the spread or intended impact of attacks, but not with such frequency that it makes the system unstable. Refreshes of critical components and services may be done periodically to hinder the ability of adversaries to exploit optimum windows of vulnerabilities. Related Controls: SC-30 , SC-34 , SI-21. Control Enhancements:

• (1) NON-PERSISTENCE / REFRESH FROM TRUSTED SOURCES

800

5

• Obtain software and data employed during system component and service refreshes from

the following trusted sources: [ Assignment: organization-defined trusted sources ]. Discussion: Trusted sources include software and data from write-once, read-only media or from selected offline secure storage facilities. Related Controls: None.

• (2) NON-PERSISTENCE / NON-PERSISTENT INFORMATION

(a) [ Selection: Refresh [ Assignment: organization-defined information ] [ Assignment: organization-defined frequency ]; Generate [ Assignment: organization-defined information ] on demand ]; and (b) Delete information when no longer needed. Discussion: Retaining information longer than is needed makes the information a potential target for advanced adversaries searching for high value assets to compromise through unauthorized disclosure, unauthorized modification, or exfiltration. For system-related information, unnecessary retention provides advanced adversaries information that can assist in their reconnaissance and lateral movement through the system. Related Controls: None.

• (3) NON-PERSISTENCE / NON-PERSISTENT CONNECTIVITY

Establish connections to the system on demand and terminate connections after [ Selection: completion of a request; a period of non-use ]. Discussion: Persistent connections to systems can provide advanced adversaries with paths to move laterally through systems and potentially position themselves closer to high value assets. Limiting the availability of such connections impedes the adversary’s ability to move freely through organizational systems. Related Controls: SC-10. References: None.

• SI-15 INFORMATION OUTPUT FILTERING

• Control: Validate information output from the following software programs and/or applications

to ensure that the information is consistent with the expected content: [ Assignment: organization-defined software programs and/or applications ]. Discussion: Certain types of attacks, including SQL injections, produce output results that are unexpected or inconsistent with the output results that would be expected from software programs or applications. Information output filtering focuses on detecting extraneous content, preventing such extraneous content from being displayed, and then alerting monitoring tools that anomalous behavior has been discovered. Related Controls: SI-3 , SI-4 , SI-11. Control Enhancements: None.

References: None.

• SI-16 MEMORY PROTECTION

Control: Implement the following controls to protect the system memory from unauthorized code execution: [ Assignment: organization-defined controls ].

Discussion: Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Controls employed to protect memory include data execution prevention and address space layout randomization. Data

800

5

execution prevention controls can either be hardware-enforced or software-enforced with hardware enforcement providing the greater strength of mechanism. Related Controls: AC-25 , SC-3 , SI-7. Control Enhancements: None. References: None.

• SI-17 FAIL-SAFE PROCEDURES

• Control: Implement the indicated fail-safe procedures when the indicated failures occur:

[ Assignment: organization-defined list of failure conditions and associated fail-safe procedures ]. Discussion: Failure conditions include the loss of communications among critical system components or between system components and operational facilities. Fail-safe procedures include alerting operator personnel and providing specific instructions on subsequent steps to take. Subsequent steps may include doing nothing, reestablishing system settings, shutting down processes, restarting the system, or contacting designated organizational personnel. Related Controls: CP-12 , CP-13 , SC-24 , SI-13.

Control Enhancements: None. References: None.

• SI-18 PERSONALLY IDENTIFIABLE INFORMATION QUALITY OPERATIONS

Control:

a. Check the accuracy, relevance, timeliness, and completeness of personally identifiable information across the information life cycle [ Assignment: organization-defined frequency ]; and b. Correct or delete inaccurate or outdated personally identifiable information. Discussion: Personally identifiable information quality operations include the steps that organizations take to confirm the accuracy and relevance of personally identifiable information throughout the information life cycle. The information life cycle includes the creation, collection, use, processing, storage, maintenance, dissemination, disclosure, and disposal of personally identifiable information. Personally identifiable information quality operations include editing and validating addresses as they are collected or entered into systems using automated address verification look-up application programming interfaces. Checking personally identifiable information quality includes the tracking of updates or changes to data over time, which enables organizations to know how and what personally identifiable information was changed should erroneous information be identified. The measures taken to protect personally identifiable information quality are based on the nature and context of the personally identifiable information, how it is to be used, how it was obtained, and the potential de-identification methods employed. The measures taken to validate the accuracy of personally identifiable information used to make determinations about the rights, benefits, or privileges of individuals covered under federal programs may be more comprehensive than the measures used to validate personally identifiable information used for less sensitive purposes. Related Controls: PM-22 , PM-24 , SI-4. Control Enhancements:

• (1) PERSONALLY IDENTIFIABLE INFORMATION QUALITY OPERATIONS / AUTOMATION SUPPORT

800

5

Correct or delete personally identifiable information that is inaccurate or outdated, incorrectly determined regarding impact, or incorrectly de-identified using [ Assignment: organization-defined automated mechanisms ]. Discussion: The use of automated mechanisms to improve data quality may inadvertently create privacy risks. Automated tools may connect to external or otherwise unrelated systems, and the matching of records between these systems may create linkages with unintended consequences. Organizations assess and document these risks in their privacy impact assessments and make determinations that are in alignment with their privacy program plans. As data is obtained and used across the information life cycle, it is important to confirm the accuracy and relevance of personally identifiable information. Automated mechanisms can augment existing data quality processes and procedures and enable an organization to better identify and manage personally identifiable information in large-scale systems. For example, automated tools can greatly improve efforts to consistently normalize data or identify malformed data. Automated tools can also be used to improve the auditing of data and detect errors that may incorrectly alter personally identifiable information or incorrectly associate such information with the wrong individual. Automated capabilities backstop processes and procedures at-scale and enable more fine-grained detection and correction of data quality errors. Related Controls: PM-18 , PM-22 , RA-8.^

• (2) PERSONALLY IDENTIFIABLE INFORMATION QUALITY OPERATIONS / DATA TAGS

Employ data tags to automate the correction or deletion of personally identifiable information across the information life cycle within organizational systems. Discussion: Data tagging personally identifiable information includes tags that note processing permissions, authority to process, de-identification, impact level, information life cycle stage, and retention or last updated dates. Employing data tags for personally identifiable information can support the use of automation tools to correct or delete relevant personally identifiable information. Related Controls: AC-3 , AC-16 , SC-16.

• (3) PERSONALLY IDENTIFIABLE INFORMATION QUALITY OPERATIONS / COLLECTION

Collect personally identifiable information directly from the individual. Discussion: Individuals or their designated representatives can be sources of correct personally identifiable information. Organizations consider contextual factors that may incentivize individuals to provide correct data versus false data. Additional steps may be necessary to validate collected information based on the nature and context of the personally identifiable information, how it is to be used, and how it was obtained. The measures taken to validate the accuracy of personally identifiable information used to make determinations about the rights, benefits, or privileges of individuals under federal programs may be more comprehensive than the measures taken to validate less sensitive personally identifiable information. Related Controls: None.

• (4) PERSONALLY IDENTIFIABLE INFORMATION QUALITY OPERATIONS / INDIVIDUAL REQUESTS

Correct or delete personally identifiable information upon request by individuals or their designated representatives. Discussion: Inaccurate personally identifiable information maintained by organizations may cause problems for individuals, especially in those business functions where inaccurate information may result in inappropriate decisions or the denial of benefits and services to individuals. Even correct information, in certain circumstances, can cause problems for

800

5

individuals that outweigh the benefits of an organization maintaining the information. Organizations use discretion when determining if personally identifiable information is to be corrected or deleted based on the scope of requests, the changes sought, the impact of the changes, and laws, regulations, and policies. Organizational personnel consult with the senior agency official for privacy and legal counsel regarding appropriate instances of correction or deletion. Related Controls: PM-22.

• (5) PERSONALLY IDENTIFIABLE INFORMATION QUALITY OPERATIONS / NOTICE OF CORRECTION OR

• DELETION

Notify [ Assignment: organization-defined recipients of personally identifiable information ] and individuals that the personally identifiable information has been corrected or deleted. Discussion: When personally identifiable information is corrected or deleted, organizations take steps to ensure that all authorized recipients of such information, and the individual with whom the information is associated or their designated representatives, are informed of the corrected or deleted information. Related Controls: None. References: [SP 800-188 ], [IR 8112].

• SI-19 DE-IDENTIFICATION

Control:

• a. Remove the following elements of personally identifiable information from datasets:

[ Assignment: organization-defined elements of personally identifiable information ]; and

b. Evaluate [ Assignment: organization-defined frequency ] for effectiveness of de-identification. Discussion: De-identification is the general term for the process of removing the association between a set of identifying data and the data subject. Many datasets contain information about individuals that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records. Datasets may also contain other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information. Personally identifiable information is removed from datasets by trained individuals when such information is not (or no longer) necessary to satisfy the requirements envisioned for the data. For example, if the dataset is only used to produce aggregate statistics, the identifiers that are not needed for producing those statistics are removed. Removing identifiers improves privacy protection since information that is

• removed cannot be inadvertently disclosed or improperly used. Organizations may be subject to

specific de-identification definitions or methods under applicable laws, regulations, or policies. Re-identification is a residual risk with de-identified data. Re-identification attacks can vary, including combining new datasets or other improvements in data analytics. Maintaining awareness of potential attacks and evaluating for the effectiveness of the de-identification over time support the management of this residual risk. Related Controls: MP-6 , PM-22 , PM-23 , PM-24 , RA-2 , SI-12. Control Enhancements:

• (1) DE-IDENTIFICATION / COLLECTION

De-identify the dataset upon collection by not collecting personally identifiable information. Discussion: If a data source contains personally identifiable information but the information will not be used, the dataset can be de-identified when it is created by not collecting the

800

5

data elements that contain the personally identifiable information. For example, if an organization does not intend to use the social security number of an applicant, then application forms do not ask for a social security number. Related Controls: None.

• (2) DE-IDENTIFICATION / ARCHIVING

Prohibit archiving of personally identifiable information elements if those elements in a dataset will not be needed after the dataset is archived. Discussion: Datasets can be archived for many reasons. The envisioned purposes for the archived dataset are specified, and if personally identifiable information elements are not required, the elements are not archived. For example, social security numbers may have been collected for record linkage, but the archived dataset may include the required elements from the linked records. In this case, it is not necessary to archive the social security numbers. Related Controls: None.

• (3) DE-IDENTIFICATION / RELEASE

Remove personally identifiable information elements from a dataset prior to its release if those elements in the dataset do not need to be part of the data release. Discussion: Prior to releasing a dataset, a data custodian considers the intended uses of the dataset and determines if it is necessary to release personally identifiable information. If the personally identifiable information is not necessary, the information can be removed using de-identification techniques. Related Controls: None.

• (4) DE-IDENTIFICATION / REMOVAL, MASKING, ENCRYPTION, HASHING, OR REPLACEMENT OF DIRECT

• IDENTIFIERS

Remove, mask, encrypt, hash, or replace direct identifiers in a dataset. Discussion: There are many possible processes for removing direct identifiers from a dataset. Columns in a dataset that contain a direct identifier can be removed. In masking, the direct identifier is transformed into a repeating character, such as XXXXXX or 999999. Identifiers can be encrypted or hashed so that the linked records remain linked. In the case of encryption or hashing, algorithms are employed that require the use of a key, including the Advanced Encryption Standard or a Hash-based Message Authentication Code. Implementations may use the same key for all identifiers or use a different key for each identifier. Using a different key for each identifier provides a higher degree of security and privacy. Identifiers can alternatively be replaced with a keyword, including transforming “George Washington” to “PATIENT” or replacing it with a surrogate value, such as transforming “George Washington” to “Abraham Polk.” Related Controls: SC-12 , SC-13.

• (5) DE-IDENTIFICATION / STATISTICAL DISCLOSURE CONTROL

Manipulate numerical data, contingency tables, and statistical findings so that no individual or organization is identifiable in the results of the analysis. Discussion: Many types of statistical analyses can result in the disclosure of information about individuals even if only summary information is provided. For example, if a school that publishes a monthly table with the number of minority students enrolled, reports that it has 10-19 such students in January, and subsequently reports that it has 20-29 such students in March, then it can be inferred that the student who enrolled in February was a minority. Related Controls: None.

800

5

• (6) DE-IDENTIFICATION / DIFFERENTIAL PRIVACY

Prevent disclosure of personally identifiable information by adding non-deterministic noise to the results of mathematical operations before the results are reported. Discussion: The mathematical definition for differential privacy holds that the result of a dataset analysis should be approximately the same before and after the addition or removal of a single data record (which is assumed to be the data from a single individual). In its most basic form, differential privacy applies only to online query systems. However, it can also be used to produce machine-learning statistical classifiers and synthetic data. Differential privacy comes at the cost of decreased accuracy of results, forcing organizations to quantify the trade-off between privacy protection and the overall accuracy, usefulness, and utility of the de-identified dataset. Non-deterministic noise can include adding small, random values to the results of mathematical operations in dataset analysis. Related Controls: SC-12 , SC-13.

• (7) DE-IDENTIFICATION / VALIDATED ALGORITHMS AND SOFTWARE

Perform de-identification using validated algorithms and software that is validated to implement the algorithms. Discussion: Algorithms that appear to remove personally identifiable information from a dataset may in fact leave information that is personally identifiable or data that is re- identifiable. Software that is claimed to implement a validated algorithm may contain bugs or implement a different algorithm. Software may de-identify one type of data, such as integers, but not de-identify another type of data, such as floating point numbers. For these reasons, de-identification is performed using algorithms and software that are validated. Related Controls: None.

• (8) DE-IDENTIFICATION / MOTIVATED INTRUDER

Perform a motivated intruder test on the de-identified dataset to determine if the identified data remains or if the de-identified data can be re-identified. Discussion: A motivated intruder test is a test in which an individual or group takes a data release and specified resources and attempts to re-identify one or more individuals in the

• de-identified dataset. Such tests specify the amount of inside knowledge, computational

resources, financial resources, data, and skills that intruders possess to conduct the tests. A motivated intruder test can determine if the de-identification is insufficient. It can also be a useful diagnostic tool to assess if de-identification is likely to be sufficient. However, the test alone cannot prove that de-identification is sufficient. Related Controls: None. References: [OMB A-130, Appendix II], [SP 800-188 ].

• SI-20 TAINTING

• Control: Embed data or capabilities in the following systems or system components to

determine if organizational data has been exfiltrated or improperly removed from the organization: [ Assignment: organization-defined systems or system components ]. Discussion: Many cyber-attacks target organizational information, or information that the organization holds on behalf of other entities (e.g., personally identifiable information), and exfiltrate that data. In addition, insider attacks and erroneous user procedures can remove information from the system that is in violation of the organizational policies. Tainting approaches can range from passive to active. A passive tainting approach can be as simple as adding false email names and addresses to an internal database. If the organization receives email at one of the false email addresses, it knows that the database has been compromised. Moreover, the organization knows that the email was sent by an unauthorized entity, so any

800

5

packets it includes potentially contain malicious code, and that the unauthorized entity may have potentially obtained a copy of the database. Another tainting approach can include embedding false data or steganographic data in files to enable the data to be found via open-source analysis. Finally, an active tainting approach can include embedding software in the data that is able to “call home,” thereby alerting the organization to its “capture,” and possibly its location, and the path by which it was exfiltrated or removed. Related Controls: AU-13. Control Enhancements: None. References: [OMB A-130, Appendix II], [SP 800-160-2 ].

• SI-21 INFORMATION REFRESH

Control: Refresh [ Assignment: organization-defined information ] at [ Assignment: organization- defined frequencies ] or generate the information on demand and delete the information when no longer needed. Discussion: Retaining information for longer than it is needed makes it an increasingly valuable and enticing target for adversaries. Keeping information available for the minimum period of time needed to support organizational missions or business functions reduces the opportunity for adversaries to compromise, capture, and exfiltrate that information. Related Controls: SI-14. Control Enhancements: None.

References: [OMB A-130 ], [SP 800-160-2 ].

• SI-22 INFORMATION DIVERSITY

Control: a. Identify the following alternative sources of information for [ Assignment: organization- defined essential functions and services ]: [ Assignment: organization-defined alternative information sources ]; and b. Use an alternative information source for the execution of essential functions or services on [ Assignment: organization-defined systems or system components ] when the primary source of information is corrupted or unavailable. Discussion: Actions taken by a system service or a function are often driven by the information it receives. Corruption, fabrication, modification, or deletion of that information could impact the ability of the service function to properly carry out its intended actions. By having multiple sources of input, the service or function can continue operation if one source is corrupted or no longer available. It is possible that the alternative sources of information may be less precise or less accurate than the primary source of information. But having such sub-optimal information sources may still provide a sufficient level of quality that the essential service or function can be carried out, even in a degraded or debilitated manner. Related Controls: None.

Control Enhancements: None. References: [SP 800-160-2 ].

• SI-23 INFORMATION FRAGMENTATION

Control: Based on [ Assignment: organization-defined circumstances ]:

800

5

a. Fragment the following information: [ Assignment: organization-defined information ]; and b. Distribute the fragmented information across the following systems or system components: [ Assignment organization-defined systems or system components ]. Discussion: One objective of the advanced persistent threat is to exfiltrate valuable information. Once exfiltrated, there is generally no way for the organization to recover the lost information. Therefore, organizations may consider dividing the information into disparate elements and distributing those elements across multiple systems or system components and locations. Such actions will increase the adversary’s work factor to capture and exfiltrate the desired information and, in so doing, increase the probability of detection. The fragmentation of information impacts the organization’s ability to access the information in a timely manner. The extent of the fragmentation is dictated by the impact or classification level (and value) of the information, threat intelligence information received, and whether data tainting is used (i.e., data tainting- derived information about the exfiltration of some information could result in the fragmentation of the remaining information). Related Controls: None.

Control Enhancements: None. References: [SP 800-160-2 ].

800

5

Quick link to Supply Chain Risk Management Summary Table

• SR-1 POLICY AND PROCEDURES

Control: a. Develop, document, and disseminate to [ Assignment: organization-defined personnel or roles ]:

1. [ Selection (one or more): organization-level; mission/business process-level; system- level ] supply chain risk management policy that: (a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the supply chain risk management policy and the associated supply chain risk management controls; b. Designate an [ Assignment: organization-defined official ] to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures; and c. Review and update the current supply chain risk management:
3. Policy [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]; and
4. Procedures [ Assignment: organization-defined frequency ] and following [ Assignment: organization-defined events ]. Discussion: Supply chain risk management policy and procedures address the controls in the SR family as well as supply chain-related controls in other families that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of supply chain risk management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission-or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to supply chain risk management policy and procedures include assessment or audit findings, security or privacy incidents, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. Related Controls: PM-9 , PM-30 , PS-8 , SI-12. Control Enhancements: None.

800

5

References: [FASC18], [41 CFR 201], [EO 13873], [SP 800-12 ], [SP 800-30 ], [SP 800-39 ], [SP 800- 100 ], [SP 800-161 ].

• SR-2 SUPPLY CHAIN RISK MANAGEMENT PLAN

Control:

a. Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of the following systems, system components or system services: [ Assignment: organization-defined systems, system components, or system services ]; b. Review and update the supply chain risk management plan [ Assignment: organization- defined frequency ] or as required, to address threat, organizational or environmental changes; and c. Protect the supply chain risk management plan from unauthorized disclosure and modification. Discussion: The dependence on products, systems, and services from external providers, as well as the nature of the relationships with those providers, present an increasing level of risk to an organization. Threat actions that may increase security or privacy risks include unauthorized production, the insertion or use of counterfeits, tampering, theft, insertion of malicious software and hardware, and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system element or component, a system, an organization, a sector, or the Nation. Managing supply chain risk is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders. Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against plans. The SCRM plan (at the system-level) is implementation specific, providing policy implementation, requirements, constraints and implications. It can either be stand-alone, or incorporated into system security and privacy plans. The SCRM plan addresses managing, implementation, and monitoring of SCRM controls and the development/sustainment of systems across the SDLC to support mission and business functions. Because supply chains can differ significantly across and within organizations, SCRM plans are tailored to the individual program, organizational, and operational contexts. Tailored SCRM plans provide the basis for determining whether a technology, service, system component, or system is fit for purpose, and as such, the controls need to be tailored accordingly. Tailored SCRM plans help organizations focus their resources on the most critical mission and business functions based on mission and business requirements and their risk environment. Supply chain risk management plans include an expression of the supply chain risk tolerance for the organization, acceptable supply chain risk mitigation strategies or controls, a process for consistently evaluating and monitoring supply chain risk, approaches for implementing and communicating the plan, a description of and justification for supply chain risk mitigation measures taken, and associated roles and responsibilities. Finally, supply chain risk management plans address requirements for developing trustworthy, secure, privacy-protective, and resilient system components and systems, including the application of the security design principles implemented as part of life cycle-based systems security engineering processes (see SA-8 ).

Related Controls: CA-2 , CP-4 , IR-4 , MA-2 , MA-6 , PE-16 , PL-2 , PM-9 , PM-30 , RA-3 , RA-7 , SA-8 , SI-4. Control Enhancements:

• (1) SUPPLY CHAIN RISK MANAGEMENT PLAN / ESTABLISH SCRM TEAM

800

5

Establish a supply chain risk management team consisting of [ Assignment: organization-

• defined personnel, roles, and responsibilities ] to lead and support the following SCRM

activities: [ Assignment: organization-defined supply chain risk management activities ]. Discussion: To implement supply chain risk management plans, organizations establish a coordinated, team-based approach to identify and assess supply chain risks and manage these risks by using programmatic and technical mitigation techniques. The team approach enables organizations to conduct an analysis of their supply chain, communicate with internal and external partners or stakeholders, and gain broad consensus regarding the appropriate resources for SCRM. The SCRM team consists of organizational personnel with diverse roles and responsibilities for leading and supporting SCRM activities, including risk executive, information technology, contracting, information security, privacy, mission or business, legal, supply chain and logistics, acquisition, business continuity, and other relevant functions. Members of the SCRM team are involved in various aspects of the SDLC and, collectively, have an awareness of and provide expertise in acquisition processes, legal practices, vulnerabilities, threats, and attack vectors, as well as an understanding of the technical aspects and dependencies of systems. The SCRM team can be an extension of the security and privacy risk management processes or be included as part of an organizational risk management team. Related Controls: None. References: [FASC18], [41 CFR 201], [EO 13873], [SP 800-30 ], [SP 800-39 ], [SP-800-160-1 ], [SP 800-161 ], [IR 7622], [IR 8272].

• SR-3 SUPPLY CHAIN CONTROLS AND PROCESSES

Control: a. Establish a process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes of [ Assignment: organization-defined system or system component] in coordination with [ Assignment: organization-defined supply chain personnel ];

• b. Employ the following controls to protect against supply chain risks to the system, system

component, or system service and to limit the harm or consequences from supply chain- related events: [ Assignment: organization-defined supply chain controls ]; and c. Document the selected and implemented supply chain processes and controls in [ Selection: security and privacy plans; supply chain risk management plan; [ Assignment: organization- defined document ]]. Discussion: Supply chain elements include organizations, entities, or tools employed for the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, and firmware development processes; shipping and handling procedures; personnel security and physical security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components. Supply chain elements and processes may be provided by organizations, system integrators, or external providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to cause harm to the organization and affect its ability to carry out its core missions or business functions. Supply chain personnel are individuals with roles and responsibilities in the supply chain. Related Controls: CA-2 , MA-2 , MA-6 , PE-3 , PE-16 , PL-8 , PM-30 , SA-2 , SA-3 , SA-4 , SA-5 , SA-8 , SA-9 , SA-10 , SA-15 , SC-7 , SC-29 , SC-30 , SC-38 , SI-7 , SR-6 , SR-9 , SR-11. Control Enhancements:

800

5

• (1) SUPPLY CHAIN CONTROLS AND PROCESSES / DIVERSE SUPPLY BASE

• Employ a diverse set of sources for the following system components and services:

[ Assignment: organization-defined system components and services ]. Discussion: Diversifying the supply of systems, system components, and services can reduce the probability that adversaries will successfully identify and target the supply chain and can reduce the impact of a supply chain event or compromise. Identifying multiple suppliers for replacement components can reduce the probability that the replacement component will become unavailable. Employing a diverse set of developers or logistics service providers can reduce the impact of a natural disaster or other supply chain event. Organizations consider designing the system to include diverse materials and components. Related Controls: None.

• (2) SUPPLY CHAIN PROTECTION CONTROLS AND PROCESSES / LIMITATION OF HARM

• Employ the following controls to limit harm from potential adversaries identifying and

targeting the organizational supply chain: [ Assignment: organization-defined controls ]. Discussion: Controls that can be implemented to reduce the probability of adversaries successfully identifying and targeting the supply chain include avoiding the purchase of custom or non-standardized configurations, employing approved vendor lists with standing reputations in industry, following pre-agreed maintenance schedules and update and patch delivery mechanisms, maintaining a contingency plan in case of a supply chain event, using procurement carve-outs that provide exclusions to commitments or obligations, using diverse delivery routes, and minimizing the time between purchase decisions and delivery. Related Controls: None.

• (3) SUPPLY CHAIN PROTECTION CONTROLS AND PROCESSES / SUB-TIER FLOW DOWN

Ensure that the controls included in the contracts of prime contractors are also included in the contracts of subcontractors. Discussion: To manage supply chain risk effectively and holistically, it is important that organizations ensure that supply chain risk management controls are included at all tiers in the supply chain. This includes ensuring that Tier 1 (prime) contractors have implemented processes to facilitate the “flow down” of supply chain risk management controls to sub-tier contractors. The controls subject to flow down are identified in SR-3b. Related Controls: SR-5 , SR-8.

References: [FASC18], [41 CFR 201], [EO 13873], [ISO 20243], [SP 800-30 ], [SP 800-161 ], [IR 7622 ].

• SR-4 PROVENANCE

• Control: Document, monitor, and maintain valid provenance of the following systems, system

components, and associated data: [ Assignment: organization-defined systems, system components, and associated data ]. Discussion: Every system and system component has a point of origin and may be changed throughout its existence. Provenance is the chronology of the origin, development, ownership, location, and changes to a system or system component and associated data. It may also include personnel and processes used to interact with or make modifications to the system, component, or associated data. Organizations consider developing procedures (see SR-1 ) for allocating responsibilities for the creation, maintenance, and monitoring of provenance for systems and system components; transferring provenance documentation and responsibility between organizations; and preventing and monitoring for unauthorized changes to the provenance records. Organizations have methods to document, monitor, and maintain valid provenance baselines for systems, system components, and related data. These actions help track, assess,

800

5

and document any changes to the provenance, including changes in supply chain elements or configuration, and help ensure non-repudiation of provenance information and the provenance change records. Provenance considerations are addressed throughout the system development life cycle and incorporated into contracts and other arrangements, as appropriate. Related Controls: CM-8 , MA-2 , MA-6 , RA-9 , SA-3 , SA-8 , SI-4.

Control Enhancements:

• (1) PROVENANCE / IDENTITY

Establish and maintain unique identification of the following supply chain elements,

• processes, and personnel associated with the identified system and critical system

components: [ Assignment: organization-defined supply chain elements, processes, and personnel associated with organization-defined systems and critical system components ]. Discussion: Knowing who and what is in the supply chains of organizations is critical to gaining visibility into supply chain activities. Visibility into supply chain activities is also important for monitoring and identifying high-risk events and activities. Without reasonable visibility into supply chains elements, processes, and personnel, it is very difficult for organizations to understand and manage risk and reduce their susceptibility to adverse events. Supply chain elements include organizations, entities, or tools used for the research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of systems and system components. Supply chain processes include development processes for hardware, software, and firmware; shipping and handling procedures; configuration management tools, techniques, and measures to maintain provenance; personnel and physical security programs; or other programs, processes, or procedures associated with the production and distribution of supply chain elements. Supply chain personnel are individuals with specific roles and responsibilities related to the secure the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of a system or system component. Identification methods are sufficient to support an investigation in case of a supply chain change (e.g. if a supply company is purchased), compromise, or event. Related Controls: IA-2 , IA-8 , PE-16.

• (2) PROVENANCE / TRACK AND TRACE

Establish and maintain unique identification of the following systems and critical system components for tracking through the supply chain: [ Assignment: organization-defined systems and critical system components ]. Discussion: Tracking the unique identification of systems and system components during development and transport activities provides a foundational identity structure for the establishment and maintenance of provenance. For example, system components may be labeled using serial numbers or tagged using radio-frequency identification tags. Labels and tags can help provide better visibility into the provenance of a system or system component. A system or system component may have more than one unique identifier. Identification methods are sufficient to support a forensic investigation after a supply chain compromise or event. Related Controls: IA-2 , IA-8 , PE-16 , PL-2.

• (3) PROVENANCE / VALIDATE AS GENUINE AND NOT ALTERED

Employ the following controls to validate that the system or system component received is genuine and has not been altered: [ Assignment: organization-defined controls ]. Discussion: For many systems and system components, especially hardware, there are technical means to determine if the items are genuine or have been altered, including optical and nanotechnology tagging, physically unclonable functions, side-channel analysis,

800

5

cryptographic hash verifications or digital signatures, and visible anti-tamper labels or stickers. Controls can also include monitoring for out of specification performance, which can be an indicator of tampering or counterfeits. Organizations may leverage supplier and contractor processes for validating that a system or component is genuine and has not been altered and for replacing a suspect system or component. Some indications of tampering may be visible and addressable before accepting delivery, such as inconsistent packaging, broken seals, and incorrect labels. When a system or system component is suspected of being altered or counterfeit, the supplier, contractor, or original equipment manufacturer may be able to replace the item or provide a forensic capability to determine the origin of the counterfeit or altered item. Organizations can provide training to personnel on how to identify suspicious system or component deliveries. Related Controls: AT-3 , SR-9 , SR-10 , SR-11.

• (4) PROVENANCE / SUPPLY CHAIN INTEGRITY — PEDIGREE

Employ [ Assignment: organization-defined controls ] and conduct [ Assignment: organization-defined analysis ] to ensure the integrity of the system and system components by validating the internal composition and provenance of critical or mission- essential technologies, products, and services. Discussion: Authoritative information regarding the internal composition of system components and the provenance of technology, products, and services provides a strong basis for trust. The validation of the internal composition and provenance of technologies, products, and services is referred to as the pedigree. For microelectronics, this includes material composition of components. For software this includes the composition of open- source and proprietary code, including the version of the component at a given point in time. Pedigrees increase the assurance that the claims suppliers assert about the internal composition and provenance of the products, services, and technologies they provide are valid. The validation of the internal composition and provenance can be achieved by various evidentiary artifacts or records that manufacturers and suppliers produce during the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of technology, products, and services. Evidentiary artifacts include, but are not limited to, software identification (SWID) tags, software component inventory, the manufacturers’ declarations of platform attributes (e.g., serial numbers, hardware component inventory), and measurements (e.g., firmware hashes) that are tightly bound to the hardware itself. Related Controls: RA-3. References: [FASC18], [41 CFR 201], [EO 13873], [ISO 27036], [ISO 20243], [SP 800-160-1 ], [SP 800-161 ], [IR 7622], [IR 8112], [IR 8272].

• SR-5 ACQUISITION STRATEGIES, TOOLS, AND METHODS

• Control: Employ the following acquisition strategies, contract tools, and procurement methods

to protect against, identify, and mitigate supply chain risks: [ Assignment: organization-defined acquisition strategies, contract tools, and procurement methods ]. Discussion: The use of the acquisition process provides an important vehicle to protect the supply chain. There are many useful tools and techniques available, including obscuring the end use of a system or system component, using blind or filtered buys, requiring tamper-evident packaging, or using trusted or controlled distribution. The results from a supply chain risk assessment can guide and inform the strategies, tools, and methods that are most applicable to the situation. Tools and techniques may provide protections against unauthorized production, theft, tampering, insertion of counterfeits, insertion of malicious software or backdoors, and poor development practices throughout the system development life cycle. Organizations also

800

5

consider providing incentives for suppliers who implement controls, promote transparency into their processes and security and privacy practices, provide contract language that addresses the prohibition of tainted or counterfeit components, and restrict purchases from untrustworthy suppliers. Organizations consider providing training, education, and awareness programs for personnel regarding supply chain risk, available mitigation strategies, and when the programs should be employed. Methods for reviewing and protecting development plans, documentation, and evidence are commensurate with the security and privacy requirements of the organization. Contracts may specify documentation protection requirements. Related Controls: AT-3 , SA-2 , SA-3 , SA-4 , SA-5 , SA-8 , SA-9 , SA-10 , SA-15 , SR-6 , SR-9 , SR-10 , SR-11. Control Enhancements:

• (1) ACQUISITION STRATEGIES, TOOLS, AND METHODS / ADEQUATE SUPPLY

Employ the following controls to ensure an adequate supply of [ Assignment: organization- defined critical system components ]: [ Assignment: organization-defined controls ]. Discussion: Adversaries can attempt to impede organizational operations by disrupting the supply of critical system components or corrupting supplier operations. Organizations may track systems and component mean time to failure to mitigate the loss of temporary or permanent system function. Controls to ensure that adequate supplies of critical system components include the use of multiple suppliers throughout the supply chain for the identified critical components, stockpiling spare components to ensure operation during mission-critical times, and the identification of functionally identical or similar components that may be used, if necessary. Related Controls: RA-9.

• (2) ACQUISITION STRATEGIES, TOOLS, AND METHODS / ASSESSMENTS PRIOR TO SELECTION,

• ACCEPTANCE, MODIFICATION, OR UPDATE

Assess the system, system component, or system service prior to selection, acceptance, modification, or update. Discussion: Organizational personnel or independent, external entities conduct assessments of systems, components, products, tools, and services to uncover evidence of tampering, unintentional and intentional vulnerabilities, or evidence of non-compliance with supply chain controls. These include malicious code, malicious processes, defective software, backdoors, and counterfeits. Assessments can include evaluations; design proposal reviews; visual or physical inspection; static and dynamic analyses; visual, x-ray, or magnetic particle inspections; simulations; white, gray, or black box testing; fuzz testing; stress testing; and penetration testing (see SR-6( 1 )). Evidence generated during assessments is documented for follow-on actions by organizations. The evidence generated during the organizational or independent assessments of supply chain elements may be used to improve supply chain processes and inform the supply chain risk management process. The evidence can be leveraged in follow-on assessments. Evidence and other documentation may be shared in accordance with organizational agreements. Related Controls: CA-8 , RA-5 , SA-11 , SI-7 , SR-9. References: [FASC18], [41 CFR 201], [EO 13873], [ISO 27036], [ISO 20243], [SP 800-30 ], [SP 800- 161 ], [IR 7622], [IR 8272].

• SR-6 SUPPLIER ASSESSMENTS AND REVIEWS

Control: Assess and review the supply chain-related risks associated with suppliers or contractors and the system, system component, or system service they provide [ Assignment: organization-defined frequency ].

800

5

Discussion: An assessment and review of supplier risk includes security and supply chain risk management processes, foreign ownership, control or influence (FOCI), and the ability of the supplier to effectively assess subordinate second-tier and third-tier suppliers and contractors. The reviews may be conducted by the organization or by an independent third party. The reviews consider documented processes, documented controls, all-source intelligence, and publicly available information related to the supplier or contractor. Organizations can use open-source information to monitor for indications of stolen information, poor development and quality control practices, information spillage, or counterfeits. In some cases, it may be appropriate or required to share assessment and review results with other organizations in accordance with any applicable rules, policies, or inter-organizational agreements or contracts.

Related Controls: SR-3 , SR-5. Control Enhancements:

• (1) SUPPLIER ASSESSMENTS AND REVIEWS / TESTING AND ANALYSIS

Employ [ Selection (one or more): organizational analysis, independent third-party analysis, organizational testing, independent third-party testing ] of the following supply chain elements, processes, and actors associated with the system, system component, or system service: [ Assignment: organization-defined supply chain elements, processes, and actors ]. Discussion: Relationships between entities and procedures within the supply chain, including development and delivery, are considered. Supply chain elements include organizations, entities, or tools that are used for the research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of systems, system components, or system services. Supply chain processes include supply chain risk management programs; SCRM strategies and implementation plans; personnel and physical security programs; hardware, software, and firmware development processes; configuration management tools, techniques, and measures to maintain provenance; shipping and handling procedures; and programs, processes, or procedures associated with the production and distribution of supply chain elements. Supply chain actors are individuals with specific roles and responsibilities in the supply chain. The evidence generated and collected during analyses and testing of supply chain elements, processes, and actors is documented and used to inform organizational risk management activities and decisions. Related Controls: CA-8 , SI-4. References: [FASC18], [41 CFR 201], [EO 13873], [ISO 27036], [ISO 20243], [FIPS 140-3 ], [FIPS 180-4 ], [FIPS 186-4 ], [FIPS 202], [SP 800-30 ], [SP 800-161 ], [IR 7622], [IR 8272].

• SR-7 SUPPLY CHAIN OPERATIONS SECURITY

• Control: Employ the following Operations Security (OPSEC) controls to protect supply chain-

related information for the system, system component, or system service: [ Assignment: organization-defined Operations Security (OPSEC) controls ].

Discussion: Supply chain OPSEC expands the scope of OPSEC to include suppliers and potential suppliers. OPSEC is a process that includes identifying critical information, analyzing friendly actions related to operations and other activities to identify actions that can be observed by potential adversaries, determining indicators that potential adversaries might obtain that could be interpreted or pieced together to derive information in sufficient time to cause harm to organizations, implementing safeguards or countermeasures to eliminate or reduce exploitable vulnerabilities and risk to an acceptable level, and considering how aggregated information may expose users or specific uses of the supply chain. Supply chain information includes user identities; uses for systems, system components, and system services; supplier identities; security and privacy requirements; system and component configurations; supplier processes; design specifications; and testing and evaluation results. Supply chain OPSEC may require

800

5

organizations to withhold mission or business information from suppliers and may include the use of intermediaries to hide the end use or users of systems, system components, or system services. Related Controls: SC-38. Control Enhancements: None.

References: [EO 13873], [SP 800-30 ], [ISO 27036], [SP 800-161 ], [IR 7622].

• SR-8 NOTIFICATION AGREEMENTS

Control: Establish agreements and procedures with entities involved in the supply chain for the system, system component, or system service for the [ Selection (one or more): notification of supply chain compromises; results of assessments or audits; [ Assignment: organization-defined information ]]. Discussion: The establishment of agreements and procedures facilitates communications among supply chain entities. Early notification of compromises and potential compromises in the supply chain that can potentially adversely affect or have adversely affected organizational systems or system components is essential for organizations to effectively respond to such incidents. The results of assessments or audits may include open-source information that contributed to a decision or result and could be used to help the supply chain entity resolve a concern or improve its processes. Related Controls: IR-4 , IR-6 , IR-8.

Control Enhancements: None. References: [FASC18], [41 CFR 201], [EO 13873], [ISO 27036], [SP 800-30 ], [SP 800-161 ], [IR 7622 ].

• SR-9 TAMPER RESISTANCE AND DETECTION

Control: Implement a tamper protection program for the system, system component, or system service. Discussion: Anti-tamper technologies, tools, and techniques provide a level of protection for systems, system components, and services against many threats, including reverse engineering, modification, and substitution. Strong identification combined with tamper resistance and/or tamper detection is essential to protecting systems and components during distribution and when in use. Related Controls: PE-3 , PM-30 , SA-15 , SI-4 , SI-7 , SR-3 , SR-4 , SR-5 , SR-10 , SR-11. Control Enhancements:

• (1) TAMPER RESISTANCE AND DETECTION / MULTIPLE STAGES OF SYSTEM DEVELOPMENT LIFE CYCLE

Employ anti-tamper technologies, tools, and techniques throughout the system development life cycle. Discussion: The system development life cycle includes research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal. Organizations use a combination of hardware and software techniques for tamper resistance and detection. Organizations use obfuscation and self-checking to make reverse engineering and modifications more difficult, time-consuming, and expensive for adversaries. The customization of systems and system components can make substitutions easier to detect and therefore limit damage. Related Controls: SA-3.

800

5

References: [ISO 20243].

• SR-10 INSPECTION OF SYSTEMS OR COMPONENTS

• Control: Inspect the following systems or system components [ Selection (one or more): at

random; at [ Assignment: organization-defined frequency ], upon [ Assignment: organization- defined indications of need for inspection ]] to detect tampering: [ Assignment: organization- defined systems or system components ]. Discussion: The inspection of systems or systems components for tamper resistance and detection addresses physical and logical tampering and is applied to systems and system components removed from organization-controlled areas. Indications of a need for inspection include changes in packaging, specifications, factory location, or entity in which the part is purchased, and when individuals return from travel to high-risk locations. Related Controls: AT-3 , PM-30 , SI-4 , SI-7 , SR-3 , SR-4 , SR-5 , SR-9 , SR-11. References: [ISO 20243].

• SR-11 COMPONENT AUTHENTICITY

Control: a. Develop and implement anti-counterfeit policy and procedures that include the means to detect and prevent counterfeit components from entering the system; and b. Report counterfeit system components to [ Selection (one or more): source of counterfeit component; [ Assignment: organization-defined external reporting organizations ] ; [ Assignment: organization-defined personnel or roles ]]. Discussion: Sources of counterfeit components include manufacturers, developers, vendors, and contractors. Anti-counterfeiting policies and procedures support tamper resistance and provide a level of protection against the introduction of malicious code. External reporting organizations include CISA. Related Controls: PE-3 , SA-4 , SI-7 , SR-9 , SR-10. Control Enhancements:

• (1) COMPONENT AUTHENTICITY / ANTI-COUNTERFEIT TRAINING

Train [ Assignment: organization-defined personnel or roles ] to detect counterfeit system components (including hardware, software, and firmware). Discussion: None. Related Controls: AT-3.

• (2) COMPONENT AUTHENTICITY / CONFIGURATION CONTROL FOR COMPONENT SERVICE AND REPAIR

• Maintain configuration control over the following system components awaiting service or

repair and serviced or repaired components awaiting return to service: [ Assignment: organization-defined system components ]. Discussion: None. Related Controls: CM-3 , MA-2 , MA-4 , SA-10.

• (3) COMPONENT AUTHENTICITY / ANTI-COUNTERFEIT SCANNING

Scan for counterfeit system components [ Assignment: organization-defined frequency ]. Discussion: The type of component determines the type of scanning to be conducted (e.g., web application scanning if the component is a web application). Related Controls: RA-5.

800

5

References: [ISO 20243].

• SR-12 COMPONENT DISPOSAL

Control: Dispose of [ Assignment: organization-defined data, documentation, tools, or system components ] using the following techniques and methods: [ Assignment: organization-defined techniques and methods ]. Discussion: Data, documentation, tools, or system components can be disposed of at any time during the system development life cycle (not only in the disposal or retirement phase of the life cycle). For example, disposal can occur during research and development, design, prototyping, or operations/maintenance and include methods such as disk cleaning, removal of cryptographic keys, partial reuse of components. Opportunities for compromise during disposal affect physical and logical data, including system documentation in paper-based or digital files; shipping and delivery documentation; memory sticks with software code; or complete routers or servers that include permanent media, which contain sensitive or proprietary information. Additionally, proper disposal of system components helps to prevent such components from entering the gray market. Related Controls: MP-6. References: None.