Level 3 Assessment Guide: Difference between revisions

From CMMC Toolkit Wiki
Jump to navigation Jump to search
← Older editNewer edit →
VisualWikitext
No edit summary
No edit summary
Line 111: Line 111:
For some requirements, the assessor reviews documentation to determine if assessment objectives are met. Interviews with OSC staff may identify the documents uses. Documents need to be in their final forms; working papers (e.g., drafts) of documentation are not eligible to be submitted as evidence because they are not yet official and are still subject to change.
For some requirements, the assessor reviews documentation to determine if assessment objectives are met. Interviews with OSC staff may identify the documents uses. Documents need to be in their final forms; working papers (e.g., drafts) of documentation are not eligible to be submitted as evidence because they are not yet official and are still subject to change.


Common types of documents that can be used as evidence include: <br />
Common types of documents that can be used as evidence include:
* policy, process, and procedure documents;
* policy, process, and procedure documents;
* training materials;
* training materials;
Line 328: Line 328:


== Risk Assessment (RA) ==
== Risk Assessment (RA) ==
=== RA.L3-3.11.1e – Threat-Informed Risk Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.1e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.2e – Threat Hunting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.2e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.3e – Advanced Risk Identification ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.3e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.4e – Security Solution Rationale ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.4e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.5e – Security Solution Effectiveness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.5e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.6e – Supply Chain Risk Response ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.6e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.7e – Supply Chain Risk Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_RA.L3-3.11.7e_Details|More Practice Details...]]
|}


== Security Assessment (CA) ==
=== CA.L3-3.12.1e – Penetration Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_CA.L3-3.12.1e_Details|More Practice Details...]]
|}


== System and Communications Protection (SC) ==
=== SC.L3-3.13.4e – isolation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
|-
|'''ASSESSMENT OBJECTIVES'''
|-
|[[Practice_SC.L3-3.13.4e_Details|More Practice Details...]]
|}


 
== System and Information Integrity (SI) ==
 
=== SI.L3-3.14.1e – Integrity Verification ===
 
{|class="wikitable"
 
|'''SECURITY REQUIREMENT'''
 
|-
|'''ASSESSMENT OBJECTIVES'''
 
|-
RA.L3-3.11.1e – Threat-Informed Risk Assessment
|[[Practice_SI.L3-3.14.1e_Details|More Practice Details...]]
 
|}
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
=== SI.L3-3.14.3e – Specialized Asset Security ===
 
{|class="wikitable"
48
|'''SECURITY REQUIREMENT'''
 
|-
''' '''
|'''ASSESSMENT OBJECTIVES'''
 
|-
 
|[[Practice_SI.L3-3.14.3e_Details|More Practice Details...]]
'''RA.L3-3.11.1E – THREAT-INFORMED RISK ASSESSMENT '''
|}
 
=== SI.L3-3.14.6e – Threat-Guided Intrusion Detection ===
Employ threat intelligence, at a minimum from open or commercial sources, and any DoD-
{|class="wikitable"
 
|'''SECURITY REQUIREMENT'''
provided sources, as part of a risk assessment to guide and inform the development of
|-
 
|'''ASSESSMENT OBJECTIVES'''
organizational systems, security architectures, selection of security solutions, monitoring,
|-
 
|[[Practice_SI.L3-3.14.6e_Details|More Practice Details...]]
threat hunting, and response and recovery activities.
|}
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[ODP1] Sources of threat intelligence are defined;'' <br />
''[a] A risk assessment methodology is identified; <br />
[b] Threat intelligence, at a minimum from open or commercial sources, and any
 
DoD-provided sources, are employed as part of a risk assessment to guide and inform the
 
development of organizational systems and security architectures;
 
[c] Threat intelligence, at a minimum from open or commercial sources, and any
 
DoD-provided sources, are employed as part of a risk assessment to guide and inform the
 
selection of security solutions;
 
[d] Threat intelligence, at a minimum from open or commercial sources, and any
 
DoD-provided sources, are employed as part of a risk assessment to guide and inform
 
system monitoring activities;
 
[e] Threat intelligence, at a minimum from open or commercial sources, and any
 
DoD-provided sources, are employed as part of a risk assessment to guide and inform
 
threat hunting activities; and
 
[f] Threat intelligence, at a minimum from open or commercial sources, and any
 
DoD-provided sources, are employed as part of a risk assessment to guide and inform
 
response and recovery activities.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: Information security program plan; risk assessment policy; threat
 
awareness program documentation; procedures for the threat awareness program; security
 
planning policy and procedures; procedures addressing organizational assessments of risk;
 
threat hunting program documentation; procedures for the threat hunting program; risk
 
assessment results relevant to threat awareness; threat hunting results; list or other
 
documentation on the cross-organization, information-sharing capability; security plan; risk
 
assessment; risk assessment results; risk assessment reviews; risk assessment updates;
 
 
 
 
 
 
 
 
 
RA.L3-3.11.1e – Threat-Informed Risk Assessment
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
49
 
''' '''
 
contingency planning policy; contingency plan; incident response policy; incident response
 
plan; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security program
 
planning and plan implementation; organizational personnel responsible for the threat
 
awareness and threat hunting programs; organizational personnel responsible for risk
 
assessments; organizational personnel responsible for the cross-organization, information-
 
sharing capability; organizational personnel responsible for information security;
 
organizational personnel responsible for contingency planning; organizational personnel
 
responsible for incident response; personnel with whom threat awareness information is
 
shared by the organization].
 
'''Test <br />
'''[SELECT FROM: Mechanisms supporting and/or implementing the threat awareness
 
program; mechanisms supporting and/or implementing the cross-organization,
 
information-sharing capability; mechanisms supporting and/or implementing the threat
 
hunting program; mechanisms for conducting, documenting, reviewing, disseminating, and
 
updating risk assessments; mechanisms supporting and/or implementing contingency
 
plans; mechanisms supporting and/or implementing incident response plans].
 
'''DISCUSSION [NIST SP 800-172] '''
 
The constant evolution and increased sophistication of adversaries, especially the APT,
 
makes it more likely that adversaries can successfully compromise or breach organizational
 
systems. Accordingly, threat intelligence can be integrated into each step of the risk
 
management process throughout the system development life cycle. This risk management
 
process includes defining system security requirements, developing system and security
 
architectures, selecting security solutions, monitoring (including threat hunting), and
 
remediation efforts. <br />
[NIST SP 800-30] provides guidance on risk assessments. [NIST SP 800-39] provides
 
guidance on the risk management process. [NIST SP 800-160-1] provides guidance on
 
security architectures and systems security engineering. [NIST SP 800-150] provides
 
guidance on cyber threat information sharing.
 
'''FURTHER DISCUSSION '''
 
An organization consumes threat intelligence and improves their security posture based on
 
the intelligence relevant to that organization and/or a system(s). The organization can
 
obtain threat intelligence from open or commercial sources but must also use any
 
DoD-provided sources. Threat information can be received in high volumes from various
 
providers and must be processed and analyzed by the organization. It is the responsibility of
 
the organization to process the threat information in a manner that is useful and actionable
 
to their needs. Processing, analyzing, and extracting the intelligence from the threat feeds
 
 
 
 
 
 
 
 
 
RA.L3-3.11.1e – Threat-Informed Risk Assessment
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
50
 
''' '''
 
and applying it to all organizational security engineering needs is the primary benefit of this
 
requirement. Note that more than one source is required to meet assessment objectives.
 
'''Example <br />
'''Your organization receives a commercial threat intelligence feed from FIRST and
 
government threat intelligence feeds from both USCERT and DoD/DC3 to help learn about
 
recent threats and any additional information the threat feeds provide [b,c,d,e,f]. Your
 
organization uses the threat intelligence for multiple purposes: <br />
•
 
To perform up-to-date risk assessments for the organization [a];
 
•
 
To add rules to the automated system put in place to identify threats (indicators of
 
compromise, or IOCs) on the organization’s network [e];
 
•
 
To guide the organization in making informed selections of security solutions [c];
 
•
 
To shape the way the organization performs system monitoring activities [d];
 
•
 
To manage the escalation process for identified incidents, handling specific events, and
 
performing recovery actions [f];
 
•
 
To provide additional information to the hunt team to identify threat activities [e];
 
•
 
To inform the development and design decisions for organizational systems and the
 
overall security architecture, as well as the network architecture [b,c];
 
•
 
To assist in decision-making regarding systems that are part of the primary network and
 
systems that are placed in special enclaves for additional protections [b]; and
 
•
 
To determine additional security measures based on current threat activities taking place
 
in similar industry networks [c,d,e,f].
 
'''Potential Assessment Considerations <br />
'''•
 
Does the organization detail how threat feed information is to be ingested, analyzed, and
 
used [a]?
 
•
 
Can the organization’s SOC or hunt teams discuss how they use the threat feed
 
information after it is processed [e,f]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.1e
 
 
 
 
 
 
 
 
 
 
 
RA.L3-3.11.2e – Threat Hunting
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
51
 
''' '''
 
'''RA.L3-3.11.2E – THREAT HUNTING '''
 
Conduct cyber threat hunting activities on an on-going aperiodic basis or when indications
 
warrant, to search for indicators of compromise in organizational systems and detect, track,
 
and disrupt threats that evade existing controls.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[ODP4] Organizational systems to search for indicators of compromise are defined;'' <br />
''[a] Indicators of compromise are identified; <br />
[b] Cyber threat hunting activities are conducted on an on-going aperiodic basis or when
 
indications warrant, to search for indicators of compromise in organizational systems;
 
and
 
[c] Cyber threat hunting activities are conducted on an on-going aperiodic basis or when
 
indications warrant, to detect, track, and disrupt threats that evade existing controls.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: System and information integrity policy; policy and procedures addressing
 
system monitoring; threat hunting program documentation; procedures for the threat
 
hunting program; threat hunting results; system design documentation; security plan;
 
system monitoring tools and techniques documentation; security planning policy and
 
procedures; system configuration settings and associated documentation; system
 
monitoring logs or records; system audit records; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for threat hunting program;
 
system/network administrators; organizational personnel responsible for information
 
security; system developers; organizational personnel installing, configuring, and/or
 
maintaining the system; organizational personnel responsible for monitoring the system
 
and/or network].
 
'''Test <br />
'''[SELECT FROM: Mechanisms supporting and/or implementing a threat hunting program;
 
mechanisms supporting and/or implementing a system monitoring capability; mechanisms
 
supporting and/or supporting and/or implementing incident response plans].
 
'''DISCUSSION [NIST SP 800-172] '''
 
Threat hunting is an active means of defense that contrasts with traditional protection
 
measures, such as firewalls, intrusion detection and prevention systems, quarantining
 
 
 
 
 
 
 
 
 
RA.L3-3.11.2e – Threat Hunting
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
52
 
''' '''
 
malicious code in sandboxes, and Security Information and Event Management (SIEM)  
 
technologies and systems. Cyber threat hunting involves proactively searching
 
organizational systems, networks, and infrastructure for advanced threats. The objective is
 
to track and disrupt cyber adversaries as early as possible in the attack sequence and to
 
measurably improve the speed and accuracy of organizational responses. Indicators of
 
compromise are forensic artifacts from intrusions that are identified on organizational
 
systems at the host or network level and can include unusual network traffic, unusual file
 
changes, and the presence of malicious code. <br />
Threat hunting teams use existing threat intelligence and may create new threat information,
 
which may be shared with peer organizations, Information Sharing and Analysis
 
Organizations (ISAO), Information Sharing and Analysis Centers (ISAC), and relevant
 
government departments and agencies. Threat indicators, signatures, tactics, techniques,
 
procedures, and other indicators of compromise may be available via government and non-
 
government cooperatives, including Forum of Incident Response and Security Teams, United
 
States Computer Emergency Response Team, Defense Industrial Base Cybersecurity
 
Information Sharing Program, and CERT Coordination Center. <br />
[NIST SP 800-30] provides guidance on threat and risk assessments, risk analyses, and risk
 
modeling. [NIST SP 800-160-2] provides guidance on systems security engineering and
 
cyber resiliency. [NIST SP 800-150] provides guidance on cyber threat information sharing.
 
'''FURTHER DISCUSSION '''
 
For this requirement, threat hunting is conducted on an on-going aperiodic basis. On-going
 
aperiodic refers to activities that happen over and over but without an identifiable repeating
 
pattern over time. For threat hunting, on-going activities take place in an automated manner
 
(e.g., collecting logs, automated analysis, and alerts). Aperiodicity includes humans
 
performing the hunt activities, which take place on an as-needed or as-planned basis. <br />
APTs can penetrate an environment by means that defeat or avoid conventional monitoring
 
methods and alert triggers—for example, by using zero-day attacks. Zero-day attacks
 
become known only after the attack has happened and alerts are sent via threat intelligence
 
feeds based on expert analysis. Because of the nature of zero-day attacks, automated alerts
 
do not generally trigger when the event occurs but the activity is captured in system logs and
 
forwarded for analysis and retention by the SIEM. Threat intelligence information is typically
 
used by hunt teams to search SIEM systems, system event and security logs, and other
 
components to identify activity that has already taken place on an environment. The hunt
 
team will identify systems related to the event(s) and pass the case to Incident Response
 
team for action on the event(s). The hunt team will also use indicators to identify smaller
 
components of an attack and search for that activity, which may help uncover a broader
 
attack on the environment. <br />
Threat hunting can also look for anomalous behavior or activity based on an organization’s
 
normal pattern of activity. Understanding the roles and information flows within an
 
organization can help identify activity that might be indicative of adversary behavior before
 
the adversary completes their attack or mission.
 
 
 
 
 
 
 
 
 
RA.L3-3.11.2e – Threat Hunting
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
53
 
''' '''
 
'''Example <br />
'''You are the lead for your organization’s cyber threat hunting team. You have local and
 
remote staff on the team to process threat intelligence. Your team is tied closely with the SOC
 
and IR teams. Through a DoD (DC3) intelligence feed, you receive knowledge of a recent
 
APT’s attacks on defense contractors. The intelligence feed provided the indicators of
 
compromise for a zero-day attack that most likely started within the past month. After
 
receiving the IOCs, you use a template for your organization to place the information in a
 
standard format your team understands. You then email the information to your team
 
members and place the information in your hunt team’s dashboard, which tracks all IOCs [a]. <br />
Your team starts by using the information to hunt for IOCs on the environment [b]. One of
 
your team members quickly responds, providing information from the SIEM that an HR
 
system’s logs show evidence that IOCs related to this threat occurred three days ago. The
 
team contacts the owner of the system as they take the system offline into a quarantined
 
environment. Your team pulls all logs from the system and clones the storage on the system.
 
Members go through the logs to look for other systems that may be part of the APT’s attack
 
[c]. While the team is cloning the storage system for evidence, you alert the IR team about
 
the issue. After full forensics of the system, your team has verified your company has been
 
hit by the APT, but nothing was taken and no additional attacks happened. You also alert DoD
 
(DC3) about the finding and discuss the matter with them. There is an after action report and
 
a briefing given to management to make them aware of the issue.
 
'''Potential Assessment Considerations <br />
'''•
 
Does the organization have a methodology for performing cyber threat hunting actions
 
[b,c]?
 
•
 
Has the organization defined all organizational systems within scope of cyber threat
 
hunting, including valid and approved documentation for any organization systems that
 
are not within scope [b,c]?
 
•
 
Has the organization identified a specific set of individuals to perform cyber threat
 
hunting [b,c]?
 
•
 
Does the threat hunting team have qualified staff members using the threat feed
 
information [b,c]?
 
•
 
Does the threat hunting team use combinations of events to determine suspicious
 
behaviors [b,c]?
 
•
 
Does the organization have a documented list of trusted threat feeds that are used by
 
their cyber hunt teams as the latest indicators of compromise during their efforts [a]?
 
•
 
Does the organization have a clear methodology for processing threat feed information
 
and turning it into actionable information they can use for their threat hunting approach
 
[a]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.2e
 
 
 
 
 
 
 
 
 
 
RA.L3-3.11.3e – Advanced Risk Identification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
54
 
''' '''
 
'''RA.L3-3.11.3E – ADVANCED RISK IDENTIFICATION '''
 
Employ advanced automation and analytics capabilities in support of analysts to predict and
 
identify risks to organizations, systems, and system components.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] Advanced automation and analytics capabilities to predict and identify risks to
 
organizations, systems, and system components are identified;
 
[b] Analysts to predict and identify risks to organizations, systems, and system components
 
are identified; and
 
[c] Advanced automation and analytics capabilities are employed in support of analysts to
 
predict and identify risks to organizations, systems, and system components.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: System and information integrity policy; risk assessment policy; security
 
planning policy and procedures; procedures addressing organizational assessments of risk;
 
procedures addressing system monitoring; enterprise architecture documentation; system
 
design documentation; system architecture and configuration documentation; system
 
monitoring tools and techniques documentation; system configuration settings and
 
associated documentation; system monitoring logs or records; system audit records;
 
security plan; risk assessment artifacts; risk assessment results; risk assessment reviews;
 
risk assessment updates; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security;
 
organizational personnel responsible for risk assessments; risk analysts; system developers;
 
organizational personnel installing, configuring, and/or maintaining the system;
 
organizational personnel responsible for monitoring; system/network administrators].
 
'''Test <br />
'''[SELECT FROM: Automated mechanisms supporting and/or implementing risk analytics
 
capabilities; automated mechanisms supporting and/or implementing system monitoring
 
capability; automated mechanisms supporting and/or implementing the discovery,
 
collection, distribution, and use of indicators of compromise; automated mechanisms for
 
conducting, documenting, reviewing, disseminating, and updating risk assessments].
 
 
 
 
 
 
 
 
 
RA.L3-3.11.3e – Advanced Risk Identification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
55
 
''' '''
 
'''DISCUSSION [NIST SP 800-172] '''
 
A properly resourced Security Operations Center (SOC) or Computer Incident Response
 
Team (CIRT) may be overwhelmed by the volume of information generated by the
 
proliferation of security tools and appliances unless it employs advanced automation and
 
analytics to analyze the data. Advanced automation and predictive analytics capabilities are
 
typically supported by artificial intelligence concepts and machine learning. Examples
 
include Automated Workflow Operations, Automated Threat Discovery and Response
 
(which includes broad-based collection, context-based analysis, and adaptive response
 
capabilities), and machine-assisted decision tools. <br />
[NIST SP 800-30] provides guidance on risk assessments and risk analyses.
 
'''FURTHER DISCUSSION '''
 
Advanced automation includes tools to correlate and reduce the cyber data overload created
 
by defensive tools, making the data understandable to the analyst. Automation also allows
 
the defensive mechanisms to respond rapidly when adversary events are identified.
 
Examples of such capabilities are SIEM; Security Orchestration, Automation, and Response
 
(SOAR); and Extended Detection and Response (XDR) tools. An example of an automated
 
rapid response action is a security alert being pushed to the SIEM while the organization’s
 
SOAR solution communicates to the network firewall to block communications to the remote
 
system identified in the security alert. <br />
SIEM is primarily a log collection tool intended to support data storage and analysis. It
 
collects and sends alerts to security personnel for further investigation. SOAR is a software
 
stack that enables an organization to collect data about security threats and respond to
 
security events without human assistance in order to improve security operations.
 
Orchestration connects and integrates disparate internal and external tools. Automation, fed
 
by the data and alerts collected from security orchestration, ingests and analyzes data and
 
creates repeated, automated responses. SOAR incorporates these capabilities based on the
 
SIEM data and enables disparate security tools to coordinate with one another. SOAR can use
 
artificial intelligence to predict and respond to similar future threats, if such tools are
 
employed. <br />
XDR streamlines security data ingestion, analysis, prevention, and remediation workflows
 
across an organization’s entire security stack, providing a single console to view and act on
 
threat data. However, the presence of these tools by themselves does not necessarily provide
 
an advanced capability. It is essential that the security team employ critical thinking in
 
support of the intrusion detection and threat hunting processes.
 
'''Example <br />
'''You are responsible for information security in your organization. The organization holds
 
and processes CUI in an enterprise. To protect that data, you want to minimize phishing
 
attacks through the use of Security Orchestration and Automated Response (SOAR). Rather
 
than relying on analysts to manually inspect each inbound item, emails containing links
 
and/or attachments are processed by your automation playbook. Implementation of these
 
 
 
 
 
 
 
 
 
RA.L3-3.11.3e – Advanced Risk Identification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
56
 
''' '''
 
processes involves sending all email links and attachments to detonation chambers or
 
sandboxes prior to delivery to the recipient. When the email is received, SOAR extracts all
 
URL links and attachments from the content and sends them for analysis and testing [a]. The
 
domains in the URLs and the full URLs are processed against bad domain and URL lists. Next,
 
a browser in a sandbox downloads the URLs for malware testing. Lastly, any attachments are
 
sent to detonation chambers to identify if they attempt malicious activities. The hash of the
 
attachments is sent to services to identify if it is known malware [b]. If any one of the items
 
triggers a malware warning from the sandbox, detonation chamber, domain/URL validation
 
service, attachment hash check services, or AV software, an alert about the original email is
 
sent to team members with the recommendation to quarantine it. The team is given the
 
opportunity to select a “take action” button, which would have the SOAR solution take
 
actions to block that email and similar emails from being received by the organization [c].
 
'''Potential Assessment Considerations <br />
'''•
 
Has the organization implemented a security information and event management system
 
[a,c]?
 
•
 
Has the organization implemented security orchestration, automation, and response
 
tools [a,b,c]?
 
•
 
Does the organization use automated processing integrated with the SIEM system to
 
perform analytics [c]?
 
•
 
Can the organization demonstrate use of relevant threat data to inform detection
 
methods that in turn provide automated alerts/recommendations [c]?
 
•
 
Has the organization implemented an extended detection capability [c]?
 
•
 
Does the organization have the ability to merge traditional cyber data, such as network
 
packet captures (e.g., PCAP), or process logs with enrichment data, such as reputation or
 
categorization data [c]?
 
•
 
Can the organization provide examples of both basic and emerging analytics used to
 
analyze alert anomalies, e.g., both simple queries and unsupervised machine learning
 
algorithms that both improve their effectiveness and automatically filter, reduce, or
 
enrich alerting capabilities [c]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.3e
 
 
''' '''
 
 
 
 
 
 
 
 
 
RA.L3-3.11.4e – Security Solution Rationale
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
57
 
''' '''
 
'''RA.L3-3.11.4E – SECURITY SOLUTION RATIONALE '''
 
Document or reference in the system security plan the security solution selected, the
 
rationale for the security solution, and the risk determination.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] The system security plan documents or references the security solution selected; <br />
[b] The system security plan documents or references the rationale for the security solution;
 
and
 
[c] The system security plan documents or references the risk determination.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: system security plan; records of security plan reviews and updates; system
 
design documentation; security planning policy; procedures addressing security plan
 
development; procedures addressing security plan reviews and updates; enterprise
 
architecture documentation; enterprise security architecture documentation; system
 
interconnection security agreements and other information exchange agreements; other
 
relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security;
 
organizational personnel responsible for developing, implementing, or approving system
 
interconnection and information exchange agreements; personnel managing the systems to
 
which the Interconnection Security Agreement/Information Exchange Agreement applies;
 
system developers; organizational personnel responsible for security planning and plan
 
implementation; organizational personnel responsible for boundary protection; system
 
developers; system/network administrators].
 
'''Test <br />
'''[SELECT FROM: Organizational processes for security plan development, review, update,
 
and approval].
 
'''DISCUSSION [NIST SP 800-172] '''
 
System security plans relate security requirements to a set of security controls and solutions.
 
The plans describe how the controls and solutions meet the security requirements. For the
 
enhanced security requirements selected when the APT is a concern, the security plan
 
provides traceability between threat and risk assessments and the risk-based selection of a
 
security solution, including discussion of relevant analyses of alternatives and rationale for
 
 
 
 
 
 
 
 
 
RA.L3-3.11.4e – Security Solution Rationale
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
58
 
''' '''
 
key security-relevant architectural and design decisions. This level of detail is important as
 
the threat changes, requiring reassessment of the risk and the basis for previous security
 
decisions. <br />
When incorporating external service providers into the system security plan, organizations
 
state the type of service provided (e.g., software as a service, platform as a service), the point
 
and type of connections (including ports and protocols), the nature and type of the
 
information flows to and from the service provider, and the security controls implemented
 
by the service provider. For safety critical systems, organizations document situations for
 
which safety is the primary reason for not implementing a security solution (i.e., the solution
 
is appropriate to address the threat but causes a safety concern). <br />
[NIST SP 800-18] provides guidance on the development of system security plans.
 
'''FURTHER DISCUSSION '''
 
The System Security Plan (SSP) is a fundamental component of an organization’s security
 
posture. When solutions for implementing a requirement have differing levels of capabilities
 
associated with their implementation, it is essential that the plan specifically document the
 
rationale for the selected solution and what was acquired for the implementation. This
 
information allows the organization to monitor the environment for threat changes and
 
identify which solutions may no longer be applicable. While not required, it may also be
 
useful to document alternative solutions reviewed and differing levels of risk associated with
 
each alternative, as that information may facilitate future analyses when the threat changes.
 
In addition to the implementations required for Level 2 certification, which may not be risk
 
based, at Level 3, the SSP must carefully document the link between the assessed threat and
 
the risk-based selection of a security solution for the enhanced security requirements (i.e.,
 
all CMMC L3 requirements derived from NIST SP 800-172).
 
'''Example <br />
'''You are responsible for information security in your organization. Following CMMC
 
requirement RA.L3-3.11.1e – ''Threat Informed Risk Assessment'', your team uses threat
 
intelligence to complete a risk assessment and make a risk determination for all elements of
 
your enterprise. Based on that view of risk, your team decides that requirement
 
RA.L3-3.11.2e – ''Threat Hunting'' is a requirement that is very important in protecting your
 
organization’s use of CUI, and you have determined the solution selected could potentially
 
add risk. You want to detect an adversary as soon as possible when they breach the network
 
before any CUI can be exfiltrated. However, there are multiple threat hunting solutions, and
 
each solution has a different set of features that will provide different success rates in
 
identifying IOCs. <br />
As a result, some solutions increase the risk to the organization by being less capable in
 
detecting and tracking an adversary in your networks. To reduce risk, you evaluate five
 
threat hunting solutions and in each case determine the number of IOCs for which there is a
 
monitoring mechanism. You pick the solution that is cost effective, easy to operate, and
 
optimizes IOC detection for your enterprise; purchase, install, and train SOC personnel on its
 
use; and document the risk-based analysis of alternatives in the SSP. In creating that
 
 
 
 
 
 
 
 
 
RA.L3-3.11.4e – Security Solution Rationale
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
59
 
''' '''
 
documentation in the SSP, you follow the guidance found in NIST SP 800-18, ''Guide for ''
 
''Developing Security Plans for Federal Information Systems'' [a,b,c].
 
'''Potential Assessment Considerations <br />
'''•
 
Has the organization completed a risk assessment and made a risk determinations for
 
enterprise components that need to be protected [c]?
 
•
 
Can the organization identify what is being protected and explain why specific protection
 
solutions were selected [a,b]?
 
•
 
Have all the decisions been documented in the SSP [a,b,c]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.4e
 
 
''' '''
 
 
 
 
 
 
 
 
 
RA.L3-3.11.5e – Security Solution Effectiveness
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
60
 
''' '''
 
'''RA.L3-3.11.5E – SECURITY SOLUTION EFFECTIVENESS '''
 
Assess the effectiveness of security solutions at least annually or upon receipt of relevant
 
cyber threat information, or in response to a relevant cyber incident, to address anticipated
 
risk to organizational systems and the organization based on current and accumulated threat
 
intelligence.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] Security solutions are identified; <br />
[b] Current and accumulated threat intelligence is identified; <br />
[c] Anticipated risk to organizational systems and the organization based on current and
 
accumulated threat intelligence is identified; and
 
[d] The effectiveness of security solutions is assessed at least annually or upon receipt of
 
relevant cyber threat information, or in response to a relevant cyber incident, to address
 
anticipated risk to organizational systems and the organization based on current and
 
accumulated threat intelligence.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: Risk assessment policy; security planning policy and procedures; security
 
assessment policy and procedures; security assessment plans; security assessment results;
 
procedures addressing organizational assessments of risk; security plan; risk assessment;
 
risk assessment results; risk assessment reviews; risk assessment updates; threat
 
intelligence information; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for security assessments;
 
organizational personnel responsible for risk assessments; organizational personnel
 
responsible for threat analysis; organizational personnel responsible for information
 
security].
 
'''Test <br />
'''[SELECT FROM: Mechanisms supporting, conducting, documenting, reviewing,
 
disseminating, and updating risk assessments; mechanisms supporting and/or
 
implementing security assessments].
 
 
 
 
 
 
 
 
 
RA.L3-3.11.5e – Security Solution Effectiveness
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
61
 
''' '''
 
'''DISCUSSION [NIST SP 800-172] '''
 
Threat awareness and risk assessment of the organization are dynamic, continuous, and
 
inform system operations, security requirements for the system, and the security solutions
 
employed to meet those requirements. Threat intelligence (i.e., threat information that has
 
been aggregated, transformed, analyzed, interpreted, or enriched to help provide the
 
necessary context for decision making) is infused into the risk assessment processes and
 
information security operations of the organization to identify any changes required to
 
address the dynamic threat environment. <br />
[NIST SP 800-30] provides guidance on risk assessments, threat assessments, and risk
 
analyses.
 
'''FURTHER DISCUSSION '''
 
This requirement requires the organization to analyze threat intelligence and consider the
 
effectiveness of currently deployed cybersecurity solutions against existing, new, and
 
emerging threats. The goal is to understand the risk to the systems and the organization
 
based on threat intelligence and to make adjustments to security solutions to reduce the risk
 
to an acceptable level. Analysis of solutions should include analysis of operational system
 
settings of the deployed systems and not be solely a conceptual capability analysis. This
 
analysis includes verifying configuration settings are configured as desired by the
 
organization and have not been changed over time. <br />
Threat information can be thought of as raw data that may be limited in terms of evaluating
 
the effectiveness of controls across the enterprise. For example, knowledge of a threat that
 
has not been correlated with other threats may result in evaluation of an implementation
 
that only provides partial protection for one set of systems when, in fact, the emerging threat
 
is applicable to the entire enterprise. Large organizations may also have the resources to
 
aggregate, transform, analyze, correlate, interpret, and enrich information to support
 
decision-making about adequacy of existing security mechanisms and methods.
 
'''Example <br />
'''You are responsible for information security in your organization, which holds and
 
processes CUI. The organization subscribes to multiple threat intelligence sources [b]. In
 
order to assess the effectiveness of current security solutions, the security team analyzes any
 
new incidents reported in the threat feed. They identify weaknesses that were leveraged by
 
malicious actors and subsequently look for similar weaknesses in their own security
 
architecture[a,c]. This analysis is passed to the architecture team for engineering change
 
recommendations, including system patching guidance, new sensors, and associated alerts
 
that should be generated, and to identify ways to mitigate, transfer, or accept the risk
 
necessary to respond to events if they occur within their own organization [d].
 
 
 
 
 
 
 
 
 
RA.L3-3.11.5e – Security Solution Effectiveness
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
62
 
''' '''
 
'''Potential Assessment Considerations <br />
'''•
 
Does the organization make adjustments during an incident or operational
 
improvements after an incident has occurred [d]?
 
•
 
Has the organization implemented an analytical process to assess the effectiveness of
 
security solutions against new or compiled threat intelligence [b,c,d]?
 
•
 
Has the organization implemented a process to identify if an operational security
 
solution fails to contribute to the protections needed against specific adversarial actions
 
based on new threat intelligence [a,b,c,d]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.5e
 
 
''' '''
 
 
 
 
 
 
 
 
 
RA.L3-3.11.6e – Supply Chain Risk Response
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
63
 
''' '''
 
'''RA.L3-3.11.6E – SUPPLY CHAIN RISK RESPONSE '''
 
Assess, respond to, and monitor supply chain risks associated with organizational systems
 
and system components.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] Supply chain risks associated with organizational systems and system components are
 
identified;
 
[b] Supply chain risks associated with organizational systems and system components are
 
assessed;
 
[c] Supply chain risks associated with organizational systems and system components are
 
responded to; and
 
[d] Supply chain risks associated with organizational systems and system components are
 
monitored.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: Risk assessment policy; procedures addressing organizational assessments
 
of risk; security planning policy and procedures; supply chain risk management plan;
 
security plan; risk assessment; risk assessment results; risk assessment reviews; risk
 
assessment updates; threat intelligence information; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security;
 
organizational personnel responsible for risk assessments; organizational personnel
 
responsible for supply chain risk management].
 
'''Test <br />
'''[SELECT FROM: Mechanisms supporting, conducting, documenting, reviewing,
 
disseminating, and updating risk assessments].
 
'''DISCUSSION [NIST SP 800-172] '''
 
Supply chain events include disruption, use of defective components, insertion of
 
counterfeits, theft, malicious development practices, improper delivery practices, and
 
insertion of malicious code. These events can have a significant impact on a system and its
 
information and, therefore, can also adversely impact organizational operations (i.e.,
 
mission, functions, image, or reputation), organizational assets, individuals, other
 
organizations, and the Nation. The supply chain-related events may be unintentional or
 
malicious and can occur at any point during the system life cycle. An analysis of supply chain
 
 
 
 
 
 
 
 
 
RA.L3-3.11.6e – Supply Chain Risk Response
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
64
 
''' '''
 
risk can help an organization identify systems or components for which additional supply
 
chain risk mitigations are required. <br />
[NIST SP 800-30] provides guidance on risk assessments, threat assessments, and risk
 
analyses. [NIST SP 800-161 Rev. 1] provides guidance on supply chain risk management.
 
'''FURTHER DISCUSSION '''
 
Organizations will have varying policies, definitions, and actions for this requirement. It is
 
important for a single organization to be consistent and to build a process that makes sense
 
for their organization, strategy, unique supply chain, and the technologies available to them.
 
'''Example ''' <br />
You are responsible for information security in your organization, which holds and
 
processes CUI. One of your responsibilities is to manage risk associated with your supply
 
chain that may provide an entry point for the adversary. First, you acquire threat information
 
by subscribing to reports that identify supply chain attacks in enough detail that you are able
 
to identify the risk points in your organization’s supply chain [a]. You create an organization-
 
defined prioritized list of risks the organization may encounter and determine the responses
 
to be implemented to mitigate those risks [b,c]. <br />
In addition to incident information, the intelligence provider also makes recommendations
 
for monitoring and auditing your supply chain. You assess, integrate, correlate, and analyze
 
this information so you can use it to acquire monitoring tools to help identify supply chain
 
events that could be an indicator of an incident. This monitoring tool provides visibility of
 
the entire attack surface, including your vendors’ security posture [d]. Second, you analyze
 
the incident information in the intelligence report to help identify defensive tools that will
 
help respond to each of those known supply chain attack techniques as soon as possible after
 
such an incident is detected, thus mitigating risk associated with known techniques.
 
'''Potential Assessment Considerations <br />
'''•
 
Has the organization prioritized risks to the supply chain [a,b]?
 
•
 
Does the organization have viable service-level agreements that describe and enable
 
responses to supply chain incidents [c,d]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.6e
 
 
''' '''
 
 
 
 
 
 
 
 
 
RA.L3-3.11.7e – Supply Chain Risk Plan
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
65
 
''' '''
 
'''RA.L3-3.11.7E – SUPPLY CHAIN RISK PLAN '''
 
Develop a plan for managing supply chain risks associated with organizational systems and
 
system components; update the plan at least annually, and upon receipt of relevant cyber
 
threat information, or in response to a relevant cyber incident.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] Supply chain risks associated with organizational systems and system components are
 
identified;
 
[b] Organizational systems and system components to include in a supply chain risk
 
management plan are identified;
 
[c] A plan for managing supply chain risks associated with organizational systems and
 
system components is developed; and
 
[d] The plan for managing supply chain risks is updated at least annually, and upon receipt
 
of relevant cyber threat information, or in response to a relevant cyber incident.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: Risk assessment policy; supply chain risk management plan; security
 
planning policy and procedures; procedures addressing organizational assessments of risk;
 
security plan; risk assessment; risk assessment results; risk assessment reviews; risk
 
assessment updates; threat intelligence information; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security;
 
organizational personnel responsible for risk assessments; organizational personnel
 
responsible for supply chain risk management].
 
'''Test <br />
'''[SELECT FROM: Automated mechanisms supporting, conducting, documenting, reviewing,
 
disseminating, and updating risk assessments].
 
'''DISCUSSION [NIST SP 800-172] '''
 
The growing dependence on products, systems, and services from external providers, along
 
with the nature of the relationships with those providers, present an increasing level of risk
 
to an organization. Threat actions that may increase risk include the insertion or use of
 
counterfeits, unauthorized production, tampering, theft, insertion of malicious software and
 
hardware, and poor manufacturing and development practices in the supply chain. Supply
 
chain risks can be endemic or systemic within a system element or component, a system, an
 
 
 
 
 
 
 
 
 
RA.L3-3.11.7e – Supply Chain Risk Plan
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
66
 
''' '''
 
organization, a sector, or the Nation. Managing supply chain risk is a multifaceted
 
undertaking that requires a coordinated effort across an organization to build trust
 
relationships and communicate with both internal and external stakeholders. Supply chain
 
risk management (SCRM) activities involve identifying and assessing risks, determining
 
appropriate mitigating actions, developing SCRM plans to document selected mitigating
 
actions, and monitoring performance against plans. SCRM plans address requirements for
 
developing trustworthy, secure, and resilient systems and system components, including the
 
application of the security design principles implemented as part of life cycle-based systems
 
security engineering processes. <br />
[NIST SP 800-161 Rev. 1] provides guidance on supply chain risk management.
 
'''FURTHER DISCUSSION '''
 
An organization is required to have a supply chain risk management plan that assesses and
 
responds to the identified risks from those organizations that provide IT products or
 
services, including any cloud or other third-party services with a role in the operation of the
 
system. The organization should be cognizant of services outside the scope of the system but
 
required for the operation of the system as part of their plan. Since the cyber environment
 
changes rapidly and continuously, it is equally important for the organization to update the
 
plan in response to supply chain cyber incidents or emerging information.
 
'''Example <br />
'''You are responsible for information security in your organization, and you have created a
 
supply chain risk management plan [a,b,c]. One of the organization’s suppliers determines
 
that it has been the victim of a cyberattack. Your security team meets with the supplier to
 
determine the nature of the attack and to understand the adversary, the attack, the potential
 
for corruption of delivered goods or services, and current as well as future risks. The
 
understanding of the supply chain will help protect the local environment. Subsequently, you
 
update the risk management plan to include a description of the necessary configuration
 
changes or upgrades to monitoring tools to improve the ability to identify the new risks, and
 
when improved tools are available, you document the acquisition of defensive tools and
 
associated functionality to help mitigate any of the identified techniques [d].
 
'''Potential Assessment Considerations <br />
'''•
 
Does the organization’s current supply chain risk management plan apply across the
 
enterprise, or does it only apply to a limited portion of the supply chain [b]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.11.7e
 
 
 
 
 
 
 
 
 
CA.L3-3.12.1e – Penetration Testing
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
67
 
''' '''
 
Security Assessment (CA) <br />
'''CA.L3-3.12.1E – PENETRATION TESTING '''
 
Conduct penetration testing at least annually or when significant security changes are made
 
to the system, leveraging automated scanning tools and ad hoc tests using subject matter
 
experts.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] Automated scanning tools are identified; <br />
[b] Ad hoc tests using subject matter experts are identified; and <br />
[c] Penetration testing is conducted at least annually or when significant security changes
 
are made to the system, leveraging automated scanning tools and ad hoc tests using
 
subject matter experts.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: Security assessment policy; procedures addressing penetration testing;
 
security plan; security assessment plan; penetration test report; security assessment report;
 
security assessment evidence; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for security assessments; penetration
 
testing team; system/network administrators; organizational personnel responsible for
 
information security].
 
'''Test <br />
'''[SELECT FROM: Automated mechanisms supporting security assessments; automated
 
mechanisms supporting penetration testing].
 
'''DISCUSSION [NIST SP 800-172] '''
 
Penetration testing is a specialized type of assessment conducted on systems or individual
 
system components to identify vulnerabilities that could be exploited by adversaries.
 
Penetration testing goes beyond automated vulnerability scanning. It is conducted by
 
penetration testing agents and teams with particular skills and experience that include
 
technical expertise in network, operating system, and application-level security. Penetration
 
testing can be used to validate vulnerabilities or determine a system’s penetration resistance
 
to adversaries within specified constraints. Such constraints include time, resources, and
 
 
 
 
 
 
 
 
 
CA.L3-3.12.1e – Penetration Testing
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
68
 
''' '''
 
skills. Organizations may also supplement penetration testing with red team exercises. Red
 
teams attempt to duplicate the actions of adversaries in carrying out attacks against
 
organizations and provide an in-depth analysis of security-related weaknesses or
 
deficiencies. <br />
Organizations can use the results of vulnerability analyses to support penetration testing
 
activities. Penetration testing can be conducted internally or externally on the hardware,
 
software, or firmware components of a system and can exercise both physical and technical
 
controls. A standard method for penetration testing includes pretest analysis based on full
 
knowledge of the system, pretest identification of potential vulnerabilities based on the
 
pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All
 
parties agree to the specified rules of engagement before the commencement of penetration
 
testing. Organizations correlate the rules of engagement for penetration tests and red
 
teaming exercises (if used) with the tools, techniques, and procedures that they anticipate
 
adversaries may employ. The penetration testing or red team exercises may be organization-
 
based or external to the organization. In either case, it is important that the team possesses
 
the necessary skills and resources to do the job and is objective in its assessment. <br />
[NIST SP 800-53A] provides guidance on conducting security assessments.
 
'''FURTHER DISCUSSION '''
 
It is important that the organization has a repeatable penetration testing capability,
 
regardless of who performs the penetration testing. This requirement entails performing
 
tests against components of the organization’s architecture to identify cyber weaknesses and
 
vulnerabilities. It does not mean everything in the architecture requires penetration testing.
 
This requirement provides findings and mitigation strategies that benefit the organization
 
and help create a stronger environment against adversary efforts. It may be beneficial for
 
the organization to define the scope of penetration testing. The organization’s approach may
 
involve hiring an expert penetration testing team to perform testing on behalf of the
 
organization. When an organization has penetration testing performed, either by an internal
 
team or external firm, they should establish rules of engagement and impose limits on what
 
can be performed by the penetration test team(s). <br />
Ensuring the objectivity of the test team is important as well. Potential conflicts of interest,
 
such as having internal testers report directly or indirectly to network defenders or an
 
external test team contracted by network defense leadership, must be carefully managed by
 
organizational leadership. <br />
Reports on the findings should be used by the organization to determine where to focus
 
funding, staffing, training, or technical improvements for future mitigation strategies.
 
 
 
 
 
 
 
 
 
CA.L3-3.12.1e – Penetration Testing
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
69
 
''' '''
 
'''Example <br />
'''You are responsible for information security in your organization. Leveraging a contract
 
managed by the CIO, you hire an external expert penetration team annually to test the
 
security of the organization’s enclave that stores and processes CUI [a,c]. You hire the same
 
firm annually or on an ad hoc basis when significant changes are made to the architecture or
 
components that affect security [b,c].
 
'''Potential Assessment Considerations <br />
'''•
 
Does the organization have internal team members who possess the proper level of
 
expertise to perform a valued penetration testing effort [b]?
 
•
 
If the penetration testing is performed by an internal team, are the individuals
 
performing the testing objectively [b]?
 
•
 
Is a penetration testing final report provided to the internal team responsible for
 
organizational defense?
 
•
 
If previous penetration tests have been conducted, can the organization provide samples
 
of penetration test plans, findings reports, and mitigation guidance based on the findings
 
[a,b,c]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.12.1e
 
 
 
 
 
 
 
 
 
SC.L3-3.13.4e – isolation
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
70
 
''' '''
 
System and Communications Protection (SC) <br />
'''SC.L3-3.13.4E – ISOLATION '''
 
Employ physical isolation techniques or logical isolation techniques or both in organizational
 
systems and system components.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[ODP1] One or more of the following is/are selected: physical isolation techniques;
 
logical isolation techniques; <br />
[ODP2] Physical isolation techniques are defined (if selected); <br />
[ODP3] Logical isolation techniques are defined (if selected); <br />
[a] Physical isolation techniques or logical isolation techniques or both are employed in
 
organizational systems and system components.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: System and communications protection policy; procedures addressing
 
boundary protection; system design documentation; procedures addressing the use of thin
 
nodes; list of key internal boundaries of the system; security plan; boundary protection
 
hardware and software; system configuration settings and associated documentation;
 
enterprise architecture documentation; system architecture; security architecture
 
documentation; system audit records; system component inventory; list of security tools and
 
support components to be isolated from other system components; other relevant
 
documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security;
 
system/network administrators; system developers; organizational personnel responsible
 
for boundary protection].
 
'''Test <br />
'''[SELECT FROM: Mechanisms implementing the boundary protection capability; mechanisms
 
implementing physical isolation techniques; mechanisms supporting and/or implementing
 
the isolation of information security tools, mechanisms, and support components;
 
mechanisms supporting and/or implementing the capability to separate system components
 
supporting organizational missions and business functions; mechanisms implementing
 
 
 
 
 
 
 
 
 
SC.L3-3.13.4e – isolation
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
71
 
''' '''
 
logical isolation techniques; mechanisms supporting or implementing separate network
 
addresses/different subnets; mechanisms supporting and/or implementing thin nodes].
 
'''DISCUSSION [NIST SP 800-172] '''
 
A mix of physical and logical isolation techniques (described below) implemented as part of
 
the system architecture can limit the unauthorized flow of CUI, reduce the system attack
 
surface, constrain the number of system components that must be secure, and impede the
 
movement of an adversary. When implemented with a set of managed interfaces, physical
 
and logical isolation techniques for organizational systems and components can isolate CUI
 
into separate security domains where additional protections can be implemented. Any
 
communications across the managed interfaces (i.e., across security domains), including for
 
management or administrative purposes, constitutes remote access even if the
 
communications remain within the organization. Separating system components with
 
boundary protection mechanisms allows for the increased protection of individual
 
components and more effective control of information flows between those components.
 
This enhanced protection limits the potential harm from and susceptibility to hostile cyber-
 
attacks and errors. The degree of isolation can vary depending on the boundary protection
 
mechanisms selected. Boundary protection mechanisms include routers, gateways, and
 
firewalls separating system components into physically separate networks or subnetworks;
 
virtualization and micro-virtualization techniques; encrypting information flows among
 
system components using distinct encryption keys; cross-domain devices separating
 
subnetworks; and complete physical separation (i.e., air gaps). <br />
System architectures include logical isolation, partial physical and logical isolation, or
 
complete physical isolation between subsystems and at system boundaries between
 
resources that store, process, transmit, or protect CUI and other resources. Examples
 
include: <br />
•
 
Logical isolation: Data tagging, digital rights management (DRM), and data loss
 
prevention (DLP) that tags, monitors, and restricts the flow of CUI; virtual machines or
 
containers that separate CUI and other information on hosts; and virtual local area
 
networks (VLAN) that keep CUI and other information separate on networks.
 
•
 
Partial physical and logical isolation: Physically or cryptographically isolated networks,
 
dedicated hardware in data centers, and secure clients that (a) may not directly access
 
resources outside of the domain (i.e., all applications with cross-enclave connectivity
 
execute as remote virtual applications hosted in a demilitarized zone [DMZ] or internal
 
and protected enclave), (b) access via remote virtualized applications or virtual desktop
 
with no file transfer capability other than with dual authorization, or (c) employ
 
dedicated client hardware (e.g., a zero or thin client) or hardware approved for multi-
 
level secure (MLS) usage.
 
•
 
Complete physical isolation: Dedicated (not shared) client and server hardware;
 
physically isolated, stand-alone enclaves for clients and servers; and (a) logically
 
separate network traffic (e.g., using a VLAN) with end-to-end encryption using Public Key
 
Infrastructure (PKI)-based cryptography or (b) physical isolation from other networks.
 
 
 
 
 
 
 
 
 
SC.L3-3.13.4e – isolation
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
72
 
''' '''
 
Isolation techniques are selected based on a risk management perspective that balances the
 
threat, the information being protected, and the cost of the options for protection.
 
Architectural and design decisions are guided and informed by the security requirements
 
and selected solutions. Organizations consider the trustworthiness of the isolation
 
techniques employed (e.g., the logical isolation relies on information technology that could
 
be considered a high value target because of the function being performed), introducing its
 
own set of vulnerabilities. <br />
[NIST SP 800-160-1] provides guidance on developing trustworthy, secure, and cyber
 
resilient systems using systems security engineering practices and security design concepts.
 
'''FURTHER DISCUSSION '''
 
For this requirement, organizations must identify the systems or enclaves that need to be
 
isolated, then design and implement the isolation. The resulting isolation solutions are
 
documented or referenced in the SSP. Documentation will be dependent on the design
 
selected and may include a high-level diagram, but specific details that may change on some
 
frequency would be omitted. During an assessment, providing details such as subnet and
 
VLAN implementation identifiers, internal boundary protection hardware and software,
 
interface device functionality, and system configuration and Access Control List (ACL)
 
settings will be useful.
 
'''Example <br />
'''You are responsible for information security in your organization, which holds and
 
processes CUI. You have decided to isolate the systems processing CUI by limiting all
 
communications in and out that enclave with cross-domain interface devices that implement
 
access control [a]. Your security team has identified all the systems containing such CUI,
 
documented network design details, developed network diagrams showing access control
 
points, documented the logic for the access control enforcement decisions, described the
 
interface and protocol to the identification and authentication mechanisms, and documented
 
all details associated with the ACLs, including review, updates, and credential revocation
 
procedures.
 
'''Potential Assessment Considerations <br />
'''•
 
Has the organization clearly identified where they use physical, logical, or both isolation
 
techniques [a]?
 
•
 
Can the organization describe the isolation techniques they have employed [a]?
 
•
 
Has the organization deployed subnetting, internal firewalls, and VLANs to control
 
packet flow between internal segments [a]?
 
•
 
Does the organization employ metadata to inform isolation techniques [a]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.13.4e
 
 
 
 
 
 
 
 
 
SI.L3-3.14.1e – Integrity Verification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
73
 
''' '''
 
System and Information Integrity (SI) <br />
'''SI.L3-3.14.1E – INTEGRITY VERIFICATION '''
 
Verify the integrity of security critical and essential software using root of trust mechanisms
 
or cryptographic signatures.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[ODP1] Security critical or essential software is defined; <br />
[a] Root of trust mechanisms or cryptographic signatures are identified; and <br />
[b] The integrity of security critical and essential software is verified using root of trust
 
mechanisms or cryptographic signatures.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: System and information integrity policy; procedures addressing software,
 
firmware, and information integrity; system design documentation; security plan; system
 
configuration settings and associated documentation; system component inventory;
 
integrity verification tools and associated documentation; records of integrity verification
 
scans; system audit records; cryptographic mechanisms and associated documentation;
 
records of detected unauthorized changes to software, firmware, and information; other
 
relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security;
 
organizational personnel responsible for software, firmware, and/or information integrity;
 
system developers; system/network administrators].
 
'''Test <br />
'''[SELECT FROM: Software, firmware, and information integrity verification tools;
 
mechanisms supporting and/or implementing integrity verification of the boot process;
 
mechanisms supporting and/or implementing protection of the integrity of boot firmware;
 
cryptographic mechanisms implementing software, firmware, and information integrity;
 
safeguards implementing protection of the integrity of boot firmware].
 
 
 
 
 
 
 
 
 
SI.L3-3.14.1e – Integrity Verification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
74
 
''' '''
 
'''DISCUSSION [NIST SP 800-172] '''
 
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. <br />
[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.
 
'''FURTHER DISCUSSION '''
 
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. <br />
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. <br />
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.
 
 
 
 
 
 
 
 
 
SI.L3-3.14.1e – Integrity Verification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
75
 
''' '''
 
'''Example 1 <br />
'''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].
 
'''Example 2 <br />
'''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 <br />
'''•
 
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]?
 
 
 
 
 
 
 
 
 
SI.L3-3.14.1e – Integrity Verification
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
76
 
''' '''
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.14.1e
 
 
''' '''
 
 
 
 
 
 
 
 
 
SI.L3-3.14.3e – Specialized Asset Security  
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
77
 
''' '''
 
'''SI.L3-3.14.3E – SPECIALIZED ASSET SECURITY '''
 
Ensure that specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems
 
and test equipment are included in the scope of the specified enhanced security
 
requirements or are segregated in purpose-specific networks.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[a] Specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems and test
 
equipment are included in the scope of the specified enhanced security requirements;
 
and
 
[b] Systems and system components that are not included in specialized assets including IoT,
 
IIoT, OT, GFE, Restricted Information Systems and test equipment are segregated in
 
purpose-specific networks.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: Access control policy; information flow control policies; system and services
 
acquisition policy; system and communications protection policy; procedures addressing
 
security function isolation; procedures addressing application partitioning; procedures
 
addressing security engineering principles used in the specification, design, development,
 
implementation, and modification of the system; procedures addressing information flow
 
enforcement; procedures addressing access enforcement; system architecture; system
 
design documentation; security plan; system component inventory; system configuration
 
settings and associated documentation; system baseline configuration; list of security
 
functions to be isolated from non-security functions; system audit records; security
 
requirements and specifications for the system; list of approved authorizations (user
 
privileges); list of information flow authorizations; other relevant documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for access enforcement;
 
system/network administrators; organizational personnel responsible for information
 
security; system developers; system integrators; organizational personnel responsible for
 
acquisition/contracting; organizational personnel responsible for determining system
 
security requirements; system security architects; enterprise architects; organizational
 
personnel responsible for system specification, design, development, implementation, and
 
modification].
 
'''Test <br />
'''[SELECT FROM: Mechanisms implementing the access control policy; mechanisms
 
implementing the information flow enforcement policy; mechanisms supporting the
 
 
 
 
 
 
 
 
 
SI.L3-3.14.3e – Specialized Asset Security
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
78
 
''' '''
 
application of security engineering principles in system specification, design, development,
 
implementation, and modification].
 
'''DISCUSSION [NIST SP 800-172] '''
 
Organizations may have a variety of systems and system components in their inventory,
 
including Information Technology (IT), Internet of Things (IoT), Operational Technology
 
(OT), and Industrial Internet of Things (IIoT). The convergence of IT, OT, IoT, and IIoT
 
significantly increases the attack surface of organizations and provides attack vectors that
 
are challenging to address. Compromised IoT, OT, and IIoT system components can serve as
 
launching points for attacks on organizational IT systems that handle CUI. Some IoT, OT, and
 
IIoT system components can store, transmit, or process CUI (e.g., specifications or
 
parameters for objects manufactured in support of critical programs). Most of the current
 
generation of IoT, OT, and IIoT system components are not designed with security as a
 
foundational property and may not be able to be configured to support security functionality.
 
Connections to and from such system components are generally not encrypted, do not
 
provide the necessary authentication, are not monitored, and are not logged. Therefore,
 
these components pose a significant cyber threat. Gaps in IoT, OT, and IIoT security
 
capabilities may be addressed by employing intermediary system components that can
 
provide encryption, authentication, security scanning, and logging capabilities—thus,
 
preventing the components from being accessible from the Internet. However, such
 
mitigation options are not always available or practicable. The situation is further
 
complicated because some of the IoT, OT, and IIoT devices may be needed for essential
 
missions and business functions. In those instances, it is necessary for such devices to be
 
isolated from the Internet to reduce the susceptibility to cyber-attacks. <br />
[NIST SP 800-160-1] provides guidance on security engineering practices and security
 
design concepts.
 
'''FURTHER DISCUSSION '''
 
Specialized Assets are addressed in the scoping guidance, which should be overlaid on this
 
requirement. The OSC must document Specialized Assets in the asset inventory; develop,
 
document, and periodically update system security plans; and include Specialized Assets in
 
the network diagram. The Specialized Asset section of the SSP should describe associated
 
system boundaries, system environments of operation, how security requirements are
 
implemented, and the relationships with or connections to other systems. <br />
Specialized Assets within the Level 3 CMMC assessment scope must be either assessed
 
against all CMMC security requirements or separated into purpose-specific networks.
 
Specialized Assets may have limitations on the application of certain security requirements.
 
To accommodate such issues, the SSP should describe any mitigations. <br />
Intermediary devices are permitted to mitigate an inability for the asset itself to implement
 
one or more CMMC requirements. An example of an intermediary device used in conjunction
 
with a specialized asset is a boundary device or a proxy. <br />
The high-level list of Specialized Assets includes:
 
 
 
 
 
 
 
 
 
SI.L3-3.14.3e – Specialized Asset Security
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
79
 
''' '''
 
•
 
Government Furnished Equipment;
 
•
 
IoT and IIoT devices (physical or virtual) with sensing/actuation capability and
 
programmability features;
 
•
 
OT used in manufacturing systems, industrial control systems (ICS), or supervisory
 
control and data acquisition (SCADA) systems;
 
•
 
Restricted Information Systems, which can include systems and IT components that are
 
configured based on government requirements; and
 
•
 
Test equipment.
 
'''Example <br />
'''You are responsible for information security in your organization, which processes CUI on
 
the network, and this same network includes GFE for which the configuration is mandated
 
by the government. The GFE is needed to process CUI information [a]. Because the company
 
cannot manage the configuration of the GFE, it has been augmented by placing a bastion host
 
between it and the network. The bastion host meets the requirements that the GFE cannot,
 
and is used to send CUI files to and from the GFE for processing. You and your security team
 
document in the SSP all of the GFE to include GFE connectivity diagrams, a description of the
 
isolation mechanism, and a description of how your organization manages risk associated
 
with that GFE [a].
 
'''Potential Assessment Considerations <br />
'''•
 
Has the organization documented all specialized assets in asset inventory [a]?
 
•
 
Has the organization documented all specialized assets in the SSP to show how risk is
 
managed [b]?
 
•
 
Has the organization provided a network diagram for specialized assets [a,b]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.14.3e
 
 
''' '''
 
 
 
 
 
 
 
 
 
SI.L3-3.14.6e – Threat-Guided Intrusion Detection  
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
80
 
''' '''
 
'''SI.L3-3.14.6E – THREAT-GUIDED INTRUSION DETECTION '''
 
Use threat indicator information and effective mitigations obtained from, at a minimum,
 
open or commercial sources, and any DoD-provided sources, to guide and inform intrusion
 
detection and threat hunting.
 
'''ASSESSMENT OBJECTIVES [NIST SP 800-172A] '''
 
Determine if: <br />
[ODP1] External organizations from which to obtain threat indicator information and
 
effective mitigations are defined; <br />
[a] Threat indicator information is identified; <br />
[b] Effective mitigations are identified; <br />
[c] Intrusion detection approaches are identified; <br />
[d] Threat hunting activities are identified; and <br />
[e] Threat indicator information and effective mitigations obtained from, at a minimum,
 
open or commercial sources and any DoD-provided sources, are used to guide and inform
 
intrusion detection and threat hunting.
 
'''POTENTIAL ASSESSMENT METHODS AND OBJECTS [NIST SP 800-172A] '''
 
'''Examine <br />
'''[SELECT FROM: System and information integrity policy; information security program plan;
 
procedures addressing security alerts, advisories, and directives; threat awareness program
 
documentation; procedures addressing system monitoring; procedures for the threat
 
awareness program; risk assessment results relevant to threat awareness; records of
 
security alerts and advisories; system design documentation; security plan; system
 
monitoring tools and techniques documentation; system configuration settings and
 
associated documentation; system monitoring logs or records; system audit records;
 
documentation on the cross-organization information-sharing capability; other relevant
 
documents or records].
 
'''Interview <br />
'''[SELECT FROM: Organizational personnel responsible for information security program
 
planning and plan implementation; system/network administrators; organizational
 
personnel responsible for the threat awareness program; organizational personnel
 
responsible for the cross-organization information-sharing capability; organizational
 
personnel responsible for information security; organizational personnel responsible for
 
installing, configuring, and/or maintaining the system; organizational personnel security
 
alerts and advisories; organizational personnel responsible for implementing, operating,
 
maintaining, and using the system; organizational personnel, organizational elements,
 
and/or external organizations to whom alerts, advisories, and directives are to be
 
 
 
 
 
 
 
 
 
SI.L3-3.14.6e – Threat-Guided Intrusion Detection
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
81
 
''' '''
 
disseminated; personnel with whom threat awareness information is shared by the
 
organization; system developers].
 
'''Test <br />
'''[SELECT FROM: Mechanisms supporting and/or implementing the threat awareness
 
program; mechanisms supporting and/or implementing the cross-organization information-
 
sharing capability; mechanisms supporting and/or implementing the system monitoring
 
capability; mechanisms supporting and/or implementing the definition, receipt, generation,
 
and dissemination of security alerts, advisories, and directives; mechanisms supporting
 
and/or implementing security directives; mechanisms supporting and/or implementing
 
threat hunting; mechanisms supporting and/or implementing intrusion detection;
 
mechanisms supporting and/or implementing the discovery, collection, distribution, and use
 
of indicators of compromise].
 
'''DISCUSSION [NIST SP 800-172] '''
 
Threat information related to specific threat events (e.g., TTPs, targets) that organizations
 
have experienced, threat mitigations that organizations have found to be effective against
 
certain types of threats, and threat intelligence (i.e., indications and warnings about threats
 
that can occur) are sourced from and shared with trusted organizations. This threat
 
information can be used by organizational Security Operations Centers (SOC) and
 
incorporated into monitoring capabilities. Threat information sharing includes threat
 
indicators, signatures, and adversary TTPs from organizations participating in threat-
 
sharing consortia, government-commercial cooperatives, and government-government
 
cooperatives (e.g., CERTCC, CISA/US-CERT, FIRST, ISAO, DIB CS Program). Unclassified
 
indicators, based on classified information but which can be readily incorporated into
 
organizational intrusion detection systems, are available to qualified nonfederal
 
organizations from government sources.
 
'''FURTHER DISCUSSION '''
 
One way to effectively leverage threat indicator information is to access human- or machine-
 
readable threat intelligence feeds. Effectiveness may also require the organization to create
 
TTPs in support of operational requirements, which will typically include defensive cyber
 
tools supporting incident detection, alerts, incident response, and threat hunting. It is
 
possible that this requirement will be implemented by a third-party managed service
 
provider, and in that case, it will be necessary to carefully define the boundary and
 
responsibilities between the OSC and the ESP to guarantee a robust implementation. It is also
 
important that the OSC validate threat indicator integration into the defensive cyber toolset
 
by being able to (1) implement mitigations for sample industry relevant indicators of
 
compromise (e.g., IP address, file hash), (2) identify sample indicators of compromise across
 
sample endpoints, and (3) identify sample indicators of compromise using analytical
 
processes on a system data repository.
 
 
 
 
 
 
 
 
 
SI.L3-3.14.6e – Threat-Guided Intrusion Detection
 
'''CMMC Assessment Guide – Level 3 '''|''' Version 2.13 '''
 
82
 
''' '''
 
'''Example <br />
'''You are responsible for information security in your organization. You have maintained an
 
effective intrusion detection capability for some time, but now you decide to introduce a
 
threat hunting capability informed by internal and external threat intelligence [a,c,d,e]. You
 
install a SIEM system that leverages threat information to provide functionality to: <br />
•
 
analyze logs, data sources, and alerts;
 
•
 
query data to identify anomalies;
 
•
 
identify variations from baseline threat levels;
 
•
 
provide machine learning capabilities associated with the correlation of anomalous data
 
characteristics across the enterprise; and
 
•
 
categorize data sets based on expected data values.
 
Your team also manages an internal mitigation plan (playbook) for all known threats for your
 
environment. This playbook is used to implement effective mitigation strategies across the
 
environment [b]. Some of the mitigation strategies are developed by team members, and
 
others are obtained by threat feed services.
 
'''Potential Assessment Considerations <br />
'''•
 
Which external sources has the organization identified as threat information sources [a]?
 
•
 
Does the organization understand the TTPs of key attackers [c,d]?
 
•
 
Does the organization deploy threat indicators to EDR systems, network intrusion
 
detection systems, or both [c,d,e]?
 
•
 
What actions does the organization implement when a threat alert/indicator is signaled
 
[c,d,e]?
 
•
 
Does the organization use internal threat capabilities within their existing security tools
 
[e]?
 
•
 
How does the organization respond to a third-party notification of a threat indicator [e]?
 
'''KEY REFERENCES '''
 
•
 
NIST SP 800-172 3.14.6e


== Appendix A – Acronyms and Abbreviations ==
== Appendix A – Acronyms and Abbreviations ==

Revision as of 01:40, 27 March 2025

Source of Reference: The official CMMC Level 3 Assessment Guide Version 2.13, September 2024 from the Department of Defense Chief Information Officer (DoD CIO).

For inquiries and reporting errors on this wiki, please contact us. Thank you.

NOTICES

The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

Introduction

This document provides guidance in the preparation for and conduct of a Level 3 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.18 of title 32, Code of Federal Regulations (CFR). Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in CMMC Assessment Guide – Level 1. Guidance for conducting both a Level 2 self-assessment and Level 2 certification assessment, can be found in CMMC Assessment Guide – Level 2. More details on the model can be found in the CMMC Model Overview document.

An Assessment as defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system, or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18. A Level 3 certification assessment as defined in 32 CFR § 170.4 is the activity performed by the Department of Defense (DoD) to evaluate the CMMC level of an Organization Seeking Certification (OSC). For Level 3, assessments are conducted exclusively by the DCMA DIBCAC.

An OSC seeking a Level 3 certification assessment must have first achieved a CMMC Status of Final Level 2 (C3PAO), as set forth in 32 CFR § 170.18(a), for all applicable information systems within the CMMC Assessment Scope, and the OSC must implement the Level 3 requirements specified in 32 CFR § 170.14(c)(4). This is followed by the Level 3 certification assessment conducted by the DCMA DIBCAC.

OSCs may also use this guide to perform Level 3 self-assessments (for example, in preparation for an annual affirmation); however, they are not eligible to submit results from a self-assessment in support of a Level 3 certification assessment. Only the results from an assessment by DCMA DIBCAC are considered for award of the CMMC Statuses Conditional Level 3 (DIBCAC) or Final Level 3 (DIBCAC). Level 3 reporting and affirmation requirements can be found in 32 CFR § 170.18 and 32 CFR § 170.22.

Level 3 Description

Level 3 consists of selected security requirements derived from National Institute of Standards and Technology (NIST) Special Publication (SP) 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, with DoD-approved parameters where applicable. Level 3 only applies to systems that have already achieved a Final Level 2 (C3PAO) CMMC Status. Level 2 consists of the security requirements specified in NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.

Like Level 2, Level 3 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.

Level 3 provides additional protections against advanced persistent threats (APTs), and increased assurance to the DoD that an OSC can adequately protect CUI at a level commensurate with the adversarial risk, to include protecting information flow with the government and with subcontractors in a multitier supply chain.

Purpose and Audience

This guide is intended for assessors, OSCs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 3 certification assessment.

Document Organization

This document is organized into the following sections:

  • Assessment and Certification: provides an overview of the Level 3 assessment processes set forth in 32 CFR § 170.18. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(d).
  • CMMC-Custom Terms: incorporates definitions from 32 CFR § 170.4, definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of specific terms as used in the context of CMMC.
  • Assessment Criteria and Methodology: provides guidance on the criteria and methodology (i.e., interview, examine, and test) to be employed during a Level 3 assessment, as well as on assessment findings.
  • Requirement Descriptions: Provides guidance specific to each Level 3 security requirement.

Assessment and Certification

The DCMA DIBCAC will use the assessment methods defined in NIST SP 800-172A[1], Assessing Enhanced Security Requirements for Controlled Unclassified Information, along with the supplemental information in this guide to conduct Level 3 certification assessments. Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 3 certification assessment for an entire enterprise network or for specific enclave(s), depending on how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(d).

Assessment Scope

Prior to conducting a CMMC Level 3 certification assessment, the Level 3 CMMC Assessment Scope must be defined as addressed in 32 CFR § 170.19(d) and the CMMC Scoping Guide – Level 3 document[2]. The CMMC Assessment Scope informs which assets within the OSC’s environment will be assessed and the details of the assessment. The OSC must have achieved a CMMC Status of Final Level 2 (C3PAO) of all systems included within the Level 3 CMMC Assessment Scope prior to requesting the Level 3 assessment, as set forth in 32 CFR § 170.18.

The Level 3 assessment scoping is based on the requirements defined in 32 CFR § 170.19(d) and supported by the CMMC Scoping Guide – Level 3 document. The CMMC Scoping Guide – Level 3 document is available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/. If a Final Level 2 (C3PAO) CMMC Status has not already been achieved for the desired CMMC Assessment Scope, the OSC may not proceed with the Level 3 assessment.

CMMC-Custom Terms

The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The custom terms associated with Level 3 are:

  • Assessment: As defined 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization defined in 32 CFR § 170.15 to 32 CFR § 170.18.
    • Level 3 certification assessment is the term for the activity performed by the DCMA DIBCAC to evaluate the information system of an OSC when seeking a CMMC Status of Level 3 (DIBCAC).
    • POA&M closeout certification assessment is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
  • Assessment Objective: Means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
  • Asset: Means an item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns. Understanding assets is critical to identifying the CMMC Assessment Scope; for more information see CMMC Scoping Guide – Level 3.
  • CMMC Assessment Scope: As defined in 32 CFR § 170.4 means the set of all assets in the OSC’s environment that will be assessed against CMMC security requirements.
  • CMMC Status: The result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally presented on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
    • Conditional Level 3 (DIBCAC): Defined in 32 CFR § 170.18(a)(1)(ii). The OSC will achieve CMMC Status of Conditional Level 3 (DIBCAC) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 3 POA&M requirements listed in 32 CFR § 170.21(a)(3).
    • Final Level 3 (DIBCAC): Defined in 32 CFR § 170.18(a)(1)(iii). The OSC will achieve Final Level 3 (DIBCAC) CMMC Status for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and, if applicable a POA&M closeout assessment within 180 days. Additional guidance can be found in 32 CFR §170.21.
  • Enduring Exception: As defined 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and Government Furnished Equipment (GFE) may be Enduring Exceptions.
  • Event: Any observable occurrence in a system[3]. As described in NIST SP 800-171A[4], the terms “information system” and “system” can be used interchangeably. Events sometimes provide indication that an incident is occurring.
  • Incident: An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.[5]
  • Monitoring: The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an organization-defined frequency and rate.[6]
  • Operational plan of action: As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
  • Organization-defined: As determined by the OSC being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of a OSC’s solution.
  • Organization-Defined Parameters (ODPs): Selected enhanced security requirements contain selection and assignment operations to give organizations[7] flexibility in defining variable parts of those requirements, as defined in NIST SP 800-172A. ODPs are used in NIST SP 800-172 and NIST SP 800-172A to allow Federal agencies, in this case the DoD, to customize security requirements. Once specified, the values for the assignment and selection operations become part of the requirement and objectives, where applicable.
The assignments and selections chosen for Level 3 are underlined in the requirement statement and objectives. In some cases, further specificity of the assignment or selection will need to be made by the OSC. In those cases, the term and abbreviation ODPs is used in the assessment objectives to denote where additional definition is required.
  • Periodically: Means occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is organization-defined to provide OSC flexibility, with an interval length of no more than one year.
  • Security Protection Data: As defined 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. Security Protection Data is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
  • System Security Plan (SSP): Means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems.
  • Temporary deficiency: As defined 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

Assessment Criteria and Methodology

The CMMC Assessment Guide – Level 3 leverages the assessment procedure described in NIST SP 800-172A Section 2.1:

An assessment procedure consists of an assessment objective and a set of potential assessment methods and objects that can be used to conduct the assessment. Each assessment objective includes a set of determination statements related to the CUI enhanced security requirement that is the subject of the assessment. Organization-defined parameters (ODP) that are part of selected enhanced security requirements are included in the initial determination statements for the assessment procedure. ODPs are included since the specified parameter values are used in subsequent determination statements. ODPs are numbered sequentially and noted in bold italics.
Determination statements reflect the content of the enhanced security requirements to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to an enhanced security requirement produces assessment findings. The findings are used to determine if the enhanced security requirement has been satisfied.
Assessment objects are associated with the specific items being assessed. These objects can include specifications, mechanisms, activities, and individuals.
* Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.
* Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.
* Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).
* Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.
Assessment methods define the nature and the extent of the assessor’s actions. The methods include examine, interview, and test.
* The examine method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities).
* The interview method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.
* The test method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.
The purpose of the assessment methods is to facilitate understanding, achieve clarification, and obtain evidence. The results obtained from applying the methods are used for making the specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.

Criteria

Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-172A. The criteria are authoritative and provide a basis for the assessor to conduct an assessment of a requirement.

Methodology

During the CMMC certification assessment, the assessor will verify and validate that the OSC has met the requirements. Because an OSC can meet the assessment objectives in different ways (e.g., through documentation, computer configuration, network configuration, or training), the assessor may use a variety of techniques, including one or more of the three assessment methods described above from NIST SP 800-172A, to determine if the OSC meets the intent of the requirements.

The assessor will follow the guidance in NIST SP 800-172A when determining which assessment methods to use:

Organizations [DoD] are not expected to use all of the assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations have the flexibility to establish the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and objects are deemed to be the most useful in obtaining the desired results). The decision on level of effort is made based on how the organization can accomplish the assessment objectives in the most cost-effective and efficient manner and with sufficient confidence to support the determination that the CUI enhanced security requirements have been satisfied.

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix C of NIST SP 800-172A.

Figure 1 illustrates an example of an assessment procedure for requirement AC.L3-3.1.3e.


Who Is Interviewed

The assessor has discussions with OSC staff to understand if a requirement has been addressed. Interviews with applicable staff (possibly at different organizational levels) determine if CMMC security requirements are implemented and if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

What Is Examined

Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities. The primary focus will be to examine through demonstrations during interviews.

For some requirements, the assessor reviews documentation to determine if assessment objectives are met. Interviews with OSC staff may identify the documents uses. Documents need to be in their final forms; working papers (e.g., drafts) of documentation are not eligible to be submitted as evidence because they are not yet official and are still subject to change.

Common types of documents that can be used as evidence include:

  • policy, process, and procedure documents;
  • training materials;
  • plans and planning documents; and
  • system-level, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSC may not have these specific documents, and other documents may be used to provide evidence of compliance.

In other cases, the requirement is best assessed by observing that safeguards are in place by viewing hardware or associated configuration information or observe staff exercising a process.

What Is Tested

Testing is an important part of the assessment process. Interviews tell the assessor what the OSC staff believe to be true, documentation provides evidence of intent, and testing demonstrates what has or has not been done and is the preferred assessment method when possible. For example, staff may talk about how users are identified and documentation may provide details on how users are identified, but seeing a demonstration of user identification provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

Assessment Findings

The assessment of a CMMC security requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve CMMC Status of Final Level 3 (DIBCAC) as described in 32 CFR § 170.18, the OSC will need a finding of MET or NOT APPLICABLE on all Level 3 security requirements.

  • MET: All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and a not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
    • Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
    • Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
  • NOT MET: One or more objectives for the security requirement is not satisfied. During a Level 3 certification assessment, for each requirement objective marked NOT MET, the assessor will document why the evidence provided by the OSC does not conform.
  • NOT APPLICABLE (N/A): A security requirement and/or objective does not apply at the time of the assessment. For example, SI.L3-3.14.3e might be N/A if there are no Internet of Things (IoT), Industrial Internet of Things (IIoT), Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, or test equipment included in the Level 3 CMMC Assessment Scope.

If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.

Each assessment objective in NIST SP 800-171A and NIST SP 800-172A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.

CMMC certification assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.

A security requirement can be applicable even when assessment objectives included in the security requirements are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.

Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or ESP, implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSC uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

Requirement Descriptions

This section provides detailed information and guidance for assessing each Level 3 security requirement. The section is organized first by domain and then by individual security requirement. Each security requirement description contains the following elements as described in 32 CFR § 170.14(c):

  • Requirement Number, Name, and Statement: Headed by the requirement identification number in the format DD.L#-REQ (e.g., AC.L3-3.1.2e); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement. In the case where the original NIST SP 800-172 requirement requires an assignment and/or selection statement, the Level 3 assignment (and any necessary selection) text is emphasized using underlining. See Section 2.2 in NIST SP 800-172 for the discussion on assignments and selections.
  • Assessment Objectives [NIST SP 800-172A]: Identifies the specific list of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-172A and includes the Level 3 assignment/selection text (as appropriate). In cases where a Level 3 assignment fully satisfies the definition(s) required in an organization-defined parameter (ODP) in NIST SP 800-172A, the ODP statement is not included as an objective, since that objective has been met by the assignment itself. However, when the assignment does not fully contain all required aspects of a NIST SP 800-172A ODP, the ODP is included as its own objective, using the original NIST SP 800-172A ODP number (e.g., “[ODP4]”). See the breakout box ORGANIZATION-DEFINED PARAMETERS in Section 2.1 of NIST SP 800-172A for additional details on an ODP. In all cases where an assignment is used within an objective, it also emphasized using underlining.
  • Potential Assessment Methods and Objects [NIST SP 800-172A]: Defines the nature and extent of the assessor’s actions. Potential assessment methods and objects are as defined in NIST SP 800-172A. The methods include examine, interview, and test. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.
  • Discussion [NIST SP 800-172]: Contains discussion from the associated NIST SP 800-172 security requirement.
  • Further Discussion:
    • Expands upon the NIST content to provide supplemental information on the requirement intent.
    • Contains examples illustrating how the OSC might apply the requirement. These examples provide insight but are not intended to be prescriptive of how the requirement must be implemented, nor comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in brackets (e.g., [a,d] for objectives “a” and “d”) within the text. Note that some of the examples contain company names; all company names used in this document are fictitious.
    • Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions the assessor may ask when assessing the objectives.
  • Key References: Lists the security requirement from NIST SP 800-172.

Access Control (AC)

AC.L3-3.1.2e – Organizationally Controlled Assets

SECURITY REQUIREMENT

Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.

ASSESSMENT OBJECTIVES
[a] Information resources that are owned, provisioned, or issued by the organization are identified; and
[b] Access to systems and system components is restricted to only those information resources that are owned, provisioned, or issued by the organization.
More Practice Details...

AC.L3-3.1.3e – Secured Information Transfer

SECURITY REQUIREMENT

Employ secure information transfer solutions to control information flows between security domains on connected systems.

ASSESSMENT OBJECTIVES
[ODP1] Secure information transfer solutions are defined;
[a] Information flows between security domains on connected systems are identified; and
[b] Secure information transfer solutions are employed to control information flows between security domains on connected systems.
More Practice Details...

Awareness and Training (AT)

AT.L3-3.2.1e – Advanced Threat Awareness

SECURITY REQUIREMENT

Provide awareness training upon initial hire, following a significant cyber event, and at least annually, focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training at least annually or when there are significant changes to the threat.

ASSESSMENT OBJECTIVES

Determine if:

[a] Threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors are identified;
[b] Awareness training focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors is provided upon initial hire, following a significant cyber event, and at least annually;
[c] Significant changes to the threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors are identified; and
[d] Awareness training is updated at least annually or when there are significant changes to the threat.
More Practice Details...

AT.L3-3.2.2e – Practical Training Exercises

SECURITY REQUIREMENT

Include practical exercises in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users, that are aligned with current threat scenarios and provide feedback to individuals involved in the training and their supervisors.

ASSESSMENT OBJECTIVES

Determine if:

[a] Practical exercises are identified;
[b] Current threat scenarios are identified;
[c] Individuals involved in training and their supervisors are identified;
[d] Practical exercises that are aligned with current threat scenarios are included in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users; and
[e] Feedback is provided to individuals involved in the training and their supervisors.
More Practice Details...

Configuration Management (CM)

CM.L3-3.4.1e – Authoritative Repository

SECURITY REQUIREMENT

Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.

ASSESSMENT OBJECTIVES

Determine if:

[a] Approved system components are identified;
[b] Implemented system components are identified;
[c] An authoritative source and repository are established to provide a trusted source and accountability for approved and implemented system components; and
[d] An authoritative source and repository are maintained to provide a trusted source and accountability for approved and implemented system components.
More Practice Details...

CM.L3-3.4.2e – Automated Detection & Remediation

SECURITY REQUIREMENT

Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, remove the components or place the components in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.

ASSESSMENT OBJECTIVES

Determine if:

[a] Automated mechanisms to detect misconfigured or unauthorized system components are identified;
[b] Automated mechanisms are employed to detect misconfigured or unauthorized system components;
[c] Misconfigured or unauthorized system components are detected; and
[d] After detection, system components are removed or placed in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.
More Practice Details...

CM.L3-3.4.3e – Automated Inventory

SECURITY REQUIREMENT

Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.

ASSESSMENT OBJECTIVES

Determine if:

[a] Automated discovery and management tools for the inventory of system components are identified;
[b] An up-to-date, complete, accurate, and readily available inventory of system components exists; and
[c] Automated discovery and management tools are employed to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
More Practice Details...

Identification and Authentication (IA)

IA.L3-3.5.1e – Bidirectional Authentication

SECURITY REQUIREMENT

Identify and authenticate systems and system components, where possible, before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant.

ASSESSMENT OBJECTIVES

Determine if:

[ODP1] Systems and system components to identify and authenticate are defined;
[a] Bidirectional authentication that is cryptographically-based is implemented;
[b] Bidirectional authentication that is replay-resistant is implemented; and
[c] Systems and system components, where possible, are identified and authenticated before establishing a network connection using bidirectional authentication that is cryptographically-based and replay-resistant.
More Practice Details...

IA.L3-3.5.3e – Block Untrusted Assets

SECURITY REQUIREMENT

Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.

ASSESSMENT OBJECTIVES

Determine if:

[a] System components that are known, authenticated, in a properly configured state, or in a trust profile are identified;
[b] Automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems are identified; and
[c] Automated or manual/procedural mechanisms are employed to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
More Practice Details...

Incident Response (IR)

IR.L3-3.6.1e – Security Operations Center

SECURITY REQUIREMENT

Establish and maintain a security operations center capability that operates 24/7, with allowance for remote/on-call staff.

ASSESSMENT OBJECTIVES

Determine if:

[a] A security operations center capability is established;
[b] The security operations center capability operates 24/7, with allowance for remote/on-call staff; and
[c] The security operations center capability is maintained.
More Practice Details...

IR.L3-3.6.2e – Cyber Incident Response Team

SECURITY REQUIREMENT

Establish and maintain a cyber incident response team that can be deployed by the organization within 24 hours.

ASSESSMENT OBJECTIVES

Determine if:

[a] A cyber incident response team is established;
[b] The cyber incident response team can be deployed by the organization within 24 hours; and
[c] The cyber incident response team is maintained.
More Practice Details...

Personnel Security (PS)

PS.L3-3.9.2e – Adverse Information

SECURITY REQUIREMENT

Ensure that organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI.

ASSESSMENT OBJECTIVES

Determine if:

[a] Individuals with access to CUI are identified;
[b] Adverse information about individuals with access to CUI is defined;
[c] Organizational systems to which individuals have access are identified; and
[d] Mechanisms are in place to protect organizational systems if adverse information develops or is obtained about individuals with access to CUI.
More Practice Details...

Risk Assessment (RA)

RA.L3-3.11.1e – Threat-Informed Risk Assessment

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

RA.L3-3.11.2e – Threat Hunting

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

RA.L3-3.11.3e – Advanced Risk Identification

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

RA.L3-3.11.4e – Security Solution Rationale

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

RA.L3-3.11.5e – Security Solution Effectiveness

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

RA.L3-3.11.6e – Supply Chain Risk Response

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

RA.L3-3.11.7e – Supply Chain Risk Plan

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

Security Assessment (CA)

CA.L3-3.12.1e – Penetration Testing

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

System and Communications Protection (SC)

SC.L3-3.13.4e – isolation

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

System and Information Integrity (SI)

SI.L3-3.14.1e – Integrity Verification

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

SI.L3-3.14.3e – Specialized Asset Security

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

SI.L3-3.14.6e – Threat-Guided Intrusion Detection

SECURITY REQUIREMENT
ASSESSMENT OBJECTIVES
More Practice Details...

Appendix A – Acronyms and Abbreviations

AC Access Control
ACL Access Control List
ACM Automated Configuration Management
ACMS Automated Configuration Management System
APT Advanced Persistent Threat
AT Awareness and Training
C3PAO CMMC Third-Party Assessment Organization
CA Certification Authority
CA Security Assessment

CERT

Computer Emergency Response Team

CFR

Code of Federal Regulations

CIO

Chief Information Officer

CIRT

Computer Incident Response Team; Cyber Incident Response Team

CISO

Chief Information Security Officer

CM

Configuration Management

CMMC

Cybersecurity Maturity Model Certification

CUI

Controlled Unclassified Information

DCSA

Defense Counterintelligence and Security Agency

DFARS

Defense Federal Acquisition Regulation Supplement

DIB

Defense Industrial Base

DLP

Data Loss Prevention

DMZ

Demilitarized Zone

DoD

Department of Defense

DRM

Digital Rights Management

ESP

External Service Provider

FIPS

Federal Information Processing Standard

GFE

Government Furnished Equipment

GPO

Group Policy Object

HR

Human Resources

IA

Identification and Authentication

ICS

Industrial Control System

IIoT

Industrial Internet of Things

IOC

Indicators of Compromise

IoT

Internet of Things

IP

Internet Protocol

IR

Incident Response

ISAC

Information Sharing and Analysis Center






Appendix A – Acronyms and Abbreviations

CMMC Assessment Guide – Level 3 | Version 2.13

84

ISAO

Information Sharing and Analysis Organization

IT

Information Technology

MLS

Multi-Level Secure

N/A

Not Applicable

NAC

Network Access Control

NIST

National Institute of Standards and Technology

ODP

Organization-Defined Parameters

OS

Operating System

OT

Operational Technology

PKI

Public Key Infrastructure

PS

Personnel Security

RA

Risk Assessment

SC

System and Communications Protection

SCADA

Supervisory Control and Data Acquisition

SCRM

Supply Chain Risk Management

SI

System and Information Integrity

SIEM

Security Information and Event Management

SOAR

Security Orchestration, Automation, and Response

SOC

Security Operations Center

SP

Special Publication

SSP

System Security Plan

TEE

Trusted Execution Environment

TLS

Transport Layer Security

TPM

Trusted Platform Module

TTP

Tactics, Techniques, and Procedures

UEFI

Unified Extensible Firmware Interface

USB

Universal Serial Bus

VLAN

Virtual Local Area Network

VPN

Virtual Private Network

XDR

Extended Detection and Response

  1. ↑ NIST SP800-172A, March 2022
  2. ↑ Note that an OSC ought to be mindful of their full Level 3 scoping in their request for a Level 2 assessment.
  3. ↑ NIST SP 800-53 Rev. 5, p. 402
  4. ↑ NIST SP 800-171A, June 2018, p. v
  5. ↑ NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)
  6. ↑ NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55
  7. ↑ The organization defining the parameters is the DoD.
Retrieved from "https://cmmcwiki.org/index.php?title=Level_3_Assessment_Guide&oldid=1225"