SA-17 Developer Security and Privacy Architecture and Design

Guidance: nonePolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
High	Organization	9 (0 in a baseline)

Related controls: PL-2, PL-8, PM-7, SA-3, SA-4, SA-8, SC-7

Control statement

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.

NIST discussion

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

Baselines: Not in a baseline

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.

Discussion and assessment objectives for SA-17(1)

Formal models describe specific behaviors or security and privacy policies using formal languages, thus enabling the correctness of those behaviors and policies to be formally proven. Not all components of systems can be modeled. Generally, formal specifications are scoped to the behaviors or policies of interest, such as nondiscretionary access control policies. Organizations choose the formal modeling language and approach based on the nature of the behaviors and policies to be described and the available tools.

Determine if:

• SA-17(01)(a)
  • SA-17(01)(a)[01] as an integral part of the development process, the developer of the system, system component, or system service is required to produce a formal policy model describing the [Assignment: organization-defined organizational security policy] to be enforced;
  • SA-17(01)(a)[02] as an integral part of the development process, the developer of the system, system component, or system service is required to produce a formal policy model describing the [Assignment: organization-defined organizational privacy policy] to be enforced;
• SA-17(01)(b)
  • SA-17(01)(b)[01] the developer of the system, system component, or system service is required to 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(01)(b)[02] the developer of the system, system component, or system service is required to prove that the formal policy model is internally consistent and sufficient to enforce the defined elements of the organizational privacy policy when implemented.

Examine: System and services acquisition policy; system and services acquisition procedures; enterprise architecture policy; enterprise architecture documentation; procedures addressing developer security and privacy architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; system configuration settings and associated documentation; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer.

SA-17(2) Security-relevant Components

Baselines: Not in a baseline

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.

Discussion and assessment objectives for SA-17(2)

The security-relevant hardware, software, and firmware represent the portion of the system, component, or service that is trusted to perform correctly to maintain required security properties.

Determine if:

• SA-17(02)(a)
  • SA-17(02)(a)[01] the developer of the system, system component, or system service is required to define security-relevant hardware;
  • SA-17(02)(a)[02] the developer of the system, system component, or system service is required to define security-relevant software;
  • SA-17(02)(a)[03] the developer of the system, system component, or system service is required to define security-relevant firmware;
• SA-17(02)(b) the developer of the system, system component, or system service is required to provide a rationale that the definition for security-relevant hardware, software, and firmware is complete.

Examine: System and services acquisition policy; enterprise architecture policy; procedures addressing developer security architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; list of security-relevant hardware, software, and firmware components; documented rationale of completeness regarding definitions provided for security-relevant hardware, software, and firmware; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developers; organizational personnel with information security architecture and design responsibilities.

SA-17(3) Formal Correspondence

Baselines: Not in a baseline

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.

Discussion and assessment objectives for SA-17(3)

Correspondence is an important part of the assurance gained through modeling. It demonstrates that the implementation is an accurate transformation of the model, and that any additional code or implementation details that are present have no impact on the behaviors or policies being modeled. Formal methods can be used to show that the high-level security properties are satisfied by the formal system description, and that the formal system description is correctly implemented by a description of some lower level, including a hardware description. Consistency between the formal top-level specification and the formal policy models is generally not amenable to being fully proven. Therefore, a combination of formal and informal methods may be needed to demonstrate such consistency. Consistency between the formal top-level specification and the actual implementation may require the use of an informal demonstration due to limitations on the applicability of formal methods to prove that the specification accurately reflects the implementation. Hardware, software, and firmware mechanisms internal to security-relevant components include mapping registers and direct memory input and output.

Determine if:

• SA-17(03)(a)
  • SA-17(03)(a)[01] as an integral part of the development process, the developer of the system, system component, or system service is required to produce a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions;
  • SA-17(03)(a)[02] as an integral part of the development process, the developer of the system, system component, or system service is required to produce a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of error messages;
  • SA-17(03)(a)[03] as an integral part of the development process, the developer of the system, system component, or system service is required to produce a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of effects;
• SA-17(03)(b) the developer of the system, system component, or system service is required to show proof that the formal top-level specification is consistent with the formal policy model to the extent feasible with additional informal demonstration as necessary;
• SA-17(03)(c) the developer of the system, system component, or system service is required to show via informal demonstration that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;
• SA-17(03)(d) the developer of the system, system component, or system service is required to show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware;
• SA-17(03)(e) the developer of the system, system component, or system service is required to describe the security-relevant hardware, software, and firmware mechanisms that are not addressed in the formal top-level specification but are strictly internal to the security-relevant hardware, software, and firmware.

Examine: System and services acquisition policy; enterprise architecture policy; formal policy model; procedures addressing developer security architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; formal top-level specification documentation; system security architecture and design documentation; system design documentation; system configuration settings and associated documentation; documentation describing security-relevant hardware, software, and firmware mechanisms not addressed in the formal top-level specification documentation; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with information security architecture and design responsibilities.

SA-17(4) Informal Correspondence

Baselines: Not in a baseline

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

Discussion and assessment objectives for SA-17(4)

Correspondence is an important part of the assurance gained through modeling. It demonstrates that the implementation is an accurate transformation of the model, and that additional code or implementation detail has no impact on the behaviors or policies being modeled. Consistency between the descriptive top-level specification (i.e., high-level/low-level design) and the formal policy model is generally not amenable to being fully proven. Therefore, a combination of formal and informal methods may be needed to show such consistency. Hardware, software, and firmware mechanisms strictly internal to security-relevant hardware, software, and firmware include mapping registers and direct memory input and output.

Determine if:

• SA-17(04)(a)
  • SA-17(04)(a)[01] as an integral part of the development process, the developer of the system, system component, or system service is required to produce an informal, descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions;
  • SA-17(04)(a)[02] as an integral part of the development process, the developer of the system, system component, or system service is required to produce an informal, descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of error messages;
  • SA-17(04)(a)[03] as an integral part of the development process, the developer of the system, system component, or system service is required to produce an informal, descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of effects;
• SA-17(04)(b) the developer of the system, system component, or system service is required to 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(04)(c) the developer of the system, system component, or system service is required to show via informal demonstration that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;
• SA-17(04)(d) the developer of the system, system component, or system service is required to show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware;
• SA-17(04)(e) the developer of the system, system component, or system service is required to describe the security-relevant hardware, software, and firmware mechanisms that are not addressed in the descriptive top-level specification but are strictly internal to the security-relevant hardware, software, and firmware.

Examine: System and services acquisition policy; enterprise architecture policy; formal policy model; procedures addressing developer security architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; informal, descriptive top-level specification documentation; system security architecture and design documentation; system design documentation; system configuration settings and associated documentation; documentation describing security-relevant hardware, software, and firmware mechanisms not addressed in the informal, descriptive top-level specification documentation; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with information security architecture and design responsibilities.

SA-17(5) Conceptually Simple Design

Baselines: Not in a baseline

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.

Discussion and assessment objectives for SA-17(5)

The principle of reduced complexity states that the system design is as simple and small as possible (see SA-8(7) ). A small and simple design is easier to understand and analyze and is also less prone to error (see AC-25, SA-8(13) ). The principle of reduced complexity applies to any aspect of a system, but it has particular importance for security due to the various analyses performed to obtain evidence about the emergent security property of the system. For such analyses to be successful, a small and simple design is essential. Application of the principle of reduced complexity contributes to the ability of system developers to understand the correctness and completeness of system security functions and facilitates the identification of potential vulnerabilities. The corollary of reduced complexity states that the simplicity of the system is directly related to the number of vulnerabilities it will contain. That is, simpler systems contain fewer vulnerabilities. An important benefit of reduced complexity is that it is easier to understand whether the security policy has been captured in the system design and that fewer vulnerabilities are likely to be introduced during engineering development. An additional benefit is that any such conclusion about correctness, completeness, and existence of vulnerabilities can be reached with a higher degree of assurance in contrast to conclusions reached in situations where the system design is inherently more complex.

Determine if:

• SA-17(05)(a) the developer of the system, system component, or system service is required to design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics;
• SA-17(05)(b) the developer of the system, system component, or system service is required to internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism.

Examine: System and services acquisition policy; enterprise architecture policy; procedures addressing developer security architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; system security architecture documentation; system configuration settings and associated documentation; developer documentation describing the design and structure of security-relevant hardware, software, and firmware components; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with information security architecture and design responsibilities.

SA-17(6) Structure for Testing

Baselines: Not in a baseline

Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing.

Discussion and assessment objectives for SA-17(6)

Applying the security design principles in SP 800-160-1 promotes complete, consistent, and comprehensive testing and evaluation of systems, system components, and services. The thoroughness of such testing contributes to the evidence produced to generate an effective assurance case or argument as to the trustworthiness of the system, system component, or service.

Determine if the developer of the system, system component, or system service is required to structure security-relevant hardware, software, and firmware to facilitate testing.

Examine: System and services acquisition policy; enterprise architecture policy; procedures addressing developer security architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; system security architecture documentation; privacy architecture documentation; system configuration settings and associated documentation; developer documentation describing the design and structure of security-relevant hardware, software, and firmware components to facilitate testing; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer; organizational personnel with information security and privacy architecture and design responsibilities.

SA-17(7) Structure for Least Privilege

Baselines: Not in a 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.

Discussion and assessment objectives for SA-17(7)

The principle of least privilege states that each component is allocated sufficient privileges to accomplish its specified functions but no more (see SA-8(14) ). Applying the principle of least privilege limits the scope of the component’s actions, which has two desirable effects. First, the security impact of a failure, corruption, or misuse of the system component results in a minimized security impact. Second, the security analysis of the component is simplified. Least privilege is a pervasive principle that is reflected in all aspects of the secure system design. Interfaces used to invoke component capability are available to only certain subsets of the user population, and component design supports a sufficiently fine granularity of privilege decomposition. For example, in the case of an audit mechanism, there may be an interface for the audit manager, who configures the audit settings; an interface for the audit operator, who ensures that audit data is safely collected and stored; and, finally, yet another interface for the audit reviewer, who only has a need to view the audit data that has been collected but no need to perform operations on that data.

In addition to its manifestations at the system interface, least privilege can be used as a guiding principle for the internal structure of the system itself. One aspect of internal least privilege is to construct modules so that only the elements encapsulated by the module are directly operated upon by the functions within the module. Elements external to a module that may be affected by the module’s operation are indirectly accessed through interaction (e.g., via a function call) with the module that contains those elements. Another aspect of internal least privilege is that the scope of a given module or component includes only those system elements that are necessary for its functionality, and the access modes to the elements (e.g., read, write) are minimal.

Determine if the developer of the system, system component, or system service is required to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.

Examine: System and services acquisition policy; enterprise architecture policy; procedures addressing developer security architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; system security architecture documentation; system configuration settings and associated documentation; developer documentation describing the design and structure of security-relevant hardware, software, and firmware components to facilitate controlling access with least privilege; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with information security architecture and design responsibilities.

SA-17(8) Orchestration

Baselines: Not in a baseline

Design [Assignment: organization-defined critical systems] with coordinated behavior to implement the following capabilities: [Assignment: organization-defined capabilities].

Discussion and assessment objectives for SA-17(8)

Security resources that are distributed, located at different layers or in different system elements, or are implemented to support different aspects of trustworthiness can interact in unforeseen or incorrect ways. Adverse consequences can include cascading failures, interference, or coverage gaps. Coordination of the behavior of security resources (e.g., by ensuring that one patch is installed across all resources before making a configuration change that assumes that the patch is propagated) can avert such negative interactions.

Determine if [Assignment: organization-defined critical systems] are designed with coordinated behavior to implement [Assignment: organization-defined capabilities].

Examine: System and services acquisition policy; enterprise architecture policy; procedures addressing developer security and privacy architecture and design; enterprise architecture; security architecture; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; system configuration settings and associated documentation; developer documentation describing design orchestration; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer; organizational personnel with information security architecture responsibilities.

SA-17(9) Design Diversity

Baselines: Not in a baseline

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

Discussion and assessment objectives for SA-17(9)

Design diversity is achieved by supplying the same requirements specification to multiple developers, each of whom is responsible for developing a variant of the system or system component that meets the requirements. Variants can be in software design, in hardware design, or in both hardware and a software design. Differences in the designs of the variants can result from developer experience (e.g., prior use of a design pattern), design style (e.g., when decomposing a required function into smaller tasks, determining what constitutes a separate task and how far to decompose tasks into sub-tasks), selection of libraries to incorporate into the variant, and the development environment (e.g., different design tools make some design patterns easier to visualize). Hardware design diversity includes making different decisions about what information to keep in analog form and what information to convert to digital form, transmitting the same information at different times, and introducing delays in sampling (temporal diversity). Design diversity is commonly used to support fault tolerance.

Determine if different designs are used for [Assignment: organization-defined critical systems] to satisfy a common set of requirements or to provide equivalent functionality.

Examine: System and services acquisition policy; enterprise architecture policy; procedures addressing developer security architecture and design diversity for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; system security architecture documentation; system configuration settings and associated documentation; developer documentation describing design diversity; system security plan; other relevant documents or records.

Interview: Organizational personnel with system and service acquisition responsibilities; organizational personnel with information security responsibilities; system developer; organizational personnel with information security architecture responsibilities.

Assessment objectives (SP 800-53A)

Objectives and methods for SA-17

Determine if:

• SA-17(a)
  • SA-17(a)[01] the developer of the system, system component, or system service is required to produce a design specification and security architecture that are consistent with the organization’s security architecture, which is an integral part the organization’s enterprise architecture;
  • SA-17(a)[02] the developer of the system, system component, or system service is required to produce a design specification and privacy architecture that are consistent with the organization’s privacy architecture, which is an integral part the organization’s enterprise architecture;
• SA-17(b)
  • SA-17(b)[01] the developer of the system, system component, or system service is required to produce a design specification and security architecture that accurately and completely describe the required security functionality and the allocation of controls among physical and logical components;
  • SA-17(b)[02] the developer of the system, system component, or system service is required to produce a design specification and privacy architecture that accurately and completely describe the required privacy functionality and the allocation of controls among physical and logical components;
• SA-17(c)
  • SA-17(c)[01] the developer of the system, system component, or system service is required to produce a design specification and security architecture that express how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection;
  • SA-17(c)[02] the developer of the system, system component, or system service is required to produce a design specification and privacy architecture that express how individual privacy functions, mechanisms, and services work together to provide required privacy capabilities and a unified approach to protection.

Examine: System and services acquisition policy; system and services acquisition procedures; enterprise architecture policy; enterprise architecture documentation; procedures addressing developer security and privacy architecture and design specifications for the system; solicitation documentation; acquisition documentation; service level agreements; acquisition contracts for the system, system component, or system service; system design documentation; information system configuration settings and associated documentation; system security plan; privacy plan; other relevant documents or records.

Interview: Organizational personnel with acquisition responsibilities; organizational personnel with information security and privacy responsibilities; system developer.

Policy statement

• The System owner shall 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, as an integral part of the organization’s enterprise architecture (PL-8). (SA-17a)
• The design specification and architecture shall accurately and completely describe the required security and privacy functionality, and the allocation of controls among physical and logical components. (SA-17b)
• The design specification and architecture shall express how the individual security and privacy functions, mechanisms and services work together to provide the required security and privacy capabilities and a unified approach to protection. (SA-17c)
• The System owner shall have the design specification and architecture reviewed by the security architect and, for a system that processes personally identifiable information, the Senior privacy official, before the design is accepted. (SA-17)

From the System and Services Acquisition Policy template (draft). Highlighted fields are values your organization sets.

Artifacts

• System and Services Acquisition Decision Worksheet
• System and Services Acquisition Policy