SA-17 Developer Security and Privacy Architecture and Design
System and Services Acquisition
Description
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.
Supplemental Guidance
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.
Changes from Rev 4
No significant changes from Rev 4.
Enhancements (9)
What NIST adds to this control. Select one to read its statement.
SA-17(01) 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.
SA-17(02) 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.
SA-17(03) 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; 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.
SA-17(04) 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 (one): 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.
SA-17(05) Conceptually Simple Design
Require the developer of the system, system component, or system service to: 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.
SA-17(06) 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.
SA-17(07) 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.
SA-17(08) 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].
SA-17(09) 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.
Patterns that use this control (2)
Grouped by the emphasis each pattern gives it.
MITRE ATT&CK Techniques (7)
ATT&CK v16.1Techniques mitigated by this control, mapped via CTID.