SA-17: Developer Security Architecture And Design
Control Family:
CSF v1.1 References:
Baselines:
- Low
N/A
- Moderate
N/A
- High
- SA-17
Next Version:
- NIST Special Publication 800-53 Revision 5:
- SA-17: Developer Security and Privacy Architecture and Design
Control Statement
The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:
- 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;
- Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and
- Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.
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.
Control Enhancements
SA-17(1): Formal Policy Model
Baseline(s):
The organization requires the developer of the information system, system component, or information 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 policy] to be enforced; and Prove that the formal policy model is internally consistent and sufficient to enforce…
SA-17(2): Security-Relevant Components
Baseline(s):
The organization requires the developer of the information system, system component, or information 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):
The organization requires the developer of the information system, system component, or information 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…
SA-17(4): Informal Correspondence
Baseline(s):
The organization requires the developer of the information system, system component, or information 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 [Selection: informal demonstration, convincing argument…
SA-17(5): Conceptually Simple Design
Baseline(s):
The organization requires the developer of the information system, system component, or information 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):
The organization requires the developer of the information system, system component, or information system service to structure security-relevant hardware, software, and firmware to facilitate testing.
SA-17(7): Structure For Least Privilege
Baseline(s):
The organization requires the developer of the information system, system component, or information system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.