3.15 Planning

Statement

• Develop a security architecture for the system that:

  • Describes the security requirements and approach to be taken for protecting the confidentiality, integrity, and availability of CUI,

  • Describes how the architecture is integrated into and supports the enterprise architecture, and

  • Describes any assumptions about, and dependencies on, external systems and services.

• Review and update the security architecture {{ insert: param, A.03.15.01E.ODP.01 }} to reflect changes in the enterprise architecture.

• Reflect planned security architecture changes in system security plans, concept of operations, criticality analysis, organizational procedures, and procurements and acquisitions.

Guidance

The security architecture at the system level is consistent with the organization-wide security architecture, which is integral to and developed as part of the enterprise architecture. The security architecture includes an architectural description, the allocation of security functionality (i.e., safeguards and countermeasures), security-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. The architectures can also include other information, such as user roles and the access privileges assigned to each role; security requirements; types of information processed, stored, and transmitted by the system; cybersecurity supply chain risk management (CSCRM) requirements; restoration priorities of information and system services; and other protection needs. With the use of modern computing technologies, it is becoming less common for organizations to control all information resources. There may be key dependencies on external services and service providers. Describing such dependencies as part of the security architecture is necessary for developing a comprehensive CUI protection strategy. Establishing, documenting, and maintaining a baseline configuration for organizational systems under configuration control is critical to implementing and maintaining an effective security architecture. Guidance on developing trustworthy, secure, and cyber-resilient systems using systems security engineering practices and security design concepts is provided in SP 800-160v2 .23. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171.

Statement

• (includes preempt) Ensure that the threat event does not have an impact.

  • Reduce likelihood of occurrence and/or reduce likelihood of impact.

  • The adversary’s efforts or resources cannot be applied or are wasted.

• (includes exert) Make it more difficult for threat events to cause adverse impacts or consequences.

  • Reduce likelihood of impact and reduce level of impact.

  • Adversary activities are restricted in scope, fail to achieve full effect, do not take place in accordance with adversary timeline, or require greater resources than adversary had planned.

Assessment objective

a security architecture for the system that describes the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of CUI is developed.

Assessment objective

a security architecture for the system that describes how the security architecture is integrated into and supports the enterprise architecture is developed.

Assessment objective

a security architecture for the system that describes any assumptions about and dependencies on external systems and services is developed.

Assessment objective

the security architecture is reviewed and updated {{ insert: param, A.03.15.01E.ODP.01 }} to reflect changes in the enterprise architecture.

Assessment objective

planned security architecture changes are reflected in system security plans, concept of operations, criticality analyses, organizational procedures, procurements, and acquisitions.

Assessment method

• Security planning policy procedures addressing information security architecture development procedures addressing information security architecture reviews and updates enterprise architecture documentation information security architecture documentation system security plan security CONOPS for the system records of information security architecture reviews and updates other relevant documents or records

Assessment method

• Personnel with security planning and plan implementation responsibilities personnel with information security responsibilities personnel with information security architecture development responsibilities

Assessment method

• Mechanisms supporting and/or implementing the development, review, and update of the information security architecture processes for developing, reviewing, and updating the information security architecture

Statement

• Design the security architecture for the system using a defense-in-depth approach.

• Allocate {{ insert: param, A.03.15.02E.ODP.01 }} to {{ insert: param, A.03.15.02E.ODP.02 }}.

• Ensure that the allocated requirements operate in a coordinated and mutually reinforcing manner.

Guidance

Organizations strategically allocate security requirements and the associated protection mechanisms in the security architecture so that adversaries must overcome multiple defensive layers to achieve their objective. Requiring adversaries to defeat multiple defensive layers makes it more difficult to attack systems by increasing the work factor of the adversary. It also increases the likelihood of detection. Defense-in-depth architectural approaches include modularity and layering, the separation of system and user functionality, and security function isolation. The coordination of allocated security requirements is essential to help ensure that an attack that involves one requirement does not create adverse, unintended consequences (e.g., system lockout and cascading alarms) by interfering with other requirements. The value of organizational assets and the impacts or consequences of loss are important considerations in providing additional defensive layers. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets.

Statement

• (includes preempt) Ensure that the threat event does not have an impact.

  • Reduce likelihood of occurrence and/or reduce likelihood of impact.

  • The adversary’s efforts or resources cannot be applied or are wasted.

• (includes exert) Make it more difficult for threat events to cause adverse impacts or consequences.

  • Reduce likelihood of impact and reduce level of impact.

  • Adversary activities are restricted in scope, fail to achieve full effect, do not take place in accordance with adversary timeline, or require greater resources than adversary had planned.

• (includes reduce) Restrict the consequences of realized threat events by limiting the damage or effects they cause in terms of time, system resources, and/or mission or business impacts.

  • Reduce level of impact and reduce likelihood of impact of subsequent events in the same threat scenario.

  • The adversary’s effectiveness is restricted.

Assessment objective

the security architecture for the system is designed using a defense-in-depth approach.

Assessment objective

{{ insert: param, A.03.15.02E.ODP.01 }} are allocated to {{ insert: param, A.03.15.02E.ODP.02 }} .

Assessment objective

the security requirements allocated to the architectural layers and locations are coordinated and mutually reinforcing.

Assessment method

• Security planning policy procedures addressing information security architecture development enterprise architecture documentation information security architecture documentation system security plan security CONOPS for the system other relevant documents or records

Assessment method

• Personnel with information security responsibilities personnel with information security architecture development responsibilities personnel with security planning and plan implementation responsibilities

Assessment method

• Processes for designing the information security architecture mechanisms supporting and/or implementing the design of the information security architecture

Statement

Require that {{ insert: param, A.03.15.03E.ODP.01 }} allocated to {{ insert: param, A.03.15.03E.ODP.02 }} are obtained from different suppliers.

Guidance

Information technology products have different strengths and weaknesses. Providing a broad spectrum of products complements the individual offerings. For example, vendors that offer malicious code protection typically update their products at different times and develop solutions for known viruses, Trojans, or worms based on their priorities and development schedules. Deploying different types of products from a diversity of suppliers at different locations increases the likelihood that at least one of the products will detect the malicious code. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets.

Statement

• (includes preempt and negate) Ensure that the threat event does not have an impact.

  • Reduce likelihood of occurrence and/or reduce likelihood of impact.

  • The adversary’s efforts or resources cannot be applied or are wasted.

• (includes exert) Make it more difficult for threat events to cause adverse impacts or consequences.

  • Reduce likelihood of impact and reduce level of impact.

  • Adversary activities are restricted in scope, fail to achieve full effect, do not take place in accordance with adversary timeline, or require greater resources than adversary had planned.

• (includes reduce) Restrict the consequences of realized threat events by limiting the damage or effects they cause in terms of time, system resources, and/or mission or business impacts.

  • Reduce level of impact and reduce likelihood of impact of subsequent events in the same threat scenario.

  • The adversary’s effectiveness is restricted.

Assessment objective

{{ insert: param, A.03.15.03E.ODP.01 }} that are allocated to {{ insert: param, A.03.15.03E.ODP.02 }} are obtained from different suppliers.

Assessment method

• Security planning policy procedures addressing information security architecture development enterprise architecture documentation information security architecture documentation system security plan security CONOPS for the system IT acquisitions policy other relevant documents or records

Assessment method

• Personnel with acquisition responsibilities personnel with information security responsibilities personnel with security planning and plan implementation responsibilities personnel with information security architecture development responsibilities

Assessment method

• Processes for obtaining information security safeguards from different suppliers