SA-17: Developer Security and Privacy Architecture and Design

CSF v1.1 References:

CSF v2.0 References:

Baselines:

  • Low

    N/A

  • Moderate

    N/A

  • High
    • SA-17
  • Privacy

    N/A

Previous Version:

Control Statement

Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:

  1. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;
  2. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and
  3. 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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

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):

(Not part of any baseline)

Use different designs for [Assignment: organization-defined critical systems or system components] to satisfy a common set of requirements or to provide equivalent functionality.