Requirement text: CM.5.074: 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).
DISCUSSION FROM SOURCE: DRAFT NIST SP 800-171B (MODIFIED)
Verifying the integrity of the organization’s security critical or essential software is an
important capability as 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 and correctness 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. Formal
verification involves proving that a software program satisfies some formal property or set
of properties. The nature of such formal verification is generally time consuming and not
employed for most commercial operating systems and applications. Therefore, it would
likely only be applied to some very limited uses such as verifying cryptographic protocols.
However, in cases where software exists with formal verification of its security properties,
such software provides more assurance and trustworthiness and is preferred over similar
software that has not been formally verified. The use 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. NIST
SP 800-147 provides BIOS protection guidance. The NIST Roots of Trust project provides
additional guidance.
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.
References
• CMMC modification of Draft NIST SP 800-171B 3.14.1e
• CIS Controls v7.1 2.10
• NIST CSF v1.1 PR.DS-6, PR.DS-8, PR.IP-2
• CERT RMM v1.2 TM:SG2.SP2
• NIST SP 800-53 Rev 4 SI-7(6), SI-7(9), SI-7(10), SA-17