SA-17 Developer Security Architecture and Design (H)

NIST SP 800-53 (r4) Control:

The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:

a. Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture;

b. Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and

c. Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.

NIST 800-53 (r4) Supplemental Guidance:

This control is primarily directed at external developers, although it could also be used for internal (in-house) development. In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations develop an information security architecture and such security architecture is integrated or tightly coupled to the enterprise architecture. This distinction is important if/when organizations outsource the development of information systems, information system components, or information system services to external entities, and there is a requirement to demonstrate consistency with the organization’s enterprise architecture and information security architecture. Related controls: PL-8, PM-7, SA-3, SA-8.

NIST 800-53 (r5) 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 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.

38North Guidance:

Meets Minimum Requirement:

• • Develop and design a security architecture that is consistent with the organization's production environment and describes the security functions and controls implemented by establishing standard templates for developer to use. The security architecture design should mirror the design established in PL-8.

Best Practice:

• • None.

Unofficial FedRAMP Guidance:

• • None.

Assessment Evidence:

• • Provide evidence that describes the developer security architecture.

CSP Implementation Tips:

• • Amazon Web Services (AWS): Introduction to Security by Design (https://aws.amazon.com/compliance/security-by-design/)

  • Microsoft Azure: Azure Architecture Center (https://docs.microsoft.com/en-us/azure/architecture/)

  • Google Cloud Platform: Google Cloud Architecture Framework (https://cloud.google.com/architecture/framework)