DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.1

Editor’s note: This article is one of a series of articles about the CMMC Level 1 Practices. In these articles we dive into the CMMC Practice Guides and provide our thoughts about the practices and what contractors should consider. The CMMC ecosystem is still developing, and as those developments occur, we will update these articles accordingly. As such, we hope that these articles represent an evergreen CMMC Level 1 resource.

(source: CMMC ML-1 Assessment Guide)

Note: CMMC practice RA.L2-3.11.1 – Vulnerability Scanning and RA.L2-3.11.2 – Vulnerability Remediation are CMMC Level 2 requirements. For organizations that are targeting CMMC Level 2, there will almost certainly be some overlap/redundancy with the subject of this article SI.L1-3.14.1 – Flaw Remediation.

Overview of SI.L1-3.14.1

According to IBM’s Cost of a Data Breach Report 2023, roughly 6% of data breaches start with an attacker leveraging known vulnerabilities in software or firmware. The infamous Equifax data breach, in which hackers stole the personally identifiable information of 147 million Americans, was perpetrated by exploiting an unpatched vulnerability in the Apache Struts framework on an Equifax webserver.

These attacks also target end users. Such attacks start with a victim user being prompted to open a malicious file with a vulnerable application. When the application tries to open the malicious file, the application is usually forced into an error state, such as a buffer overflow, from which the malicious file can now run its own arbitrary code.

This happens more than you might think. The Common Vulnerability and Exposure (CVE) database, for example, reports 22 new vulnerabilities for Adobe Acrobat Reader in the first four months of 2024; 82 in 2023, and a staggering 2,115 vulnerabilities dating back to 1999. Nearly every recent Acrobat Reader vulnerability is exploited when victim users “open a malicious file.”

The good news, however, is that software manufacturers are generally pretty good about releasing patches to fix the vulnerabilities. Organizations that want to shore up those vulnerabilities have to apply those patches when they are available.

SI.L1-3.14.1 is the CMMC requirement that requires patching security vulnerabilities. Although simple in concept, organizations with complex infrastructure or immature endpoint security will have some work to do.

Flaw Remediation has six assessment objectives, which relate to three main areas:

1. Identifying flaws [a, b]
2. Reporting flaws [c, d]
3. Correcting flaws [e, f]

Half of the objectives require formalizing timelines to identify [a], report [c], and correct [e] flaws; the other half [b, d, and f] require implementation of those timelines.

Software Inventory – A Helpful Prerequisite

To patch vulnerable software or firmware, you must first know a flaw exists to patch. And to know if a flaw exists to patch, you must first know what software and firmware is installed on your systems and network. A well-designed patching program is therefore predicated on the ability to maintain an inventory of software and firmware.

When creating an inventory, we recommend considering software that runs on:

• Network devices – Firewalls, managed switches, wireless access points, and other network devices all have a type of software called firmware that needs patching.
• Servers – Including the operating system and any other software necessary for the server to perform its function.
• End-user computers – Operating systems, office productivity software, web browsers, PDF readers, and more.
• IoT Devices – Multi-function printers, cameras, etc.

The most challenging of the above are end-user computers, and that challenge is most acute in organizations that allow end-users unrestricted rights to install software, usually through local admin privileges.

Maintaining a software inventory and a functioning patching program is practically impossible if end users can install whatever they want.

Organizations should disable local admin rights for end users wherever possible. If local admin privileges are necessary, as may be the case when certain end-user software requires it, other mitigations should be implemented to prevent unauthorized software from running (such as AppLocker).

Organizations may also find it helpful to use automated tools to generate inventory reports, monitor the software installed on end-user computers, and even patch them.

Identify Flaws

Once an organization has a reliable system inventory, it needs to have documented mechanisms to be notified when there are flaws and/or patches. This will typically mean some combination of configuring automated alerts or periodically checking sources for flaw notifications.

Organizations should identify in policy the cadence with which system flaws must be identified from the point in time they are published, e.g., weekly [a]. This establishes organizational requirements from which those tasked with execution can use to implement the practice.

To identify the flaws, we recommend organizations document how to identify flaws for each item in the system inventory [b]. Some examples might include:

• In-application notifications of an available patch
• Periodically visiting the vendor’s security notifications website
• Subscribing to the vendor’s security notifications
• Periodically logging into a device’s administration interface to check for available updates

Reporting Flaws

For many small and midsize organizations, there is no practical distinction between identification [a, b] and reporting [c, d]. This is because the same person or team often performs system administration and security functions, and there is no need to report something to yourself!

Larger organizations that have dedicated security analysts, who are constantly on the hunt for vulnerabilities and flaws, should document time frames for reporting flaws to system administrators [c] and report them through a formal mechanism such as an internal ticketing system [d].

Correcting Flaws

With knowledge of what needs correcting, administrators can correct the actual flaws. Most commonly, this is simply the application of security patches that are available from the vendor. However, correcting a flaw could be changing a configuration, for example, using a more secure cipher in a site-to-site VPN.

Organizations should document in policy a timeframe within which to correct flaws [e] and implement a process to apply the corrections within that timeframe [f].

For SMBs, we recommend a document, such as the one below, that identifies all the software and firmware within the enclave that needs patching as well as other information needed to implement the practice, including who is responsible.

Evidence

To retain evidence that these patching activities are occurring, we recommend documenting each one in a ticket within the organization’s ticketing system. Ticket types, tags, and naming conventions could further assist in the generation of evidence for an assessor or to support your Senior Official’s Annual Affirmation.

With the following in place, organizations should have no problem passing this practice:

• Policies defining timeliness requirements for flaw identification, reporting, and correction
• Implementation details/instructions for each type of software/firmware (see the example in the table above)
• Tickets showing when the activities take place
• The ability to show the current versions of software for an assessor wishing to check individual software / firmware installations

Monitoring

Applying software patches is a largely automated process and computer operations tend to be deterministic. Once configured it should just work, right?

Not exactly. The reality, however, is that applying updates across an enterprise is notoriously fickle, especially when it comes to end user computers. For a variety of reasons, some computers get stuck and never successfully install a patch without manual intervention.

CMMC Level 2 contains practice requirements for Security Control Assessments (CA.L2-3.12.1) and Security Control Monitoring (CA.L2-3.12.3). Adding a layer of monitoring and periodic assessments to your system patching will help catch those patching recalcitrant systems and support Level 2 requirements.

Conclusion

SI.L1-3.14.1 – Flaw Remediation – requires organizations to identify, report, and correct flaws in a timely manner. For most, this is a simple matter of layering some additional governance and documentation onto existing system patching processes. However, organizations that have provided end users with the ability to download and install any software will have some additional work.

Many DoD contractors will not have the expertise or resources needed to perform a CMMC readiness assessment, identify the gaps, and develop corrective action plans. In these cases, the contractors are turning to cybersecurity consultants with knowledge of NIST and the CMMC framework. If you want to learn more about CMMC, Keiter’s team of cybersecurity specialists can help you. Email | Call: 804.747.0000.

Our team will continue to monitor the rollout of the CMMC program and update you on new information and changing requirements for DoD contractors.