SA-4 Acquisition Process (L) (M) (H)

NIST SP 800-53 (r4) Control:

The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs:

a. Security functional requirements;

b. Security strength requirements;

c. Security assurance requirements;

d. Security-related documentation requirements;

e. Requirements for protecting security-related documentation;

f. Description of the information system development environment and environment in which the system is intended to operate; and

g. Acceptance criteria.

NIST 800-53 (r4) Supplemental Guidance:

Information system components are discrete, identifiable information technology assets (e.g., hardware, software, or firmware) that represent the building blocks of an information system. Information system components include commercial information technology products. Security functional requirements include security capabilities, security functions, and security mechanisms. Security strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to direct attack, and resistance to tampering or bypass. Security assurance requirements include: (i) development processes, procedures, practices, and methodologies; and (ii) evidence from development and assessment activities providing grounds for confidence that the required security functionality has been implemented and the required security strength has been achieved. Security documentation requirements address all phases of the system development life cycle.

Security functionality, assurance, and documentation requirements are expressed in terms of security controls and control enhancements that have been selected through the tailoring process. The security control tailoring process includes, for example, the specification of parameter values through the use of assignment and selection statements and the specification of platform dependencies and implementation information. Security documentation provides user and administrator guidance regarding the implementation and operation of security controls. The level of detail required in security documentation is based on the security category or classification level of the information system and the degree to which organizations depend on the stated security capability, functions, or mechanisms to meet overall risk response expectations (as defined in the organizational risk management strategy). Security requirements can also include organizationally mandated configuration settings specifying allowed functions, ports, protocols, and services. Acceptance criteria for information systems, information system components, and information system services are defined in the same manner as such criteria for any organizational acquisition or procurement. The Federal Acquisition Regulation (FAR) Section 7.103 contains information security requirements from FISMA. Related controls: CM-6, PL-2, PS-7, SA-3, SA-5, SA-8, SA-11, SA-12.

NIST 800-53 (r5) Discussion:

Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in 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 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.

38North Guidance:

Meets Minimum Requirement:

• • The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).

  • Contracts for IT services, software, or hardware, must include security functional, strength and assurance requirements; requirements to document security-related information and for protecting security-related documentation (to include a description of the information system development environment and environment in which the system is intended to operate); and defining and documenting acceptance criteria.

  • External services must also be FedRAMP-authorized.

Best Practice:

• • Document the requirement that all external services must be FedRAMP-authorized.

  • Document and maintain contracts and service level agreements for prior and current vendors/contractors.

  • Update contract requirements and criteria annually as part of reviewing security requirements (if/when required).

  • Develop a process to monitor and maintain vendors and contractors which includes maintaining any documentation related to risk assessments or cost-benefit analysis related to service contracts and agreements.

  • Designate a specific role(s) with authority to determine if vendors meet functional requirements.

  • Define the protections in place to safeguard all security documentation, both storage as well as access control related.

Unofficial FedRAMP Guidance:

• • The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred (refer to https://www.niap-ccevs.org/Product/)

  • SA-4 Additional FedRAMP Requirements and Guidance (L) (M) (H): The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).

Assessment Evidence:

• • Documented Policy describing the CSPs IT acquisition process along with requirements and criteria to be included in contract with external vendors/contractors.

  • List of approved IT vendors (include software/hardware) and associated Service Level Agreements (SLAs).

  • Documentation supporting acquisitions of IT technology, contracts with agreements for IT services, or other evidence for acquired system components (hardware, software, firmware) showing that security requirements are documented (including, but not limited to, security functional, strength, assurance, documentation, etc.).

  • Risk assessments or cost/benefit analysis performed prior to purchasing IT services or software/hardware.

  • Samples of acquisition contracts or documented evidence to show:

    • Security requirements are addressed

    • A description of the product is provided

    • The security controls employed by the product

    • A plan for continuous monitoring is produced

    • The functions, ports, protocols, and services required to operation are defined

    • Testing performed on acquired product prior to implementation
      

CSP Implementation Tips:

• • None.