
CMMC Compliance Guide
Our experiences inspired the creation of The CMMC Compliance Guide Podcast and its accompanying resources. The podcast began as a way to share what we learned through real-world challenges—like helping that aerospace machine shop—and to provide accessible education for businesses navigating DoD cybersecurity requirements.
The CMMC Compliance Guide Podcast breaks down complex topics like NIST 800-171 and CMMC into actionable, easy-to-understand steps. Whether you’re a subcontractor struggling to meet compliance deadlines or a business owner looking to secure your supply chain, the guide offers practical advice to help you take control of your cybersecurity journey.
CMMC Compliance Guide
Decoding NIST 800-171: Your Plain English Path to CMMC Level 2 Compliance
Submit any questions you would like answered on the podcast!
Feeling overwhelmed by CMMC compliance and NIST 800-171’s 110 controls? You’re not alone — but you don’t have to be stuck.
In this episode of the CMMC Compliance Guide Podcast, Brooke and Austin break down NIST 800-171 Revision 2 in plain English — no government-speak, no tech jargon — so you can finally understand what each control family means for your business.
You'll learn:
- What NIST 800-171 really requires (and why it matters for your SPRS score)
- How to tackle key control families like Access Control, Awareness & Training, and Audit & Accountability
- The critical mistakes contractors make (and how to avoid them)
- Why documentation is the #1 secret weapon for CMMC success
- Real-world tips for manufacturing, machine shop, and aerospace contractors navigating CMMC Level 2
🔥 Don’t wait until an assessor says “No Soup for You” — build a compliance system that actually protects your business and wins contracts.
👉 Need help fast-tracking your compliance journey?
Visit https://cmmccomplianceguide.com to download free resources or schedule a discovery call.
Hey there, welcome to the CMMC Compliance Guide Podcast. I'm Austin. And I'm Brooke. From Justice IT Consulting. We're here to help businesses like yours navigate CMMC and NIST 800-171 compliance. We're hired guns getting companies fast-tracked to compliance. But today, we're here to give you all the secrets for free. So if you want to tackle it yourself, you're equipped to do so. Let's dive into today's episode and keep your business on track. Today's episode is your plain English breakdown of what those 110 controls in NIST 800-171 actually mean and how to stop being overwhelmed by them. Before we dive into control families, Brooke, can you give us the short version of what NIST 800-171 is and what even matters to our audience?
SPEAKER_00:Sure. So NIST 800-171 or revision two, because that's the one we're talking about a what we care about, even though it's been superseded by Revision 3. And we've covered that in previous episodes, but we're sticking to Revision 2. So that's the foundation for CMMC Level 2 compliance. It really is all about protecting FCI and CUI. CUI is the important part of that that you really need to pay attention to. And so if your business handles CUI as part of a contract, or potentially could, because some people don't ever get anything that's marked, of course, but you should have some DFARS clauses to look for. In any case, if you handle some of that CUI as part of your contract, you're expected to implement NIST 800-171, revision 2, and all of its full glory, and 110 controls. You're supposed to have all those implemented. By this point, the government says you've had plenty of time, and we just expect for all the costs to implement those to already be implemented.
SPEAKER_01:So they've got a contract, says they have to do it, and that's why it matters.
SPEAKER_00:That's exactly why it matters. And, of course, this is what your SPRS score, your SPURS score,
SPEAKER_01:comes from. Right, which is the self-assessment thing you have to fill out on Existar or whatever other.
SPEAKER_00:Yeah, so it's an Existar, of course. That's their kind of version of it. And SPRS, you actually enter it on the– PIEE website. It's a DOD website where you go in and enter your cage code and your score and stuff like that. And that's where you officially enter your SPRS score or SPRS score, Supplier Performance Risk System, I believe is what it is, but SPRS.
SPEAKER_01:All right. So since we're getting into the control families and we're trying to get it into plain language as much as we can. That's
SPEAKER_00:sometimes a challenge, by the way, getting into plain English.
SPEAKER_01:Yes. More so than we bargained for. Right. And I'm going to put it on you. Can
SPEAKER_00:you help us break it down in plain English? Right. You know, maybe... brick English or otherwise, you know, maybe a little bit of Texan or something like that. But yes, we'll break it down into as much plain English as we can.
SPEAKER_01:More understandable than the government does. Hopefully. We're trying to. Hopefully. These controls in the families, they're basically the federal government wants you to have as operational habits, right, that are supposed to reduce your risk in handling their information. And for For small contractors, it's about implementation that fits into your workflow without overwhelming the team. Can you start with access control and try and break that down and play in English for us? Sure. We'll start alphabetically because that's how NIST does it.
SPEAKER_00:Access control really is who can access what and all the other details that go along with it. You're looking at role-based permissions. You're looking at individuals permissions. not groups. You can't say a shop is accessing this or the engineering team is accessing this. It has to be Joe or Bob or Sally or George or whoever. You have to know who is accessing that information. So it has to be individualized accounts. It cannot be shared accounts. You can't just have one drive that is open to everybody. Even if you say this is all CUI, you really need to have it divided up and, you know, Joe can access this. Sally can access that. They can't access what each other needs to, unless there's a good business reason for them to do so. But just because it's easier to say, you know, here's all of it, is not a good reason to do that. You have access control for a reason. You need to control that access and make sure people have access to only what is needed. to perform their job.
SPEAKER_01:And I think it's a couple intentions there is you have, you get to see who accessed when What, when, right? And then you also have the just restriction of people not able to access things they don't need to, which is supposed to limit the scope of the risks. Like if their account got hacked, then it keeps that sprawl from going too far. Is that right? Is that the intention behind it?
SPEAKER_00:It does, yes. If their account gets hacked and they can only get access to part of it. You've got to remember that– This really is because, and we'll pick on China because they're easy to pick on, but this is really because if you go look at Humvee or the Joint Strike Fighter or several other things, China has some stuff that impressively look a lot like our Humvee and a lot like our Joint Strike Fighter, stuff like that. And it wasn't just by chance. It's because they broke in and stole all the stuff. So the government is saying, look, no more. We're going to protect our warfighters. We're going to protect our advantage. And we're going to do that by protecting this data. And it really all boils down to that's the government's data, and we need to keep our advantage everywhere we can. And that also does protect the warfighters. So that's really why they're doing this. I'll get off my soapbox there, but that's why they're doing this. Access control is very important. Only, you know, think about least privilege. Least privilege means that you only have the access that you need to complete your job. You don't have any more. In other words, you don't want your shop people accessing all the HR files right so you wouldn't want Joe seeing that Sally makes eight times what he makes you know or whatever it may be and a lot of people will control that but then when it comes to CUI it's just like well it's all CUI you know and or it's all it's all and actually more than that you know a lot of times the thought is well it's all it comes from our vendor and it's you know it's everybody needs access to it well they don't really need access to every bit of it some of it's contract information Some of it is part information, some of it, you know, so you can divide up that access to only who needs access to those specific parts. Is it a pain sometimes? I'll admit it's a pain, but you do need to divide that up and figure out. what the least amount of access is that you can give. It also goes to admin privileges for configuring the system as well. Do you want your local users to be able to install their old programs? Well, you may want to, but the correct answer is no. You don't want your users to be able to install programs and admin their own system. It's a simple one. They should not be local admins,
SPEAKER_01:for instance. It's coming from Uncle Sam, not from us.
SPEAKER_00:Right, yes.
SPEAKER_01:Sorry to spend so much time on this one, but this is a popular one. And say, like an aerospace manufacturer, a very common practice on the shop floor is to have computers. They're shared. You've shared accounts. It makes it easy. They'll go grab a program or enter a job code or something, whatever they need to do. And then. travel their machine, do their thing. They can't use shared accounts anymore, you're saying. Right. How would they handle that?
SPEAKER_00:There are several ways to handle that, but you really need to have individualized accounts for several reasons, but for compliance, you have to have it to access CUI. So you can argue what is CUI and what is not CUI. I can't remember what they call the data points, but the instructions for the CNC machines, they're just Basically, they're basically just instructions on what to do and the points where the machine goes to do that. Is that really CUI? We can argue that point, but if you have to argue the point and you have to bend over backwards to figure out that you don't think it's CUI, then is an assessor going to agree with that? Yeah. I would have a tendency to err on the side that says, yes, go ahead and treat it like CUI. Yes, that does throw a monkey wrench into things because you want to have shared accounts and all that kind of fun stuff. Then you've got to protect that data. Those machines don't necessarily– there's a whole can of worms there. But the point is– you really should access any of that data with an individualized account and no shared accounts. And you should, as much as possible, just get those shared accounts out of your system altogether. It's never– even outside of CUI and CMMC compliance, it's really not a good idea to have shared accounts anyway. I understand why it makes things easy. But when something happens, trying to find out who did it or whatever, it's impossible to find out what happened, right? So exactly. And I can tell you that a lot of times when something happens, people are like, well, we're going to give everybody their own accounts. Well, that's probably what you should have done from the beginning. But yes, no more shared accounts. Like I said, that's a big thing in machine shops. But it's just not a good idea. And not compliant.
SPEAKER_01:Everyone on the shop floor needs their own account, needs to log in to the computer on their own account, or if the computer's locked down, like a kiosk mode, whatever data entry or time clock machine they have, within that program, they need to have their own account as well.
SPEAKER_00:Yeah, if it doesn't have anything to do with CUI, it's just now, if you clock in to a certain job, want to know the individual that's clocking in and doing the work, so maybe, it depends on where you're authenticating, right, and what you're authenticating with, but at some point, you need those individualized permissions. And if you're logging in to clock in to a job, that job is going to have a job number. It may have some CUI associated with it. In any case, that should be an individualized account. But to access it, If you're not accessing any other CUI because that's where you would authenticate, then maybe you don't have to log into that machine with an individual account. But also, to back up just a little bit, if there is on a machine that you access CUI but some people need to log in and not access CUI or if you have a shared account, it's okay to have a shared account. You just have to do your proper access control and make sure when they log in with that shared account, they can't access any CUI.
UNKNOWN:Mm-hmm.
SPEAKER_00:So there may be things I need to do. Don't deal with CUI. And it's okay. You can use a fast user switching for that. But if you can access that CUI from that shared account, that's not a good thing. And again, access control.
SPEAKER_01:So moving on to this next one is a little less troublesome, I think, for people to implement, but far less popular. Or maybe it's not less popular in access control, but it's certainly not one of the more popular ones, which is awareness and training. Can you break that down, what needs to happen there, and some plain English on that?
SPEAKER_00:For awareness and training, looking at role-based training, you're looking at risks associated with their roles. So you need to have training for those people for their roles. You need to have cybersecurity training for risks that may be apparent in their job. And you need to keep track of it. And Actually, it reminds me about access and control, but I'll go back to it in just a minute. So you have to keep track of all that. You have to prove that you've been doing this training. Not only that, there's DOD mandatory CUI training, and you need to keep track of it. If you use the government's website for that, they get this little PDF. It's all great. It gives you a little certificate that says, good job, you just passed. And then if you don't do anything with that PDF, there is absolutely no tracking required. The government doesn't save anything. There's nothing else. So you've got to save that PDF somewhere to prove that you've taken that training. It makes it kind of a pain in the rear. But if you're going to do that for your mandatory CUI training, you've just got to remember to save that PDF. Shocking that they don't make that easy for you. Right. So it is a way to accomplish that CUI training. You've just got to keep them in a central spot. Yeah. keep them logged and all that kind of fun stuff. I think
SPEAKER_01:the main thing is the documentation. I think what you were saying there is being able to prove you've been doing it is don't listen to DOD, but far more important than the training itself. The training is obviously important, but in terms of getting certified for the people out there listening, you can do the training all day long and be learned on it. But if you don't have documentation, it doesn't freaking matter.
SPEAKER_00:Absolutely. You've got to have that documented. CUI is all about control and access, Managing that access, meaning ongoing management, and then it's about being able to prove that. So those things are themes throughout. And so to go back to access control, not only do you need to do all the stuff with access, I won't beat that dead horse anymore, but not only do you need to do all that with access control, but you need to be able to prove it and you need to document it. You need to document who's authorized, what devices are authorized, because access control is, is devices as well. Your computers, your smartphone, if you use a phone to access it and that's a whole nother can of worms. Uh, so, uh, but it's those devices that every, anything that accesses CUI person, um, Service account, application account, laptop, whatever it may be, needs to be listed and authorized. It's signed off on that, yes, you do authorize these things. Again, documentation. I've always said documentation, documentation, and documentation. What is it? Documentation. Oh, okay. Sorry, I forgot. But there's a ton of documentation that goes with this. That's throughout every one of these families, every one of these controls. So you've got to document everything to go along with your access control as well as your awareness and training.
SPEAKER_01:MMC is full of gotchas. Bet you all didn't know a lot of manufacturers and stuff out there. Your computer has an account too. A lot of people don't know that. So, like, you have an account to log in to the system, but your computer does too. And you have to manage that. Who would have thunk it? Right. Yeah. Absolutely. I guess it's IT people we know. Right.
SPEAKER_00:You also have to go a step further. You have to list all of your– anything that touches a network, anything that you might have on the network, you have to document all of it. Switches, access points, firewalls, you have to list all of it. Mm-hmm. And it's got to be a certain type of resource,
SPEAKER_01:UI asset or whatever. Which is why we always say documentation is the most burdensome part of compliance. All right, moving on to audit and accountability, that control family. Can you break that down in plain English for us?
SPEAKER_00:Logging is important. The proper logging is important. So you've got to make sure you have the proper logging turned on on your firewall, APs and switches, especially on servers and computers. workstations. You've got to have the right logging turned on, you know, who accesses what, when is what you're trying to get to. Also, who accesses admin functions and when and what did they access, right? You need to be able to log all that. And it's all pretty easy to log, right? But then you've got to protect those logs. So how do you protect them? Really, you get a SIM to ingest all those logs and keep them somewhere where they can't be deleted And then you give only a– again, this goes to access control. You only give people who need access to that logging, which are going to be the admins or maybe a– depending on how big your team is, a subset of those admins. So only certain people can have access to that logging. So– It's got to be protected. You've got to be able to log all that. And you've got to keep that for at least 90 days. We like to keep those logs for a year. Part of that is, well, it's really to go back and be able to find things that have happened. Forensics. Forensics, exactly. In our job every day, we use an IT. You try to figure out a problem, it's like, well– Go look at the log. See what the log says. You go look at the application log, security log, system log. You go look at the server. You go look at whatever it is. You look at the logs and try to find an error related. So it's the same concept. Any access you need to be able to look up and see if something goes wrong, this is where it went wrong at, and this is how it went wrong, and this is what happened afterwards, et cetera, et cetera.
SPEAKER_01:Yeah, and fun, another little fun, dirty little secret of IT is that log times, those logs don't exist unless you turn on the logging capability prior. So if you've never turned it on, you can't look at them.
SPEAKER_00:Yeah, by default, Windows doesn't have everything turned on necessarily that you need, so you need to go enable the rest of those logs. Same sort of thing with other systems. You've just got to make sure that those items you need logged are turned on. So you do have logging turned on with most systems. It's just not always enough. Sometimes it is. Most of the time you need to go in and tweak it a little bit.
SPEAKER_01:Yeah, so logging seems like a simple... task until you dig in that you have to protect it and turn on all these extra things and everything else.
SPEAKER_00:The other thing that I will say that a sim helps with, sorting through all that data. Back in the day, in the early days for me in IT, I guess I'm kind of a dinosaur, but there are people that are even more dinosaur than me. I could look through a log pretty easy and find stuff. I didn't know
SPEAKER_01:abacuses had logs.
SPEAKER_00:They do. An abacus has an abacus that's a log for it. But you can look through logs and find stuff pretty easy. And you still can look through logs and find stuff. But when it really comes to forensics, it's harder these days than it used to be. And even network traffic. I used to be able to sniff some network traffic and be able to tell pretty easily what's going on. In fact, I've found some infected machines that way before. But these days, that's really hard. to find network sniffing because a lot of the stuff is encrypted. The traffic is encrypted. The data inside the traffic is encrypted, so you can't necessarily see what's going on. But anyway. All that just to say there's a lot that goes on in those logs, and there will be tens of thousands of entries for you to have to go look for and search for things, and it's a lot easier to get a SIM that will help you with popping those alerts. It's also a lot easier if you have a SOC team, a Security Operations Center team on the back end, and there's caveats to that about what you can use and what you can't. Even with a SIM, too, you've got to be compliant. But if you have a SOC team on the back end that are actual real security, certified real security experts that do that 24-7. They can definitely find more than you can.
SPEAKER_01:And what you're talking about there is that there are vendors that you can pay will either use your application, the SIM you bought that aggregates all your logs. They'll either provide that or use yours and then look through it. So you don't have to actually hire the people in-house. Correct. You can kind of hire them fractionally, if you will, kind of like an accounting system. Exactly.
SPEAKER_00:I would argue that you need those people because as good as IT people might be, as good as your best engineer might be, and I'm an engineer and architect, but I realize I can look through the security logs and I can find a lot of stuff. Just a quick anecdote about this. Some of you may know about it. The Rite of Boom, I went to that. They have some pre-day contracts. learning classes. And so I went to one of those, I think it was a life in the day of a SOC analyst or something. Right. And so you have a, they give you a scenario and then you split up in teams. I'm pretty proud of what I can look through and find. And I feel pretty good about myself. I realize I'm not a rocket scientist. Okay. Uh, but I feel pretty good about my ability. So we go through this, uh, we do pretty well. Our team gets a second place and, uh, we figure most everything out or feeling real good, you know, like what we did, you know, and we After they get finished announcing results and everything, they say, oh, by the way, this case was so easy, we almost never see this in the wild. That made us deflate pretty quickly. But things are a lot more obfuscated than a lot of people give it credit for. So when something really goes wrong, it's obfuscated, hard to tell, hard to see. There was a– not to chase another rabbit, but there was a cybersecurity alert because we have to stay on top of those– you know of a new malware and one of the obfuscation techniques it uses is it uses some characters that look like blank spots and and so you don't see the command because it's out of your vision and so you just don't see it and you don't go oh what's all that blank spot for and go figure it out it just it escapes your immediate cursory view when you go past it so but a sim will catch that a sock team will catch that where you may not so anyway that's that was my point about all that it's hard and you need some help doing it
SPEAKER_01:yeah so i think the point there is is that if you have an IT person, they're probably busy fixing the printers or the email that's not working and the things they're getting yelled at about. And if you have a quality person that you call your IT person, they're probably even busier because they're doing two jobs. The last thing they're going to do is look at the logs.
SPEAKER_00:Not only that, but you probably assign both of those, the IT person and the quality person, you probably assign them the job of making sure you're compliant with CMMC. So they're busy with that and they're not going to be able to look through those logs. They have even less time to do that because they're trying to make sure you're compliant.
SPEAKER_01:And that's assuming you haven't given them a drinking problem because all the problems. That's true. Yeah. All right. So moving on. to configuration management. Can you demystify that one for us?
SPEAKER_00:So configuration management is just basically you have to have a baseline for your systems and that's your workstations, that's your server, that's your network switches, that's your firewalls. You have to have a baseline. What is your baseline and what is your baseline configuration for those and do they meet that and how do you manage that? Again, there's that word. You've got to manage it. How do you manage that and how do you show that they're still in compliance? So what can configuration management is about. You have to manage that change somehow. How do you manage that change? You've got to be able to prove that you do that. And a lot of times it's going to be, you know, you start with a brand new build on, we'll just say workstations are easy, okay? So I guess you can start with a firewall too. But anyway, you start with a brand new build. You don't start with a vendor's build. You start with a brand new build, whether it's an image, whether it's a scripted install, whatever it may be, brand new. You set your security You set your basic settings. You have a list of, again, a documentation. You have a list of what your settings are. And then you have maybe GPOs that apply or Intune policies that apply. And, yes, those have to be documented. They're documented in Intune or they're documented in your GPOs. But really, to make it better for your assessor and for yourself, it's probably good on a– whatever basis to export those and document those and put them in with your GRC platform, your governance risk and compliance platform, whatever you use. It's good to keep that in there.
SPEAKER_01:This is something that if you're DIYing as someone who's not an IT person, by trade is really hard because it's not anywhere close to natural. You're used to get it up and running, get in production, you're done. Even for IT people, same thing. I mean, get it going, you're done. This is really a, ultimately, documentation requirement that is needed and most people don't do. And it's skirted over because it, again, is burdensome to have to do all this, you know, what essentially is paperwork, digital version of paperwork, to put together a configuration like baseline and all that. So it's not natural. It's one you're probably going to miss. You're not very intentional about it.
SPEAKER_00:IT teams or people generally fall into categories in this. Most IT folks are going to keep some sort of standards. on all our machines. Promise all
SPEAKER_01:the standards are going to be
SPEAKER_00:up here. That's exactly where they're at. They cannot be documented in your mind. They can, but then you have to regurgitate those on paper. So most IT folks are going to have some sort of standard, and they're going to say, of course we have a standard. Well, what is it? Well, we have this, we have that. What kind of standard does it follow? So you have to document those. You have to say why you're doing that. And then the other part of that is procedure. You know, how do you go about that? And really, when you get into procedures, then that's where you can beat up your deployment and it's not necessarily burdensome because you've already documented it. This is your procedures. This is how you do it. You get that machine, do a scripted install. There's Active Directory, for instance, and it pushes all those policies out. So it doesn't have to be hard. It just has to be documented and you have to know what that baseline is and what that configuration is.
SPEAKER_01:Let's move on to the next one. Identification and authentic So
SPEAKER_00:for identification and authentication, it works closely with access control, of course. You need to be able to identify accounts, the people, the computers, wherever it is. You need to be able to identify those accounts, need to authenticate those accounts, and you need to have some password policies. Password has to meet certain qualifications. Multi-factor authentication falls in there also. There's all sorts of other things that go along with that. Basically, you've got to prove who it is logging on, you've got to authenticate them logging on, and you've got to provide multi-factor authentication. factor authentication. And multi-factor authentication, if you access CUI over the network as a normal user, or if you access anything remotely, which would be any cloud services too, or VPNs, if you do any admin activities, all those things need MFA. So really what that leads to is everybody has to have MFA for everything, right? But now if you have all your CUI on your local computer, then really technically, and you don't You don't access any cloud applications. You don't access the network, anything like that. I guess really you don't have to have multi-factor authentication except for the admin functions on there. Most people have a server or something, SharePoint or whatever. So you've got to have– and that would be GCC High SharePoint or I guess Prevail or XSR or whatever. But anyway– you've got to have multi-factor authentication.
SPEAKER_01:I think I hear the pitchforks coming. Yes. Everyone hates multi-factor authentication. And you're saying that I have a server and I'm my shop and my drawing is on the server and I access it from my computer. I have to use multi-factor authentication to get that drawing? Yes.
SPEAKER_00:Now there's arguments about that. Where do you feel the assessors fall on that argument? Well, there's argument between assessors too. But I think mostly assess are going to fall on the fact that it's over the network and you really need to have multi-factor authentication. But I have had assessors say, I'm like, hey, I've got it. It's just on the server. It's on the local network. It's not remote. It's not on a separate subnet. It's on that network. That's really not what it says. But the assessor is like, well, if you have it in all the other instances here, then I would pass you. I would be careful with that. And multi-factor authentication, it's not hard to implement. It's not expensive to implement. The other caveat or the other note I might put on this is that Windows Hello can meet that multi-factor authentication. A couple of caveats to that. You want to make sure you meet, but Windows Hello can meet that multi-factor authentication for you.
SPEAKER_01:Microsoft is helping you for once.
SPEAKER_00:I wouldn't necessarily go that far because they make it very confusing. The reason I say it's confusing is if you're looking at, you know, can you use Windows Hello? Look at Windows Hello for business. So there's different things. And then there's, you know, what else do they do that with? Surface for business. They have different things. Everything, pretty much. And then something for business. OneDrive. OneDrive for business. OneDrive personal, you know. So anyway. But Windows Hello for business is what you'd want to look for and look up the caveats. So you're
SPEAKER_01:saying when you Google it, type in Windows Hello for business, not Windows Hello. Yeah. I think this is one of those things, like, if I'm– in my office my server is physically in my office and I'm accessing it from my laptop having to have MFA MFA is one of those things where it doesn't really have to make sense or like be reasonable it's just what makes it compliant right so like whether you agree with it or not and whether there's justification for that being the case you know one of those things that doesn't matter because compliance is a compliance it's not necessarily the same as what makes sense and what's secure and again you'll depends on you know what the assessor decides and where they fall. So next is incident response. What do you have there for us?
SPEAKER_00:Oh, this is the one you would never want to have to deal with. You have to have a policy. You have to have a written plan and know what to do in the case of an incident. And what does that now the government Take that definition of an incident. So if you have an incident, this is what we do in case of an incident. It's got to be reported right now within 72 hours. That might change to something different. Right now, you've got basically three days to report. And it's three days, not three business days, just so you know. If it happens on a Friday afternoon, the weekend counts.
SPEAKER_01:It's not really three days. It's 72 hours.
SPEAKER_00:Yes, it is 72 hours. So just keep that in mind. And that bar may be changing lower. I absolutely do not agree with, and a lot of people don't, but the government is the government. So we'll see where that ends up. But so you've got to have that plan. You've got to have definition of an incident. You've got to know how to report it. who to report it to. There's a certificate you have to go out and get, medium assurance certificate, to put on your computer to be able to report those incidents. I can guarantee you that if you wait until you have an incident to get that medium assurance certificate for your computer, you will not report that incident in time and you will be behind that timeline.
SPEAKER_01:That's something you have to go get from the DOD.
SPEAKER_00:It's a certificate that you have to buy. It's a little encrypted... encrypted certificate that you put on your computer and register on your computer that when you go to the DC3 website to be able to report an incident, it'll recognize your computer and say, oh, okay, we know who you are. Now you can log in and create an incident. So what
SPEAKER_01:happens if that computer is compromised?
SPEAKER_00:Well, you have a backup. Okay. You should have– you should not have one. You should have more than one and at least two– Maybe more. But also, those are kind of hard to go find after the fact if you didn't document it. Again, documentation. But if you didn't document where you put those certificates and who has them and you forget. or they change computers, then you'll have no clue and you won't be able to report that incident. So document that somehow. Notate that computer that it's an incident reporting computer. So if it gets changed out or something, that you need to move that. Mm-hmm. probably buy a new certificate. But anyway, that you need to take care of that.
SPEAKER_01:I feel like they should have done a hotline that you call and they ask you who your childhood girlfriend was or your childhood dog or something. It would have been a lot easier just to have a phone
SPEAKER_00:number. It would be a lot easier. The funny thing is those security questions that banks like to ask you and stuff, that has proved to be one of the least secure ways to secure your account. Because
SPEAKER_01:it's public information. It's things
SPEAKER_00:you know. You post on Facebook, I missed my first dog Snoopy or whatever it may be Other thing with incident response you have to do is you have to, the plan, the policy and the plan that you develop, you have to test that. You have to come up with some scenario. that pertains to you know an incident and test that run through the steps and make sure that your incident response plan addresses that and does that it does what it needs to do and what i can tell you is you know come up with different ones every time you do this and you'll have to i have no doubt you'll have to tweak it that's okay tweak it and um you know make sure you document and save your, uh, your latest version. So again, if you have a GRC platform, that's where the latest version, the live version will reside.
SPEAKER_01:Yeah. It's also understated that if you actually do have a incident, like forget all the DOD compliance stuff. Um, say you get hacked and it's your business and money's on the line, having an instant response plan, something you like, uh, a game plan to actually execute on. It's really understated how much that helps. Get you, hedge the issues, risks, money loss, and get you taken care of.
SPEAKER_00:And to go a little further on that, your incident response plan, surprise, surprise, should not be solely about compliance. Your incident response plan and procedure will also involve contacting your insurance company, your attorney, whoever else. Is there a forensics team that you have on retainer? Probably not. But is there one that you have that you've talked to that you know you'll use in an instance like this? All that needs to be documented. And you need to have that idea, the idea of what you're going to do with Just another quick anecdote. An incident is also described as a potential incident, right? I'll just use an email incident because it's happened before. We had a client a while back, a great client we love to death. This was back a few years ago. Tried talking them into MFA on their email, and they were like, that's too tough. We don't want MFA on our email. We don't keep CUI in there. And I was like, well, you know, some people send you CUI through email, and they shouldn't, we know, but that happens. And they're like, well, but our policy is we don't have CUI on email, so we're not going to put MFA on it. Like, well, we really highly suggest you do. Anyway, long story short– They didn't want to do it. So there was some credentials out on the dark web from one of the employees, and they got logged into their account. They created a forwarding rule, and, of course, we got notified immediately, right? And so really in the end, this hacker was– I say hacker in quotes. I guess it's– Not in quotes if they actually got into their account. Anyway, but they got into their account. They created a rule that would divert all the replies to that fake invoice into a certain folder. They created rules to hide their tracks and then forward all the fake invoices, the replies and whatnot, to their own email address, which they– I can't remember on this particular one where they created a similar domain, but that's a common tactic– You know, all this fun stuff. And we got alerted. We called them and said, hey, Billy Bob, you know. Billy Bob was not really his name, just so you know. No, no. Hey, Billy Bob, you know, hey. there's some weird activity going on on your account. Did you create a forwarding rule, you know, to do this? No, I didn't do that. And Hey, I'm getting, I'm getting some calls, you know, that I haven't had somebody call me and say, I sent him an invoice and I didn't send anything out. We were like, Oh, all hands on deck, you know? So we, uh, we found what was going on. We bumped that person out, that hacker out. Like I said, he only had access for like 15 minutes. Uh, but, uh, That's an incident. And so we said, look, this needs to be reported, this, that, and the other. And before they could get to the point of where they reported it, one of the prime contractors they worked with reported it. And then they were this close to losing their contract, and we had to jump through it. We had to jump through so many hoops to prove that we had going on, that we had everything secure, all that. So we had to jump through a lot of hoops. Even though everything ended up okay, we had to jump through a lot of hoops, spend a lot of time, a lot of documentation, a lot of proof, and a reputation hit for our client. We had to go through all that with them and help them out. What I can tell you is immediately after that happened, I said, hey, how about implementing MFA? And they said, now, let's do it now. So that helped push that forward. Also helped push forward some other things we wanted to do. But that is just a quick anecdote. It may not be only your choice because if something like that happens, an incident just isn't somebody hacking into your computer and accessing that CUI. It may be somebody accessing your email, which is a cloud platform and So not a fake invoice or, you know, the other fear is, of course, accessing CUI that's somewhere on your Microsoft 365 platform, SharePoint, OneDrive, you know, something like that. So anyway, it's not always your choice whether you think it's an incident or not. Look at the definition of an incident, and if it's an incident or potential incident, then it needs to be reported. It's scary, but if you take care of business, you'll be fine.
SPEAKER_01:Yeah, they've built the framework to expect incidents. So if you handle them correctly, then you don't have to necessarily be scared of them. It's whenever you mishandle them that you have negative consequences. Maintenance is up next. What do you have on that one?
SPEAKER_00:There's a few areas, but you want to be able to show that you perform maintenance on your systems, patching updates, stuff like that. Again... What did I say? You want to be able to prove that? So you want to do it, of course, but you want to be able to prove it. And that's through– for us, that would be through tickets that are open. That would be through, you know– our policies and plans and authorizations, stuff like that. But it's also on systems that you allow people to come in and work on. You know, they come in, they sign in, you have your copier folks come in, they need to do work on the copier. They come in and do that work. You know, do you shadow them? You know, what do you do? The correct answer is yes, you escort them. And anything that they need to plug in is verified first, all that kind of fun stuff. But you need to perform maintenance, and you need to make sure that all the tools that you use to perform maintenance are vetted. And you have to prove all that. It has to be documented.
SPEAKER_01:Next is media protection.
SPEAKER_00:So for media protection, that's electronic media and physical media. So for electronic media, anywhere that CUI resides has to be encrypted. So it has to be encrypted at rest, which is on a hard disk resting somewhere, or a USB stick, anything, wherever it's at rest at, it needs to be encrypted. But it also needs to be encrypted in transit. So Wherever it goes to and from, it needs to be encrypted. And the next leg to that is if it's CUI and it's encrypted, it really needs to be FIPS 140-2 or 3 validated encryption, not compliant. I go round and round with vendors with this all the time. Our encryption is FIPS 140-2 compliant. Well, that's nice. So to be able to use it in this program, in this compliance, it has to be validated. Is it validated? What's that? So in other words, it's in the CMVP database. You can go look it up, and it's got a module that has been validated, and you have to, again, you have to document that module that you use for encryption or that the program uses for encryption. I like Windows. Windows is there. That's another story. Windows 11, Windows 10, and Windows 11. That's a whole other story. We won't go there. Windows 2009, 2019, 2016, you know, they're in the CMVP database. But it's got to be encrypted. Now, as far as physical media goes, it's got to be protected as well. I know a lot of manufacturers have travelers that they use. You know, they print some CUI out or whatever. whatever it may be, whatever the CUI may be, they print it out and they carry it to the station. They do their work and they go put it back up. So it's got to be protected. If it's out somewhere and you're using it, you're using it and it's okay. You've got to be able to see it. Right. But if you walk away, you're supposed to cover it up and to where nobody else can see it. So it's, which only makes sense, but you should cover it up. When you're not using it, when you're finished with it, it needs to go in a secured place, which usually means a locked room or a locked filing cabinet. That's usually what that means. So you've got to make sure that is secured. You've got to make sure that only the people who can access it can access it.
SPEAKER_01:So what do, like, for example, most machine shops have USB sticks. They go stick in a machine, stick in a computer, you know. How do you handle that if you have to encrypt it?
SPEAKER_00:Well, there's several different ways to work with encrypted USBs. You can... You can encrypt them with BitLocker. Easy solution. Always compatible with older machines that you may need to transfer that information to. Operational asset. What we've found that works well is there's some USBs that are... The USB itself is FIPS 140-2 or 3 encrypted. And it has a little keypad on it. So when you need to use it, you can plug it in, press your... unencryption key, and it'll make that USB available to the operating system. It's nothing beyond that to the operating system. It's nothing special. It's not BitLocker encrypted where that operating system has to be the right version to read it. It just has to be able to read that USB. And if it can do that, then once you unencrypt it, it unlocks it, and that system can see it. That's been shown to work really well. Mm-hmm. be forewarned, those are not cheap. So you're looking at, you know, 150 bucks each, you know, something like that. But
SPEAKER_01:if, I mean, as machine shop, People know it all comes down to the aggregate time, right? So if you're fighting an encrypted USB stick or something like that where it may be an expensive USB stick, if you're adding all the time it takes to run that job, personal walkover, fuss with the encrypted device, it might well be worth the money because you get operational efficiency out of it.
SPEAKER_00:You do. You get operational efficiency. You also get peace of mind knowing that that is encrypted and there's no question about it, right? Mm-hmm. It's also
SPEAKER_01:easier for a programmer to run a– sorry, not programmer, but machine operator to remember a code.
SPEAKER_00:You just got to tell them, punch in the code and it'll work. As opposed to, hey, when I plug it in, nothing works. You do follow– BitLocker encryption is pretty easy, but it does have some problems trying to work with it with different versions and different older computers and specialized computers and stuff like that. So we'll run into some issues with that. Or your very expensive machine you don't want to replace. Yes, some of those machines are very expensive. The other thing I would say, again, as part of documentation– Not only in your system security plan do you have to define your data locations, which is physical and electronic, but you need to... have an authorized list of, if you use USBs, is USB. And, you know, any filing cabinets or whatever you might have. All
SPEAKER_01:right, up next is personnel security. So does that mean you have to hire security guards to go around your building?
SPEAKER_00:Well... Might not be a bad idea, especially depending on where you're located at. But what that really means is you have to screen your employees. Then you also have to do that screening every so often. You have to schedule it every so often. So all of your employees, when they're hired, or if you already have a bunch hired, you have to go conduct the screening on them so you have that. Then every so often, every... however many years you say is what you
SPEAKER_01:have to do. So you get to create the standard, but you should probably write the standard down as to where the bar is because that
SPEAKER_00:really matters. Absolutely. And you have to document all the stuff that you do.
SPEAKER_01:Right. So that will also help you from a legal perspective as well. So make sure you do that. So I would start with your insurance company. So if you need to do drug tests, people operating machinery, forklifts, et cetera, I'll probably put that one in. and obviously find some sort of criminal or whatever standard you want that is okay or not okay. Maybe getting public intoxication in college isn't a problem, but maybe a DUI is or something. You just got to define it, right? And put it on paper. And then another one is if ITAR, So citizenship would be a good screening as well, depending on what, uh, you know, business you're in. So if you're handling exporting of arms or having the ITAR requirements, I would put that.
SPEAKER_00:Yes. The other part of that is when people are terminated or they leave or whatever, or they change positions, you need to make sure that their access is handled appropriately. You know, it's, uh, when somebody is terminated or leaves, their access needs to be cut immediately. Uh, If they change positions, you need to make sure that their access is changed appropriately at the appropriate time.
SPEAKER_01:Next is physical protection. What about that one?
SPEAKER_00:Physical protection, make sure that where you store CUI is secured, locked, secured, however you need to secure it with keys or with proximity cards, wherever it may be. That is secure. The electronic locations and the physical paper or whatever other kind of location or CUI that is. Make sure they're secured. Those physical access means, keys, key cards, proximity cards, stuff like that, you need to, again, document. You need to have an inventory of those and make sure. So that means your physical keys really need to be serialized somehow. Proximity cards usually are anyway, but you need to keep track of those. So visitor access logs. A lot of places have sort of a reception area or a man trap, something like that, You go in and you sign in and go on in. And then when you leave, you sign out. And so you need to have something like that in place. Some sort of man trap, some sort of reception where people cannot pass that. They have to sign in. You, of course, have to keep those logs. You have to review those logs. Somebody has to review those logs.
SPEAKER_01:We are on risk assessment next.
SPEAKER_00:So for risk assessment, you've got to evaluate the risk potential of all your systems. And then you have to evaluate that ongoing. You have to make sure that they're still the same. has changed. But then you also have to do vulnerability assessments, run those, address any vulnerabilities, address any issues. And what I would argue is that a vulnerability assessment is not just an IT, what we think is a vulnerability, a CVE, but it would be inactive accounts. It would be even open ports that are not necessarily showing up on a vulnerability. Do we need this port open? So you need to run those risk assessments, evaluate those vulnerabilities and address those in a timely manner.
SPEAKER_01:Also, a great low-hanging fruit type thing any business can do that most aren't is just run a vulnerability assessment monthly, quarterly, and patch the holes before a hacker finds it.
SPEAKER_00:Yeah, and that's what this requires. But really, like you say, that is just a low-hanging fruit, something easy to do. And it really needs to be done.
SPEAKER_01:Next up is security assessment, which is not the same as risk assessment.
SPEAKER_00:Right. It's not. So you've got to review all your– basically all your security settings, your SSP. You've got to review all that and make sure that it's still appropriate. What about this new server we put in? We didn't ever do anything with it. What about– do these– Does this access control security settings or whatever, do they still apply the same way that they did? You have to go through and review all your controls and make sure that they and your policies and your plans and procedures make sure that everything you put in place still is appropriate.
SPEAKER_01:What about system and communications protection?
SPEAKER_00:So you have to protect your systems not only at the border, which would be your firewall, right? So you do have to do that. You have to protect things at the border. You have to make sure that CUI is encrypted anywhere it goes. Transit is a big thing we talked about a while ago. It's big here. If your CUI... For instance, if you... print your CUI this is a common one if you print CUI it's not encrypted so if it goes over a wireless network you know is it encrypted you know or are you transmitting that CUI to a website that uses the appropriate encryption those are the kind of things you have to think about with systems and communication protection there are other things also making sure that your normal stuff a firewall will do like making sure that the sessions are not spoofed and stuff like that I mean those are there's all sorts of things there but it's all your normal network level level. Cautions you take need to be taken and documented. Of course, everything needs to be documented. How you use it. For this, you would want to have a data flow diagram. Well, for a lot of these, you want to have a data flow diagram, but it would help this as well.
SPEAKER_01:The next is system and information integrity.
SPEAKER_00:So for a system and information integrity, you really want to keep all your protections up to date, your antivirus or your endpoint, whatever your endpoint protection is, whether it's MDR, ADR, whatever it may be, you know, make sure it's up to date. Make sure your systems are patched. Make sure, you know, and it's not just Windows. I mean, it's pretty common for your IT shops to, you know, patch your Windows machines, you know. But what about the Mac machines? What about, do you have any Linux in place? What about your firewall? What about your wireless access points? What about your switches? You know, what about whatever other network devices there may be? Are they patched? You know, you really want to make sure that all that is taken care of. You want Can you
SPEAKER_01:tell me that that switch that we threw up in the false ceiling and then ran a cord down to the CNC machine to get it working matters?
SPEAKER_00:Yeah, absolutely it does. Absolutely. Everything, that's a point of access for someone. If a hacker happens to get in on your network, the first thing they do is some reconnaissance to figure out what's going on and they find some Belkin switch that was put up five years ago and nobody's touched it since and, oh, hey, look here, I can get into this licking split and they get into that now they've moved laterally and uh and they're off of where they initially came in at and now they're a lot harder to track you got to keep everything updated keep everything patched uh scan for anomalies and you just you got to be proactive about this and you got to prove that you're on doing it ongoing again there's documentation and the management
SPEAKER_01:i would say that you know when you implement all of these things together ultimately what nist is outside of maybe maybe disagreeable compliance things that we've talked about um uh what it does is, of course, checks the compliance box, but really just makes your business resilient against threats. It does, absolutely. You have to do all this compliance stuff, but the nice thing thing you get out of it is that you're nice and protected and feel good and sleep good at night so absolutely kind of to bring it home uh what would you say out of all these controls um and requirements uh is the most uh misunderstood or missed thing uh that uh people might get wrong um but they can take home and do something about
SPEAKER_00:it's not necessarily one control uh or two or three controls but it's uh it's and again i sound like a broken record but it's it's a documentation portion of this. For instance, if it says identify somewhere, then that means you have to list out. You have to identify the users. If it says authorize, you have to have proof that somebody authorized this. It's easy for an IT person to glaze over that and go, we've got an Active Directory full of users. There's my list of authorized users. That goes a long way, but not quite all the way there because I guarantee you there's probably some people, well, depending on what kind of business it is. There may be some people there that are not in Active Directory that don't log on to the computers, and they should be listed on that list with no access. IT guys, and I'm one of them, and I'm guilty of that too, you look at identify and you look at authorize, what does that really mean? It's going to be documentation. When you get down to it, documentation is really the biggest piece of this. The Technical controls, we can implement those, but all the documentation to back it up. You have to have your SSP. You have to define how each control is implemented. Really, if you go further and define how each of the objectives in those controls are achieved, that would be even better, and that defines things very well for an assessor. If they see that, you're well on the way. You're doing well.
SPEAKER_01:When it comes to documentation, have you ever seen Seinfeld? the soup episode. I can't call him though. Weird. Cause I think the one, I think that'll get us banned automatically tagged on YouTube. But, um, if you want to do everything right, he goes, no soup for you. Documentation, uh, is that for CMMC compliance? So you can do everything right. But, uh, if you haven't documented it, no soup for you.
SPEAKER_00:That's right. No soup for you. I guess the soup in this would be, uh, the, uh, CMMC certification. Exactly. Uh, yeah. And so that documentation is not just your, SSP, it goes down to if you do a policy for each one of your families, control families, access control and whatnot, or domains. Anyway, so have a policy for each one of those, but then you need to break out and have your plans and procedures like your disaster recovery, like your incident response, stuff like that. Then you also need to have your authorized lists and things like that. So inventory list, but Documentation is huge. Documentation is gigantic. Then to go even further than that, you have to have proof of all these things, not just your documentation, but when it comes time for an assessment, you have to have proof. Show me where the policy is implemented in Active Directory or in Intune or wherever it may be. Show us where that is. Show us a screenshot, all that kind of fun stuff. So you have to have proof of that.
SPEAKER_01:If you have questions about what we've covered, please reach out to us. We're here to help fast-track your compliance journey. Text, email or call in your questions. We'll answer them here for free on the podcast. You can find our contact information at cmmccomplianceguide.com. Stay tuned for our next episode. Until then, stay compliant and stay secure. Make sure you like, subscribe and share.