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).
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.
(MODIFIED 800-171B) 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 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.
CIS Controls v7.1 2.10
NIST SP 800-53 Rev 4 SI-7(6), SI-7(9), SI-7(10), SA-17
NIST CSF v1.1 PR.DS-6, PR.DS-8, PR.IP-2
CERT RMM v1.2 TM:SG2.SP2
CMMC modification of Draft NIST SP 800-171B 3.14.1e