Achieving CMMC / DFARS compliance is no easy feat. With 110 controls and 320 objectives, the NIST 800-171 standard can be challenging to even the most experienced security professional.
In 2023, the DIBCAC revealed the top 10 most frequently failed, or “other than satisfied,” NIST 800-171 requirements. In this blog, we’ll break down each of these requirements and dissect their challenging, ambiguous components so you can feel confident about achieving and maintaining compliance.
3.13.11, FIPS-validated cryptography [Systems and Communication Protection (SC)]
Topping the list of most frequently missed requirements is 3.13.11, which states that whenever encryption is used to protect the confidentiality of CUI at rest or in transit, the encryption module must be FIPS-validated 140-1 or -2 or NSA-approved.
Organizations fail this requirement for several reasons. Many simply fail to ensure that their encryption modules are validated, or they’ll only check that the algorithms are validated, not the module as a whole. Additionally, many companies acquire FIPS-capable technology but don’t properly configure it to run in FIPS mode.
Another common reason organizations fail 3.13.11 is because of how many dependencies it has. If you miss any of the following related requirements, 3.13.11 won’t be met:
- AC.L2-3.1.13 – Remote Access Confidentiality
- AC.L2-3.1.19 – Encrypt CUI On Mobile
- MP.L2-3.8.6 – Portable Storage Encryption
- IA.L2-3.5.10 – Cryptographically-protected Passwords
- MP.L2-3.8.6 – Portable Storage Encryption (Mind the “unless” condition)
- SC.L2-3.13.8 – Data In Transit (Mind the “unless” condition)
- SC.L2-3.13.10 – Key Management
- SC.L2-3.13.16 – Data At Rest (Mind the “unless” condition — can utilize physical safeguards in lieu)
3.5.3, Multifactor Authentication [Identification and Authentication (IA)]
The next most frequently missed NIST 800-171 requirement is 3.5.3, which states that you must use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts.
This requirement has several conditions — which many organizations fail to address — baked into it. This includes:
- Using MFA for privileged accounts on local access. 3.5.3[b]
- Using MFA for privileged accounts on network access. 3.5.3[c]
- Using MFA for non-privileged accounts on network access.3.5.3[d]
You’ll also need to identify all privileged accounts, as per 3.5.3[a]. Failure to provide this list of accounts, or to implement MFA for every account and component, will result in not passing.
When it comes to successfully enforcing MFA, there are two primary methods: adding the enforcement mechanism at the endpoint level via a method like offline mode or PKI, and/or adding the enforcement mechanism at a container or captive portal level before users can access the CUI enclave. MFA must be enforced in all layers where CUI is processed, stored, or transmitted. If CUI is stored on the endpoint, then the offline mode/PKI is a must.
The critical decision point is ensuring that MFA is enforced in all layers where CUI is processed, stored, or transmitted. If CUI is stored on the endpoint, then the offline mode/PKI is a must.
3.14.1, Identify, report, and correct system flaws [System and Information Integrity (SI)]
3.14.1 states that organizations must identify, report, and correct information and information system flaws in a timely manner.
To identify system flaws, you must perform continuous monitoring activities like system scans, vulnerability scans, threat intel monitoring, and risk assessments. To report system flaws, you must present the findings, periodically, of your continuous monitoring activities to previously defined stakeholders. And to correct system flaws, you must actually remediate these findings, following a previously defined risk-based approach.
Passing 3.14.1 requires, at a minimum, a vulnerability scanner and patch management strategy (i.e. process, tools, and personnel). It also requires you to define what a “timely manner” is and then abide by this definition in 3.14.1[a], 3.14.1[c], and 3.14.1[e].
3.11.1, Periodically assess risk [Risk Assessment (RA)]
To pass 3.11.1, you must periodically assess the risk of processing, storing, or transmitting CUI to organizational operations, assets, and individuals.
This control requires a system categorization, definition of the operating environment, and/or organizational level understanding of the programs and products affected by and affecting the DoD services and products and thus those that process, store, or transmit CUI.
Passing 3.11.1 requires your organization to have the following:
- Risk management program and methodology that defines how the organization will assess, monitor, and manage risk.
- Risk assessment schedule that defines the frequency and use cases of these assessments.
- Risk management remediation plan that defines the course of action for addressing risks, which can be created in alignment with the Plan of Actions and Milestones (POA&Ms) process.
3.11.2, Scan for vulnerabilities [Risk Assessment (RA)]
3.11.2 states that organizations must scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities are identified. It ties into several other requirements from the Risk Assessment (RA), Audit and Accountability (AU), and System Information (SI) families.
To fulfill this requirement, you must have a vulnerability management program capable of scanning for and detecting vulnerabilities through automated, pre-scheduled, ad-hoc, or manual on-demand scans.
In these scans, you should look for functions, ports, protocols, and services that could be vulnerable, as well as configuration settings and information/data flow. You may also monitor for system deviation from the previously defined baseline configuration setting, likely established in alignment with DISA STIGs or CIS Benchmark.
3.3.3, Review and update logged events [Audit and Accountability (AU)]
3.3.3 requires that you review and update logged events, and it extends the AU, RA, AC, CA, CM, and SI requirement families.
To pass this requirement, you’ll need to have correctly categorized your information and information systems. Additionally, you’ll need to have defined the audit records necessary to support cyber incidents and investigation.
After these prerequisites are in place, you’ll need to review all discoverable events and take actions per the risk assessment/management strategy. Make sure KRIs are monitored and risk is managed at organizationally defined levels.
Defining the review process of log records is a key component of this requirement. The review, human or non-human, should generate actions to avoid risk, reduce the logging requirements, or update the audit record to maximize the auditing strategy. The update of audit records can be performed as an operational task but ideally via the established POAMs process.
3.3.4, Audit logging process failure alerts [Audit and Accountability (AU)]
To pass 3.3.4, your organization must have a system in place to alert you in the event of an audit logging process failure.
The alerting use cases can include:
- If a system, or system component, is not generating the required audit events.
- If a system is generating the logs but not sending/forwarding them to the SIEM.
- If a system is generating the logs and sending/forwarding them to the SIEM, but the SIEM is not consuming them after being forwarded.
- If a system is offline for an extended period of time.
- If the SIEM is at or near capacity.
- If the SIEM is malfunctioning.
The most frequent reason organizations fail this requirement is because they don’t formalize the notification process. To pass, ensure that you’ve categorized your information systems and identified the systems, system components, logging capability(ies) use cases, and the personnel responsible for responding to the alert.
3.3.5, Audit record review, analysis, and reporting processes [Audit and Accountability (AU)]
3.3.5 states that you must correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
In other words, you must take a big-picture, integrated approach to your audit review proces that allows you to cross-reference events happening in different areas of your network.
By being able to identify commonalities between system flaws and indicators of compromise (IOCs) — something typically achieved through a SIEM — you’ll be in a much better place to conduct remediation activities.
To pass 3.3.5, you must have performed all previous AU requirements correctly as well as have the internal resources in place to review and analyze the auditable events. Additionally, you must formally define “unlawful, unauthorized, suspicious, or unusual behavior” and the reporting process for when this behavior is detected. This reporting process must have a predetermined list of key internal and external stakeholders.
3.6.3, Test Incident Response Capability [Incident Response (IR)]
3.6.3 requires that your organization tests its incident response (IR) capability.
To do this, you must have an incident handling, response, and reporting policy, plan, and program in place (3.6.1 and 3.6.2). Your IR plan must be operational, meaning it goes beyond the concept level and into day-to-day activities or tests. This plan must also include an IR team and IR process that details the incident handling lifecycle up to, and including, reporting.
Per NIST 800-84, organizations may develop test, training, and exercise (TT&E) programs to support 3.6.3:
- Test: Organizations may choose to perform periodic tests of their IR Plan’s reporting capability to validate identified vulnerabilities and IOCs within the defined timeframe and report into the DIBNet within 72 hours of discovery.
- Training: The organization ensures the IR Team is fully aware of their responsibilities when the IR Plan is enacted.
- Exercise: Organizations are strongly advised to conduct periodic tabletop exercises. They can also conduct functional exercises in lieu of tabletop exercises that are aimed to test specific functions within the IR Team through simulations.
3.4.1, Establish/maintain baseline configuration [Configuration Management (CM)]
3.4.1 is one of the most taxing requirements. To satisfy it, you must have:
- Established baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation)
- Maintained, reviewed, and updated baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation)
- Established a secure system development lifecycle (SSDLC)
- Incorporated the respective secure system development lifecycles to day-to-day operations, including through their system’s acquisition process (buy vs. build).
A common reason for failing 3.4.1 is maintaining inventories and baselines that don’t cover all components of the system in scope, especially software and network device firmware. Deploying centralized configuration management databases (CMDB) can make this requirement a bit less daunting.
Pass Your C3PAO or DIBCAC High Assessment the First Time with SP6
At SP6, our mission is simple: safeguard your data, slash cyber risk, and secure compliance. Our Certified CMMC Professionals (CCPs) and Certified CMMC Assessors (CCAs) have 15+ years of experience empowering companies to reduce the cost, workload, and complexity of security and compliance.
To get started, start a conversation with us today.
