SA – System and Services Acquisition

NIST SP 800-53 Rev. 5 – SA – System and Services Acquisition

1.Kravtext (engelskt original)#

SA-1 – Policy and Procedures#

• a. Develop, document, and disseminate to [organization-defined personnel or roles]:
  • 1. [organization-level or mission/business process-level or system-level] system and services acquisition policy that:
    • (a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
    • (b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
  • 2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;
• b. Designate an [organization-defined official] to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and
• c. Review and update the current system and services acquisition:
  • 1. Policy [organization-defined frequency] and following [organization-defined events] ; and
  • 2. Procedures [organization-defined frequency] and following [organization-defined events].

SA-2 – Allocation of Resources#

• a. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;
• b. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and
• c. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.

SA-3 – System Development Life Cycle#

• a. Acquire, develop, and manage the system using [organization-defined system-development life cycle] that incorporates information security and privacy considerations;
• b. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;
• c. Identify individuals having information security and privacy roles and responsibilities; and
• d. Integrate the organizational information security and privacy risk management process into system development life cycle activities.

SA-3(1) – Manage Preproduction Environment

Protect system preproduction environments commensurate with risk throughout the system development life cycle for the system, system component, or system service.

SA-3(2) – Use of Live or Operational Data

• (a) Approve, document, and control the use of live data in preproduction environments for the system, system component, or system service; and
• (b) Protect preproduction environments for the system, system component, or system service at the same impact or classification level as any live data in use within the preproduction environments.

SA-3(3) – Technology Refresh

Plan for and implement a technology refresh schedule for the system throughout the system development life cycle.

SA-4 – Acquisition Process#

Include the following requirements, descriptions, and criteria, explicitly or by reference, using [standardized contract language or [organization-defined contract language] ] in the acquisition contract for the system, system component, or system service:

• a. Security and privacy functional requirements;
• b. Strength of mechanism requirements;
• c. Security and privacy assurance requirements;
• d. Controls needed to satisfy the security and privacy requirements.
• e. Security and privacy documentation requirements;
• f. Requirements for protecting security and privacy documentation;
• g. Description of the system development environment and environment in which the system is intended to operate;
• h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
• i. Acceptance criteria.

SA-4(1) – Functional Properties of Controls

Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.

SA-4(2) – Design and Implementation Information for Controls

Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [security-relevant external system interfaces or high-level design or low-level design or source code or hardware schematics or [organization-defined design and implementation information] ] at [organization-defined level of detail].

SA-4(3) – Development Methods, Techniques, and Practices

Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes:

• (a) [organization-defined systems engineering methods];
• (b) [[organization-defined system security engineering methods] or [organization-defined privacy engineering methods] ] ; and
• (c) [[organization-defined software development methods] or [organization-defined testing, evaluation, assessment, verification, and validation methods] or [organization-defined quality control processes] ].

SA-4(4) – Assignment of Components to Systems

SA-4(5) – System, Component, and Service Configurations

Require the developer of the system, system component, or system service to:

• (a) Deliver the system, component, or service with [organization-defined security configurations] implemented; and
• (b) Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.

SA-4(6) – Use of Information Assurance Products

• (a) Employ only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and
• (b) Ensure that these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures.

SA-4(7) – NIAP-approved Protection Profiles

• (a) Limit the use of commercially provided information assurance and information assurance-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and
• (b) Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved.

SA-4(8) – Continuous Monitoring Plan for Controls

Require the developer of the system, system component, or system service to produce a plan for continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization.

SA-4(9) – Functions, Ports, Protocols, and Services in Use

Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.

SA-4(10) – Use of Approved PIV Products

Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.

SA-4(11) – System of Records

Include [organization-defined Privacy Act requirements] in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function.

SA-4(12) – Data Ownership

• (a) Include organizational data ownership requirements in the acquisition contract; and
• (b) Require all data to be removed from the contractor’s system and returned to the organization within [organization-defined time frame].

SA-5 – System Documentation#

• a. Obtain or develop administrator documentation for the system, system component, or system service that describes:
  • 1. Secure configuration, installation, and operation of the system, component, or service;
  • 2. Effective use and maintenance of security and privacy functions and mechanisms; and
  • 3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;
• b. Obtain or develop user documentation for the system, system component, or system service that describes:
  • 1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;
  • 2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and
  • 3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;
• c. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take [organization-defined actions] in response; and
• d. Distribute documentation to [organization-defined personnel or roles].

SA-5(1) – Functional Properties of Security Controls

SA-5(2) – Security-relevant External System Interfaces

SA-5(3) – High-level Design

SA-5(4) – Low-level Design

SA-5(5) – Source Code

SA-6 – Software Usage Restrictions#

SA-7 – User-installed Software#

SA-8 – Security and Privacy Engineering Principles#

Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: [organization-defined systems security and privacy engineering principles].

SA-8(1) – Clear Abstractions

Implement the security design principle of clear abstractions.

SA-8(2) – Least Common Mechanism

Implement the security design principle of least common mechanism in [organization-defined systems or system components].

SA-8(3) – Modularity and Layering

Implement the security design principles of modularity and layering in [organization-defined systems or system components].

SA-8(4) – Partially Ordered Dependencies

Implement the security design principle of partially ordered dependencies in [organization-defined systems or system components].

SA-8(5) – Efficiently Mediated Access

Implement the security design principle of efficiently mediated access in [organization-defined systems or system components].

SA-8(6) – Minimized Sharing

Implement the security design principle of minimized sharing in [organization-defined systems or system components].

SA-8(7) – Reduced Complexity

Implement the security design principle of reduced complexity in [organization-defined systems or system components].

SA-8(8) – Secure Evolvability

Implement the security design principle of secure evolvability in [organization-defined systems or system components].

SA-8(9) – Trusted Components

Implement the security design principle of trusted components in [organization-defined systems or system components].

SA-8(10) – Hierarchical Trust

Implement the security design principle of hierarchical trust in [organization-defined systems or system components].

SA-8(11) – Inverse Modification Threshold

Implement the security design principle of inverse modification threshold in [organization-defined systems or system components].

SA-8(12) – Hierarchical Protection

Implement the security design principle of hierarchical protection in [organization-defined systems or system components].

SA-8(13) – Minimized Security Elements

Implement the security design principle of minimized security elements in [organization-defined systems or system components].

SA-8(14) – Least Privilege

Implement the security design principle of least privilege in [organization-defined systems or system components].

SA-8(15) – Predicate Permission

Implement the security design principle of predicate permission in [organization-defined systems or system components].

SA-8(16) – Self-reliant Trustworthiness

Implement the security design principle of self-reliant trustworthiness in [organization-defined systems or system components].

SA-8(17) – Secure Distributed Composition

Implement the security design principle of secure distributed composition in [organization-defined systems or system components].

SA-8(18) – Trusted Communications Channels

Implement the security design principle of trusted communications channels in [organization-defined systems or system components].

SA-8(19) – Continuous Protection

Implement the security design principle of continuous protection in [organization-defined systems or system components].

SA-8(20) – Secure Metadata Management

Implement the security design principle of secure metadata management in [organization-defined systems or system components].

SA-8(21) – Self-analysis

Implement the security design principle of self-analysis in [organization-defined systems or system components].

SA-8(22) – Accountability and Traceability

Implement the security design principle of accountability and traceability in [organization-defined systems or system components].

SA-8(23) – Secure Defaults

Implement the security design principle of secure defaults in [organization-defined systems or system components].

SA-8(24) – Secure Failure and Recovery

Implement the security design principle of secure failure and recovery in [organization-defined systems or system components].

SA-8(25) – Economic Security

Implement the security design principle of economic security in [organization-defined systems or system components].

SA-8(26) – Performance Security

Implement the security design principle of performance security in [organization-defined systems or system components].

SA-8(27) – Human Factored Security

Implement the security design principle of human factored security in [organization-defined systems or system components].

SA-8(28) – Acceptable Security

Implement the security design principle of acceptable security in [organization-defined systems or system components].

SA-8(29) – Repeatable and Documented Procedures

Implement the security design principle of repeatable and documented procedures in [organization-defined systems or system components].

SA-8(30) – Procedural Rigor

Implement the security design principle of procedural rigor in [organization-defined systems or system components].

SA-8(31) – Secure System Modification

Implement the security design principle of secure system modification in [organization-defined systems or system components].

SA-8(32) – Sufficient Documentation

Implement the security design principle of sufficient documentation in [organization-defined systems or system components].

SA-8(33) – Minimization

Implement the privacy principle of minimization using [organization-defined processes].

SA-9 – External System Services#

• a. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: [organization-defined controls];
• b. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and
• c. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: [organization-defined processes, methods, and techniques].

SA-9(1) – Risk Assessments and Organizational Approvals

• (a) Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and
• (b) Verify that the acquisition or outsourcing of dedicated information security services is approved by [organization-defined personnel or roles].

SA-9(2) – Identification of Functions, Ports, Protocols, and Services

Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: [organization-defined external system services].

SA-9(3) – Establish and Maintain Trust Relationship with Providers

Establish, document, and maintain trust relationships with external service providers based on the following requirements, properties, factors, or conditions: [organization-defined security and privacy requirements, properties, factors, or conditions defining acceptable trust relationships].

SA-9(4) – Consistent Interests of Consumers and Providers

Take the following actions to verify that the interests of [organization-defined external service providers] are consistent with and reflect organizational interests: [organization-defined actions].

SA-9(5) – Processing, Storage, and Service Location

Restrict the location of [information processing or information or data or system services] to [organization-defined locations] based on [organization-defined requirements].

SA-9(6) – Organization-controlled Cryptographic Keys

Maintain exclusive control of cryptographic keys for encrypted material stored or transmitted through an external system.

SA-9(7) – Organization-controlled Integrity Checking

Provide the capability to check the integrity of information while it resides in the external system.

SA-9(8) – Processing and Storage Location — U.S. Jurisdiction

Restrict the geographic location of information processing and data storage to facilities located within in the legal jurisdictional boundary of the United States.

SA-10 – Developer Configuration Management#

Require the developer of the system, system component, or system service to:

• a. Perform configuration management during system, component, or service [design or development or implementation or operation or disposal];
• b. Document, manage, and control the integrity of changes to [organization-defined configuration items];
• c. Implement only organization-approved changes to the system, component, or service;
• d. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and
• e. Track security flaws and flaw resolution within the system, component, or service and report findings to [organization-defined personnel].

SA-10(1) – Software and Firmware Integrity Verification

Require the developer of the system, system component, or system service to enable integrity verification of software and firmware components.

SA-10(2) – Alternative Configuration Management Processes

Provide an alternate configuration management process using organizational personnel in the absence of a dedicated developer configuration management team.

SA-10(3) – Hardware Integrity Verification

Require the developer of the system, system component, or system service to enable integrity verification of hardware components.

SA-10(4) – Trusted Generation

Require the developer of the system, system component, or system service to employ tools for comparing newly generated versions of security-relevant hardware descriptions, source code, and object code with previous versions.

SA-10(5) – Mapping Integrity for Version Control

Require the developer of the system, system component, or system service to maintain the integrity of the mapping between the master build data describing the current version of security-relevant hardware, software, and firmware and the on-site master copy of the data for the current version.

SA-10(6) – Trusted Distribution

Require the developer of the system, system component, or system service to execute procedures for ensuring that security-relevant hardware, software, and firmware updates distributed to the organization are exactly as specified by the master copies.

SA-10(7) – Security and Privacy Representatives

Require [organization-defined security and privacy representatives] to be included in the [organization-defined configuration change management and control process].

SA-11 – Developer Testing and Evaluation#

Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:

• a. Develop and implement a plan for ongoing security and privacy control assessments;
• b. Perform [unit or integration or system or regression] testing/evaluation [organization-defined frequency to conduct] at [organization-defined depth and coverage];
• c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
• d. Implement a verifiable flaw remediation process; and
• e. Correct flaws identified during testing and evaluation.

SA-11(1) – Static Code Analysis

Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.

SA-11(2) – Threat Modeling and Vulnerability Analyses

Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that:

• (a) Uses the following contextual information: [organization-defined information];
• (b) Employs the following tools and methods: [organization-defined tools and methods];
• (c) Conducts the modeling and analyses at the following level of rigor: [organization-defined breadth and depth of modeling and analyses] ; and
• (d) Produces evidence that meets the following acceptance criteria: [organization-defined acceptance criteria].

SA-11(3) – Independent Verification of Assessment Plans and Evidence

• (a) Require an independent agent satisfying [organization-defined independence criteria] to verify the correct implementation of the developer security and privacy assessment plans and the evidence produced during testing and evaluation; and
• (b) Verify that the independent agent is provided with sufficient information to complete the verification process or granted the authority to obtain such information.

SA-11(4) – Manual Code Reviews

Require the developer of the system, system component, or system service to perform a manual code review of [organization-defined specific code] using the following processes, procedures, and/or techniques: [organization-defined processes, procedures, and/or techniques].

SA-11(5) – Penetration Testing

Require the developer of the system, system component, or system service to perform penetration testing:

• (a) At the following level of rigor: [organization-defined breadth and depth of testing] ; and
• (b) Under the following constraints: [organization-defined constraints].

SA-11(6) – Attack Surface Reviews

Require the developer of the system, system component, or system service to perform attack surface reviews.

SA-11(7) – Verify Scope of Testing and Evaluation

Require the developer of the system, system component, or system service to verify that the scope of testing and evaluation provides complete coverage of the required controls at the following level of rigor: [organization-defined breadth and depth of testing and evaluation].

SA-11(8) – Dynamic Code Analysis

Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis.

SA-11(9) – Interactive Application Security Testing

Require the developer of the system, system component, or system service to employ interactive application security testing tools to identify flaws and document the results.

SA-12 – Supply Chain Protection#

SA-12(1) – Acquisition Strategies / Tools / Methods

SA-12(2) – Supplier Reviews

SA-12(3) – Trusted Shipping and Warehousing

SA-12(4) – Diversity of Suppliers

SA-12(5) – Limitation of Harm

SA-12(6) – Minimizing Procurement Time

SA-12(7) – Assessments Prior to Selection / Acceptance / Update

SA-12(8) – Use of All-source Intelligence

SA-12(9) – Operations Security

SA-12(10) – Validate as Genuine and Not Altered

SA-12(11) – Penetration Testing / Analysis of Elements, Processes, and Actors

SA-12(12) – Inter-organizational Agreements

SA-12(13) – Critical Information System Components

SA-12(14) – Identity and Traceability

SA-12(15) – Processes to Address Weaknesses or Deficiencies

SA-13 – Trustworthiness#

SA-14 – Criticality Analysis#

SA-14(1) – Critical Components with No Viable Alternative Sourcing

SA-15 – Development Process, Standards, and Tools#

• a. Require the developer of the system, system component, or system service to follow a documented development process that:
  • 1. Explicitly addresses security and privacy requirements;
  • 2. Identifies the standards and tools used in the development process;
  • 3. Documents the specific tool options and tool configurations used in the development process; and
  • 4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and
• b. Review the development process, standards, tools, tool options, and tool configurations [organization-defined frequency] to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: [organization-defined security and privacy requirements].

SA-15(1) – Quality Metrics

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 [[organization-defined frequency] or [organization-defined program review] or upon delivery].

SA-15(2) – Security and Privacy Tracking 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.

SA-15(3) – Criticality Analysis

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: [organization-defined decision points] ; and
• (b) At the following level of rigor: [organization-defined breadth and depth of criticality analysis].

SA-15(4) – Threat Modeling and Vulnerability Analysis

SA-15(5) – Attack Surface Reduction

Require the developer of the system, system component, or system service to reduce attack surfaces to [organization-defined thresholds].

SA-15(6) – Continuous Improvement

Require the developer of the system, system component, or system service to implement an explicit process to continuously improve the development process.

SA-15(7) – Automated Vulnerability Analysis

Require the developer of the system, system component, or system service [organization-defined frequency] to:

• (a) Perform an automated vulnerability analysis using [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 [organization-defined personnel or roles].

SA-15(8) – Reuse of Threat and Vulnerability Information

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.

SA-15(9) – Use of Live Data

SA-15(10) – Incident Response Plan

Require the developer of the system, system component, or system service to provide, implement, and test an incident response plan.

SA-15(11) – Archive System or Component

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.

SA-15(12) – Minimize Personally Identifiable Information

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.

SA-15(13) – Logging Syntax

Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.

SA-16 – Developer-provided Training#

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: [organization-defined training].

SA-17 – Developer Security and Privacy Architecture and Design#

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.

SA-17(1) – Formal Policy Model

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

SA-17(2) – Security-relevant Components

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.

SA-17(3) – Formal Correspondence

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.

SA-17(4) – Informal Correspondence

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

SA-17(5) – Conceptually Simple Design

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.

SA-17(6) – Structure for Testing

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

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

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

SA-17(9) – Design Diversity

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

SA-18 – Tamper Resistance and Detection#

SA-18(1) – Multiple Phases of System Development Life Cycle

SA-18(2) – Inspection of Systems or Components

SA-19 – Component Authenticity#

SA-19(1) – Anti-counterfeit Training

SA-19(2) – Configuration Control for Component Service and Repair

SA-19(3) – Component Disposal

SA-19(4) – Anti-counterfeit Scanning

SA-20 – Customized Development of Critical Components#

Reimplement or custom develop the following critical system components: [organization-defined critical system].

SA-21 – Developer Screening#

Require that the developer of [organization-defined system, systems component, or system service]:

• a. Has appropriate access authorizations as determined by assigned [organization-defined official government duties] ; and
• b. Satisfies the following additional personnel screening criteria: [organization-defined additional personnel screening criteria].

SA-21(1) – Validation of Screening

SA-22 – Unsupported System Components#

• a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
• b. Provide the following options for alternative sources for continued support for unsupported components [in-house support or [organization-defined support from external providers] ].

SA-22(1) – Alternative Sources for Continued Support

SA-23 – Specialization#

Employ [design modification or augmentation or reconfiguration] on [organization-defined systems or system components] supporting mission essential services or functions to increase the trustworthiness in those systems or components.

SA-24 – Design For Cyber Resiliency#

• a. Design organizational systems, system components, or system services to achieve cyber resiliency by:
  • 1. Defining the following cyber resiliency goals: [organization-defined cyber resiliency goals].
  • 2. Defining the following cyber resiliency objectives: [organization-defined cyber resiliency objectives].
  • 3. Defining the following cyber resiliency techniques: [organization-defined cyber resiliency techniques].
  • 4. Defining the following cyber resiliency implementation approaches: [organization-defined cyber resiliency implementation approaches].
  • 5. Defining the following cyber resiliency design principles: [organization-defined cyber resiliency design principles].
• b. Implement the selected cyber resiliency goals, objectives, techniques, implementation approaches, and design principles as part of an organizational risk management process or systems security engineering process.

National Institute of Standards and Technology, OSCAL release 5.2.0. Republished courtesy of the National Institute of Standards and Technology. CC0 1.0. Source.