Navigate

SA-17

SA-17: Developer Security Architecture And Design

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

SA-17a.: 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;

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

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

Supplemental

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.

CIA Levels
Confidentiality	high
Integrity	high
Availability	high

Overlays
Privacy (High), Privacy (Low), Privacy (Mod)

Related Controls

The controls below (if any) were marked by NIST as being related to SA-17.

Control	Description
PL-8	The organization: PL-8a.: Develops an information security architecture for the information system that: PL-8a.1.: Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information; PL-8a.2.: Describes how the information security architecture is integrated into and supports the enterprise architecture; and PL-8a.3.: Describes any information security assumptions about, and dependencies on, external services; PL-8b.: Reviews and updates the information security architecture [Assignment: organization-defined frequency] to reflect updates in the enterprise architecture; and PL-8c.: Ensures that planned information security architecture changes are reflected in the security plan, the security Concept of Operations (CONOPS), and organizational procurements/acquisitions.
PM-7	The organization develops an enterprise architecture with consideration for information security and the resulting risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.
SA-3	The organization: SA-3a.: Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations; SA-3b.: Defines and documents information security roles and responsibilities throughout the system development life cycle; SA-3c.: Identifies individuals having information security roles and responsibilities; and SA-3d.: Integrates the organizational information security risk management process into system development life cycle activities.
SA-8	The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system.

Enhancements

The controls below (if any) add on to the requirements of SA-17.

Control	Description
SA-17 (1)	The organization requires the developer of the information system, system component, or information system service to: SA-17 (1)(a): 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 SA-17 (1)(b): Prove that the formal policy model is internally consistent and sufficient to enforce the defined elements of the organizational security policy when implemented.
SA-17 (2)	The organization requires the developer of the information system, system component, or information system service to: SA-17 (2)(a): Define security-relevant hardware, software, and firmware; and SA-17 (2)(b): Provide a rationale that the definition for security-relevant hardware, software, and firmware is complete.
SA-17 (3)	The organization requires the developer of the information system, system component, or information system service to: SA-17 (3)(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; SA-17 (3)(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; SA-17 (3)(c): Show via informal demonstration, that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware; SA-17 (3)(d): Show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware; and SA-17 (3)(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 (4)	The organization requires the developer of the information system, system component, or information system service to: SA-17 (4)(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; SA-17 (4)(b): Show via [Selection: informal demonstration, convincing argument with formal methods as feasible] that the descriptive top-level specification is consistent with the formal policy model; SA-17 (4)(c): Show via informal demonstration, that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware; SA-17 (4)(d): Show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware; and SA-17 (4)(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 (5)	The organization requires the developer of the information system, system component, or information system service to: SA-17 (5)(a): Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and SA-17 (5)(b): Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism.
SA-17 (6)	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)	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.

Related CCIs

The CCIs below are tied to SA-17.

CCI	Definition
CCI-003293	The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture.
CCI-003294	The design specification and security architecture 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.
CCI-003295	The design specification and security architecture accurately and completely describes the required security functionality.
CCI-003296	The design specification and security architecture accurately and completely describes the allocation of security controls among physical and logical components.
CCI-003297	The design specification and security architecture expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.