SA-17: Developer Security and Privacy Architecture and Design
Control Family:
CSF v1.1 References:
Baselines:
- Low
N/A
- Moderate
N/A
- High
- SA-17
- Privacy
N/A
Previous Version:
- NIST Special Publication 800-53 Revision 4:
- SA-17: Developer Security Architecture And Design
Control Statement
Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:
- Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;
- Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and
- 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.
Control Enhancements
SA-17(1): Formal Policy Model
Baseline(s):
Require the developer of the system, system component, or system service to: 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 Prove that the formal policy model is internally consistent and sufficient to enforce the defined…
SA-17(2): Security-relevant Components
Baseline(s):
Require the developer of the system, system component, or system service to: Define security-relevant hardware, software, and firmware; and Provide a rationale that the definition for security-relevant hardware, software, and firmware is complete.
SA-17(3): Formal Correspondence
Baseline(s):
Require the developer of the system, system component, or system service to: 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; Show via proof to the extent feasible with additional informal demonstration as…
SA-17(4): Informal Correspondence
Baseline(s):
Require the developer of the system, system component, or system service to: 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; Show via [Assignment: informal demonstration, convincing argument with formal methods as…
SA-17(5): Conceptually Simple Design
Baseline(s):
Require the developer of the system, system component, or system service to: Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism.
SA-17(6): Structure for Testing
Baseline(s):
Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing.
SA-17(7): Structure for Least Privilege
Baseline(s):
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(8): Orchestration
Baseline(s):
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(9): Design Diversity
Baseline(s):
Use different designs for [Assignment: organization-defined critical systems or system components] to satisfy a common set of requirements or to provide equivalent functionality.