Today we are focusing on a review of CMMC Section 3.6, which provides individual practices for incident response after a cyberattack. The biggest takeaway? Good cybersecurity isn’t just about preventing attacks; it’s also about being prepared to respond.
Table of Contents:
What You Need to Know About CMMC Incident Response
Section 3.6.1
Section 3.6.2
Section 3.6.3
Your Guide to CMMC Compliance Success
Don't want to read the article? Watch the full recording below.
Be sure to register here for the Cybersecurity for the Rest of Us webinar series!
Section 3.6 contains three practices. Broadly speaking, they focus on the need for your systems to be capable of handling an incident. That includes not just preparation and detection but also analysis, containment, recovery, and user activities.
That nuance is important — the guidance now recommends more than simply having an incident response plan on file. While you might be tempted to think you can easily prepare a plan that satisfies all three of the practices detailed below, a closer look will likely reveal otherwise.
3.6.1: Establish an Operational Incident-Handling Capability for Organizational Systems that Includes Preparation, Detection, Analysis, Containment, Recovery, and User Response Activities
Most of our clients come to us focused on preventing cybersecurity incidents. That’s understandable — nobody wants to experience a breach or be the victim of a phishing attack. But it’s noteworthy that this first practice also calls out containment, recovery, and user response activities.
In this day and age, as attacks have become more sophisticated, we are seeing a shift in the industry. We need to look beyond just stopping an incident and determine how to react when one happens.
Your people and processes are key here. Having good tools is important, but tools can’t always look at the data and understand what’s actually going on in the moment.
For example, if an employee tries to log in from a home connection and then remembers to use their VPN, a tool may register this as a person signing in from two locations at the same time. You need people and processes to be able to take that data, understand what it really means, and then decide if it needs a response.
Another area where you shouldn’t rely solely on tools is detecting insider threats. If you have a disgruntled employee exfiltrating data, the security tools probably won’t detect their behavior unless it’s far outside of the ordinary. While this isn’t the kind of thing organizations usually test for, it’s also not an unusual scenario. You need good people and processes in place to be ready for it.
Let’s continue with the example of a disgruntled employee: Once you’ve detected the incident, what happens next? Do you go to law enforcement? Does HR need to be involved? Have you been (or should you be) monitoring all your employees?
These are questions you need to consider before an incident takes place so that you already have the answers when you need them.
The same is true when it comes to determining who needs to be informed or involved after an incident. At a minimum, you should have a table in your incident response plan that includes representatives from every department in your organization. You will also need to identify your key stakeholders and decision makers. When a security incident takes place, you don’t want to lose time figuring these things out after the fact.
The most important thing to understand here is that organizations should be spending a lot more time planning on what to do after an incident. Because while there’s been plenty of emphasis on prevention and detection, organizations have spent far too little time on analysis, containment, and recovery.
It’s not fun to think so, but eventually you’re going to be hacked. Now is your opportunity to plan for how you’ll respond.
Section 3.6.2: Track, Document, and Report Incidents to Designated Officials and/or Authorities Both Internal and External to the Organization
When an incident occurs, who in your organization must be informed? What about law enforcement, state officials, or the federal government? What executive orders have been passed that you must abide by? And if you’re on a federal contract, what contracting officers need to be notified?
While the answers to these and similar questions depend heavily on the industry you work in, you must make sure you know them in advance. Agencies may have different requirements, or different notification methods, including web portals, particular forms, or specific people you’ll need to contact.
It’s a lot to figure out, but right now, time is on your side. After a security incident? Not so much.
Beyond the ethical component of reporting incidents properly, there can also be serious legal and financial repercussions to making mistakes. To name just one example of many, Twitter was fined $150 million by the Department of Justice over privacy violations. While that may not seem like much to a social media giant, these hefty fines can have serious consequences for smaller businesses.
Why do organizations fail to report incidents? Often it has less to do with the threat of a fine than it does with making assumptions.
A lot of companies who don’t report incidents simply assume the incident doesn’t meet the threshold for reporting, and — once they’re in the middle of a crisis — don’t have time or resources to confirm their assumption is correct.
That can be a costly mistake.
It’s important, then, to plan ahead and make sure it’s absolutely clear what the reporting threshold actually is. Equally important is making sure your information is all up to date. What are the current requirements about reporting? Do you have the correct contact information for those you need to inform? If you haven’t updated your information since you signed a contract five years ago, you may find it’s out of date when you need it. Make sure that doesn’t happen by verifying early and often.
Section 3.6.3: Test the Organizational Incident Response Capability
While the first two practices are tied to your legal obligations after an incident, this practice is focused on testing your incident response capability.
Your ability to recover after an incident depends, in part, on how well you have tested your systems and processes.
For example, many organizations assume they can rely on their backups. But do they test to ensure those backups work? We’ve seen numerous organizations that created regular backups … only to find at the critical hour that some of them didn’t restore.
In addition to testing your systems, you also need to regularly test your processes. One of the best ways to do this is to create a tabletop test library. This library should be composed of testable scenarios specific to your organization, inspired by your environment. It should also be regularly updated with new scenarios as they become relevant.
Most importantly, these tests should be teaching you something. Create a “lessons learned” document and update it with the results of your tests every month or each quarter. Use those lessons to evolve your organization to be more adept and agile at incident response, and make sure you’re doing your due diligence. The last thing you want is to have a data breach happen due to a documented problem that you’ve done nothing about — that opens you up to a whole world of potential liability.
If you take only one lesson from this blog, let it be this: Your organization will eventually be the victim of a cyberattack. The practices outlined in Section 3.6 offer guidance on the best way to prepare yourself and your organization. By making a plan, creating thorough documentation, testing your preparations, and regularly updating all of the above, you can ensure you’re prepared for the worst.
If that sounds like a lot? It certainly is. But you don’t have to do it alone. Contact Ntiva today, and work with a partner as dedicated to your business as you are.