CMTC's Shifting Gears


We succeed because you do.

Season 6 Episode 3 - What Is NIST SP 800-171 All About?

Posted by Rachel Miller

Episode Show Notes

Episode 3 features two CMTC Cyber Physical Security Services consultants: Ernie Edmonds and Buzz Thomas. Ernie and Buzz define NIST SP 800-171 and explain what it entails – its requirements, which companies need to follow its guidelines, and how an SMM can implement it.

Ernie Edmonds is Sr. Managing Consultant of Cyber Physical Security Services at CMTC. Ernie has over 25 years of practice and leadership experience in the information assurance field. He holds numerous certifications including Microsoft Certified Systems Administrator/Engineer, Certified Ethical Hacker, Certified Information Systems Security Professional, Forescout certifications and many others. He has led some of the largest infrastructure and cloud datacenter deployments in the world as technical & product leads and has also worked with small and medium-sized companies.

Buzz Thomas is Managing Consultant of Cyber Physical Security Services at CMTC. Bernie has over 25 years of executive operational experience in areas requiring extreme cyber security discipline including emerging technologies, defense manufacturing, aviation, critical infrastructure, and telecommunications. Bernie’s expertise includes multitudes of certifications in Cyber Security, Cyber Ranges, Threat Hunting, Threat Intel, Business Continuity Planning, Disaster Recovery, Software Development, Infrastructure Design/Deployment and Cloud security.

Highlights

00:01:18 - Definition of NIST SP 800-171

00:02:50 - Manageability of 110 requirements for small companies

00:07:09 - Requirements of NIST SP 800-171

00:07:54 - What falls within the scope of controlled unclassified information (CUI)

00:14:19 - How SMMs can be in compliance with DFARS

00:17:26 - Ramifications of being out of compliance

00:20:45 - Definition of cybersecurity framework (CSF) and how it relates to NIST SP 800-171

00:28:18 - Distinction between compliance and security

00:33:50 - Discussion of cybersecurity framework (CSF) and risk management framework (RMF)

00:38:29 - Which companies need to follow the NIST SP 800-171 guidelines

00:39:50 - How an SMM can implement NIST SP 800-171

Transcript

Gregg Profozich [00:00:02] In the world of manufacturing, change is the only constant. How are small and medium-sized manufacturers, SMMs, to keep up with new technologies, regulations, and other important shifts let alone leverage them to become leaders in their industries? Shifting Gears, a podcast from CMTC, highlights leaders from the modern world of manufacturing, from SMMs to consultants to industry experts. Each quarter we go deep into topics pertinent to both operating a manufacturing firm and the industry as a whole. Join us to hear about manufacturing sectors’ latest trends, groundbreaking technologies, and expert insights to help SMMs in California set themselves apart in this exciting modern world of innovation and change. I’m Gregg Profozich, Director of Advanced Manufacturing Technologies at CMTC. I’d like to welcome you.

In this episode, I'm joined by two CMTC Cyber Physical Security Services consultants: Ernie Edmonds and Buzz Thomas. Ernie and Buzz define NIST SP 800-171 and explain what it entails – its requirements, which companies need to follow its guidelines, and how an SMM can implement it.

Welcome, Buzz. I appreciate you being here with us today.

Buzz Thomas [00:01:12] Hi, Gregg. Thanks for having me.

Gregg Profozich [00:01:14] Ernie, welcome to you, as well. It’s great to have you here.

Ernie Edmonds [00:01:16] Thanks, Gregg. Appreciate it.

Gregg Profozich [00:01:18] It’s great to speak with both of you again. Looking forward to our conversation. We’re here to talk about cybersecurity but in particular the NIST SP 800-171 cybersecurity standards and how they impact small and midsize manufacturers. By the end of the conversation, our goal is to have a good understanding of what NIST SP 800-171 is as well as some practical actions that small and midsize manufacturers can take to help protect their businesses. Let’s jump right in. For context, what is NIST SP 800-171? Ernie, why don’t you kick us off?

Ernie Edmonds [00:01:50] The 800-171 is a list of standards provided by NIST. It’s on its second revision at this point, so it’s SP 800-171 revision 2. There are 110 requirements within the 171. They cover anything from access control to physical and logical security, personnel security. Those are broken down into families. Depending on what the topics are, there could be from, say, 2 to 22 requirements in each of the families. They do a good job at getting a start into security. Understand that this is a compliance, usually, effort and not a security effort. There is an intersection at some point, but normally when people start with the 171, it’s exactly that—it’s a start. They can determine what their security posture is from these baseline requirements and determine where they need to go from there.

Gregg Profozich [00:02:50] A hundred and ten requirements seems like a lot broken into families. How manageable or unmanageable is it for a small company?

Ernie Edmonds [00:02:57] For a small to medium enterprise, the 171 represents a basic understanding and basic assessment of what their security posture is. It can be manageable if there is a certain amount of in-house expertise that understands what they’re dealing with. Some small to mediums that I go to don’t even understand the words. We start with what the words mean, and then we go to the concepts, and ultimately, we get to where we’re going. But others I go to have engineers on staff; they’re a fairly technically adept group, and they understand completely. Often they have a lot of the stuff already done by the time we start an engagement. It just depends on the competency and the people that are there. But these are not hard things; these are basic security hygiene things. It’s not something where they’re going to have to stand up, something very complex. Now, there can be complexities to it, but it’s not that way often. There’s only probably three things that are pretty heavy lifts within the 171.

Gregg Profozich [00:04:10] Basic security hygiene things. Example or two?

Ernie Edmonds [00:04:14] Password management. We all know through experience eight characters minimum, alphanumeric complexity, things like that. That’s one of the things it covers, but there’s other things like training, and there’s incident response and reporting. There’s a good basic security posture that comes out of this.

Gregg Profozich [00:04:33] It sounds like it’s more of a checklist of 110 things I could look at to see where I’m at as a starting point. Is it like a compliance checklist almost?

Ernie Edmonds [00:04:41] Yeah, it’s a laundry list. You start at 1, and you end at 110. For each one, there is either successful implementation or not. There’s alternative implementations for some that sometimes you choose to do something other than what most people would, but in the end, it still provides the security posture that’s needed.

Gregg Profozich [00:05:01] Got it. Buzz, anything to add to this?

Buzz Thomas [00:05:03] That was a good description, I think. There’s 14 control families in that, and they were aimed at nonfederal computer systems. 171 is for nonfederal computer systems like contractors. If it’s federal systems, there’s a different standard, which is 853. It started out being a way to allow contractors to store, process, transmit controlled, unclassified information that they were working on behalf of the federal government. Then it’s evolved to where even private companies are starting to use that for their security reference, even when they’re not using controlled unclassified information.

Gregg Profozich [00:05:46] I’m thinking I’m hypothetically a small machine shop owner. I know machine shops; I know machining; I know engineering; I know metals, et cetera. I’m not necessarily an expert in IT and cybersecurity. If I looked at the standard, I could look and check off, of the 110, I have maybe 40 things in place already. We use strong passwords, et cetera, et cetera. We have certain things in place. Then it would give me a list of things that maybe are risk points that I might want to look at more deeply. I’m a federal contractor, though, so I probably should be paying attention to this. Is that the way it’s coming from, or is it evolving differently than that?

Buzz Thomas [00:06:18] I think the mindset behind it is that nobody historically really knew all the things to do to have a good security defensive posture. The government, NIST, came up with this as a minimum baseline to say if you have nothing else, this is what you have to have at a minimum in order to use, store, process, or transmit the CUI, controlled unclassified information. We need to keep in mind that while it is a good standard, it does represent a minimum baseline. It’s not meant to be the best of breed and the most defensive posture you can take.

Gregg Profozich [00:06:56] But it’s a good way for me to figure out if I own that machine shop hypothetically we’re talking about what my current state is. I audit against it and figure out my current state. If I get up to at least it, now I’m hitting the minimum standards, and I can think about incrementally improving over that.

Buzz Thomas [00:07:08] That’s right.

Gregg Profozich [00:07:09] What are the requirements of NIST SP 800-171?

Buzz Thomas [00:07:12] There are 14 families of controls, meaning different categories of control like access control. There’s physical controls. What they’re designed to do is to teach you how to protect your information and your systems. If your systems are using or storing and processing CUI data, government type data, you have to have a password. Passwords have to have minimum complexity levels met. It will have controls on passwords, on encryption, on storage, on transporting data between sites. Just about anything that your machine shop would run into in terms of how to handle the CUI data is outlined in the 171.

Gregg Profozich [00:07:54] We keep talking about CUI data. What falls within the scope of controlled unclassified information?

Buzz Thomas [00:08:00] This is the million-dollar question. Even when we go through training with clients on what CUI is, it seems like the next day, it’s all been deleted because it’s unfamiliar to think about data this way. Let’s start with the government definition. The government says… Let’s be very specific and talk about DOD, Defense Department. Defense Department says first of all, if it’s our data, meaning we made it own it, or you made it on our behalf, and we determine that there should be controls on how it’s disseminated, then that’s CUI; that’s controlled unclassified information. Then if you are in a contract relationship in their prime, define something as CUI whether you know it to be true or not, that also has to be treated like CUI.

Gregg Profozich [00:08:56] When you say treat it like CUI, what does that mean?

Buzz Thomas [00:09:00] That means that any system that processes, stores, or transmits has to meet the security control requirements in the 800-171. That’s the relationship. Is it CUI or not? If it is, then it has to be on systems that meet the 171. If it doesn’t meet the 171, then it can’t store, transmit, or process CUI.

Gregg Profozich [00:09:22] In looking into cybersecurity for manufacturing, one comes across a couple of terms repeatedly, among them DFARS, Defense Federal Acquisition Regulation Supplement, and CMMC, Cybersecurity Maturity Model Certification. What are they, and how do they relate to NIST SP 800-171?

Ernie Edmonds [00:09:40] The DFARS that we’re really talking about with the CUI is the 252.204-7012. In that, it says what is required in order to, as Buzz mentioned earlier, store, process, or transmit CUI. It specifically states that the 171 is the compelling mandate for right now. Going forward that will probably change—this is speculative—but we suspect that it’ll change to reference the CMMC at level 2.0. When we’re talking about CMMC, Cybersecurity Maturity Model Certification, we’re talking about version 2 at this point, which came out last December. In order to possess, store, or transmit CUI, you have to be at a level 2. They’re in different orders from the 171. The 171 has the 14 families. They’re broken down into 1 through X. It’s pretty straightforward. Since there’s multiple levels with the CMMC, in this case, level 1 and then level 2, both of those are cumulative. If one possesses CUI, needs to protect CUI, then you’ll not only have level 2, but you combine that with level 1 to get level 2. You still end up with the same 110 requirements. It’s just they’re in a different order. The security posture will be the same outcome. There is provision for what’s called a plan of actions and milestones. If you don’t have it completely finished at the beginning—you find something that’s not been successfully implemented—then that’s the path that you mark it down as not implemented, and you come up with a strategy to how to successfully implement that particular line item. Again, it’s just like a laundry list. The level 2 is exactly the same controls as the 171. That will be the new standard going forward. There can be additional requirements like a third-party assessment for those who are on what’s considered a preferred contract.

Gregg Profozich [00:11:43] There’s a lot in there. I want to unpack that just a little bit. What I think I heard you say is that for CMMC, the Cybersecurity Maturity Model Certification, basically what they’ve done is disassembled and repackaged, in a way, the 800-171 110 requirements and 14 families, and they’ve broken it into level 1 and 2. Depending on what kind of information I’m doing and what kind of a contract I have, I may need to have level 1 or level 2 compliance. If I have level 1 and level 2 compliance, it’s the same thing as following all 110 controls across the 14 families. Is that correct?

Ernie Edmonds [00:12:18] That’s exactly right. Some contracts will only need level 1. If it’s something that does not have CUI but it’s still a federal contract, then it’s possible to be a level 1 only. With that, you have fewer controls. Of course, it’s much easier to implement because of the fewer controls, but you don’t have the security posture necessary to, again, possess, store, transmit CUI.

Gregg Profozich [00:12:41] That makes sense. Then DFARS, Defense Federal Acquisition Regulation Supplement. Currently, 800-171 is mandated. I missed the alphabet soup and numbers that you threw out there, Ernie. They rolled off your tongue. They scared me how easily you said those things.

Ernie Edmonds [00:12:58] The DFARS 252.204-7012 is what we’re talking about.

Gregg Profozich [00:13:03] Say that three times fast. Currently, to comply with that part of the DFARS regulations, NIST SP800-171 is currently mandated as the standard to use.

Ernie Edmonds[00:13:14] That’s correct.

Gregg Profozich [00:13:15] If I’m doing defense federal acquisitions, if I’m producing anything within the defense supply chain, chances are 800-171 applies to me, and it’s something I need to know about and figure out how I can be in adherence to. Buzz, anything to add to any of that conversation?

Buzz Thomas [00:13:29] I would maybe say that the regulation that says you have to comply is DFARS. DFARS says what standards or guidance you have to follow, and they’re pointing to the 171. Many people ask, “Do I have to comply with the 171?” We often correct them and say, “No, you have to comply with DFARS.” It’s just in federal situations. It’s the FISMA laws, the Federal Information Security Management Act, that point to NIST 853. You have to comply with that. If it didn’t have the law, then it would just be another guideline or standard. 800-171 by itself is a set of cybersecurity control requirements that are considered minimum best practice for CUI data.

Gregg Profozich [00:14:19] That makes sense. Thank you for that clarification and addition. The NIST SP800-171 is referenced as a security control baseline followed by DFARS, safeguarding covered defense information and cyber incident reporting. How can SMMs be in compliance with DFARS?

Buzz Thomas [00:14:34] To be in compliance with DFARS right now, you can do that by self-reporting if you’re trying to do DOD contracts. In order to have that privilege, you have to show that you’re compliant. You do that by self-reporting to the DIBnet portal. Right now, that’s easy. You just go to this control set, the 171 110 controls, and you check off yeah, I’ve implemented that, or no, I haven’t. At the end, you have a score that says I’ve got 87 points out of the 110. You report that to the DIBnet portal. Once you report it, it’s officially recorded; then you’re in compliance the way things are right now. Once CMMC comes into play, 2.0, that may change, and you may lose the ability to not meet all the controls. I know that the CMMC 2.0 official language is saying that there will still be a POA&M (Plan of Action and Milestone) process, which is the process that says you don’t have to meet everything right away; you can take some time to fix it. But they’re saying that their POA&M process is going to be an exception-based thing, and it has to be approved. Most people, as I understand it, when CMMC rolls around, will have to comply with all 110 controls.

Gregg Profozich [00:15:57] It sounds like there’s progression here in terms of how the federal government is ramping up the cybersecurity posture of the entire defense supply chain. It can’t happen overnight, but it’s something that’s being incremented in. Is that the case? I hear you’re saying that once CMMC 2.0 is in place, the self-reporting may change and become something a little bit more stringent.

Buzz Thomas [00:16:18] That’s exactly correct. It is in flux. Even the levels of CMMC are going to be changing. They’ve defined level 1 and level 2. They’ve announced there’s going to be a level 3, but that hasn’t been fully fleshed out yet.

Gregg Profozich [00:16:31] Ernie, anything to add to those points?

Ernie Edmonds [00:16:34] Just to clarify, the 171 is the CMMC. The CMMC is the 171 at level 2, CMMC 2.0 level 2. The 171 has been mandated for years now. When CMMC 2.0 rolls around, there is an expectation that companies will already have all this stuff done. Whether that’s true or not yet I guess we’ll see. But there is an expectation right now that everyone is in adherence with the 171, compliance with the DFARS 7012. It should in theory not be a Herculean effort to meet the CMMC 2.0 because defense contractors, short of somebody’s getting new business, a new contract award, and they’ve never seen it before, they should already be in a good position to be successful with this.

Gregg Profozich [00:17:26] If I’m a small or midsize manufacturer, I’m that hypothetical machine shop owner I mentioned a few minutes ago, my key takeaways are that 800-171 is the base standard and that the cybersecurity posture that the federal government is taking for all contractors within the defense supply chain and by extension across the entire federal government, I think, is continuously being increased; it’s leveling up. This is something I need to pay attention to and make sure I get ahead of because there may come a point at which if you don’t comply to all of this and be able to verify compliance, you don’t get contracts. Is that where they’re going with some of these things?

Ernie Edmonds [00:18:01] That’s loosely a true statement. There is a process that we call the DODAM, the Department of Defense Assessment Methodology. With that, you get a score. The perfect score is 110. With that, if you do not have a score in there… We’re told right now, in early 2022, mid-2022, that it doesn’t matter what your score is; you just have to have a score in what’s called the SPRS, the supplier risk reporting. If you have a score in there, then you’re eligible for new business option or extension, whatever that would look like. If you don’t have a score, then you’re not eligible for award of any kind. That’s in place right now. The supplier has to have a score in there, even if it’s negative 210. That’s a real score. It goes to 110 positive. You can have a negative score. This is exactly the 171. The controls are exactly the same, but they’re indexed and weighted based on the relative risk in a general context. Some of these requirements will be five points, and others will be one point. Then there’s two, and there’s three also involved. There’s two of them that offer multiple flavors of points based on how you implement it, so FIPS (Federal Information Processing Standards) validated cryptography versus non-FIPS validated cryptography versus no crypto. Then, of course, no crypto is zero, and then if you have FIPS validated crypto, that’s five. If you have crypto, but it’s not FIPS validated, then you get two. It’s fairly complicated at first. It doesn’t take that long to learn it. Based on that, you can end up with 80% correct and still end up with a negative score if you get a bunch of the five-pointers wrong. Back to the original question, you do have to have a score in SPRS that is based on the 171 in order to be awarded a contract, or an option, or whatever. Going forward, they will be looking at scores. If you have a 110, which is perfect, and someone else has an 80, well, that represents less risk to the Department of Defense. It’s likely that would be weighted into the contract award process.

Gregg Profozich [00:20:25] It’s not necessarily the lowest cost bidder anymore because it’s not just the cost of producing; it’s the cost of the stolen IP that can happen if you don’t have the security protocols in place. Those are options they have to consider when they’re making these. We don’t know that they’re making these judgments or not, but these are things they can look at.

Ernie Edmonds [00:20:39] Exactly. It’s speculative as far as the way we’re looking at it, but I would suspect that’s right.

Gregg Profozich [00:20:45] In reading up on NIST SP 800-171 I came across the NIST cybersecurity framework—that identify, protect, detect, respond, and recover. What is it, and how does it relate to 800-171?

Ernie Edmonds [00:20:58] The CSF, cybersecurity framework—there are lots of frameworks within this. This one tries to assess risk. That’s what it’s about is assessing the risk to an organization. The families are pigeonholed into a particular part of that process, whether it be protect, detect, respond, whatever. Certain families lend themselves to that methodology.

Gregg Profozich [00:21:23] Families in 800-171, those 14 you mentioned?

Ernie Edmonds [00:21:27] Yeah. They get plugged in. For instance, protectors, access control, awareness, training, and things like that all get plugged in along the way. I think that there’s still opportunity within the CSF, the cybersecurity framework, in that it does not go into the depth necessary to get a good understanding of risk per use case. I know that’s a mouthful. When we talk about use case-based risk management, the best way that I found to do this is to bring up another NIST document. It’s actually the cloud series, the 500 series, NIST SP 500-299 Annex A. The Annex A and the 500-299 shows a lot of different use cases. There’s about 450. We talk about the 171. There’s 110 requirements there. Well, there are 450 use cases that are independent and are not necessarily analogous to the 110 requirements in the 171. There’s a complexity there, and there’s a complexity with the CSF because if you take risk as a whole, then you’re going to have a lot falling through the cracks. This is just experience. I’ve been in the industry for about 30 years. If you take each of those 450 things, then the first thing to do is define what it means. It’s not just talking about the technical network. There’s things like contracting and FCI, federal contract information which also comes into play. There’s a lot of other things, too. The key is to go through the process there as far as a use case-based risk management concept. You take what is in the 299, and you define it. You define it in general context, and you can also further define it into what you think it means as it relates to your organization. The next step is to figure out the different exploit vectors for that. Exploit vectors can be operational in nature, they could be physical, whatever that would look like, but they can also be technical avenues, logical based attacks, and things like that. Out of this 450, it can grow to easily 1,000 because of these different definitions and attack vectors. These, again, are just line item use cases, line item things like a laundry list. Then once you determine the definition and then the exploit vectors (plural) that someone might attack you with—someone or something, if it’s a bot, whatever—then you determine how to mitigate the exposure because the exploit is going to be there. You have to mitigate the exposure for what that means to you as an organization. Based on that, you can have multiple remediation. Ideally, it’s full remediation, but it could be partially mitigated at some level. There you have to determine what makes sense for you as an organization. You do this for the 450 to 1,500, whatever you end up with this number, and it takes a while. That’s the opportunity that I see within the CSF and other frameworks—it doesn’t go into this use case-based approach for the true risk mitigation. If it doesn’t, then there’s probably more that falls through the cracks than you actually capture. I think that until that becomes the norm as far as operation, there’s always going to be something that somebody can find to exploit.

Gregg Profozich [00:25:04] There’s a lot in there. I want to take it back through to make sure I understand this more thoroughly. We started off with the DOD assessment methodology, and the score, and SPRS, and that piece, and then we moved into the IPDRR—identify, protect, detect, respond, and recover—the NIST cybersecurity framework, the CSF. You’re saying that it’s a way of assessing risk and that it ties into the 800-171 because all the product families are broken down and plugged into one of those five letters, I, P, D, R, or R—identify, protect, et cetera, et cetera. It’s a way of identifying risk, but there are some other ways of doing that. The NIST SP502-299 Annex A, I think you said, has a bunch of use cases. Now, if I’m a small or midsize manufacturer, I’m probably feeling a little overwhelmed. I got 110 controls, and 14 product families and a bunch of alphabet soup from the government to try to keep straight and keep forward, and then I got 450 use cases to use. I’m guessing it’s actually a good thing. Somebody’s thought through 450 things that I can bounce my organization against over time and look at which ones apply to me and get ahead of the game. Is that really the case?

Ernie Edmonds [00:26:16] Let me try to back up a little bit because you’re right; this gets so complicated so quickly. The thing with the DFARS and the 171 is that is a compliance and adherence effort. You have to comply with the DFARS in order to get contracting. In order to do that, you adhere to the 171 currently. That is a compliance effort; it is not a security effort. Again, the security is much, much harder to achieve, if ever, than compliance. Compliance is very easy compared to security. Some of my clients with CMTC I’ve had… Literally, I walked into one of my clients. They said, “Count everything wrong. We just want to get this right.” They literally got it done in three weeks. They went from everything wrong to everything right with the 171 in three weeks. Now, that’s atypical. Most of my clients take considerably longer than that, but it is possible. When you change the mindset from one of compliance to one of security, you end up with all these different use cases because you have to look at everything that goes into your organization from a security perspective. That can be something as simple as propping the door open to let somebody carry in a heavy box. Well, somebody could tailgate, come right in. Now they could actually see things; they could manipulate things; they can manipulate people. Now you’re looking at everything in the organization. Just about everything in the organization will have a risk component to it. Now we’re looking at the sky’s the limit. The 450 that’s in the 299, the 500-299 Annex A, that’s still a start. It’s probably not everything. It’s just the best place I know to get your baseline of security use cases so that you can start. Then if there’s something you figure out additionally along the way, then great. Now you can at least know what it is so that you can address it.

Gregg Profozich [00:28:18] You’re making a distinction between compliance and security. I think I understand what you’re saying. Compliance is, “do I meet the standards, and do I have the right processes in place.”

Ernie Edmonds [00:28:29] Correct.

Gregg Profozich [00:28:30] It’s a minimum level. But security is a different story. If I prop the door open because I’m going to carry in four loads of heavy boxes from my car. There’s one of the early stories of one of the hacks that happened to, I think, one of the big retailers. The air conditioning contractor stole a badge, or somebody stole a badge from the air conditioning contractor, went into the server room, and literally plugged into the Ethernet port a transmitter, and then just transmitted all the information on over cell phone signal and had everybody’s usernames, passwords, PIN numbers on their debit cards.

Ernie Edmonds [00:29:01] That’s not uncommon at all.

Gregg Profozich [00:29:03] Physical security is as important as having the doors locked when they’re supposed to be locked, and don’t prop them open is as important as having a firewall, and malware protection, and a segmented network, et cetera, et cetera. I’m hearing you say that. Is that what we’re saying?

Ernie Edmonds [00:29:15] That is correct. To add to that, there are all these additional use cases, as well. Say you have someone come in for an interview. Well, back in the day, I used to do PIN testing, and I would carry in a wireless access point. I would find a POE, Power Over Ethernet, that would power my little device. It was Wi-Fi; it wasn’t cellular. This was before those came to be. I would go in for the interview. I’d say, “I need to go hit the head,” or whatever. They would leave me. They wouldn’t escort me. When I’m coming out, I’ve already scoped the place. I see the network jack, and I just plug it in. Now I’ve got Wi-Fi that extends to the parking lot. I can simply go to the parking lot and hack them from out there. I don’t have to be in there. Usually, I would blow the interview to where it looked like I just wasn’t a good candidate. But the interview was not the intent to begin with; it was to hack the organization.

Gregg Profozich [00:30:08] The 450 use cases allows me to not have to think of everything myself and come up with every possible combination. It gives me a start on 450 possible ways somebody could try to hack me.

Ernie Edmonds [00:30:19] Correct. Then if you see that there’s something missing, then it spurred the thought process to determine what that is. Then you can figure out the exploit vectors potentially that exist, and then figure out if you have any exposure at all, and then how to mitigate or ultimately, ideally, remediate each of those.

Gregg Profozich [00:30:35] Buzz, I’m sure you have some things to add to this. There’s a lot of things said here.

Buzz Thomas [00:30:40] When you first said this question, I flashbacked to a Pink Floyd album, where there’s a bunch of music going on, and then all of sudden, it gets very quiet. Everything stops, and you just hear this big heavy sigh. I was like, “Oh, this is a heavy question.” There is so much in this one. First, I’ll say that CSF, our SMM audience, may never run across this. Just saying that. CSF is in version 1, and they’re in the process of making version 2 right now. It’s out for comments. One of the most public comments that came back on this was from the Defense Department that said if you want to figure out how to make CSF better, why not make it align with RMF, because the risk management framework, RMF, we’re already required to do, and your CSF doesn’t recognize the risk measurement from RMF when it’s doing its thing. There is already recognition that the two standards are not quite the same, but they are being used successfully in different ways right now. I see the CSF being used all the time as scorecards. They look at the CSF, and they say this is how you should manage your risk. Then they look at the RMF and say this is how you should measure your risk. If you’re measuring risk, RMF, you’ve got the steps. Categorize your data, select your security controls, implement the controls. Which controls? The ones from the 171. Then assess your controls. Which ones? The ones from the 171. Then authorize a monitor. It’s the same control, 171, at least in this audience. Then the CSF, this is more like how are you managing your risk? What are the operational aspects when I’m seeing this kind of separation? You’ve got the build and measure, and then you’ve got the manage. CSF, it’s been fitting largely in the manage framework space where they’re talking about identify what your risks are—protect your systems, put your controls in place, which is a rough alignment with implementing your controls, protect your systems, but it’s also processes. Then detect, respond, recover; these are very operational. I see the government putting out report cards to the government agencies in the CSF formats. What’s your score for CSF? What’s your score for identify? What’s your score for protect? In terms of the relationship between the 171, 171 is the security requirements that fulfill the RMF requirement to select controls, but it’s also some of the ones you would use in the CSF to protect and detect. I think the real big difference here is CSF management focus or math risk measurement focus. There’s a lot of overlap.

Gregg Profozich [00:33:50] Why would there be two? Any ideas?

Buzz Thomas [00:33:52] I know that many people in the community asked the same question to NIST. We had the RMF. Why did you make the CSF? It’s an ongoing conversation, and it’s probably what’s driving CSF 2.0 to come out with something different.

Gregg Profozich [00:34:08] They’re the same but not. The cybersecurity framework, the CSF, and the risk management framework, the RMF, they’re parallel. I have identify in CSF and in RMF I have categorize. Identify, protect, detect, respond, recover—the same thing with categorize, select, implement, assess, authorize a monitor. They’re the same, so it’s understandable how there can be some confusion there.

Buzz Thomas [00:34:29] I can understand why it would be seen that way. But if you dive into it deeply when you’re looking at the RMF and you’re selecting controls—in other words, you’re saying what security characteristics am I going to implement in this application, and then you implement them in that application in that system—that’s one system. For CSF, when you’re saying I want to identify my risk and protect, detect, respond, that’s an enterprise function. That’s your security operation center that’s saying how am I going to protect all of these applications behind me. Each of those applications have gone to RMF to select their own individual controls. But then there’s the programmatic level protection CSF, where you’re trying to protect all of those individual systems which also have their own protection mechanisms. If you’re in CSF and you say monitor, you’re thinking security operations. If you’re in RMF and you say monitor, you’re thinking continuous monitoring for compliance. Are all the controls still implemented? Are they still turned on? Do they still meet the requirements? It’s not checking Internet traffic, for example, for attacks.

Gregg Profozich [00:35:49] It sounds like there’s a more ongoing process and risk management perspective. I have controls in place on January 1. I add some new equipment, I get into a new line of business in March. Have I extended those controls over that new equipment, that new line of business, those new assets and new potential threat vectors? That monitor step thereof are we still managing risk effectively and proactively looking for additional risk points is different than monitor waiting to be attacked in the CSF.

Buzz Thomas [00: 36:16] Each time you add a new system, in government-speak, you’re creating new system boundaries, and then you’re identifying controls within that boundary. I think we’re getting to the heart of the matter here that the RMF is very system based around data in a system, and the CSF is enterprise space.

Gregg Profozich [00:36:32] Ernie, anything to add about the CSF and RMF?

Ernie Edmonds [00:36:35] Yeah. Context matters, like Buzz just mentioned. These are security-centric things; they’re not necessarily compliance-centric things. If I’m a small business, the first thing that I want to do is find out what I have to do in order to do what I need to do to make whatever the widget is or service, whatever. I look for compelling mandates there. If I’m looking at the 171 through the DFARS or in the future CMMC, then that’s compelling, and I have to do it. Now we start looking… Once we get past that, we start looking, is that really the security posture that I’m going to stick with long-term? Usually, the answer is, “no.” Now I can use RMF, CSF, whatever framework. There’s all kinds of frameworks out there by people other than NIST, too. I look at these, and I figure out what makes sense for me and my organization. That’s how I proceed. I do compelling first, and then I start looking at security, and what makes sense for me, and to what my budget will allow. If I need to take this stuff as a multiphase thing—I don’t have the money to do something right now, but next year I can come up with the line item. It was unexpected for this year, whatever that would look like—then I can use these multiple frameworks to figure out a security program for my own organization and see how that works.

Gregg Profozich [00:38:07] That makes sense. Compliance data and 171 is a good baseline, and then from there, I can use the frameworks to continuously improve my security posture.

Ernie Edmonds [00:38:15] Correct. They’re not mutually exclusive. You can have system security that extends into OPSEC that extends into organizational holistic security. Those shades of gray can go both directions, up and down.

Gregg Profozich [00:38:29] We talked about this before a little bit. We mentioned it, but let’s talk about it explicitly. Who needs to follow the NIST SP800-171 guidelines?

Buzz Thomas [00:38:37] In our current context, we’re talking about largely defense contractors. Those contractors fall under the DFARS acquisition requirements, which is similar to the federal acquisition requirements that you see in civilian space, the FARS. This is the DFARS, the defense version. DFARS does require compliance with the 252.204-7012 that Ernie mentioned. The 7012 points directly at the 800-171 and said, by the way, to be compliant without that rule, it’s the 171 that you have to adhere to. Anyone that’s trying to get defense contracts needs to adhere to that. There are other voluntary adherence things going on, especially in the commercial space, but the ones that have to comply are the ones going for DOD contracts.

Gregg Profozich [00:39:27] An OEM gets a defense contract. Does it apply to the downstream supply chain, as well?

Buzz Thomas [00:39:32] The controls of the 171 that whoever the prime is on the contract when they get that contract, they have to flow down the same control requirements to any subset they use if the subs are going to be storing, transmitting, and processing CUI.

Gregg Profozich [00:39:50] How can a small or medium-sized manufacturer implement NIST SP800-171? What does a successful plan look like?

Buzz Thomas [00:39:58] Typically, your example of a machine shop. These folks know their trade. Manufacturing is manufacturing. Suppliers know their products, and they don’t know cybersecurity. When they’re told that they have to comply to get the contracts, they need to bring in somebody. Really, the path is get some compliance-minded security expert to go through the 171 and modify your network so that it has all the capabilities and the restrictions that the 171 outlines. Then you simply have to go through one of the workbooks that NIST supplies, like the 171A, to figure out if you’re meeting these things and create your score. You put that score in the SPRS website that Ernie was talking about, and now you’re compliant. The better approach would be to find someone who specializes in getting your SPRS scores entered and higher and bring them in. Companies like CMTC specialize in this.

Gregg Profozich [00:40:59] Ernie, anything to add?

Ernie Edmonds [00:41:01] Yeah. I guess just to add on, the 171, again, it’s a laundry list. There’s 110 things, hoops to jump through if you will, and there are different ways that you can meet these requirements. What I do when I’m going through these with clients is there’s the baseline for each of these. We all know those. We’re trained in them. We develop them. We at CMTC we’ve developed an entire process for fixing this that we’ve repeated hundreds of times. We have these baseline solutions. Those are based on what the thing is. We follow a similar methodology to what we were talking about with the 500-299. We define it. We’ve got a definition staring us in the face, but then what does that mean exactly, and then what are the different vectors of exploit, and then how do we either mitigate or remediate those. Then at the end of the day, once that’s complete, we have that requirement implemented based on our solution. We do that 110 times. The workflow for success is essentially that. There’s some deviation. One of the things we look at is what is the most critical path at the least cost for the manufacturer, for our client, to get this fixed without spending excess money, whether that be with resource time, or with product offerings, or whatever that would look like. Sometimes we will vary from the baseline solution because whatever the manufacturer or whatever the client has going on doesn’t support that as most critical path at least cost. It takes somebody like Buzz was saying, an expert in solutioning along with understanding what these things are in order to figure out—we call it MCP at LC, most critical path at least cost—what that means for that particular line item for that particular client. That granularity, going down to first principles thinking, that’s how you solve security. You start with compliance because you have to do that. Then that’s how you solve the real question of security—first principles thinking, going to the use case, going to what that definition is, trying to figure out what the exploit is and what the exposure vectors are and then addressing each of those. That will perc up into a really sound security program for whatever the organization is.

Gregg Profozich [00:43:35] It sounds like there’s a lot of tailoring that’s necessary because every organization is different, everyone has different equipment, different situations, different place in a supply chain, different structure, et cetera.

Ernie Edmonds [00:43:46] Exactly. What happens is the baseline solution will fix it. We know that it’ll fix it in nearly every case. That’s why it becomes our baseline. But the client, the SMM, they’re trying to be competitive in the marketplace, so they don’t want to waste money. We assess it. We don’t necessarily change it, but we assess it as the most critical path at least cost for them. We do that for each of the 110. Some of these things are not systems-based, not technologically based. We look at what the thing is. For instance, incidence reporting. If you have a potential compromised confidentiality of CUI, that’s not a technical thing; that’s an OPSEC thing. It’s operational in nature. It would demand an operational remediation. You’re not going to fix this with a GPO through Windows, group policy object with Windows. It doesn’t work that way. You look at the type of the requirement, and then you implement a similar type of control. That usually is the most critical path at least cost. It could be that you would have something that the problem manifests in operations and in OPSEC, but if you have an operational control, that may not be exactly the best fit. Sometimes you’ll use a management control for an operation or a technical requirement. Something that comes to mind is don’t post CUI on publicly accessible information systems. You can block Facebook, Google, Twitter, whatever. You can block all of those, but then somebody’s going to find the new one that came out last week, and they can post it to that. If you put a policy at the top level… There’s three types of controls. There’s management, which is policy; there’s operations, which is procedure—operational, and that’s a human-based procedure—and then there’s a technical solution, what I call a tech standard that will be at the lowest level. In this case, the thing is, don’t post on a publicly accessible system. The best fix for that is to create a policy at that top-level saying thou shalt not under penalty of termination and potential prosecution, whatever that verbiage would look like. By using that management control, it covers all of the grays. If some new thing comes up the next week, it covers that, too, so you don’t have to go in and just filter rules and stuff like that. There is a complexity to it. Realize that with the 171, only about 40% of that manifests in technology; the OPSEC and management is about 60%. You’ve got to cover that, too, because remember, your CUI can live in paper form. Well, if it’s stored in a file cabinet, what system is that? It’s an operational system. You have to handle that, too.

Gregg Profozich [00:46:40] We’ve covered an awful lot of information today. Ernie, Buzz, it was great to have you here. Thank you so much for joining me and for sharing your perspectives, insights, and expertise with me and with our listeners.

Ernie Edmonds [00:46:50] Thanks, Gregg.

Buzz Thomas [00:46:51] Really appreciate being here. Thanks.

Gregg Profozich [00:46:53] To our listeners, thank you for joining me for this conversation with Ernie Edmonds and Buzz Thomas in discussing the NIST SP800-171 cybersecurity standards. Have a great day. Stay safe and healthy.

Thank you for listening to Shifting Gears, a podcast from CMTC. If you enjoyed this episode, please share it with others and post it on your social media platforms. You can subscribe to our podcasts on Apple Podcasts, Spotify, or your preferred podcast directory. For more information on our topic, please visit www.cmtc.com/shiftinggears. CMTC is a private nonprofit organization that provides technical assistance, workforce development, and consulting services to small and medium-sized manufacturers throughout the state of California. CMTC’s mission is to serve as a trusted adviser providing solutions that increase the productivity and competitiveness of California’s manufacturers. CMTC operates under a cooperative agreement for the state of California with the Hollings Manufacturing Extension Partnership Program, MEP, at the National Institute of Standards and Technology within the Department of Commerce. For more information about CMTC, please visit www.cmtc.com. For more information about the MEP National Network or to find your local MEP center, visit www.nist.gov/mep.

9 Elements of Cybersecurity for Small and Medium-Sized Manufacturers

Topics: Cybersecurity

Tell Us What You Think