Welcome back everybody to part four of “What you need to know about CMMC”. I’m Bob Hanley from Sabre Systems and today we’re going to continue our discussions on CMMC domains. During the series, we’ve been discussing the 17 CMMC domains and as you remember we discussed identification and authentication last week, or IA. Today, we’re going to discuss incident response, commonly referred to as IR. Remember, CMMC is about protecting controlled, unclassified information, or CUI. That includes “lim-dis” – limited distribution and FOUO, “for official use only”.

So, as a refresher, CMMC has five maturity levels with five being the most stringent. Contractors and subcontractors will all need to have the minimum level 1. Prime contractors will need minimum level 3. IR has level 2 and level 3 requirements but does not have level one requirements. It does have level four and level five, but today we’re only going to focus on what you need to get to that level three as a prime contractor. Incident response is geared towards protecting your organization’s information, as well as its reputation by developing and implementing an incident response infrastructure. Level two and level three are about documenting and managing processes as I described earlier.

So level two IR – five practices and controls. The first one is establishing an operational incident handling capability. For organizational systems, that includes preparation, detection, analysis, containment, recovery and user response activities – emphasis here on activities because next on control we will talk about managing events. So how do you obtain incident information? Well you need to establish a collection process, typically email dropboxes, SharePoint, etc. Determine who in the organization needs to be informed about incidents – that hopefully should be easy to do, harder in a larger organization, not as hard in a small organization. Establish the process for how to submit incidents. So, if somebody gets an incident they get a phishing scam email, there should not be a question on what they should do in order to inform somebody about this incident. So, that activity needs to be captured. Define the process of what you should do if an incident occurs. That should be well documented, there should be no second guessing if you have an incident on how to react to it and who to inform.

So an example, if you receive an email that looks suspicious, typically called a phishing scam, you need to send this to your security team for inspection, but you also want to make sure your team knows how to handle any phishing email that it gets. So as an example, a lot of phishing emails have links that you should never click because it could impart malicious code within to your system and cause significant problems. So please make sure you track on how to do that information and how to send that information to your security team.

The second practice is about detecting and reporting events, emphasis here on events. Now that you’ve established the activities that need to take place on IR, you need to understand the reporting process for the events. First, you need to understand how to detect events on your network. An event is any observable unusual or unexpected occurrence on your network. An example: your business operates from 8 in the morning to 6pm at night. Nobody really works there from 6pm at night until the next morning. If you notice a high amount of traffic on your network when you’re closed, that is an event that you should be reporting on after you’ve detected it. So, you can detect events in several ways – observations of breakdowns and processes or loss of productivity within your company could be a trigger point. Observations such as alarms and alerts, notifications from other organizations or the results of audits or assessments. After you detect an event determine if it will affect organizational assets and/or has the potential to disrupt operations. This may require the start of the incident process and report. So report the event through direct communication with your security team via text messages, email SharePoint, etc.

So, the third practice is about analyzing and triaging events to support event resolution and incident declaration. You should analyze all events to determine what action to take. Through analysis you should determine the type and extent of the event – is it physical? Is it cyber? Whether the event is related to other events, is this part of a bigger issue, an attack on your company that’s systematic, widespread, systemic, one that could significantly impact multiple sites if your company has multiple sites. In what order events should be addressed is based on the perceived criticality to your operation. So, some may be considered minor and can be handled within the next few days, others are urgent that may have to be handled right now in order to stop the damage to your company. So, a phishing scam from security telling you to click on a link could be a major problem if that sufficient scam, uh, that you find out through further investigation. So, what does this mean? So, companies are able to and hackers are able to take over your typical protocols for emails and send emails within your company that look like actual emails coming from your security team. Now you could just click on the email address and it will probably show that it’s not coming from your organization and that is a typical technique for you to take. Uh, first and foremost, if you see an email that looks suspicious click on that, that email see where it’s coming from. Oftentimes you’re gonna see some weird string of letters on there or something like “dot with some other country’s two letter initial”, uh, associated with it, etc. So that’s pretty simple, but if you’re unsure you need to send that to your security team and never click on a link within a suspicious email.

Analysis also helps the organization determine whether to escalate the event to an external staff. So not every company can afford a security team to do this and oftentimes they will hire out, externally source, companies or manage security service providers commonly, referred to as MSSPS.

The fourth practice is developing and implementing responses to declared incidents according to predefined procedures that you established. So, write these procedures ahead of time, these procedures will help guide the development and implementation of responses during an incident. It should be well documented, very clear to all the people within your company on exactly what they’re supposed to do. If not, delays could occur, damage could occur, etc. Make sure this is clear, train your people.

So, we’ve talked about training in some of our previous domains. It applies here, as I’ve talked about these 17 domains interact with each other considerably and complement each other so by time we’re done all 17 domains you should have all the tools you need to protect your company. At any rate, the type of response you do will vary depending upon the incident and your responses might include stopping or containing the damage, you might have to take hardware, uh, or systems offline within your company. Communicate to your users, you know? Tell people “don’t open specific types of email messages”, right? Communicate to your stakeholders, corporate management, leadership, etc. what’s going on and implement controls as soon as possible to preclude further damage or prevent future occurrences from happening.

So, the last level two IR practice is about performing a root cause analysis on the incident to determine the underlying cost. So, an after-action report, as it is typically referred to in the military, find out what happened, why it happened, how you could prevent that from occurring in the future. So, very important to be able to do that and in the future be able to figure out what actions could have been taken to stop the series of events that occurred previously from happening in the future. So examine the causes of the event or incident, how your organization responded to it, look at the administrative technical and physical control weaknesses that you may have, use available practices such as cause and effect diagrams, perform this root cause analysis, talk to each other, talk to the people that were involved with this. Communication is the best way to figure out what happened. Everybody may have a slightly different perspective of what actually occurred and that’s why white boarding sometimes is the best way to figure out exactly how all these events unfolded. After incidents are resolved, conduct reviews and capture the lessons learned, make improvements based on the outcomes of these activities, and update your plans and controls for future use and implementation.

Okay, let’s move on to level three. So, IR has two practices and controls at the level three. The first is about tracking, documenting and reporting on incidents to designated officials and/or authorities both internal and external to the organization – sounds pretty simple, but there can be a lot of steps included in that. So, incident response is about managing the consequences and reducing your risk to a future security breach or cyber-attack. The majority of processes consist of, as we discussed earlier, identification, containment, eradication and recovery from the incident. You should designate a central point of contact or security team to coordinate, communicate and track the activities. This point of contact should receive and document information from system administrators, incident handlers and others involved throughout the process. Designated staff, as designated staff member, members should also be assigned to work with stakeholders to provide the proper communication inside and outside of your organization. Please make sure you document all your actions, uh, in case further process improvements are required within your organization. People don’t elevate issues or delays in action, or loss of continuity of operations, all can occur because people didn’t take the proper steps to manage the, uh, tracking and documenting and reporting instances.

So, the last practice at level three is about how you actually test the organizational incident. Testing an organization’s incident response capability validates your process and highlights any changes, problems you may have. The test should seek to address questions like: “What happened during the incident? Who’s responsible for incident management? What tasks are assigned within your IT organization? What support will be needed from maybe your legal team, maybe public affairs or other business components within your organization? How are the resources obtained, if needed, during the incident? You may not have the appropriate staff. Do you outsource or do you have enough people inside your company to be able to address these issues and do you have to include law enforcement if you’ve had a significant breach that impacts some of your clients or personally identifiable information or financial records, etc?” You may have to bring in law enforcement, usually the FBI, and any negative impacts to normal day-to-day mission when responding to an incident should be identified and documented.

Okay, so those are the seven practices for IR for levels two and level three. Six additional practices are added for levels four and level five, which we did not cover today, but in future use if you do decide to go for a level four or level five 5 certification, those could help you in future RFPs that come out with additional bonus points awarded by the government. So, things you should do now: fund the program, I say that week in and week out, become familiar with CMMC in general and NIST SP 800-171 and 800-53, specifically.

So, thank you! In our next review, we will discuss CMMC practices for maintenance, also known as MA, and I look forward to seeing you then and thanks for sticking with us throughout this series as we move through the domains for CMMC certification. Thanks, and I’m Bob Hanley from Sabre Systems.