ezesecops/rmf-ato-core huggingface dataset:
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(1)

SA-15(1) Development Process, Standards, and Tools | Quality Metrics
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to:
(a) Define quality metrics at the beginning of the development process; and
(b) Provide evidence of meeting the quality metrics [Selection; one or more: [Assignment: organization-defined frequency] ; [Assignment: organization-defined program review] ; upon delivery].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(2) > Discussion

SA-15(2) Security and Privacy Tracking Tools - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

System development teams select and deploy security and privacy tracking tools, including vulnerability or work item tracking systems that facilitate assignment, sorting, filtering, and tracking of completed work items or tasks associated with development processes.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(2)

SA-15(2) Development Process, Standards, and Tools | Security and Privacy Tracking Tools
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to select and employ security and privacy tracking tools for use during the development process.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(3) > Discussion

SA-15(3) Criticality Analysis - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Criticality analysis performed by the developer provides input to the criticality analysis performed by organizations. Developer input is essential to organizational criticality analysis because organizations may not have access to detailed design documentation for system components that are developed as commercial off-the-shelf products. Such design documentation includes functional specifications, high-level designs, low-level designs, source code, and hardware schematics. Criticality analysis is important for organizational systems that are designated as high value assets. High value assets can be moderate- or high-impact systems due to heightened adversarial interest or potential adverse effects on the federal enterprise. Developer input is especially important when organizations conduct supply chain criticality analyses.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(3)

SA-15(3) Development Process, Standards, and Tools | Criticality Analysis
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to perform a criticality analysis:
(a) At the following decision points in the system development life cycle: [Assignment: organization-defined decision points] ; and
(b) At the following level of rigor: [Assignment: organization-defined organization-defined breadth and depth of criticality analysis].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(5) > Discussion

SA-15(5) Attack Surface Reduction - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Attack surface reduction is closely aligned with threat and vulnerability analyses and system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within systems, system components, and system services. Attack surface reduction includes implementing the concept of layered defenses, applying the principles of least privilege and least functionality, applying secure software development practices, deprecating unsafe functions, reducing entry points available to unauthorized users, reducing the amount of code that executes, and eliminating application programming interfaces (APIs) that are vulnerable to attacks.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(5)

SA-15(5) Development Process, Standards, and Tools | Attack Surface Reduction
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to reduce attack surfaces to [Assignment: organization-defined thresholds].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(6) > Discussion

SA-15(6) Continuous Improvement - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Developers of systems, system components, and system services consider the effectiveness and efficiency of their development processes for meeting quality objectives and addressing the security and privacy capabilities in current threat environments.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(6)

SA-15(6) Development Process, Standards, and Tools | Continuous Improvement
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to implement an explicit process to continuously improve the development process.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(7) > Discussion

SA-15(7) Automated Vulnerability Analysis - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Automated tools can be more effective at analyzing exploitable weaknesses or deficiencies in large and complex systems, prioritizing vulnerabilities by severity, and providing recommendations for risk mitigations.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(7)

SA-15(7) Development Process, Standards, and Tools | Automated Vulnerability Analysis
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service [Assignment: organization-defined frequency] to:
(a) Perform an automated vulnerability analysis using [Assignment: organization-defined tools];
(b) Determine the exploitation potential for discovered vulnerabilities;
(c) Determine potential risk mitigations for delivered vulnerabilities; and
(d) Deliver the outputs of the tools and results of the analysis to [Assignment: organization-defined personnel or roles].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(8) > Discussion

SA-15(8) Reuse of Threat and Vulnerability Information - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Analysis of vulnerabilities found in similar software applications can inform potential design and implementation issues for systems under development. Similar systems or system components may exist within developer organizations. Vulnerability information is available from a variety of public and private sector sources, including the NIST National Vulnerability Database.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(8)

SA-15(8) Development Process, Standards, and Tools | Reuse of Threat and Vulnerability Information
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to use threat modeling and vulnerability analyses from similar systems, components, or services to inform the current development process.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(10) > Discussion

SA-15(10) Incident Response Plan - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

The incident response plan provided by developers may provide information not readily available to organizations and be incorporated into organizational incident response plans. Developer information may also be extremely helpful, such as when organizations respond to vulnerabilities in commercial off-the-shelf products.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(10)

SA-15(10) Development Process, Standards, and Tools | Incident Response Plan
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system, system component, or system service to provide, implement, and test an incident response plan.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(11) > Discussion

SA-15(11) Archive System or Component - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Archiving system or system components requires the developer to retain key development artifacts, including hardware specifications, source code, object code, and relevant documentation from the development process that can provide a readily available configuration baseline for system and component upgrades or modifications.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(11)

SA-15(11) Development Process, Standards, and Tools | Archive System or Component
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system or system component to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security and privacy review.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(12) > Discussion

SA-15(12) Minimize Personally Identifiable Information - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Organizations can minimize the risk to an individual's privacy by using techniques such as de-identification or synthetic data. Limiting the use of personally identifiable information in development and test environments helps reduce the level of privacy risk created by a system.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(12)

SA-15(12) Development Process, Standards, and Tools | Minimize Personally Identifiable Information
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(13) > Discussion

SA-15(13) Logging Syntax - Discussion
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

In support of better incident response and the ability to more quickly reconstruct security-related actions, identifying specific requirements for secure logging facilitates the ability to connect application-produced audit event logs with operational data. Event types are consistent with the event types defined in [AU-02](#au-2).
Security and Privacy Controls for Information Systems and Organizations
SA > SA-15 > SA-15(13)

SA-15(13) Development Process, Standards, and Tools | Logging Syntax
Family: System and Services Acquisition (SA) > SA-15 Development Process, Standards, and Tools

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-16

SA-16 Developer-provided Training
Family: System and Services Acquisition (SA)

Require the developer of the system, system component, or system service to provide the following training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms: [Assignment: organization-defined training].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-16 > Discussion

SA-16 Developer-provided Training - Discussion
Family: System and Services Acquisition (SA)

Developer-provided training applies to external and internal (in-house) developers. Training personnel is essential to ensuring the effectiveness of the controls implemented within organizational systems. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Organizations can also request training materials from developers to conduct in-house training or offer self-training to organizational personnel. Organizations determine the type of training necessary and may require different types of training for different security and privacy functions, controls, and mechanisms.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17

SA-17 Developer Security and Privacy Architecture and Design
Family: System and Services Acquisition (SA)

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > Discussion

SA-17 Developer Security and Privacy Architecture and Design - Discussion
Family: System and Services Acquisition (SA)

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](#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](#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](#87087451-2af5-43d4-88c1-d66ad850f614), [ISO 15408-3](#4452efc0-e79e-47b8-aa30-b54f3ef61c2f) , and [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) 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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(1) > Discussion

SA-17(1) Formal Policy Model - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(1)

SA-17(1) Developer Security and Privacy Architecture and Design | Formal Policy Model
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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 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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(2) > Discussion

SA-17(2) Security-relevant Components - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(2)

SA-17(2) Developer Security and Privacy Architecture and Design | Security-relevant Components
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(3) > Discussion

SA-17(3) Formal Correspondence - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(3)

SA-17(3) Developer Security and Privacy Architecture and Design | Formal Correspondence
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(4) > Discussion

SA-17(4) Informal Correspondence - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(4)

SA-17(4) Developer Security and Privacy Architecture and Design | Informal Correspondence
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

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.