Verify the integrity of security critical and essential software using root of trust mechanisms or cryptographic signatures.
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 (e.g., secure boot, trusted platform modules, Unified Extensible Firmware Interface [UEFI]), 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 the boot firmware. The employment of cryptographic signatures ensures the integrity and authenticity of critical and essential software that stores, processes, or transmits, 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. Hardware roots of trust are considered to be more secure. This requirement supports 3.4.1e and 3.4.3.e.
[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. [NIST TRUST] provides guidance on the roots of trust project.
Organizations verify the integrity of security critical and essential software every time that software is executed. Secure boot mechanisms for firmware and a cryptographically protected boot chain ensure the integrity of the operating system (OS) and security critical software, and cryptographic techniques ensure the essential software has not been tampered with after development prior to execution. If software is itself considered to be CUI or if it uses CUI, this requirement ensures it has not been compromised.
Software and information integrity verification tools can help check the integrity during the development process for those organizations developing software. As critical software is updated, the integrity of any configuration data and the software must result in updated signatures and an ongoing verification process.
Operating systems include mechanisms to validate digital signatures for installed software. Most software packages use signatures to prove the integrity of the provided software, and the organization should leverage these capabilities. Similarly, most hardware appliance vendors have secure boot checks in place for their devices and built-in features that check the digital signature of an upgrade/update package before they allow an upgrade to take place. For locally developed software, the organization should sign the software to ensure its integrity.
You are responsible for information security in your organization. Your security team has identified the software used to process CUI, and the organization has decided it is mission-critical software that must be protected. You take three actions. First, you ensure all of the platform’s configuration information used at boot is hashed and stored in a TPM [a]. Second, you ensure that the platforms used to execute the software are started with a digitally signed software chain to a secure boot process using the TPM. Finally, you ensure the essential applications are cryptographically protected with a digital signature when stored and the signature is verified prior to execution [b].
Your organization has a software security team, and they are required to validate unsigned essential software provided to systems that do not have TPM modules. The organization has a policy stating no software can be executed on a system unless its hash value matches that of a hash stored in the approved software library kept by the software security team [a]. This action is performed by implementing software restriction policies on systems. The team tests the software on a sandbox system, and once it is proven safe, they run a hashing function on the software to create a hash value. This hash value is placed in a software library so the system will know it can execute the software [b]. Any changes to the software without the software security team’s approval will result in the software failing the security tests, and it will be prevented from executing.
Potential Assessment Considerations
- Does the organization use cryptographic signatures to ensure the integrity and authenticity of critical and essential software and data [b]?
- Has the organization identified those devices that require integrity verification of the boot process [a]?
- Does the organization use a TPM to store hashes of pre-run time configuration parameters for those systems [b]?
- Does the organization leverage the TPM configuration hash to verify the hardware and software configuration is unchanged in order to determine that a system is trustworthy before running mission-essential applications [b,c]?
- Does the organization use the TPM for remote attestation to determine to which extent information can be trusted from another system [b,c]?
- Has the organization identified devices requiring organization-defined security safeguards that must be implemented to protect the integrity of boot firmware [a]?
- Has the organization defined security safeguards that will be implemented to protect the integrity of boot firmware in mission-essential devices [a]?
- Has the organization implemented organization-defined security safeguards to protect the integrity of boot firmware in organization-defined essential devices [b]?