A Deep Dive into Rev 3: Incident Response (feat. Adam Evans)

[00:00:01] Hello Climbers and welcome to Climbing Mount CMMC. Boxing up by 6. Good job. What is it doing? Looks good.

[00:00:18] Hello Climbers and welcome back to another episode of Climbing Mount CMMC the podcast. My name is Kaylee Floyd and this is Adam Evans and we are part of an MSP called Axiom that is CMMC Level 2 Certified and we are excited to be here. We are excited to do a Splunking Deep Dive into Rev 3. Now if you guys are new with us, we have done this before in the past and we'll link some of our deep dives down below about Rev 3.

[00:00:48] But for those of you guys who are new and not aware what's going on in the CMMC ecosystem, for 32 CFR right now, as of the time of this recording, the important document from NIST 800-171-REV2 is what is important to us. Okay, so all of the controls, 110 controls, 320 assessment objectives are what we have to adhere to as a CMMC Level 2 Certified MSP.

[00:01:17] And for those of you who are organizations seeking certification, you're also having to adhere to these security controls and requirements. So NIST 800-171-REV3 is around the corner. It's actually already created. It's actually already published. You can take a look at it. You can review it. You can make your SSP based upon it.

[00:01:35] But as far as CMMC requirements go, we are not adhering to Rev 3 quite yet. That is coming around the corner and is going to be our future. And so how do we prepare for it?

[00:01:49] Well, I think we need to talk about it and see what's different from Rev 2 that we have, you know, our SSP based upon right now. If you guys are organizations that have an SSP based upon Rev 2 requirements, how you can prepare and understand what the differences are to prep your SSP for Rev 3. Because it is no small feat. Is that right, Adam? No, not at all. Especially depending on how the companies do their documentation and their structure. We found on our own journey, some things are pretty easy to prepare ahead of time and be ready for that Rev 3 approach.

[00:02:19] But there are certainly other ones that have more notable impact and add new challenges that companies may have to solve for. So it's a lovely can of worms, but it's the can of worms that you know. Yeah. And, you know, Adam does have the privilege and the honor of looking into this for us internally, and he knows it all too well. So why not have him on this podcast episode to dive in to this topic? And so what we're going to be focusing on today is incident response.

[00:02:47] So the IR domain, if you guys are not aware, you're going to turn your chapter to 3.6 and the dots below that, right? So 6 is the magic number for incident response. And if you guys want a little bit of an overview before we dive into some of the more detailed differences, something that is big to note is if you're looking at, and if you have NIST 800-171 Rev 2 pulled up,

[00:03:12] you're going to see that Rev 2, which we base ours upon NIST 800-171A, because that adds in the assessment objective level, which is important to look at. If you're looking at those controls, there's going to be 3.6.1, 3.6.2, 3.6.3, and stop. That's it, right?

[00:03:34] But if you're looking at Rev 3, you're going to see a 3.6.4, and you're going to see a 3.6.5. So right off the bat, there are actually two new controls that are added to the IR domain, and they come with new titles and new requirements underneath. But some of them are kind of nested into others, and Adam has some opinions on that.

[00:03:59] So Adam, if you want to go into sort of your basic, just first high-level interpretation, reading this from creating, you know, our SSP and clients' SSPs based upon Rev 2, and then seeing the Rev 3 difference. Yeah, I mean, at a high level, the changes and the differences here are pretty straightforward and make a lot of sense. I think that's kind of my general take for anything related between Rev 2 and Rev 3 is it makes a lot of sense. Because we have to keep in mind, when Rev 2 was originally authored, it was, you know, the early 2000s, 2010-ish or so.

[00:04:29] And the technology world was a very different place. Ransomware variants were fairly new and novel and kind of this uncommon thing that we would see. Still the scary, you know, boogeyman at night. But now we're seeing AI-powered threat actors that are using more novel technology. There's even a conversation about Mythos from Claude, who supposedly has these capabilities to rapidly analyze vulnerabilities and exploit them. And there's a lot of, you know, fear, uncertainty, doubt, hype around it. But the reality still comes down to is there's still threats, there's still incidents,

[00:04:56] and organizations need to prepare for when the incident occurs, not if it will, when it will. Because even in our own approach, we're very confident in our security posture, our compliance posture. But crap happens. You know, it only takes, you know, security is only as strong as your weakest user or your weakest sysadmin or your weakest configuration. So things can still go horribly wrong. And it's, you know, this domain is to make sure that companies with CMMC obligations are prepared for those eventualities. Yeah, let's dive in. Well, actually, there is one thing I do want to preference.

[00:05:27] ODPs, Organization Defined Parameters. Now, the thing to note about Rev. 3 is that you're going to see these sections that are, they have assignments for different types of ODPs. Those Organization Defined Parameters are defined by the organization that oversees the area that you're in.

[00:05:48] So, for example, if you're a defense industrial-based contractor, you're going to adhere to the Department of Defense's ODPs, right? And they have defined those for you.

[00:06:00] And so if you are reading into this and you are a contractor in the DIP space, then what you would do is look at any time you see one of those, which Adam will go into that as well, you're going to go back to where their ODPs are defined and see what those are based upon the Department of Defense or Department of War. Right, because something to keep in mind with 800-171-REV2 and REV3, the full scope of the document, the title, is Protecting Controlled Unclassified Information in Non-Federal Systems. That's right.

[00:06:30] Last I did check, we have more than one federal agency aside from the Department of Defense. I probably have some good jokes and comments around that, but we can certainly find me in the hotel lobby at a conference sometime if we can get those jokes. Sure. But that also sets up for those conversations that still float around the CMMC ecosystem of what if another government agency ever were to adopt the CMMC-CEY program? Yeah. You know, we know the Department of Defense is doing it. We know the GSA is doing it as well.

[00:06:59] But there's always the conversation because there are CMMC-CEY categories associated with education. So the education department could come online. Same with energy. Same with agriculture. I could go on and on. You want a good fun list? Read the CMMC-CEY categories. Align that to federal agencies and have a field day speculating. We're not going to do that today. Right. Exactly. So starting off, we have, you know, if people watching the video and we glancing over some reference notes, my reference notes for anyone that might want to look is just 800-171-REV3 made available on the NIST website.

[00:07:28] So our first one up here is just incident handling, which is implementing an organization incident handling capability that is consistent with the incident response plan. It includes preparation, detection, analysis, containment, eradication, and recovery. Mm-hmm. Largely unchanged from what we have previously from REV2. But notice a few small tweaks here that is consistent with the incident response plan. Remember that. We'll come back to that later. Mm-hmm.

[00:07:55] If we move on to 362, actually, well, before I move on. So just keep it in mind on some of the requirements here. Again, your basic phases of incident response and incident management, you need to prepare for that. You need to have mechanisms to detect incidents. You need to have a capability to analyze those incidents, whether that's internal and in-house with your own industry professionals or outsourced or both. You have to have mechanisms to contain that incident to prevent further spread. That can be automated. That can be manual. There are several different ways you can go about doing that.

[00:08:26] And there are lovely products and solutions out there from, you know, CrowdStrike, SentinelOne, you know, Microsoft. I can sit here and name vendors for the rest of the hour, and I don't think you want to hear me give a list of companies. Your key thing on that, though, is if they can capture a file and submit it for analysis, you need to remember that they could be capturing CUI. So keep that in mind. Mm-hmm. Great point. And then, of course, your eradication mechanisms, a.k.a. get the threat actor the heck out of the system or remove the malware or whatever the case may be.

[00:08:54] And then recovery, getting things back to the status quo, back to standard baselines, back into a functional state. Right. So those are all core elements of just an incident management program regardless of CMMC. But under CMMC, those are core requirements. So that lets us move on to 362. That is your incident monitoring, reporting, and response activities. We've got four assessment objectives and some ODPs in there. First off, we've got a track and document system incidents. When something happens, write down that it happened, go through the process, and what you've done for it.

[00:09:24] In short, if you're an IT provider like us, ticket notes. If you're doing it yourself on your own, you want to start creating that paper trail to show who did what and when, who authorized it, what was impacted. Because it may be a low severity incident at first, but keep in mind these more advanced nation states, they get access and they sit tight and they wait. That alert that you're seeing today could turn into the big data exfiltration a month from now or a year from now. So it's important to just keep those records being created.

[00:09:54] And if Dibcac or anyone else ever comes knocking, they're going to want to see those records, even if it's a false positive, just to show that you still followed a process and you had logic to determine that it was a false positive. And just again, good notes, references, things that you can do to help correlate and just think outside the box as things move down the road. So then you have your second assessment objective. Report your suspected instance to the organizational instant response capability within. Yeah. You've got an ODP. Yeah. I'm already seeing here too, Adam, with comparing it to Rev2.

[00:10:23] Something that's interesting that they're doing here in 3.6.2 is like the track and document assessment objectives looks like it's smushed into one. So like assessment objective A says track and document the system's security incidents. Whereas if you look at Rev2, it has it as A and B. So it has it as incidents are tracked as one and then incidents are documented as another.

[00:10:53] Right. And it's kind of a logical next step because if you think about it, if you're tracking the incident, how many people would just think through an instant response process to have a running list of here's all the incidents or what actually came of those incidents? Right. And in our experience too, you know, we're still documenting regardless of false positive, you know, technically a true positive but benign incident. Unfortunately, no history of critical events in the CMMC space. So hopefully no actual incidents have to go through this process.

[00:11:22] But again, it's a matter of when, not if. Mm-hmm. Mm-hmm. But it's still just a matter of having that good practice, that good paper trail, et cetera. So then you have, again, you know, I mentioned assessment objective Bravo there of reporting incidents to the organizational instant response capability. That's a little bit of an interesting statement because that capability could be technical and that could be personnel. So the key driver there is making sure that those incidents are reported in some way, shape, or form.

[00:11:46] That could be, you know, Kathy in accounting that says, I've got a note on my computer that says all my files have been locked and I need to pay with something called Bitcoin. Oh, no, Kathy. Yeah. That's still a report. Yeah. And that also works through those options as well as reporting to internal client officials as well. Think about things from a perspective, even if it was just us internally.

[00:12:09] If something goes bump in the night and we get an actual legitimate incident, we'll just say nation-state threat actors compromise one of our employee accounts. Bobby, who's not here right now, will definitely want to know that's happening. And we, in our process, we have to make the leadership team aware that things happen because if it is a significant incident, there may be other facets that come into play, such as legal counsel, public relations, et cetera. So it's important to remember those reporting requirements internally as well.

[00:12:37] Yeah, that is so interesting how that's D for this assessment objective. But I see, again, it looks like they clumped them together because if you're looking at Rev. 2, they have them broken out as not only identifying those people, whether that is the officials, like what you were saying, or just the person themselves, but also to report or notify when something happens.

[00:13:02] And those are clumped together here in Rev. 3 as well, where it's like kind of what you were saying earlier is like, why wouldn't you do one and not the other? Right. So kind of goes hand in hand. Yep. And that leads us really well into assessment objective Charlie here, which is report incident information to assignment organization to find authorities. Right. Exactly.

[00:13:23] So those are going to be your external entities. DC3 under the DOD side of stuff. I think the GSA has a different reporting requirement. And then, of course, you can identify your own authorities as well, such as local law enforcement, FBI cybercrime center, U.S. CERT, CISA. You can basically start doing your own list from there. Cyber insurance certainly comes to mind, legal counsel. So it's a matter of you've got your bare minimum to hit, but you may need to exceed that bare minimum based on your specific business needs. And it's important to keep that in mind.

[00:13:49] That is such a great point. Yeah. Don't just take the ODP and say, that's where I go. And I stop there because you internally as a business have your own people that should be notified as well. Yep. And a lot of insurance policies will say you have to report incidents as soon as practical upon discovery or something like that, too. Yeah. So you can't, you know, if you're forgetting that process through your IRP, you know, you may come down the road, have an incident, you know, go through your IRP and say, oh, crap, that costs a lot of money. I need to file that insurance claim.

[00:14:17] And, you know, you've done that three months ago and insurance is going to look at you and be like, really? We told you you have to report within five business days of discovery and it's been three months. We're not paying this out. Good luck. Yeah, that's a great point. So, and then our final bit here is assessment objective Delta. This is a newer one. Provide an incident response support resource that offers advice and assistance to system users on handling and reporting suspected incidents. Now, what does that mean?

[00:14:43] So let's put it down in simple layman terms here. You've got end users. They're not IR professionals. There's not necessarily technology professionals. They're just, you know, Kathy in accounting, Steve in sales, you know, whatever your organization has. When they see something or something goes on, they don't have the institutional knowledge of an instant response professional or IT person. They need instruction and that instruction needs to be clear and concise.

[00:15:08] So easiest way to describe that, see something, say something. It can be big. It can be small, but give a clear pathway for them to be able to report that incident up to management, IT department, the MSP. But make sure they have that, they know that, and that resource is able to provide that level of advice. And you might want to think about some thresholds of that, you know, but it's a real big exercise in psychology and thinking about that too.

[00:15:32] Because inevitably you will have that user that says, oh my gosh, sorry, I clicked the link. What do I do? And it's important in those situations to remember these are people. They have their own skill sets and strengths. That's why they work in the organization. And those skill sets and strengths are not what the IT department or the security professionals have. So many times you see those stories out there of people saying, I'm afraid to report the incident because I don't want to sound stupid or be made fun of or be called dumb.

[00:15:59] But if you're the security professional that makes your users feel that way for saying, I saw something, just update your resume and change industries because you're doing it wrong. I could not agree more. You know, the role of security, we're there to support people and make sure they can do their job safely. And sometimes that means handling that request that might be a little annoying or a little silly or the, oh my gosh, you clicked on a very obvious phishing email.

[00:16:23] But remember, they're people. Would you berate your parents or grandparents because grandma clicked the link in the scam text? No, you wouldn't. Like, so again, some basic empathy goes a long way here and that strengthens your defense posture. Yeah, I could not agree more with that. And going into talking about 3.6.3, there's not really a huge difference here going from REV2 to REV3 for this control.

[00:16:51] But could you just give a brief description on what really that control is for and the purpose behind that? Yeah, it's just a simple instant response test. You know, test the effectiveness of that instant response capability at an organization to find frequency, which I believe is at least yearly or after significant changes. So just, you know, make sure the people that are responding to this know what to do and you've tested it. Because those tests will often expose weaknesses, lessons learned, areas of improvement.

[00:17:15] And those people need to be trained and sharp, which segues perfectly into 3.6.4, instant response training. Perfect. Yes. I love it. So think about what that training is. You've got provide instant response training to system users consistent with assigned roles and responsibilities. AKA, don't teach Kathy in accounting how to do digital forensics because that's not her role and responsibility. But treat your, you know, but maybe consider that for your security team. Right. But that has three of those objectives under that.

[00:17:43] So that's within an organization defined time period of assuming an instant response role or responsibility or acquiring system access. And I believe that they have at least annual and then within a certain time period of getting that access. So you've got some flexibility when you hire that new IR lead to give them a little bit of flexibility. Or you can require it proactively and ahead of time. And then, of course, your refreshers. But also you have when required by system changes. Yep.

[00:18:12] What that basically boils down to, it's great that you train your entire people how to do instant response on a 365 tenant. But when you migrate to AWS Gov, whole separate set of procedures and new training needs to be done. Exactly. And finally, you have the third one, assignment organization for defined frequency thereafter. So an ongoing repeatable training program. Yeah.

[00:18:35] And then your final assessment objective there is review and update instant response training content, assignment organization defined frequency, and following assignment organization defined events. So what they're looking at there is keep your keep your stuff up to date. Don't train on old, outdated methodologies and whatnot. Keep it fresh. Keep it relevant. Make sure people are getting the latest and greatest. And that frequency, I believe, is annual.

[00:18:59] And the organization defined events is significant changes, changes to risk or an incident, if I'm recalling correctly. Yeah. And then lastly, before we close today, 3.6.5 is an incident response plan. This is not going to be in Rev 2. You're not going to see that in Rev 2 as a defined control. But do you want to explain what the purpose of that is? Actually, it might be in Rev 2 in Appendix E under the NFO controls. Oh, good point. Yeah.

[00:19:28] But essentially, it's that, okay, so you've done all this other stuff. You've built your, you know, how you contained, identify, et cetera, incidents. You've identified your people. You've trained them, et cetera. 3.6.5 really just says, write it the F down. Right. Document it. Yep. So you've got develop an IR plan that provides the organization with a roadmap to implement the instant response capability. Describes the structure and organization of the instant response capability. So thinking through how does the organization get there? What's the structure of it? Where do ESPs come into the mix?

[00:19:58] Where do these vendors come into the mix? How does insurance fill in the gaps there? It provides a, you know, our third assessment objective under 3.6.5a is provides the high level approach for how instant response capability fits into the overall organization. I actually just said that. It defines those reportable incidents. What is an incident that you must report? Is it a failed login from an external entity? Because, spoiler alert, if you define that as something you report, you're going to be reporting incidents every freaking hour and you're going to go insane. Yeah. Do you have the time for that? Yeah. Right.

[00:20:26] But you definitely want to make sure you're reporting data exfiltration. So something to keep in mind. Right. It also details out for your fifth one, addresses the sharing of incident information, a.k.a. when do you have to share information? How will you do it? And it designates those responsibilities to those organizational entity, personnel, and roles. You then have to get copies of that IRP to those people. Because how can you have a team of people doing an instant response if they don't have the freaking plan?

[00:20:52] And then, of course, you get to your next one here is update the IR plan to address system and organization changes or problems encountered during the implementation, testing, or execution of the plan. So, again, keep it up to date. Keep it fresh. Keep it relevant. And finally, last but not least, protect the IR plan from unauthorized disclosure. Yes. If I'm a bad guy and you give me your playbook and plan, I'm going to be playing defensive agent the whole way through and laughing as you're trying to keep up with me because you don't know I know your plan. Right. Yeah.

[00:21:21] Don't post that on Google for people to see. Yeah. Or LinkedIn or X or leak it in Discord or whatever. Yes. So, again, it's all very relevant stuff, not super wild or different from Rev 2. Smart enhancements that really boil down to write things down, make sure the right people have it, practice it, and keep it updated. Exactly. Could not have said it better myself.

[00:21:46] Well, guys, I hope you enjoyed today's episode getting into the nitty-gritty spelunking series of the IR domain. We're going to be doing more of these, so stay tuned next Thursday for another episode of Climbing Mount CMMC. Thank you, Adam, for joining us today, and we hope you guys enjoyed today's episode. But until then, guys, as always, keep on climbing. See ya. See ya.