CMMC Practice 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).

Source

CMMC Version 1.02, pg. 126

Bold Coast Security Guidance

For Level 5 compliance, your organization must have an organization-wide standard in practice for implementing processes related to information security. This means standard forms, data storage requirements, review/monitoring of each process and control, and reporting to appropriate stakeholders. Integrity is the middle of three pillars of Information Security's CIA triad. Confidentiality, Integrity, and Availability. Integrity simply means that software and data are as intended, without unauthorized tampering or change. The importance integrity has countless downstream implications. Imagine if a piece of software you relied upon to perform financial calculations, or medical analytics, was somehow altered or corrupted for a malicious purpose? Most software is designed with some integrity protections, and that includes all of the common operating systems and off-the-shelf applications. These protections include "input validation" controls, to ensure user-defined fields will only accept inputs that match pre-defined criteria and string values. There are also hardware-level protections like those mentioned in the CMMC guidance, above, e.g., TPM. As in all program elements, risk should be the main factor in deciding what integrity protections are appropriate in your environment. There are systems designed for the specific purpose of monitoring any changes to core system and application files. This is accomplished through a cryptographic mechanism called a "checksum". When installed, a checksum is created for a critical file, and if that checksum changes, an alert is sent to a user-configured resource for investigation.

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. FIPS180-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.

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