+SA-04 [H] Acquisition Process
---+SA-04(01) [H] Functional Properties of Controls
---+SA-04(02) [H] Design and Implementation Information for Controls
---+SA-04(05) [H] System, Component, and Service Configurations
---+SA-04(09) [H] Functions, Ports, Protocols, and Services in Use
---+SA-04(10) [H] Use of Approved PIV Products
|
SA-04 [H] Acquisition Process
Control
Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service:- Security and privacy functional requirements;
- Strength of mechanism requirements;
- Security and privacy assurance requirements;
- Controls needed to satisfy the security and privacy requirements.
- Security and privacy documentation requirements;
- Requirements for protecting security and privacy documentation;
- Description of the system development environment and environment in which the system is intended to operate;
- Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
- Acceptance criteria.
Discussion
Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in [SA-2](#sa-2) . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) describes the process of requirements engineering as part of the system development life cycle.
Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle.
Security and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement.
Organizations can determine other requirements that support security and operations, to include responsibilities for the organization and developer, and notification and timing requirements for support, maintenance and updates.
Assessment Objective
- security functional requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- privacy functional requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- strength of mechanism requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- security assurance requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- privacy assurance requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- controls needed to satisfy the security requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- controls needed to satisfy the privacy requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- security documentation requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- privacy documentation requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- requirements for protecting security documentation, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- requirements for protecting privacy documentation, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- the description of the system development environment and environment in which the system is intended to operate, requirements, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- the allocation of responsibility or identification of parties responsible for information security requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service;
- the allocation of responsibility or identification of parties responsible for privacy requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ];
- the allocation of responsibility or identification of parties responsible for supply chain risk management requirements, descriptions, and criteria are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ];
- acceptance criteria requirements and descriptions are included explicitly or by reference using [Selection(one-or-more): standardized contract language; {{ insert: param, sa-04_odp.02 }} ] in the acquisition contract for the system, system component, or system service.
Assessment Method
Examine
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of information security and privacy and supply chain risk management into the acquisition process
configuration management plan
acquisition contracts for the system, system component, or system service
system design documentation
system security plan
supply chain risk management plan
privacy plan
other relevant documents or records
Interview
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with information security and privacy responsibilities
system/network administrators
organizational personnel with supply chain risk management responsibilities
1. Oversigt
| Titel |
Standard |
|
SA-04(01) [H] Functional Properties of Controls
|
Control
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.
Discussion
Functional properties of security and privacy controls describe the functionality (i.e., security or privacy capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls.
Assessment Objective
the developer of the system, system component, or system service is required to provide a description of the functional properties of the controls to be implemented.
Assessment Method
Examine
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of security and privacy requirements, descriptions, and criteria into the acquisition process
solicitation documents
acquisition documentation
acquisition contracts for the system, system component, or system services
system security plan
privacy plan
other relevant documents or records
Interview
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with information security and privacy responsibilities
system developers
|
|
SA-04(02) [H] Design and Implementation Information for Controls
|
Control
Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [Selection(one-or-more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; {{ insert: param, sa-04.02_odp.02 }} ] at [Assignement: level of detail].
Discussion
Organizations may require different levels of detail in the documentation for the design and implementation of controls in organizational systems, system components, or system services based on mission and business requirements, requirements for resiliency and trustworthiness, and requirements for analysis and testing. Systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules and the interfaces between modules providing security-relevant functionality. Design and implementation documentation can include manufacturer, version, serial number, verification hash signature, software libraries used, date of purchase or download, and the vendor or download source. Source code and hardware schematics are referred to as the implementation representation of the system.
Assessment Objective
the developer of the system, system component, or system service is required to provide design and implementation information for the controls that includes using [Selection(one-or-more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; {{ insert: param, sa-04.02_odp.02 }} ] at [Assignement: level of detail].
Assessment Method
Examine
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
solicitation documents
acquisition documentation
acquisition contracts for the system, system components, or system services
design and implementation information for controls employed in the system, system component, or system service
system security plan
other relevant documents or records
Interview
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility to determine system security requirements
system developers or service provider
organizational personnel with information security responsibilities
|
|
SA-04(05) [H] System, Component, and Service Configurations
|
Control
Require the developer of the system, system component, or system service to:- Deliver the system, component, or service with [Assignement: security configurations] implemented; and
- Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.
Discussion
Examples of security configurations include the U.S. Government Configuration Baseline (USGCB), Security Technical Implementation Guides (STIGs), and any limitations on functions, ports, protocols, and services. Security characteristics can include requiring that default passwords have been changed.
Assessment Objective
- the developer of the system, system component, or system service is required to deliver the system, component, or service with [Assignement: security configurations] implemented;
- the configurations are used as the default for any subsequent system, component, or service reinstallation or upgrade.
Assessment Method
Examine
System and services acquisition policy
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
solicitation documents
acquisition documentation
acquisition contracts for the system, system component, or system service
security configurations to be implemented by the developer of the system, system component, or system service
service level agreements
system security plan
other relevant documents or records
Interview
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility to determine system security requirements
system developers or service provider
organizational personnel with information security responsibilities
|
|
SA-04(09) [H] Functions, Ports, Protocols, and Services in Use
|
Control
Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.
Discussion
The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design stages) allows organizations to influence the design of the system, system component, or system service. This early involvement in the system development life cycle helps organizations avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services or requiring system service providers to do so. Early identification of functions, ports, protocols, and services avoids costly retrofitting of controls after the system, component, or system service has been implemented. [SA-9](#sa-9) describes the requirements for external system services. Organizations identify which functions, ports, protocols, and services are provided from external sources.
Assessment Objective
- the developer of the system, system component, or system service is required to identify the functions intended for organizational use;
- the developer of the system, system component, or system service is required to identify the ports intended for organizational use;
- the developer of the system, system component, or system service is required to identify the protocols intended for organizational use;
- the developer of the system, system component, or system service is required to identify the services intended for organizational use.
Assessment Method
Examine
System and services acquisition policy
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
system design documentation
system documentation, including functions, ports, protocols, and services intended for organizational use
acquisition contracts for systems or services
acquisition documentation
solicitation documentation
service level agreements
organizational security requirements, descriptions, and criteria for developers of systems, system components, and system services
system security plan
other relevant documents or records
Interview
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility for determining system security requirements
system/network administrators
organizational personnel operating, using, and/or maintaining the system
system developers
organizational personnel with information security responsibilities
|
|
SA-04(10) [H] Use of Approved PIV Products
|
Control
Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.
Discussion
Products on the FIPS 201-approved products list meet NIST requirements for Personal Identity Verification (PIV) of Federal Employees and Contractors. PIV cards are used for multi-factor authentication in systems and organizations.
Assessment Objective
only information technology products on the FIPS 201-approved products list for the Personal Identity Verification (PIV) capability implemented within organizational systems are employed.
Assessment Method
Examine
Supply chain risk management plan
system and services acquisition policy
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
solicitation documentation
acquisition documentation
acquisition contracts for the system, system component, or system service
service level agreements
FIPS 201 approved products list
system security plan
other relevant documents or records
Interview
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility for determining system security requirements
organizational personnel with the responsibility for ensuring that only FIPS 201- approved products are implemented
organizational personnel with information security responsibilities
|
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede reguleringer
2. Identificerede krav
3. Relaterede reguleringer
Reguleringer
| Kilde |
Regulering |
Linkede sager
|