Flaw remediation is the most difficult CMMC level one practice. It was the only level one practice on the top 10 other than satisfied requirements. Patch management is the process of installing  patches, and updates throughout an organization. This includes identifying, prioritizing, acquiring, installing, and verifying patches. This blog will discuss the following topics around NIST SP 800-171 practice 3.14.1:

• A Brief History
• Practice Statement
• Assessment Objectives
• NIST SP 800-53 Objectives
• Analysis of Discussion
• DoD Criticality
• Scope of Applicability
• Inheritance
• Implementation
• Continuous Monitoring Tasks
• Policy Statements
• Proposed Rev 3 Changes

NIST introduced special publication (SP) 800-171 in 2015. NIST kept the practice number of 3.14.1 through their first and second revisions. NIST SP 800-171 Revision 3 has changed this requirement's number to 03.14.01.

The cybersecurity maturity model certification (CMMC) rule will verify SP 800-171 Rev 2. CMMC 1.02 numbered this practice SI.1.210 then SI.L1-3.14.1 under CMMC 2.0. This practice applies to organizations seeking compliance within any level of CMMC.

As of December 2023, CMMC 2.1 created two numbers for this practice:

• CMMC Level 1 uses the label SI.L1-B.1.XII. Section b(xii) references the Federal Acquisition Regulation (FAR) clause 52.204-21.

• CMMC Level 2 uses the label SI.L2-3.14.1. SI identifies the system and information integrity domain. L2 identifies the applicability to CMMC Level 2. 3.14.1 references the original number from NIST SP 800-171 Rev 2.

NIST derived the SP 800-171 basic security requirements from FIPS 200. Below is the original language from FIPS 200:

NIST split this into three practices within SP 800-171. The first part became 3.14.1:

NIST SP 800-171A provides assessment procedures for SP 800-171 security requirements. These procedures apply assessment methods to objects. Assessment methods include examining artifacts, interviewing personnel, and testing mechanisms. An assessor checks each part to determine a finding. Satisfied findings identify acceptable implementations. Other than satisfied findings identify one or more anomalies.

The assessment objectives for 3.14.1 contains six parts:

Appendix D maps SP 800-171 requirements to controls from SP 800-53 Rev 4. This mapping relates 3.14.1 to SI-2, SI-3 and SI-5. The mapping also suggests the same relationship exists for 3.14.2 and 3.14.3. Mapping this practice to SP 800-53 is more challenging since NIST derived it from FIPS 200.

We mapped these six objectives to the closest SP 800-53A Rev 5 objectives. NIST IR 8477 guidance helped define the nature and strength of the relationships. The findings indicated that:

• SI.L1-3.14.1(a) intersects with SI-02_ODP (moderate strength)
• SI.L1-3.14.1(b) intersects with SI-02a.[01] (moderate strength)
• SI.L1-3.14.1(c) intersects with SI-02_ODP (nominal strength)
• SI.L1-3.14.1(d) intersects with SI-02a.[02] (strong relationship)
• SI.L1-3.14.1(e) intersects with SI-02_ODP (strong relationship)
• SI.L1-3.14.1(f) intersects with SI-02a.[03] (strong relationship)

The CMMC Assessment Guide includes supplemental guidance from SP 800-53 Rev 4. 

Flaw Remediation

The CMMC guide derived the discussion from the supplemental guidance from SI-2. 

The CMMC Assessment Guide also provides a further discussion. This narrative provides actionable steps:

All software and firmware have potential flaws. Many vendors work to remedy those flaws by releasing vulnerability information and updates. Contractors must have a process to review relevant vendor notifications about weaknesses. After reviewing the information, the contractor must have a patch management process. The process enables the contractor to fix flaws without affecting the system functionality. Contractors must define the time frames to identify, report, and correct flaws. Consider purchasing support from your vendors to ensure timely access to updates.

The CMMC Assessment Guide also provides an example:

Software vendors release patches, service packs, and hot fixes to make software up to date. You develop a policy requiring checking vendor websites for notifications every week [a]. The policy requires an assessment of flaw severity. It requires patches implemented on computers once each week and servers once each month [c,e]. You configure the system to check for updates depending on the criticality of the software [b,e]. Your team reviews available updates and implements them according to the schedule [f].

The NIST SP 800-171 DoD Assessment Methodology Version 1.2.1 assigns this practice a 5-point value. Failing this practice may lead to data exfiltration or exploitation of the network. CMMC section 170.21(ii) removed this practice's eligibility for a limited deficiency. This practice aligns to the basic cybersecurity safeguards requirements of 52.204-21.

NIST SP 800-53 Rev 5 appendix C discusses three implementation approaches:

• (S) implemented by an information system through technical means
• (O) implemented by an individual through nontechnical means
• (O/S) implemented by an organization, system, or combination of the two

NIST defines the SI-2 as implemented through nontechnical means. The crosswalk suggests that 3.14.1 is a nontechnical practice performed by an individual.  

It is possible to inherit or share this practice with an external service provider. The Ariento shared responsibility matrix indicates 3.14.1 as an inherited practice:

The PreVeil solution also shows 3.14.1 as an inherited practice. It is important to understand the scope of each shared responsibility matrix. The PreVeil solution does not address any other systems or endpoints.

The shared responsibility for the KTL 360 enclave specifies some customer responsibilities. 

Before addressing the six parts within this practice, there are three prerequisite steps. We derived these steps from NIST SP 800-40. First, organizations should consider patching requirements early in the system architecture planning stage. Second, maintaining an inventory of assets enables patching from a per-asset perspective. Third, assign assets to maintenance groups based on technical and business characteristics. This provides the basis for better decision making for risk responses and priorities. These steps establish a better foundation for addressing each part of this practice.

System Architecture Planning

Organizations should strive to decrease the number of vulnerabilities introduced into their environments. This shrinks the attack surface and reduces the burden of patching. Consider software maintenance factors when procuring software. For example, consider how many patches they release each year.  Also consider ways to deploy applications that make patching less disruptive. For example, run software within cloud-based containers instead of on-premises server operating systems.

Maintain an Inventory of Software and Assets

Patching is reliant on knowing which software and software versions are in use. Identifying and classifying assets based on impact levels helps determine patching priorities. Establish and maintain up-to-date software inventories. You may leverage tools to discover assets across the enterprise and the cloud. These tools also help inventory their firmware, operating systems (OS), and applications. Software inventories should include technical characteristics and business characteristics. The following are examples of possible technical characteristics to track:

• The asset’s platform type (e.g., IT, OT, IoT, mobile, cloud, VM)
• The party who administrates the asset 
• The applications, services, or other mechanisms used to manage the asset
• The asset’s network connectivity (protocols, frequency/duration, and bandwidth) 
• The technical security controls already in place to safeguard the asset
• The asset’s primary user(s) or interconnected services and their privileges 

Business characteristics provide context for the risk responses to vulnerable software. Examples of business characteristics that an organization should track include:

• The asset’s role and importance to the organization
• Laws, regulations, or policies specifying how soon to address a vulnerability
• Contractual restrictions on patching
• Mission/business restrictions on risk responses for that asset 

Assign Asset Inventory to Maintenance Groups

Organizations should assign each asset to a maintenance group. Each maintenance group has similar characteristics and maintenance needs for risk response scenarios. Maintenance needs include patching and other appropriate forms of mitigation and risk response. This includes temporary mitigations used when patches are not yet available. Reassess their definitions on a scheduled frequency and adjust them as needed. Consider including a maintenance group for “exceptions”.

NIST SP 800-40 provides examples of possible maintenance groups: 

Defining time to identify system flaws

Establish a frequency and process to identify weaknesses within system components. Policy statements and supporting procedures meet this part of the practice. There are two related controls from NIST SP 800-53 that would identify system flaws:

‍SI-5: Security alerts, advisories and directives. Applying the FedRAMP moderate baseline organization defined-parameters, the first three parts read:

• SI-05a. - Receive system security alerts and advisories from US-CERT and CISA on an ongoing basis.
• SI-05b. - Generate internal security alerts, advisories, and directives as deemed necessary.
• SI-05c. - Disseminate security alerts and advisories to system security personnel with patch-management responsibilities.‍
• RA-5: Vulnerability monitoring and scanning. Applying the FedRAMP moderate baseline organization defined-parameters, the first three parts read:
• RA-05a. - Scan for vulnerabilities in the system and hosted applications monthly. Run a vulnerability scan after identifying new vulnerabilities that might affect the system.
• RA-05b. - Use vulnerability monitoring techniques and automate parts of the vulnerability management process. Use standards for:
  • Enumerating platforms, software flaws, and improper configurations;
  • Formatting checklists and test procedures; and
  • Measuring vulnerability impact 
• RA-05c. - Analyze vulnerability scan reports and results from vulnerability monitoring.

Defining time to report system flaws

Establish a frequency and process to document flaws identified. Policy statements and supporting procedures meet this part of the practice. Document flaw identification, analysis, and any planned remediation. Determine whether identified vulnerabilities exist in the system. Assess the criticality of the vulnerability and the affected system. Document the planned risk response.

Defining time to correct system flaws 

Establish a frequency and process to correct flaws identified. Policy statements and supporting procedures meet this part of the practice. The related control, vulnerability monitoring and scanning (RA-5), provides more specific guidance. Applying the FedRAMP moderate baseline organization defined-parameters to RA-5, the fourth part reads:

RA-05d. - remediate legitimate vulnerabilities:

• within 30 days from date of discovery for high-risk vulnerabilities 
• within 90 days from date of discovery for moderate-risk vulnerabilities 
• within 180 days from date of discovery for low risk vulnerabilities

Conducting a risk assessment of each new vulnerability is not workable. Organizations do not have the time, resources, expertise, or tools to do so. Planning in advance enables faster decision making when a new vulnerability becomes known. The determination of risk is dependent on two factors. The impact of exploitation and the likelihood of exploitation. Organizations assign impact levels when they define the maintenance groups. There are several methods that focus on the likelihood of vulnerability exploitation:

• Common Vulnerability Scoring System (CVSS)
• Exploit Prediction Scoring System EPSS
• Vulnerability Priority Rating (VPR)

The Stakeholder-Specific Vulnerability Categorization (SSVC) is an alternative approach. Carnegie Mellon’s SSVC generates decisions through a decision tree using qualitative inputs. Inputs include the following:

• Exploitation - measures the present state of vulnerability exploitation
  • None - No evidence of active exploitation
  • Proof of Concept (PoC) - one of the following is true
    • Threat actors sell or trade exploit code underground
    • PoC exists in public places (Metasploit or ExploitDB)
    • Vulnerability has a well-known method of exploitation
  • Active - reliable evidence of exploit used in the wild by attackers

• System Exposure - measures the attack surface of the affected system
  • Small - local service or program in a controlled network
  • Controlled - Networked service with some access restrictions or mitigations already in 

place. The number of steps in the attack path is low.

• Open - Internet accessible network where access is not restricted or controlled.

• Utility - combines the exploitation value with the ease of exploitation. Ease of exploitation is either automatable or not automatable. Determine exploitation value based on available resources in the vulnerable system. Diffuse value indicates the vulnerable system contains limited resources. Concentrated value indicates the vulnerable system is rich in resources. Utility values include:
  • Laborious - not automatable and diffuse value
  • Efficient - automatable and concentrated value OR not automatable and diffuse value
  • Super Effective - automatable and concentrated value

• Impact - combines the value of safety impact and mission impact. Safety impact values include none, minor, major, hazardous, and catastrophic. Mission impact may affect non-essential systems or supporting mission essential functions (MEF).  More significant mission impacts include MEF failure, and mission failure. The combined human impact values include
  • Low (No or minor safety impact and impacts to non-essential or supporting systems)
  • Medium (MEF failure and minor safety impact OR major safety impact)
  • High (MEF failure and major safety impact OR hazardous safety impact)
  • Very High (catastrophic safety impact or mission failure)

These inputs generate an outcome based on the decision tree. The image below shows part of this decision tree:

Outcomes include the following:

• Defer - Do not act at present (Low Vulnerability Importance)
• Scheduled - Act during routine patching - (Moderate Importance)
• Out-of-Cycle - Act quicker than usual to apply the fix (High Important)
• Immediate - Act immediately on applying the fix (Critical Importance)

Regardless of the risk assessment method, define times to remediate legitimate vulnerabilities.  Organizations should define risk response scenarios for each maintenance group. The maintenance plan defines actions when a scenario occurs for a maintenance group. NIST SP 800-40 includes examples of scenarios:

• Routine patching. This is the standard procedure for patches that are on a regular release cycle. Most patching falls under this scenario. Routine patching includes endpoint firmware, OS, and applications. It also includes server OS and applications hosted on-premises or in the cloud. Consider adopting phased deployments for routine patching. Install the patch on a small subset of the assets first. These assets act as canaries for identifying issues. In effect, this is how the patching gets tested. If the canary assets have minimal impact, the deployment can expand to all assets. This helps address significant problems before the rollout expands.

• Emergency patching. This includes severe vulnerabilities or known vulnerabilities exploited in the wild. Emergency patching  prevents the imminent exploitation of vulnerable assets. Consider accelerating the approach used in routine patching. It may still be beneficial to first deploy a new patch to a small number of canary assets. This will help confirm the patch is not corrupted and does not break the software. This period could last a few minutes to a few hours. The emergency patching itself could occur in the following hours or days.

• Emergency mitigation. This involves implementing short-term mitigations before a patch is available. Plan for the quick implementation of several types of emergency mitigations.  Mitigations may involve deactivating system functionality or isolating an asset from other assets. You may or may not roll back the mitigation after deploying the patch. Plan to replace emergency mitigations with permanent fixes. Set and enforce schedules for both patch deployment and mitigation removal.

• Unpatchable assets. Use isolation or other methods to mitigate the risk of unpatchable systems. This may include unsupported legacy systems or systems with high operational uptime requirements. Include unpatchable assets in risk response planning. A new vulnerability might change the methods needed to mitigate its risk. Plan different types of long-term risk mitigations besides patching to protect vulnerable assets. There should be an approved set of methods for each maintenance group. Review and analyze these methods in advance to determine their adequacy mitigating risk.

Include a plan for ongoing tracking and monitoring exceptions to maintenance plans. Move assets with similar long-term exceptions to a separate maintenance group. Define maintenance groups to reduce exceptions.

Identifying system flaws

Know when new software vulnerabilities affect your organization’s assets. This includes applications, operating systems, and firmware. This might include monitoring threat feeds, including but not limited to: 

• CISA Cybersecurity Alerts & Advisories
• NIST National Vulnerability Database (NVD)
• CERT/CC Vulnerability Notes Database 
• Notifications from software and firmware vendors 

Patch and asset management tools can automate the detection process for most vulnerabilities. Some include “rapid response” capabilities for vulnerabilities already exploited in the wild. In rare cases, such as one-off misconfigurations and zero-days, perform manual scans. The CISA Cybersecurity Incident & Vulnerability Response Playbook suggests best practices to find exploitations:

• Sweep for known indicators of compromise associated with exploitation of the vulnerability.
• Investigate anomalous access attempts and behavior associated with vulnerable systems.
• Complete any detection processes in CISA directives.
• If needed, collaborate with a third-party incident responder.

At the end of the Evaluation step, the goal is to understand the status of each system in the environment as:

• Not Affected. The system is not vulnerable.
• Susceptible. No signs of exploitation but the system is vulnerable and remediation has begun.
• Compromised. Analysts found signs of exploitation in the vulnerable system. Incident response and vulnerability remediation has begun. 

Reporting system flaws

Reporting documents the risk of an identified vulnerability and selected risk response. Estimating the relative importance enables remediation or mitigation prioritization. To meet the reporting requirements using SVCC, create a database of vulnerabilities identified.

Organizations should use low-level metrics when developing enterprise-level metrics. These metrics should reflect the relative importance of each vulnerability and patch. NIST SP 800-40 includes a notional example of actionable performance metrics. Each cell provides metrics based on assets and vulnerability importance. The metrics document the percentage of assets patched by each maintenance plan deadline. The metrics also include the average (mean) time and median time for patching.

Organizations can also analyze mitigation times by other characteristics. This includes platform, business units, or maintenance groups. Analyzing data by different characteristics can provide more relevant metrics to particular audiences. This may include organizational executives, technology leadership, IT operations staff, and compliance professionals.

Correcting system flaws

Remediation is the elimination or removal of a vulnerability. Remediation includes applying patches, fixes and upgrades. Automation helps keep up with patching systems with a large number of components. Remediation may also include removing the vulnerable software or system from operation. Mitigation only decreases the impact or likelihood without reducing or eliminating the vulnerability. In most cases, remediation should consist of patching. In other cases, the following mitigations may be appropriate: 

• Limiting access
• Isolating vulnerable systems, applications, services, profiles, or other assets
• Making permanent configuration changes
• Disabling services
• Reconfiguring firewalls to block access
• Increasing monitoring to detect exploitation.

Executing the risk response includes the following common phases:

Preparing the risk response

This encompasses any preparatory activities, including:

• acquiring, validating, and testing patches for the vulnerable software 
• deploying new security controls to safeguard the vulnerable software 
• acquiring a replacement for an unpatchable legacy asset 
• scheduling the risk response 
• coordinating deployment plans with others

Implementing the risk response

Risk responses may include:

• distributing and installing a patch
• purchasing cybersecurity insurance
• deploying new security controls
• changing asset configurations and state (e.g., software reset, platform reboot)
• decommissioning or replacement of vulnerable assets

Verifying the risk response

This step involves ensuring successful completion of the risk response. For patching, this means confirming patch installation and has taken effect. For deploying new security controls, ensure they are functioning as intended. For risk avoidance, verify the decommissioning or replacement of vulnerable assets.

Continuous monitoring of the risk response 

Make sure that the risk response continues to be in place. This includes making sure:

• no one uninstalls the patch, 
• no one deactivates the new security controls, 
• the cybersecurity insurance doesn’t lapse, or 
• no one restarts the decommissioned asset.

In the last phase of the life cycle, use continuous monitoring to verify the patch is still installed. For example, monitoring could confirm that:

• a user or an attacker has not uninstalled the patch 
• a backup has not restored an unpatched version of the software 
• the device has not been reset to a vulnerable factory-default state.

Monitoring also helps determine changes in the patched software’s behavior. This might detect compromised patches.

There are administrative activities occurring throughout the software vulnerability management life cycle. This includes updating:

• system documentation 
• audit logging
• generating reports as part of enterprise change management

Once patches are available and applied, you may decide to remove temporary mitigations. Keep track of system status for reporting purposes using one of these categories:

• Remediated - application of the patch or configuration change eliminated the vulnerability
• Mitigated - application of compensating controls reduced the risk of the vulnerability.
• Susceptible - no action taken and the system is still susceptible 

A continuous monitoring task verifies that controls produce their desired outcome(s). The practice 3.14.1 has four desired outcomes:

• Specify the time within which to identify, report and correct system flaws.
• Identify system flaws within the specified time frame
• Report system flaws within the specified time frame
• Correct system flaws within the specified time frame

Update System Component Inventory to identify software versions in use. Organizations should also update business characteristics associated with each asset.

Checking for New Vulnerabilities may entail reviewing security alerts on a weekly basis. This task may also include running schedule vulnerable scans on a monthly basis.

Report New Vulnerabilities on a daily or weekly basis. Organizations should have a documented process to analyze vulnerabilities and categorize their severity.

Perform Regular System Patching at least once per month. 

Other tasks might include:

Review and update policies and procedures at least once a year. This should include maintenance group definitions and maintenance plans.

Tracking and monitoring exceptions to maintenance plans. Review exceptions weekly to determine if the maintenance plan can proceed.

Verify the risk response to new vulnerability remediations or mitigations. This includes verifying patch installations and that mitigating controls are functioning as intended.

System Component Inventory

• The IT department maintains an inventory of system assets that
  • Includes firmware, operating systems (OS), and applications
  • Assigns each system component to a maintenance group. 

Flaw Identification, Reporting, Mitigation and Remediation

• IT reviews security alerts from US-CERT, CISA, and vendors every 7 days.
• IT scans for software and firmware vulnerabilities in the system every 30 days. 
• IT updates a database of identified vulnerabilities every 7 days.
• IT applies all vendor-supplied security patches within 180 days of issue
• IT tests and applies all critical patches within 14 days of issue.
• IT reviews all exceptions to maintenance plans every 30 days.

NIST SP 800-171 Rev 3 aligns 03.14.01 with SI-2 from SP 800-53 Rev 5. Revision 3 removes the requirements defining a time to identify and report flaws. Since the identifying and reporting requirements remain, we rolled these parts into A[01] and A[02]. There are two organization defined parameters. These define the time for installing released security updates to software and firmware. Under Rev 2, these requirements both fall under defining the time to correct system flaws. Correcting system flaws remains as not all remediations involve firmware or software updates. Remediations and mitigations may also include configuration changes or network segmentation.

• ODP[01] - define time to install security-relevant software updates after their release
• ODP[02] - define time to install security-relevant firmware updates after their release 
• A[01] - identify system flaws
• A[02] - report system flaws
• A[03] - correct system flaws
• B[01] - install security-relevant software updates within the defined time
• B[02] - install security-relevant firmware updates within the defined time

The crosswalk below shows the mapping of these requirements back to related parts of 3.14.1 from Revision 2:

Conclusion

Vulnerability management requires a proactive approach. Disruptions from patching are controllable, while disruptions from incidents are uncontrollable. Address vulnerability management early in system architecture planning. Maintain accurate asset inventories to include software and firmware in use. Assign assets to appropriate maintenance groups tied to impact levels and risk responses. Identify and report on system flaws according to organizational policies. Use vulnerability scoring systems or decision trees to identify high risk vulnerabilities. Remediate legitimate vulnerabilities according to organizational policies. Schedule continuous monitoring activities to ensure that risk responses remain effective.