CMMC Weekly Series #12

Posted on July 20, 2020 by Joseph Goyette, MS

In the current environment of continual cyber attacks, all organizations need to be prepared to handle a cybersecurity incident and handle it in the proper fashion.  The prevailing industry mindset today is that your organization will be breached at some point and you must be prepared to address that breach.  This is Incident Response – the overall approach to dealing with security breaches and responding to cybersecurity incidents.

The CMMC model includes a range of controls related to IR that begin with the basic IR capability that includes an IR Plan for detecting, reporting, analyzing, and responding to events, and advances to a comprehensive IR approach for gathering threat intelligence, establishing a Security Operation Center (SOC), gathering forensic data, developing Indicators of Compromise (IOCs), establishing an IR team, and conducting unannounced IR event exercises.  The latter practice is beyond the reach of most small to medium size businesses and is usually only implemented by larger organizations.

CMMC divides the IR domain into five capabilities: Plan incident response, Detect and report events, Develop and implement a response to a declared incident, Perform post incident reviews, and Test incident response.  The level 2 IR practices establishes the first four objectives, with the testing of IR covered in level 3.

IR.2.092: Establish an operational incident-handling capability for organizational systems the includes preparation, detection, analysis, containment, recover, and user response activities.
The first practice deals with establishing an IR capability – in short, this primarily involves planning and preparation for IR.  Most large organization already have an established IR capability of some sort and this practice should be easy to satisfy.

For the small to medium size organization, this may seem like a large undertaking and it can be.  However, CMMC takes into consideration the size and complexity of an organization as the examples provided in the “CMMC Clarification” section of the CMMC v1.02 illustrate.  The examples walk through a sample organization that establishes a simple IR capability and how they would address an incident that involves a phishing attempt.  The incident response capability in the example is very basic and might be enough to satisfy the practice requirement for a small organization.  Still, the larger and more complex an organization, the more mature the IR capability will need to be.

IR.2.093: Detect and report events.
The second practice deals with the basic awareness an organization must have in order to detect events, some of which may later be determined to be incidents.  The practice really involves both day-to-day observations, and active collection/monitoring of information for events.

The first method of identifying events is simply being aware of your situation and is similar to the “If you see something, say something” campaign to report suspicious activities that may be related to criminal or potentially terrorist activities.  So, if you see something that seems suspicious or out-of-the-ordinary, then report it as an event.  For example, a system administrator should report unexpected server crashes as an event, and an employee should report unknown persons tailgating employees as they enter secure areas of the office building.

The other method of identifying events is more active and requires planned collection of information and monitoring of this information.  This can entail collection of audit logs, anti-virus alerts, endpoint protection alerts, IDS/IPS alerts, threat intelligence information, and numerous other sources of collected information.  Once the information is collected, events can be identified automatically using cybersecurity products or by reviewing the collected information.  These events should be reported to the triage team for review, as appropriate.

IR.2.094: Analyze and triage events to support event resolution and incident declaration.
As stated in Appendix B, “Triage consists of categorizing, correlating, prioritizing, and analyzing events.”  But what does that mean and when exactly does an event become an incident?  In short, the job of triage is to weed-out legitimate events from malicious events, and then to further analyze the malicious events to determine if they are worth treating as an incident and kicking-off the IR process.

For larger organizations, this triage would be performed by the SOC team utilizing tools to reduce, correlate and analyze the data using established IOCs, reports, alerts, etc.  For the smaller organization with staffing contraints, the number of events needs to be reduced to a manageable number by capturing only the most relevant events, so that personnel performing triage can use their time efficiently.

IR.2.096: Develop and implement responses to declared incidents according to predefined procedures.
This practice relates directly to the preparation phase of incident response because it involves considering the different types of incidents your organization may encounter and thinking about how your organization should respond.  The CMMC practice documentation is limited and does not give extensive guidance as to what would be acceptable for meeting this practice.

In general, a company will most likely be assessed according to the size of the organization and the amount of CUI data that the contractor handles.  Large contractors will probably be expected to have a more extensive list of potential incidents and responses than will a small business.

More advanced organizations with threat hunt, incident response, and threat intelligence capabilities, likely already have predefined incident responses that are well tested.  But the small to medium size business, without an in-house IR team, may be at a loss to determine what incidents they might face and what would be an appropriate response for such an incident.


It would be wise for organizations to be careful when planning out predefined responses to incidents and to have their plans reviewed by IR experts that keep up with the latest advances in the industry.


For example, the initial reaction by most people when they discover someone has breached their network is to immediately start removing them even before they have discovered the full extent of the breach.  If you have been breached by an Advanced Persistent Threat (APT), immediate removal activities might provoke unwanted reactions such as: immediate exfiltration of data that has been staged on the network, destruction of systems, encryption of your data with ransomware, or having the APT go quiet on the network until they think your IR activities are over.  This example illustrates that you should carefully consider your responses and formulate an IR capability that is prudent and in line with current industry thinking.

IR.2.097: Perform root cause analysis on incidents to determine underlying causes.
This practice falls under the objective of performing post incident review and concerns discerning the exact cause of the incident as well as the organization’s response to the incident.  Getting a precise understanding of both the cause of and the response to an incident allows you to be better prepared to limit similar incidents in the future and better respond to them when they do occur.

For some events (such as a flood), the root cause analysis is straight forward, but for others (such as an APT breach) the analysis is difficult without advanced IR planning, which includes the gathering of necessary monitoring data.  Also, your incident response procedures can sometime inhibit determining the root cause.

For example, if the procedural first response to a compromised system is to pull it offline and rebuild/re-image the system from an approved baseline, then valuable forensic information might be getting destroyed as part of your process.  This forensic evidence may be necessary to scope the true extent of a breach and to reconstruct the series of events needed for a complete root cause analysis.

This also shows why it is important to review the organization’s response to the incident to see what could have been performed better.  An analysis of the response will help you determine how well the IR team responded under the stress of an actual incident, but also how well your planned incident responses worked.  This analysis should lead to lessons learned, which should be incorporated back into your IR plan and processes – an organization may decide to capture more monitoring data or alter some of the predefined responses to an incident.  Either way, this analysis is essential for maturity of an IR capability and should lead to concrete actions.

IR.3.098: Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
Tracking, documenting, and reporting of incidents not only supports root cause analysis, but it keeps key stakeholders informed and captures the necessary information that may need to be reported for legal, compliance, or liability purposes.  So how should these incidents be tracked, documented, and reported?

Once again, this depends on the size of the organization, amount of CUI contained within the organization, and the complexity of the systems.  All incidents should be tracked by someone within the organization and eventually reported up to management.  The severity of the incident will determine how closely the incident will be tracked and by whom – a major breach will be closely monitored by management.


Also, organizations should consider using alternative email, phone and other communication methods when dealing with an APT as the standard channels may be monitored by the attackers.


Also, how should incidents be documented?  A major security breach at a large company could involve the analysis of an extremely large amount of data, which cannot all be kept as the storage requirements would be excessive.  In general, organizations should retain all forensic evidence and documentation necessary to show the identification, containment, eradication, and recovery processes.  If legal or criminal action is sought after an incident, then special care should be taken to ensure evidence collected is forensically sound and follows established chain of custody practices.

IR.3.099: Test the organizational incident response capability.
The final IR practice, required for a CMMC level 3, involves testing of your IR capability.  Again, the size and complexity of the organization as well as the CUI handled will determine how extensive or complex the IR testing should be.  An organization with mature IR capabilities (those with a SOC, IR Team, and/or Threat Intelligence Team) should probably perform more in-depth IR testing, inclusive of a combined red/blue team exercise.

In a combined red/blue team exercise, the red team (i.e., penetration testers) conducts a simulated attack on the network using Tactics, Techniques, and Procedures (TTPs) that attackers (e.g. APTs) commonly use against the organization, while the blue team (SOC, IR team) defends the network by monitoring events, practicing incident escalation, and conducting the IR process activities.  The more realistic your test scenario the better.

For small to medium size organizations, performing an extensive test event will not be feasible.  A small company can perform table-top exercises by walking through potential incidents and how the company’s IR reaction.

For companies that want more than a table-top, there are numerous cyber ranges (physical or virtual) that can provide more realistic test environments for the organization.  The cost of these ranges varies but they offer a more hands-on test event with less operational disruption than an extensive test event using actual company systems and resources.

CMMC Level 4-5 IR Practices
The remaining IR practices relate to more advanced level organizations that have more stringent security requirements.  These practices involve integrating threat intelligence into IR, establishing a 24/7 SOC, collection of real-time forensic evidence, adding in automatic responses for incidents, establishing a Cyber Incident Response Team (CIRT) that can response within 24 hours, and conducting unannounced operational IR tests.

Pete is a Project Manager and Senior Security Engineer for Blue Mantle Technology.  He has extensive experience in corporate leadership and management in Cybersecurity, having facilitated successful corporate operations for several businesses over the last two decades.  He has a BA from Thomas Aquinas College and an MA and MS from CUA.  He holds the following certifications in the cybersecurity industry (CISSP, CISSP-ISSEP, CAP, GCIH, GCFA), and is a member of the GIAC Advisory Board.

Subscribe to Blog

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Contact Us

Let's talk about the best solution for you because that's the only one that matters.

Get in Touch

Join Us

Get a feeling for our company culture and picture yourself at Blue Mantle.

View Open Positions