Level 5 CMMC - CMMC Practices

CM.5.074  

Reference: CMMC 1.02

Family: CM

Level Introduced: 5

Practice:
Verify the integrity and correctness of security critical or essential software as defined by the organization (e.g., roots of trust, formal verification, or cryptographic signatures).

CMMC Clarification:
Systems that perform a critical security function or processing of highly valued CUI data may contain a Trusted Platform Module (TPM) version 1.2 or higher chip. The organization will configure the systems the organization has identified to use a secure boot process (i.e., verify the signature of the OS loader and all kernel objects match expected values) and key applications are authenticated before running them. These procedures ensure the integrity of the security critical software.

Example 1
You are the IT manager for your organization. You have been tasked with building a new server and the organization requires all servers to use a secure boot process. You follow the procedure published by the server vendor to go in to the BIOS settings and enable Secure Boot and install the operating system to use Secure Boot.

Example 2
You purchase desktop and laptop computers for your organization. Before placing an order for five new systems, you check with the vendor to confirm these systems all contain a TPM 2.0 chip. When the laptops are received, you follow the vendor’s procedures to configure the systems to use Secure Boot, install the organization’s standard security applications and test that everything is working correctly before making the laptops available for the new employees to use.

3.14.1e

Verify the integrity of [Assignment: organization-defined security critical or essential software] using root of trust mechanisms or cryptographic signatures.

Discussion:
Verifying the integrity of the organization’s security-critical or essential software is an important capability since corrupted software is the primary attack vector used by adversaries to undermine or disrupt the proper functioning of organizational systems. There are many ways to verify software integrity throughout the system development life cycle. Root of trust mechanisms, such as secure boot and trusted platform modules, verify that only trusted code is executed during boot processes. This capability helps system components protect the integrity of boot firmware in organizational systems by verifying the integrity and authenticity of updates to the firmware prior to applying changes to the system component and preventing unauthorized processes from modifying boot firmware. The employment of cryptographic signatures ensures the integrity and authenticity of critical and essential software that stores, processes, transmits, or protects CUI. Cryptographic signatures include digital signatures and the computation and application of signed hashes using asymmetric cryptography, protecting the confidentiality of the key used to generate the hash, and using the public key to verify the hash information.

[FIPS 140-3] provides security requirements for cryptographic modules. [FIPS 180-4] and [FIPS 202] provide secure hash standards. [FIPS 186-4] provides a digital signature standard. [SP 800-147] provides BIOS protection guidance. [NIST TRUST] provides guidance on the roots of trust project.

Source: NIST Special Publication 800-172 (Draft)

SI-7 (6)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | CRYPTOGRAPHIC PROTECTION

Description:
The information system implements cryptographic mechanisms to detect unauthorized changes to software, firmware, and information.

Supplemental Guidance:
Cryptographic mechanisms used for the protection of integrity include, for example, digital signatures and the computation and application of signed hashes using asymmetric cryptography, protecting the confidentiality of the key used to generate the hash, and using the public key to verify the hash information. Related control: SC-13.

SI-7 (9)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | VERIFY BOOT PROCESS

Description:
The information system verifies the integrity of the boot process of [Assignment: organization-defined devices].

Supplemental Guidance:
Ensuring the integrity of boot processes is critical to starting devices in known/trustworthy states. Integrity verification mechanisms provide organizational personnel with assurance that only trusted code is executed during boot processes.

SI-7 (10)

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | PROTECTION OF BOOT FIRMWARE

Description:
The information system implements [Assignment: organization-defined security safeguards] to protect the integrity of boot firmware in [Assignment: organization-defined devices].

Supplemental Guidance:
Unauthorized modifications to boot firmware may be indicative of a sophisticated, targeted cyber attack. These types of cyber attacks can result in a permanent denial of service (e.g., if the firmware is corrupted) or a persistent malicious code presence (e.g., if code is embedded within the firmware). Devices can protect the integrity of the boot firmware in organizational information systems by: (i) verifying the integrity and authenticity of all updates to the boot firmware prior to applying changes to the boot devices; and (ii) preventing unauthorized processes from modifying the boot firmware.

SA-17

DEVELOPER SECURITY ARCHITECTURE AND DESIGN

Description:
The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:
    a. Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture;
    b. Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and
    c. Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.

Supplemental Guidance:
This control is primarily directed at external developers, although it could also be used for internal (in-house) development. In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations develop an information security architecture and such security architecture is integrated or tightly coupled to the enterprise architecture. This distinction is important if/when organizations outsource the development of information systems, information system components, or information system services to external entities, and there is a requirement to demonstrate consistency with the organization’s enterprise architecture and information security architecture. Related controls: PL-8, PM-7, SA-3, SA-8.

Source: NIST Special Publication 800-53 Rev. 4

Source: CMMC v1.02