Information security frameworks like CMMC are not just about enforcing security. They’re about enforcing accountability.

That’s why a whole section of controls and rules that make up CMMC centers around incident response and reporting. You can’t just have security in place, but throw your hands up and do nothing if there’s an incident or breach. Nor can you sweep it under the rug and hope no one notices.

What does CMMC mandate as far as incident response goes, and what are the timelines for reporting when an incident happens? This is important information that can shape the future of your organization, so it’s crucial to get it right.

CMMC Incident Response Rules per Impact Level

First of all, as with all things CMMC, there is an amount of variance between the different impact levels.

CMMC Level 1 is the lowest standard of security and only encompasses federal contract information, some of the least sensitive of the “sensitive” information categories. As such, there are no formal requirements for incident response at this level.

CMMC Level 2, which is where the majority of organizations will seek certification, has specific requirements stemming from NIST SP 800-171 for incident response. In the level 2 assessment guide, these are sections IR.L2-3.6.1, 3.6.2, and 3.6.3.

CMMC Level 3, which sets the bar for higher security for CUI than what most organizations need, but which still doesn’t quite rise to the level of truly classified or secret information, adds two more controls to the mix. These stem from NIST SP 800-172, and in the level 3 assessment guide are labeled IR.L3-3.6.1E and 3.6.2E.

As far as what the underlying NIST publications encompass, the relevant section in NIST SP 800-171 is 3.6.1 through 3.6.3, collectively section 3.6: Incident Response.

Looking to NIST

Though the specifics for the CMMC impact levels are slightly different, it can be worth looking at where the information comes from. In this case, it’s extra important because of the disconnect between CMMC and NIST.

As of early last year, NIST pushed a major update to NIST SP 800-171, moving it from revision 2 to revision 3. This change made a lot of tangible and important changes to how the controls are organized and outlined. Revision 3, for example, has five sections in Incident Response rather than just three.

CMMC was unprepared for this change and, rather than rapidly update (and cause issues with every currently-certified and in-progress CMMC organization), the DoD instead issued a memo telling everyone on CMMC to continue using revision 2. So, until such time as they update CMMC, that’s the version we’ll discuss.

NIST SP 800-171 R2 has three subsections in section 3.6: Incident Response.

3.6.1: Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.

We’ll discuss these six phases in greater detail later.

NIST also provides additional documentation for guidance, with publications 800-61, 800-86, 800-101, and 800-161 offering more information on topics like incident handling, forensic investigation of incidents, and supply chain risk management.

3.6.2: Track, document, and report incidents to designated officials and/or authorities, both internal and external to the organization.

Notably, NIST does not, itself, set out timelines. Instead, they defer to the frameworks using the publication as a baseline, saying:

“The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, Executive Orders, directives, regulations, and policies.”

3.6.3: Test the organizational incident response capability.

Simply put, your incident response plans need to actually work. It’s not good enough just to have them on paper.

For CMMC level 3, additional requirements come from NIST SP 800-172, “Enhanced Security Requirements for Protecting Controlled Unclassified Information.”

3.6.1e: Establish and maintain a security operations center capability that operates in an organization-defined time period.

Generally speaking, this means that an organization needs a security operations center that is staffed and operational, usually 24/7, though the actual timing is an ODP (which is discussed in our rev2 vs rev3 guide linked above).

3.6.2e: Establish and maintain a cyber incident response team that can be deployed by the organization within an organization-defined time period.

A cyber incident response team, or CIRT, is a team of experts, analysts, and investigators who respond to incidents, document them, handle recovery, and close the hole that led to the incident. The team composition can vary, but the responsibilities are high and important.

Examining CMMC Specifics

CMMC, since it’s built on NIST SP 800-171, is largely similar. However, it outlines some specifics and pins down those organization-defined parameters for level 3.

Level 2’s incident response guidelines are word-for-word identical to NIST SP 800-171 R2, though there’s more discussion in the assessment guide. It’s a good document to reference since it’s what your C3PAO is going to be looking for.

Level 3’s document specifies the ODPs.

• 3.6.1e – Security Operations Center. Establish and maintain a security operations center capability that operates 24/7, with allowance for remote/on-call staff.
• 3.6.2e – Cyber Incident Response Team. Establish and maintain a cyber incident response team that can be deployed by the organization within 24 hours.

These are the definitions for timeframes of incident response for CMMC Level 3.

Fortunately, there’s a bit of leeway here. Specifically, organizations are not necessarily required to establish the operations center or response team in-house; they can be services outsourced to third-party vendors. Those vendors themselves need to be CMMC secure, but there are many providers that fit that bill.

The Third Puzzle Piece: DFARS

You might note that these baseline documents still don’t outline specific timelines for response and reporting. Those requirements come from another source: DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting.

In brief, DFARS 7012 is the clause in your DoD contract telling you what you specifically need to adhere to under CMMC. In a way, it’s the rosetta stone combining and tying together all of the requirements from NIST SP 800-171 and CMC itself, along with FedRAMP and more. It also mandates flow-down requirements to subcontractors all the way down the defense supply chain.

This document is where many important definitions and requirements come from. It’s where you find definitions for terms like cyber incident, covered defense information, and compromise. It’s also where timelines are defined.

For example, DFARS 7012 says this:

• “Rapidly report” means within 72 hours of discovery of any cyber incident.
• “Cyber incident” means actions taken through the use of computer networks that result in a compromise or an actual or potentially adverse effect on an information system and/or the information residing therein.
• “Compromise” means disclosure of information to unauthorized persons, or a violation of the security policy of a system, in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object, or the copying of information to unauthorized media may have occurred.

So, there’s your incident reporting timeline. Unless you have a unique contract and are somehow not under the control of DFARS 7012 (which is unlikely), you will need to report cyber incidents within 72 hours.

What constitutes a cyber incident?

Some are obvious. Any unauthorized access, ransomware, DDoS, malware campaigns, or data breaches, obviously, are incidents. However, what trips many organizations up is that attempts can also be reportable incidents. Phishing attempts and emails with potentially malicious code are reportable. The bar is very low for what can be considered an incident.

Six Phases of Incident Response

The foundation of incident response is the six-phase system outlined in 3.6.1. Looking at each of them more closely can help with determining how you need to implement your incident response plan.

Preparation

Preparation is about laying the groundwork and being able to handle incidents. It includes implementing security across all of the other relevant security controls, but more importantly, it’s about developing response plans.

When an incident is detected, what do you do, in what order? Who is involved? Who gets that phone call in the middle of the night to come secure the system? It’s the same concept as a disaster recovery plan, and closely related, as a sufficient incident can be considered a disaster.

Preparation also means training your personnel. The people watching the dashboards or seeing the alarms need to know what to do when something happens.

Being prepared, ready, and able to jump into action the moment an incident is detected is essential for rapid response and mitigation.

Detection

Detection is about both proactive and reactive systems that watch for signs of incidents and take action. Some of those actions can be automatic; others may need to be alarms or notifications to relevant personnel. Modern security tools do a lot of this work behind the scenes, and configuring them to function the right way (and testing to validate that they function) is required.

Consider systems like intrusion detection to identify unauthorized access attempts, network monitors to watch for unusual traffic patterns, security information management software to watch for unusual patterns of use, and data validation systems to check for unauthorized tampering.

While this might sound like a steep set of requirements, there are many commercially available security suites that are configured to work within the guidelines of DoD security and CMMC, so you generally don’t have to engineer this all from base principles.

Analysis

Any threat, when detected, needs analysis. The analysis phase takes place immediately and continues throughout the rest of the process. Initial analysis checks into the incident and determines what, if any, action may be necessary. An email phishing attempt (that remains unsuccessful) may require reporting and may require adjustment to email filters and other security, but little else. An active data breach from a compromised account requires very different action.

Responding to one the same way you do the other either leaves you with wildly overdone responses to minor incidents, or ineffective non-responses to major incidents. Analysis guides you on how to act.

Analysis continues beyond the remaining phases and plays a role in later reporting and post-mortem breakdowns of the incident, why it happened, what’s new about it, and how to prevent it from happening again.

Containment, Eradication, and Recovery

Containment is the first part of the action taken during an incident to stop any potential spread. Locking down systems and accounts, activating separation and isolation, and other operations help prevent a breach from getting worse. The specifics here depend on your organization’s systems and design, and the results of initial analysis.

Eradication means getting rid of any remnant of the threat in your systems. This can begin with a rollback or reset of user accounts and systems, a purge of malicious code, a removal of false credentials, and similar revocation of access. Beyond that, it also includes patching systems and removing the access, closing the door on the avenue that led to the incident.

Recovery is the restoration of normal functions after the incident. Rolling back systems, recovering from backups, and getting everything back into working order is part of the response plan.

User Response

The final element of incident response is all of the post-incident wind-down. The documentation, the root-cause analysis, and a breakdown of the lessons learned, as well as any additional reporting, go here.

This is also where adjustments to the overall incident response plan are made. More personnel training, changing alerts and alarms, and adapting the plan itself are all part of iterative security that is fully necessary in the modern cybersecurity environment.

Responding to an incident needs to be done ASAP, and reporting within 72 hours, to be within compliance with CMMC.

How Ignyte Can Help

Here at Ignyte, we’re experts in CMMC implementations. While we aren’t a security or incident response team, we can help in many ways.

Setup and achieving CMMC certification. The Ignyte Assurance Platform is engineered to help you track your adherence to security controls for frameworks like CMMC, and can make it much faster and easier for you to achieve compliance.

Ongoing monitoring. The world of security changes, and that means your state of readiness changes along with it. Keeping track of your current state at all times is also well within our capabilities.

Documentation and reporting. Keeping all of your documentation and artifacts in one place, within the platform, helps you have everything at your fingertips when you need to document your security.

You can book a free strategy session and see our platform in action simply by clicking here. Find out what Ignyte can do for you!

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/cmmc/cmmc-incident-response-timelines/