EP#31 – Ron Ross – A Brief History of NIST Guidance

ISO 27001, CMMC, NIST 800-53…

Keeping track of the myriad security guidelines can be tricky.

Especially when you don’t know the “why” behind them. 

To help clear things up, in this episode, I speak with the preeminent expert on NIST guidelines, Dr. Ron Ross, Fellow at National Institute of Standards and Technology, and learn not just what the guidelines are — but how and why they came to be that way. 

Ron and I discuss:

• The “Why” behind NIST guidance
• How certification standards like ISO 27001 relate to NIST 800-53 and map to each other
• How NIST balances policy and technical-level considerations

To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.

If you don’t use Apple Podcasts, you can find all our episodes here.

Time-Stamped Transcript

This transcript was generated primarily by an automated voice recognition tool. Although the accuracy of the tool is 99% effective you may find some small discrepancies between the written content and the native audio file.

Narrator (00:00:06):

You’re listening to the Virtual CISO Podcast, a frank discussion, providing the best information security advice and insights for security, IT and business leaders. If you’re looking for no BS answers to your biggest security questions, or simply want to stay informed and proactive, welcome to the show.

Jeremy Sporn (00:00:25):

Hi there. And welcome to another Episode of the virtual CISO Podcast. I’m your emcee, Jeremy Sporn. And you may be wondering where is John today? He is in fact, neck deep in the RP training that was recently released. That’s the registered practitioner training from the CMMCAB. So I decided to give him the afternoon off; just the kind of guy I am.

Jeremy Sporn (00:00:49):

What I can tell you is, the conversation John recently had with Dr. Ron Ross from NIST, NIST is the National Institute of Science and Technology. Their conversation was just amazing. Most people listening will know who Dr. Ross is. Like many of our guests, listing out his accomplishments is like introducing Rocky Balboa, so we’ll skip all the pleasantries. But Dr. Ross’ contributions to the information security industry, will be felt for the next several decades, at least. He is just a monster in our world; incredibly bright guy.

Jeremy Sporn (00:01:23):

And what makes this conversation with Dr. Ross so unique, is he was able to give a little bit more color between the lines as he was able to provide kind of a history lesson on sort of where NIST was, and the how and why of where NIST is going. And these quick history lessons that he gave made it easy, especially for me to understand the why behind what NIST is hoping to accomplish. And we know from Simon Sinek, you always want to start with the why, whether you are in the defense industrial base and have been working through [inaudible 00:01:56] data 10171, or you’re part of a commercial organization who really wants to leverage NIST guidance, there’s just no better source than Dr. Ross to explain the why and how NIST guidance can help you manage information security and privacy risk. He may be one of the brightest information security experts our government has, so just a phenomenal resource. And with no further ado, here’s John and Dr. Ross.

John Verry (00:02:25):

Dr. Ross, thanks for joining us today. How are you?

Ron Ross (00:02:27):

I’m great. Thanks for having me. It’s great to be here today.

John Verry (00:02:30):

Cool. Let’s start super easy. Tell me a little bit about who you are and what is it that you do?

Ron Ross (00:02:35):

Well, Ron Ross from NIST. It’s the National Institute of Standards and Technology. Actually, the organization was started back in 1901, so it goes back a long time. It was started as the nation’s premier metrology organization, so the United States could be competitive with a world’s class measurement system. At the time, we only had a kind of a second rate measurement infrastructure and system and so NIST was formed. And it was called The National Bureau of Standards until 1988, when it became NIST.

Ron Ross (00:03:07):

And we have a several different laboratories from a physical measurement lab to materials measurement. We have a communications technology laboratory, and I’m of course, part of the information technology laboratory, where we have our two cybersecurity divisions. My division is known as the computer security division and that’s run by Matt Scholl. And then our sister division is the applied cybersecurity division, and that’s led by Kevin Stein.

Ron Ross (00:03:36):

So we develop the standards and guidelines for the federal government. And many of our standards and guidelines, as you know, are used on a voluntary basis by the private sector. So we are always busy in this world of crazy cybersecurity, but we love our jobs. We love doing what we do, and we love serving the American people.

John Verry (00:03:54):

Yeah. So listen, I’m a on the record fan boy of NIST. I think that NIST puts out some fantastic guidance and excited to have a chance to chat with you today about that. So let’s start right there, because I like what you said, that there’s some people that use it voluntarily, and there’s some people that use in the government that are not voluntary.

John Verry (00:04:13):

So if I worked for an SMB SME, what is the best way for me to begin to use NIST guidance? And let’s say I’m a non DIB for now, because I think DIB has another whole branch, especially this year and going into next, it does.

Ron Ross (00:04:27):

No, that’s a great question. We get this quite often, because as you would imagine, our customer base is very broad and deep. We have all the federal agencies who are required to use our standards and guidelines, but we have a lot of folks in the private sector and that can range from Fortune 500 companies down to small mom and pops. And some of the guidance is very technical, but there’s a way to apply the guidance to any type of organization, whether it’s a large Fortune 500 company or a small mom and pop. And what I like to tell people, is that you take the guidance and you apply it. It has a context, it’s going to be applied in the context of your organization.

Ron Ross (00:05:04):

And so one example I use, is that there’s a notion of every organization needs to have a contingency plan today for those potential cyber attacks that may happen, and what do you do when that happens? So if you’re a Department of Homeland Security, your contingency plan for cyber might be 500 to 1,000 pages; very detailed, very complicated. But if you’re a small mom and pop, let’s say a doctor’s office or some small business, you can take the same concepts, and it just happens to be in our special pub, 800-34 contingency planning. You can take those same concepts and you can apply those to your small business. Your contingency plan may be only four or five pages, but it would be the essence of what you need to do to withstand that attack and then make sure your business can keep operating.

Ron Ross (00:05:49):

And so whatever’s in that plan is going to be tailored like all of our guidance to the appropriate context. Whatever the mission, the business operations, your environment of operations, the type of technology you’re using, all of those things can be customized and applied to the largest or the very smallest of organizations.

John Verry (00:06:08):

Gotcha. So let’s talk about that. So, you’re involved in most of the, what I called foundational documents, at least from my perspective of NIST. So I think what you’re saying from a contextualization perspective, we’ve got this idea of understanding risk. One of the ways we do that in your world is through FIPs 199 Security Categorization. The other way we do that is through another document you’ve been involved with: NIST SP 800-30, for doing risk assessment.

Ron Ross (00:06:32):

Right.

John Verry (00:06:33):

And then we would use those to tailor. I think of sort of the Bible, the central component of all NIST guidance as being 800-53. So is that the way that you would look at it? So, if you were chatting with a 200 person company that was interested in using NIST guidance, would that be the way that you would guide them? Or would you be-

Ron Ross (00:06:52):

Exactly.

John Verry (00:06:52):

Okay, good.

Ron Ross (00:06:53):

No, that’s exactly what we would do. In fact, we started from scratch pretty much. When FISMA was passed in 2003, we had a couple of security publications that were out. We had the SP 800-26, which was a security questionnaire. And so we virtually had to start from scratch. And NIST was charged at that time, with developing all the core standards and guidelines that would allow federal agencies to comply with the FISMA legislation, the Federal Information Security Management Act back in 2003. In 2014, it was updated to become the Federal Information Security Modernization Act.

Ron Ross (00:07:32):

So we started from scratch and we did exactly as you described. The very first standard that I was involved in writing was FIPS 199. And back then, when we have to comply with legislation, it’s very broad based and sweeping. And if you know the federal government, it’s large, it’s complex, lots of different missions and business operations from the CDC all the way to DHS and TSA. So we had to figure out a way of helping agencies protect all of their information, given their unique context and their unique missions and business operations.

Ron Ross (00:08:08):

So we started with, what’s the core concept that all of us really can rally around? Well, it’s understanding the criticality of your data, your mission, your systems, and what you do as in our case, for federal agencies? But this would apply to any business out there. And the FIPS 199 was, I call it the triaged standard. It came from an idea that I had, I served 20 years in the army. So in the military, there’s battlefield medicine uses a concept called triage and they treat the sucking chest wounds before they treat the hangnails, basically.

Ron Ross (00:08:40):

So we came up with a system saying, “Look, categorize your data, and then that data then, will drive a system categorization.” And we provided three categories: low, moderate, and high, where those different categories on impact, low impact, moderate impact, or high impact; impact to your mission or your business. In case there’s a breach or some kind of attack and you go down, what is the impact on the mission? So at the time, people said, “Well, maybe three categories is not enough. And we toyed with having 10 and 7 and 5, but we wanted to make it simple. And the triage concept really was the motivation for that standard.

Ron Ross (00:09:21):

And so the power of that standard, and I don’t think it’s used to this day is as much as it needs to be. Because today, we have a very, very complicated information infrastructure. We have trillions of lines of code billions of devices with IOT and all the different things we’re connecting up. We’re going from 4G to 5G, so it’s an incredibly complicated infrastructure. And so you have to have a tool and a vehicle to start and work this problem from the big, big, complex problem down to more manageable problems, and understanding the criticality of your data and your systems was step number one. And then from that, as you said, you can take the guidance in 800-30, which is our risk assessment guideline, and you can do a risk assessment. But again, everything in cyber is local.

Ron Ross (00:10:09):

Every organization is different, so when you do a risk assessment at IBM or TSA, you’re using the same fundamental concepts, looking at threats, vulnerabilities, impact, and likelihood, but it’s all in the context of the organization and what it means to them. And so that’s kind of how we started.

John Verry (00:10:26):

Yeah. And there’s a couple of things you pointed out there that I think are fantastic. So the first off, is the one thing that I love about NIST guidance is so many people believe, or many of the risk management frameworks tend to take an asset centric approach to risk assessment, which I’m not a fan of. I’m a fan of information centric risk assessment, which is one of the reasons I like that concept of the FIPS 199 Security Categorization.

John Verry (00:10:46):

The other thing, which is interesting about the way that you do it with 800-30, is kind of echoing that same information centric, context centric approach, that’s used by I think, all great frameworks, right? So as an example, if you look at ISO 27,001, what’s the first step in ISO 27,001? It’s scope, which is what? Understand the context, right? [crosstalk 00:11:07]

Ron Ross (00:11:08):

Exactly. We use that concept and you mentioned 853. And so if you extend the concept of the FIPS 199, which is the low modern high-impact categorization, we then developed three different baselines of security controls. So our catalog of controls has always been large. The breadth and depth is phenomenal. But we did have to decide which controls would be starting off in the low, the moderate and the high baselines. And if you’ll note it in the catalog of our 853, if those baselines do not represent all of the controls in the catalog, we have a lot of optional controls and control enhancements, which are never called out in any baseline.

Ron Ross (00:11:46):

So the idea was, an agency or any company. Once they complete the categorization, they do the risk assessment, now they can grab one of those baselines and that’s their starting point for doing what we call tailoring. And the tailoring process is really where you customize those controls. You may take out some of the controls because maybe some technology can’t support certain controls. Or maybe you add a few controls because you knew your organization is a target from the adversary. And so that tailoring process ends up giving you a tailored baseline. And those are the controls that then go into your security plan and that’s what you actually execute to.

John Verry (00:12:23):

Mm-hmm (affirmative).

Ron Ross (00:12:24):

And so I think that’s the power of frameworks and controls. You could never have a one size fits all for the federal government, for every agency. You almost had to go down a road like we did, where you have a very large, broad set of safeguards and countermeasures, but the ability to give some guidance initially on where you think they ought to start based upon the impact level of tied to their mission, to their business. And then from there, you give agency, you empower the agencies or the private sector companies to customize as they see fit. That’s the power of risk management and that’s missed by a lot of people, unfortunately.

John Verry (00:13:02):

No. Yeah. I agree completely. And I do like the idea that that tailoring is based on that 800-30 System Categorization. You also did something else, which I like, and I believe the documents called the SP 800-60, which is where if someone’s having a trouble with their FIPS Security Categorization, they can kind of look up the data types, and you’ve created sort of a shorthand way for them to understand what an appropriate security categorization is. Correct?

Ron Ross (00:13:24):

Yes. The 800-60 actually has two volumes. And those two special posts were written very close to the time we did FIPs 199, as you said. And it does provide guidance. Now, back in those days, we actually had to go to OMB and say, “Hey, what are all the different data types that the federal government uses? Which ones do you recognize and acknowledge?”

Ron Ross (00:13:45):

And so when you look in that document, it’s the 800-60 document, you will see for confidentiality, integrity, and availability, which are the three pillars of cybersecurity across the low, moderate, and high impact categories, we make some provisional recommendations on a whole bunch of different data types.

Ron Ross (00:14:05):

Now what’s happened since then, is that we have the controlled unclassified information executive order come into the federal space that happened originally in 2010, and then it was reinforced along the way. And so there are now, that was an attempt to have NARA, The National Archives and Records Administration, take all of these disparate data types, which were all over the map, and kind of do a sanity check. And they got together with all the federal agencies and they said, “What are the core data types that we need to protect within the federal government?” And that became the different categories and subcategories of controlled unclassified information, that now is resident in the NARA registry. They don’t have the sub cats anymore. Now, I think there’s 80 or 81 categories of CUI.

Ron Ross (00:14:52):

So if you look at the federal government, now it’s a lot simpler. And that’s one of the basic things, simplicity and cybersecurity, those are the two things you have to achieve. If you get too complicated, people aren’t going to be able to implement effectively. So now we have classified information, which is controlled by statute. We have controlled unclassified information. Again, NARA is the executive agent for that, and then we have everything else. So we’re kind of back to three buckets, again, where your data would fall. And each one of those, whether it’s classified CUI or other, you can protect all of those different data types with the appropriate security controls in 800-53

John Verry (00:15:34):

And three does make things simple in a lot of ways. The only thing which I think, and it’s that the Lord giveth and the Lord taketh away, is simplicity, I only have three risk levels, but of course, then we’ve got a higher level of prescriptivity to the controlled treatments, based on those risk levels. Where something with ISO, which, where you have an infinite, you’re defining your own risk levels and you can scale it any way you want, it gives you a little bit more flexibility and prescriptivity at the expense of, I think a little more complexity, from a risk assessment perspective.

Ron Ross (00:16:03):

That’s very true. It’s funny because we deal a lot with the office of management and budget and they track the number of different types of federal systems there are. So about 70% of, that’s the last stat I had, of our federal systems were moderate impact systems. And then you divide the other 30%, maybe around 10 to 15% are in the high impact area and then the rest are low impact. So one of the things that our organizations can do, if you’ve got 70% of your systems is moderate impact, that starts to make them look all like again.

Ron Ross (00:16:37):

And so when you look at all of those systems, you say, “Are they all really alike? I know they’re all moderate, but are they all the same level of criticality or sensitivity?” It turns out you can actually use FIPS 199 kind of recursively. You can go take those moderate systems and you can do another FIPS 199 categorization, so to speak, by defining all of your modern systems as low-moderate, moderate-moderate, and high moderate.

Ron Ross (00:17:04):

And why is that important? Because when you do that second level of categorization, you now can start to tailor your controls different for the high-moderate systems, as opposed to the low-moderate systems. In other words, it gives you a greater ability to do what you just described as having more categorization levels, but you do it in a very structured and kind of a top down approach. And so that allows you to take those. Some of your moderate systems may be legitimately more important than other moderate systems. And in those cases, you can increase the level of security controls. You can do more monitoring. You can actually apply a greater level of discipline structure and just focus on those systems that are more important, even within all those general moderate categories. So that’s-

John Verry (00:17:52):

Yeah. I like that idea. Do you see that? I have not seen that done personally often. Are you seeing that done more frequently now?

Ron Ross (00:18:00):

Well, the concept wasn’t really known until we did an update to the risk management framework in 2018, that’s the NIST 837 revision two, and we added a prep preparation step. Now we have the six classic RMF steps from categorize, to select controls, to implement, to assess, to authorize the system and then go to continuous monitoring. We added an organizational prep step, prepare step. And one of those steps alludes to this concept of, I call it a sub categorization. So it’s now in the actual NIST guidance document.

Ron Ross (00:18:34):

And when you come across that step, now, that’ll be on your radar. And so if you have that problem within federal agents and they all have that problem. We have a tremendous number of moderate impact systems because that’s actually the minimum level of protection for controlled unclassified information. So most agencies deal with CUI, and so you’re going to find most of our federal systems are at least moderate and then there’s many high as well.

John Verry (00:19:00):

Yeah. I just saw a stat the other day, I think of the 200, roughly FedRAMP certifications, I think 17 or 18 of them are high, which just kind of aligns with funnily with what you just said. It’s about 10% and it probably would be a little higher than that, except that high didn’t come out for a little bit after moderate was out. So I think it’s going to land at that 15 percentage so that what you thought it was going to. So that’s interesting.

Ron Ross (00:19:23):

That’s a brand new thing. And FedRAMP, I was around during 2009, when that program was first started with [inaudible 00:19:29], the Cloud First Initiative. And of course, we work with all the different federal agencies. This was GSA, DOD and Department of Homeland Security, DHS, and they brought together the low and the moderate baselines. And of course, they did their own tailoring at that time. They added one security control to the low baseline, which had to do with independent assessments and they added about 40 controls to the moderate baseline.

Ron Ross (00:19:51):

So the power of that process though, was that, and they kind of do what NIST does. We like to make sure all of our draft documents are vetted with our customers ahead of time. We like them to be able to understand what we’ve written, give us their comments, and then we take all that feedback and we try to take that into consideration as we finalize those publications. Because the worst thing in the world is developing guidance that is shelfware. We have to have guidance that is not only technically correct, but implementable.

Ron Ross (00:20:21):

And so you can see, this has been the great thing about 853, we just released our revision five yesterday. And it’s gone through that process for well over 15 years with hundreds of different drafts. And it’s just, it’s an amazing way to operate. It’s transparency, it’s sunshine, and it’s really getting your customers involved, so they take ownership of those standards and guidelines, as they’re the ones that are on the front lines. They do all the heavy lifting, it’s not us. We’re just there to help them protect their systems and build programs. But when you can get the customers to really buy in, then that’s really powerful.

John Verry (00:20:57):

Well, listen, I mean, at the end of the day, if you don’t have tone at the top in any organization, you’re not going to have a good control environment, right? Whether it’s a financial control environment or an information security. So you mentioned the risk management framework. Explain how you think that fits into the rest of the structure we’ve been talking about.

Ron Ross (00:21:13):

Well, the RMF again was created originally, it used to be the Certification and Accreditation Guidance Document when it first started-

John Verry (00:21:20):

800-37? [crosstalk 00:21:22] That was the old SCNA that a lot of entities were using.

Ron Ross (00:21:26):

Yes, exactly. And that has a long tradition. When I worked at NSA, this is back in-

John Verry (00:21:32):

That was a great document; 37.

Ron Ross (00:21:34):

Yeah, the 1990s. It started out to be, it was a DOD process certification accreditation. You might’ve heard the term DITSCAP, that was the old DOD Certification Accreditation Guidance. It evolved into the DIACAP. And then we had our own version of that at NIST. It was the original 837 publication. But between the first iteration and the second iteration, we decided to move to more of a risk-based type of a framework. And that’s where the RMF was born.

Ron Ross (00:22:03):

And again, we tried to make those original six steps, as simple as possible, knowing that we have a diverse set of agencies that have to implement that framework, so it had to be simple enough. And that’s where that all started. It was probably, well, I’m thinking 2008, 2010 timeframe where the RMF first made its appearance as the RMF. And then of course in 2018, we had the big update to the document.

Ron Ross (00:22:26):

But how does it fit in? I view it as, if you look at this like a car and the car has a lot of moving parts too, but there’s also the fuel that goes in the car. The gas goes in the car. So the RMF is kind of the organizing construct if you’re building a cybersecurity program. And if you notice, every one of the steps in the RMF, actually, it points to a more detailed NIST standard or guidance document. So it’s kind of a high level framework that has to, by definition, be simple enough and flexible enough to be able to handle all the different types of agencies that we have in organizations. And it has to actually.

PART 1 OF 4 ENDS [00:23:04]

Ron Ross (00:23:03):

Absolutely agencies that we have in organizations, and it has to actually provide a pointer to more detailed standards and guidance where they’re needed. Obviously the categorization step pointed to FIPS 199, when you go to the second step, for example, the control selection step, it would point to FIPS 200 and SB 853, the actual control catalog. Implementation, we never really had a pub for that but now we have our security engineering series of-

John Verry (00:23:30):

That’s the 160 or something?

Ron Ross (00:23:31):

That’s the 160. Now we are showing how these controls can actually be implemented within an engineering life cycle based processes which really, what happens in the real world when you build systems and software and all of those things. And then our assessment step, obviously we have the SP 853 ALPHA, which the A, some people say stands for assessment. Every control in that catalog has an equivalent assessment procedure. And then of course the authorization to operate that’s covered in 837 itself. And then we have a continuous monitoring document that we developed to SSP 837, by the way. And so that provides the detailed guidance on how to really implement the ground level. And then the other thing we’ve done is in our control catalog, if you go into 853, you will see a series of references in that document. So if you’re in a particular control, let’s say identification, authentication whatever IAN controls that will point to another detailed IAN guideline like SP 863 the authentication guide-

Speaker 1 (00:24:40):

The new guidance on passwords.

Ron Ross (00:24:42):

So, the kind of the game plan here is to start with a very general and high level framework with great flexibility. You work people into it, a step at a time, and they can go as deep as they need to go until those controls are actually implemented, operating as intended and are effective in what they want to do. And so that’s kind of how they all fit together.

John Verry (00:25:04):

Did you guys ever of put together, one of the challenges, I mean, and again, Lord, give us Lord taketh away, you guys put out an incredible amount of information, which is great and also is a little bit challenging. So what you just described, right? So the way I look at that, and again, I’ll oversimplify and I’ll take this to ISO, because that’s a framework a lot of our clients are familiar with. It’s almost like that the RMF is the overarching process, like an ISO 27,001 ASMs, right? And all of this sub guidance, right? Listen, this 853 is a kind of a [inaudible 00:25:34] at 27000 too, write a collection of good controls, good practices that based on that overarching guidance, we determined which of those controls we need to what extent in rigor and tailor them accordingly. Have you guys ever put out any document that shows how these things all fit together to simplify that?

Ron Ross (00:25:50):

We get that question as you imagine all the time-

John Verry (00:25:54):

Sorry, I didn’t hear that, rough spot.

Ron Ross (00:26:00):

I take the fifth [crosstalk 00:26:01] but I won’t do that. In fact, our two division chiefs, Matt Shaw and Kevin Steiner are putting their heads together now. And we’ve been trying to do that for years. The problem is we get so wrapped up in doing our normal day to day standards and guidelines.

John Verry (00:26:18):

Right.

Ron Ross (00:26:18):

And let’s face it the people… Were a bunch of scientists and engineers, were not great marketers. And so you know, we need to get that document created. It’s one that would really be helpful. It’s count somebody call it a glossy brochure or you know, the dummies documents-

John Verry (00:26:35):

This guidance for dummies. There you got a title for it.

Ron Ross (00:26:40):

Exactly. I’ve always not really liked that title because I don’t think anybody is dumb in anything they do. It’s just that everybody’s got their job to do. Everybody’s an expert in their own area. And our federal agencies, all the management chain, these are incredibly dedicated and busy individuals. So that kind of a document really would be a bestseller. And it is on the plan to get that done. We’ve got another couple of them, that we call them IRS they are inter-agency reports that are going to deal with kind of bringing together all of our risk management like documents and making sense of how they all fit together.

Ron Ross (00:27:15):

The other thing I would say is that you mentioned ISO, ISO has a very similar type structure to what we have done. And it is always been our goal, we would love at some point in time to kind of unify all of this and harmonize all this guidance. But the problem really goes back to the 853, when we first developed that document ISO 2701 was already in print at that time. And 2702, the problem was the depth and breadth of the controls and that standard, it wasn’t sufficient for what we want to do in the federal government.

John Verry (00:27:49):

Yeah. It still isn’t, honestly, I’m an ISO fan, but it still isn’t. I mean- [crosstalk 00:27:55]

Ron Ross (00:27:55):

It’s not a criticism, it’s just a recognition that we have to go a little deeper and a little broader, in some sense for our particular missions. You think of ISO standards that is our first goal to always create an international level standard. That’s better for US industry because many of our companies compete. Most of them compete globally now. So it’s not a lot of fun to have to compete with or to comply with two different standards, ISO in the NIST guidance, but the new standards. But in some sense that was something we had to do. And it’s something I don’t think is inevitable, but it’s true that the ISO… When you do an ISO standard, you’ve got to have an agreement with 180 countries, whatever the number of countries that are part of ISO now and that’s hard to do. So there’s a lot of compromises made.

Ron Ross (00:28:44):

And you try to get the best product you can with the greatest consensus. And it works really well in lot of things. And I think cybersecurity shouldn’t be an exception, but we just haven’t found the way to do that yet. But the good news is every time we release 853 ISO 27001 folks are looking at that. And every time they release a new update, we are looking at what they have done. So we are trying to keep up with each other-

John Verry (00:29:09):

Right. And you cross reference of it. I don’t know if you remember, we actually spoke once prior. It had to be about seven or eight years ago, if I had to guess. We both were speaking at the same conference and ISO 27K conference for the Americas. And you-

Ron Ross (00:29:27):

I remember that.

John Verry (00:29:28):

And you spoke on ISO 27001 and harmonizing NIST guidance with… That was your purpose of your speech there, was to talk about harmonization and what you guys were trying to accomplish. And it was right around the time, you know? So, and to this day, you’ve held true to that. I mean, you guys do a great job of cross referencing all of your guidance to as many other forms of guidance as you can, which is super appreciated.

Ron Ross (00:29:49):

Well, it’s important. You know mappings are always subjective, unless you’re using first order predicate calculus and doing those things, you’re not going to get an exact map. But the reason they’re important for our customers and look at that’s the reason we do what we do, we are all about our customers and if they’re successful then that means we’ve done our job. Just think from a business perspective, many of our federal agencies have lots of different contractors. Many of these contractors who are supporting them are also working globally, so they may have already done an ISO search, on a Scofield applicability for a 27001 set of controls. And so I thought that the reason the mapping is important then, and that’s actually value added. We shouldn’t always want to have them go back and implement controls again, just because they’re from the NIST catalog.

Ron Ross (00:30:35):

So we tried to get as close a mapping as we could from the 53 controls to the 27001 or 2 controls. And that would mean that, the federal agency then could make that decision if they’re working with a contractor that had a nice assert. They could actually decide if, okay, you haven’t done all of the controls in the moderate baseline, but you’ve done maybe two thirds or three quarters. We’ll give you credit for that. If you can show the evidence and then you can work on the gap, that’s a whole lot better than having to go back and waste all that time and money. And so I think we’re trying to be practical, it’s all risk management. It’s not about some utopia or some perfect world. It’s about making real decisions, real credible risk-based decisions every day, as you try to carry out these various complicated missions that the feds and the private sector have to carry out.

John Verry (00:31:27):

Right. Agreed. Completely. So question for you. So we’ve covered a lot of ground, which was awesome. So again, so if I’m listening to this and again, we haven’t gone into the dip yet, right? I’m intentionally leaving that to the end there. So if I’m someone who’s listening to this go on, this stuff sounds great. Ron sounds like a great guy, we should be looking at this. When does NCSF because a lot of people ask me about the NIST cybersecurity framework and how does that fit in? And should we be looking at that, you know it’s guidance towards, what its voluntary guidance, for critical infrastructure, right? How does that fit into with the rest of the work that you’re doing? And I don’t even know what your role was or wasn’t with NCSF.

Ron Ross (00:32:03):

Well, this is another great story. And it started out with another executive order. This was during the Obama administration. And what they discovered is, is that NIST had produced all of these wonderful standards and guidelines for the federal government, but the critical infrastructure, the private sector really didn’t have anything like what we had at NIST. And so they were very concerned that this goes back probably to 2011 timeframe and going the actual framework was finalized in 2014. But there was a big concern with all of our critical infrastructure sectors, which would include things like the electric sector, the financial services sector, the defense industrial base, the communications’ electronics sector. The first responders, there’s so many critical things going on today, where computers are at the heart of these operations. And those computers, the software, the firmware, the hardware, it has to be trustworthy because you’re supporting critical missions and business operations.

Ron Ross (00:33:02):

And if you fail at the wrong time, not only come the system go South and your operations can suck, but people can die. And so at that time, the executive order tasked NIST to go out and work with the critical infrastructure sectors to develop a cyber security framework. And it took NIST about a year to do that, I was not involved directly in that. A lot of people think I was, but we have a great team in NIST, and there’s a lot of people that were working on that project, Donna Dotson, Kevin Stein, Matt Shaw we had a lot of the people that you may know from NIST. And they did a round Robin, they criss-crossed the United States of America having, I think it was five workshops and they produced several drafts of the document. But when it was done, it was supposed to be… It is a document that’s voluntarily applied by the private sector.

Ron Ross (00:33:59):

Now, when the Trump administration came in 2017, one of the first executive orders that president Trump had, was to make that framework mandatory for the federal government as well. So now, like they say, in Houston and in NASA, Houston, we have a problem because we’ve got two frameworks now.

John Verry (00:34:22):

Yeah, exactly.

Ron Ross (00:34:22):

So the private sector had one framework, which was voluntary. Now the feds have two frameworks and they’re both mandatory. So we had a little bit of an issue here, it’s not a bad problem, in fact it turned out rather well and we’re still working on that resolution. When we did the update to the risk management framework in 2018, we said, how can we use the best concepts in both of these frameworks? In other words, the frameworks are different one is a risk management framework, one is a cybersecurity framework, but they both have strengths and weaknesses.

Ron Ross (00:34:56):

The strength of the cybersecurity framework is in its simplicity. You’ve got the five top level functions mainly identify, protect, detect, respond, recover under each one of those, you have the categories and subcategories, and then you got the informative references, which actually referenced the different security control sets from around the world to improve the ISO 27001. And this controls are there 853, you have the NERC cips for the electric sector. You’ve got covered and there’s one there, I think as well, the CIS top 20 controls are there as well. So it’s a big tree structure and it brings in three different types of elements of that framework from the core to the implementation tiers and all of that. So that’s a great way to communicate with senior leaders, because look, you’re not going to get a senior leader to understand the details of 853.

Ron Ross (00:35:55):

And sometimes you’re not even going to get them to understand the authorization the ATO, which maybe consists of three or 400 pages of documentation. But what they can understand is the cybersecurity framework, so it allows the organization and you mentioned earlier, if you don’t have senior leadership understanding an involvement in cybersecurity, nothing good is going to happen downstream in that organization. So the huge contribution of the cybersecurity framework, whether you’re public or private sector is it allows the senior leadership to understand the problem. And it gives them a vehicle on how to start to execute. So in 837, we have to, we took the CSF apart and we actually have a little tag pointers at every task in the RMF where it relates back to a specific part of the cybersecurity framework. And that’s hoping to get our agencies to use both frameworks.

Ron Ross (00:36:52):

For example, I’ll give just a quick example on the cyber security framework can be used to understand… You create a profile, you have a starting state in your framework, and then you have your goal state. And so that starts to sound a lot like my control selection process, I build a profile of what I would like to achieve in my organization with regard to cybersecurity, and that can actually form the basis of your security plan or your control selection process. So we talk about in our risk management framework, RMF 2.0, how can you actually do that? And use both frameworks together. We don’t just use the baselines anymore to do our control selection. We now, because of our engineering guidance documents, you can now drive your control selection from an engineering based approach as well. So let’s say you’re building a new system, and you’re going through all the requirements engineering at the front into that.

Ron Ross (00:37:45):

Once you get your set of system level requirements, where a subsidy of those are designated as security requirements, you can then specifically take those requirements and map those to specific controls, which can be implemented to satisfy those requirements. So it’s a top down driven process based on good systems engineering, or you can go back to the enterprise approach and take the moderate low high baseline and do tailoring.

John Verry (00:38:10):

Got you.

Ron Ross (00:38:10):

Or you can use the cybersecurity framework. The important point is you give your customers choices, pick a framework that you feel comfortable with, but make sure once you’ve got that you do a good job of executing. And if you can do that, give your customers choices. There are many, many different ways to get to a good security solution.

John Verry (00:38:30):

Right.

Ron Ross (00:38:30):

And once we understand that we’ve got the whole set of tools in our toolbox to help our customers do that.

John Verry (00:38:36):

So basically, oversimplifying again, it’s two paths that should lead to ultimately the same destination and depending upon which one works best for you. I guess the advantage with the NCSF is that you do have the… I think it is a little simpler for people to communicate and understand. It’s easier to, and I hate to say this, but with management sometimes having a dashboard or green, yellow, red lights and things of that nature, it’s a little bit easier to do that with. And I think the other advantage is the you really made it very, very simple to cross-reference to it to another, a good group of well-regarded controls. So like that CIS, CSC, a lot of people really like that standard, the idea that it’s already cross-referenced there. And that they’ve got these normative references, right there is really pretty helpful.

Ron Ross (00:39:20):

Well the other thing, when we do the RMF, we break down those tasks and activities. We point to the cybersecurity framework, and when we do our next update, we’ll probably point to the privacy framework too, because one of the things that we did with our risk management framework 2.0, 837 was that was the first framework that actually was multipurpose. It’s not just a framework that can manage cybersecurity risks, it can also manage privacy risk and supply chain risk as well.

John Verry (00:39:49):

Right.

Ron Ross (00:39:49):

And we work with our privacy team, Naomi Lefkovitz and John Bowens on the supply chain side. They were actively involved with that framework development, so the power of having a single framework that can deal with cybersecurity issues, privacy issues, supply chain issues. You’re now starting to see a framework that looks a little bit more like an enterprise wide risk management framework ERM-

John Verry (00:40:13):

ERM. Yep. Well, ISO 31, like an ISO 31,000, right? So you can go ISO 27005 if we’re just going to look at InfoSec, but I’ve always said that, that was one of the problems with, honestly, I think that’s one of the problems with information security, risk management as a whole, is that too many organizations have these silos of risk, right? You’ve got the information security risk, that’s managed by the CSO. You’ve got the supply chain, third party risk, which is managed by a different group. We’ve got enterprise risk management and all of us are talking in terms of different impact criteria.

Ron Ross (00:40:43):

Yes, that’s right.

John Verry (00:40:43):

And if we can’t talk the same impact criteria, we can’t have conversations together, a risk that’s high over here, isn’t a risk that’s high over here. So I like the idea that you’re trying to normalize that.

Ron Ross (00:40:53):

It’s not an easy problem, obviously the [inaudible 00:40:56] and we’re really trying to address that. We have one of our NISTIR folks, Nahla Ivy has been working on ERM, for a long, long time, trying to take more again at NIST and some of the other international standards, and really solve the problem that you just described because you have these different silos of risk management going on. And within those silos, we think we know what risk means, but even that’s tough sometimes. When you start try to combine those different outputs from the different silos, and you try to start to put all those risk factors together across the different areas that we just described, and come up with some macro risk management decision. It’s pretty difficult to do that, and I’m not sure we ever going to come to anything that is similar, this is not going to be an exact science.

Ron Ross (00:41:45):

There’s always going to be some degree of subjectivity and value judgments, that’s what human beings bring to this problem space. And that’s not a bad thing, but I think we can help those senior leaders understand more about where those risk feeds are coming, and help them understand how to maybe assemble those in a way that, they can make some meaningful decisions. We’re not there yet, but we’ve got some good people working on that problem.

John Verry (00:42:10):

I’m excited by that. Because I think that’s a problem in any organization I’ve ever been in. All right. So I’ve held off as long as I can, asking you about NISTIR 80171, which is obviously the discussion and due regard these days, quick question for you. I was chatting with someone the other day, and they told me that they heard you say that 800-171 was originally developed, so that States had a simpler approach to leveraging 853. Is that actually true?

Ron Ross (00:42:40):

You know, if I said that, I don’t remember saying that [crosstalk 00:42:43] I’ve given so many talks and so many presentations. I speak to so many people, the original idea there really we had a problem that again, came onto the CUI executive order.

John Verry (00:42:55):

Mm-hmm (affirmative).

Ron Ross (00:42:56):

That the executive order was really for the federal government in some sense, has CUI now we have to protect it. So NARA had two really big things on their plate to do, they had to develop memory we talked about all those categories that were in the index, 65. They came up with all the different data types, now that were, we call CUI, whether its financial data or personally identifiable information, all those different data types have been defined now, the second thing was they had to define. How do we define appropriate safeguarding measures for those particular data elements? And so we have CUI now, and it’s in the federal government.

Ron Ross (00:43:35):

And the NARA guidance says that it has to be protected at least at the moderate level of protection. So that’s kind of going in point, that works well on the federal side, because we already had 853 and had the baselines and that was, we were good to go. All we had to do is implement that, so if you had a CUI on your system. You knew it was going to be a moderate impact system, and the good news is that 70% of our systems were already moderate in the federal government, so it wasn’t going to be a heavy lift. But what we’re going to do, we have a huge number of contracts. And we have agreements with state and local governments. What do you do when that CUI now goes over the fence? And it’s sitting in a non-federal organization, we use the term non-federal system and organization, because that could be a state government, local government.

Ron Ross (00:44:25):

It could be a university, it could be a private sector, the company, one of our contractors, it could be somebody in the DIB for example, defense industrial base. What do we do now? Well, we had to sit down and said, are we have a continuum of solutions we can possibly go to on one extreme, we could just mandate the moderate baseline for all those people out there. Well, the first thing that I said was, that’s a non-starter because if you look at it, 853. We have a lot of our controls that are federally unique controls. Like the private sector, state, and local governments don’t have to do ATO or Snus authorizations to operate. There are a lot of controls like that. The other problem we had is the executive order requires the feds to protect, the confidentiality of controlled unclass information. It doesn’t speak to the other two pillars of integrity and availability.

Ron Ross (00:45:17):

So we said rather than put the modern baseline out there is the requirement which is going to be a showstopper for almost every organization. Let’s go back to the drawing board and use our own, fundamental concept of tailoring to produce a new set of controls or requirements that would be more amenable, to the non-federal organizations.

John Verry (00:45:42):

Right.

Ron Ross (00:45:43):

And so that’s how it all started. Now we could have done that with just the security controls though we did. We started out and we said okay, we know that the value of the information of CUI doesn’t change, when it goes from the federal side to the private sector side. So how do we recreate in essence, the moderate level of protection.

PART 2 OF 4 ENDS [00:46:04]

Ron Ross (00:46:03):

How do we recreate in essence, the moderate level of protection for the non-federal organizations? Well, we could have used security controls and tailored those but we decided to go to the requirements type of approach, because it was a little different. It wasn’t going to be quite as scary to all the folks out [crosstalk 00:46:19].

John Verry (00:46:19):

800-53 is a scary document, if you’re [crosstalk 00:00:22], honestly.

Ron Ross (00:46:24):

It can be terrifying.

John Verry (00:46:25):

Exactly.

Ron Ross (00:46:26):

So, we started with the moderate baseline of controls. Everything was on the table, and FIPS 200 because that also provided a higher level description. FIPS 200 had the 17 original security requirements that were really tied to the federal information security [crosstalk 00:46:45].

John Verry (00:46:45):

Just out of curiosity, that FIPS, that number 17 strikes a nerve to me. Does that tie into why CMMC level one has the 17 controls? Are they from FIPS 200?

Ron Ross (00:46:56):

No, that was a coincidence.

John Verry (00:47:00):

Just a coincidence, okay. There’s a lot of 17’s. There’s 17 with the FIPS, there’s 17 level one, there’s 17 domains in 800-171, or CMMC.

Ron Ross (00:47:09):

Yeah. What happened was there were 17 fundamental requirements that we defined in FIPS 200 that really addressed the legislation. And then from those 17 top-level requirements in FIPS 200, we created 17 families of security controls. Each family was aligned like access control, identification, authentication, contingency planning, incident response. All those families were tied back to a single requirement.

Ron Ross (00:47:40):

So, when you were going to implement you do your categorization, your impact level would be determined. So, you would implement those 17 requirements in the context of your FIPS 199 categorization and the tailoring process. It allowed us to comply with legislation in the top level FIPS, but do it in a way that was very localized, or tailored to each organization that had different missions and business operations.

Ron Ross (00:48:09):

Now fast forward back to the 171 again, is now we have the moderate baseline and FIPS 200. So, we sat down at a big table with the folks from Nora and the DOD, and we picked apart every control of the moderate baseline and every FIPS 200 requirement, and we applied these… There were three different tailoring criteria. The first one was, we got rid of everything that was federally related. So, all of those controls or the FIPS 200 that were uniquely federal, those had to take a hike.

Ron Ross (00:48:44):

The second thing we did, we focused on only confidentiality or unauthorized disclosure aspects. Now, it turns out that integrity and confidentiality are fairly closely related because of the way the mechanisms are implemented within systems, but availability was totally something we could carve off. So, the whole contingency planning family went by the wayside, totally focused on availability. And then the third thing we did, is we said, “Okay, we got rid of all the federal stuff, we got rid of all the stuff that was not confidentiality related, but there’s a whole bunch of stuff that remains that…” We know that organizations, if you’re running an organization in the 21st century, we know that there are certain things that we shouldn’t have to tell you to do.

Ron Ross (00:49:31):

So, we got rid of, for example, all of our, our Dash 1 controls, policy and procedures. We figured, we’re just going to give the non-feds a pass. We’re going to assume that you’re implementing the controls that we’re going to get rid of. And so we carved a whole bunch of other ones off the table. And what remained was the original 109 requirements that were the original 800-171. Now, that that increased to 110 in the first revision. And there’s another long story with that, which I won’t go into, but that’s the history of 171. And so, it was a way for us to make sure that the CUI that we were using in the federal government, that we had an obligation to protect by executive order and by statute and OMB policy, we now had a vehicle that we could ensure that that same level of protection will be applied if that information were shared with non- federal organizations. And that’s really the history lesson.

John Verry (00:50:33):

Yeah. I think it’s a great document. Only, one thing which has puzzled me personally and confused a lot of the people that we work with, is that 171 specifically doesn’t bring into play what I’ll refer to as third party or supply chain risk management, right? It doesn’t encumber them with that responsibility. Now, I know if we look at the DFARS Clause 252.204-7012 that points to it on subclause M or something, it does, right? It actually encumbers you to make sure that flows down to those people below. You have some obligation [inaudible 00:05:06]. Why does 800-171, and now even CMMC at a level three… I mean, supply chain risk management comes in at level four. So to me, it’s illogical that I would go to this effort to ensure that you’ve got 110 controls. I’m willing to give you my information, but I’m not going to require you, because that information is going to be shared to put in someone else’s data center or somewhere along the line, that we’re not encumbering them with that same responsibility.

Ron Ross (00:51:31):

Well, that’s a great question. In fact, we just added in 800-53 Rev. 5, which we just released yesterday. We have a whole new family of supply chain, risk management controls.

John Verry (00:51:42):

I didn’t know you released it yesterday. Congratulations.

Ron Ross (00:51:45):

Yeah, it was a heavy lift and we finally got it done. But to answer your question is that the 800-171 requirements, those are actually used by the federal agencies when they’re entering into contracts or agreements with non-federal organizations. Now, it’s true that after you have that first level instantiation of those requirements in the contract, it’s really up to the contract to specify, or the agreement to make sure that all of the subcontractors are downstream organizations that may touch that CUI, that those are actually enforceable downstream. Now, we didn’t talk anything in 171 about assessment. When you’re dealing with cybersecurity, we always have two sides of the same coin. On one side, we have our requirements, our security requirements are our controls. On the other side is, how do you know that the organization met those controls or those requirements?

Ron Ross (00:52:39):

That’s the assessment side. We were completely silent in 171 about that. In fact, we developed a publication later, 171 Alpha. The Alpha being the assessment side, which looks a lot like 800-53 Alpha, which is our security control assessment guideline. But those supply chain issues are really critical. In fact, you’re seeing coming out of the White House and the Congress, there’s a lot of emphasis on supply chain security and supply chain risk management. That’s why we put that new family in 800-53. You can imagine that our country, we’re at the forefront of new technology. We are importing and things were being built all over the world. So, there’s those software modules, the components coming in from everywhere. We’re building our systems with stuff coming in from everywhere. And that supply chain is a critical part of that. And the adversaries, if they can affect that component at the lowest level of production. In other words, they can get into the hardware production, then it’s pretty much game over. So, as you get up in the stack, moving from hardware to the firmware to the software, the office [inaudible 00:53:52]

John Verry (00:53:52):

Yeah. [inaudible 00:53:52] but you’re in trouble if they’re there.

Ron Ross (00:53:54):

Exactly. That whole stack can be breached at any level, but the lower you get in breaching the stack, if you get into the operating [crosstalk 00:54:03] it gets more difficult. So, you’re going to see in 2021 and beyond a tremendous new emphasis on supply chain security. And of course, 171, the CMMC is going to be at the heart of that discussion.

John Verry (00:54:18):

Cool. That makes sense to me. So, you knew it was a contractual obligation, so it didn’t have to be specified as a requirement. Okay. I had one other question about 171, there’s an interesting chatter in a group that I belong to, the way we talk about… Some people think that NIST 800-171 obligates people to an additional 62, I think it’s 62 NFO controls that are listed in appendix L or…

Ron Ross (00:54:47):

It’s either D or E.

John Verry (00:54:48):

Yeah. I think it’s E. So, question for you, from your perspective, is that factual, do you agree with that?

Ron Ross (00:54:55):

Well, the NFO controls, that was the group… Remember where I talked about tailoring, we had the three tailoring criteria. That was the third criteria. I call it the “giving you the benefit of the doubt” criteria. And so, as I said before, there was… When the 171 was first introduced, and this obligation was just to develop the requirements, the DOD was the big user of that document. It went into the DFARS. And, of course in the early days, they relied on self-assessments pretty much. And those self-assessments, I don’t know specifically in their contract language if they required the different contractors to attest that the NFO elements were met, those controls were met. I do think they had to… They did focus on the 110, for sure.

John Verry (00:55:42):

Right.

Ron Ross (00:55:43):

But that’s, again, going to be a matter of the contract. Everything in this world is decided by the contract. That’s the way obligations are fulfilled. So, there should be no doubt. And I think this is one of the things that the feds have to improve upon, is being more specific with their contractors and the people they deal with. What are your specific security requirements and controls you want me to meet? And what are the ways that you deem acceptable for me to meet those? That kind of transparency and specificity is the heart of a lot of our… The lack of that is the heart of many of our problems today. We just have to communicate better and then be prepared, draw the line in the sand, be very specific what you want, and people will meet that. If they don’t meet the criteria or the requirements, then you can decide how you want to adjudicate that within the mechanisms provided by the contract.

John Verry (00:56:37):

Yeah.

Ron Ross (00:56:37):

The NFOs, I would hope that most [inaudible 00:56:40] are doing those, but I’m not sure of any formal way to verify that they are doing.

John Verry (00:56:45):

I haven’t seen people consider those to be requirements. So, that was why I asked that question. And I know what I was going to say before when we were going back on the concept of supply chain. The one thing which I do think in a weird way also obligates people to measure that risk is under the risk assessment requirements of NIST 800-171, you specifically call that out. So, if I was an auditor looking at someone’s 800-171 risk assessment, and it didn’t consider third party risk, I would flag that, right? So, I would think that they’d have to have a program to convince me that third party risk was being effectively managed. And how are you with time, Dr. Ross?

Ron Ross (00:57:23):

I’m good. I’m good. I’ll be the last man standing.

John Verry (00:57:28):

You haven’t been around me very often. We might’ve had one beer together, but I can go all night. So, just be careful what you say.

Ron Ross (00:57:34):

I think this is really an important discussion and I really appreciate, because a lot of times we don’t have the chance to sit down and talk about history and why things are the way they are. And when you don’t have that, you lose the context of why things ended up the way they are. So, I appreciate it very much.

John Verry (00:57:49):

No, and this is great for me, because I’m having these conversations every day. I’m on the phone with someone and I’m saying, “Okay, well, we’ve got to deal with third party risk management. No, we don’t. It’s not a requirement.” Yes, it is. “No, no, no, no. Look, I got the listing. I’m looking at CMMC, that’s level four.” No, look at risk assessment. No, look at this. No, look at Clause M in DFARS 252.204-7012, right? Okay, cool. Cool. So, we covered that. Okay. So, what role has, and or will NIST and your groups specifically play with the CMMC as this goes forward, right? Because I like what you said. To some extent… And even DCMA for that matter, right? Because I love what you just said a second ago, is that we’ve got to do a better job as an entity, as organizations and communicating what our requirements are in a contractual way, right? So, that’s the DCMA, right? And they’re going to have to update the DFARS regulations to point to CMMC. So, my question would be is, how involved is NIST in the process with that DCMA stuff and DFARS? How much is NIST involved with the CMMC-AB and figuring out, are they going to look at third party risk at a CMMC level three? What will the auditor’s responsibilities be?

Ron Ross (00:59:06):

Well, and again, a very good question. We get asked that question all the time. I think we don’t have any direct involvement in the CMMC per se. It’s a program that has been developed by the DOD, but I think we do play a role in the CMRC in the sense that we have a long history. We work with DOD all the time as we’re trusted partners. We’ve worked on the Joint Task Force since 2009, working on documents like 800-53 and 37, 800-39, those are all Joint Task Force posts. Now, I will say that much of what CMMC depends on for requirements come from two foundational, mispublications. One of those is, we just been talking about, the 800-71, and the other one is 800-172. And, if we have time, we can talk about the history of that document.

Ron Ross (00:59:54):

It’s actually very interesting on how that came about. But our job again at NIST is to produce for the DOD and for all of our customers who use those publications, the best technical guidance that we possibly can. And in that case, it’s going to be 171 and 172, and DOD is taking those publications and they’re going to form the core of what requirements you’re going to see spread across those five levels of the CMMC from level one to level five. And so, I think that’s on the side of the coin I talked about with respect to the requirements and the controls per se. The assessment side, of course, DOD, we had some early meetings with them. They wanted to know how accreditation bodies were set up because we have a long history of working with accreditation bodies. We’ve been involved in many programs like our Cryptographic Module Validation Program.

Ron Ross (01:00:48):

We have accreditation criteria. Those are accredited private sector testing laboratories. We were involved in the early days of NIAP, the National Information Assurance Partnership, where we have common criteria testing labs. These are all private sector laboratories, but they have to have an accreditation criteria to make sure that the people who are working there have the skills to do those testing evaluation activities and those evaluations. And then when the results come out, they can be validated or certified by some entity of authority. And so we had some early discussions and then the DOD has gone off to build our work on their version of that accreditation body that will result in those CMMC certifications down the road. But again, when it comes to assessments, I am sure they’re going to be drawing off of our NIST 800-53 Alpha publication. They’ll be drawing off the NIST 800-171 Alpha, because those provide a lot of core materials for doing assessments of controls and of requirements. And so again, that’s our role, is to play that technical role and making sure that whatever we produce is technically correct and sound and can be implemented by whatever, whichever our customers are working and whatever program they’re working on.

John Verry (01:02:05):

Yeah. One document we haven’t talked about that I like, and it’s an unusual document because it’s not one of your SPs. It’s actually an HB, which I haven’t seen many of. I think it’s 162, right? That’s the document that gives some… I think it’s an excellent document. If anyone’s trying to DIY, roll their own, they can’t afford to work with a consulting firm like us and they want to implement 171, I think that’s a great document to help people understand what 171 is about, what the spirit is, how they can implement something, where they can look for the evidence of it. I think you guys did a great job with that document. And remind me again, 172 is which document?

Ron Ross (01:02:42):

The 172 is… It used to be 171 Bravo, but we changed the name.

John Verry (01:02:47):

Right, right, right, right.

Ron Ross (01:02:48):

They were getting confused that it was the next version of 171. It’s the enhanced security requirements for controlled unclassed information. And again, that document was produced in recognition that the 110 requirements in 171, they were good, but they couldn’t stop all of these cyber attacks from the advanced persistent threat, the nation state level adversaries. And that came about because of a couple of very serious breaches to the federal government. A couple were in the DOD. I won’t go into specifics, but I remember when we first had the meeting with DOD, we talked about what can we do to bolster those current requirements in 171? And so, that’s now the document that you see on our website, it’s out in draft right now. We just finished the public comment period.

Ron Ross (01:03:41):

We’re going to be locking that document down hopefully fairly soon. And that will be used in conjunction with 171, but it will be very targeted. It’s going to only be used for customers. And this doesn’t have to be just the DOD and the DIB applications. It can be any organization who has critical assets or critical or sensitive operations or assets or high value assets, there’s a term called HVA, high value assets. And so, if you’re working in a critical program where you have a high value asset, these 30-some additional requirements, there our menu, you can pick any one or all of those requirements, and you can add them to the foundation of the 171 requirements. It’s kind of like, if you think about 800-53, you got the baselines and then you have the optional controls and control enhancements, and you can build that security plan with those additional controls based on specific threat information, the environment you’re working in, the specific technologies you’re using.

Ron Ross (01:04:43):

And that again, empowers our customers to put the right amount of protection in the right place. Again, it goes back to a principle that we were talking about on one of my earlier webinars today, you can’t protect everything all the time to the highest degree, or you’re going to become very frustrated and broke. So, you’ve got to be able to understand what things are most important to me, what data, what systems, what components, and then focus like a laser beam on those. And it’s a myth that everything has to be connected to everything else today. It just doesn’t have to be that way. We have the ability to, through technology, through enterprise, the systems engineering, the architecture that we have, to really do physical and logical separation where we need to, to make sure we don’t make it so easy for the emissaries to get into our critical data.

John Verry (01:05:36):

Right. And that 172 can be super… That’s going to apply to people that are moving towards CMMC level four, level five, which is where the APT stuff comes into play.

Ron Ross (01:05:45):

And again, they didn’t use all the requirements in there. You’ll see that they chose, again, a subset of those requirements in 172. Well, it used to be 171 Bravo when they were building that initial version of CMMC. And they did the logical thing, they took which ones they thought were important and they allocated those across the level four and level five. Now, when we finalize that document, you’re going to see probably those controls are going to be, I use the term “bringing them up to code”. They’re going to be referencing the finalized version of 172 when that’s done. And that will become the core go-to for those types of programs and systems.

Ron Ross (01:06:27):

It’s heartbreaking to see how much research and development and money we put into developing our new technologies. This doesn’t just apply to the DOD and weapon systems. It applies to all of our great innovators across the country. We spend a lot of money. We have a lot of brainpower that goes into this innovation and the adversaries are literally ripping this off every day. And if you can avoid having to invest in R&D and you can grab that new technology, that puts the United States at a competitive disadvantage. And that has huge implications, not just for national security, but economic security as well. To me, they’re all tied together. You can’t have a world-class military unless you have a strong economy. And so these things are all tied together, and that’s why cyber security, even during the pandemic, cybersecurity has become even more critical than ever during this pandemic time.

John Verry (01:07:21):

Yeah. The battlefield of today is as much cyber as it is ground.

Ron Ross (01:07:27):

Absolutely.

John Verry (01:07:28):

So, that was good. And we covered that. So, let’s shift gears a little bit. You already did touch briefly on privacy. So, NIST came out with a privacy framework. They built this privacy framework so it looks like it largely aligns with the NIST cybersecurity framework, which makes total sense to me, right? That’s aligned with ISOs doing the same thing with ISO 27001 and ISO 27701, right? So, you can run your information security and privacy management systems in one framework. So, I think that’s what you guys are trying to accomplish as well there.

Ron Ross (01:07:57):

Yes. Again, this has a fairly long history. People think that we’re just now getting into privacy, but for those folks who have been using 800-53 revision four since 2013, that was the first time when we put privacy into our security control catalog. But we did it as a gentle touch. We put it in an appendix J, so it was stuck in the back of the catalog. And it was used extensively by the feds for the past seven years, still being used today. Now what happened in 2017, when we started to think about updating that 800-53 again to Rev. 5, we sat down and we made a design decision. Let’s say, “Well, let’s take those eight families of privacy controls out of the appendix and let’s bring them into the main catalog.” And that was the feeling at the time. My feeling was that privacy is every bit as important as security, even though security seems to consume all the oxygen in the tent, privacy was coming on in a big way. We had things like GDPR and other privacy frameworks that were emerging. So, we made a design decision in 2017 to do…

PART 3 OF 4 ENDS [01:09:04]

Ron Ross (01:09:03):

… were emerging. So we made a design decision in 2017 to do that, and all of those eight families of privacy controls were put into the main catalog. Now, what happened was, they ended up going into one new family, so we had 17 families and 53 originally. The privacy family… We have one privacy family now. All those eight families were collapsed into one privacy family, where some of the controls went into our program management family, which became the 18th… the 19th family. And then, we have our new supply chain family.

Ron Ross (01:09:35):

Now, it turns out that some of the controls that didn’t go into the privacy family, or the PM family, we found something interesting. We found that some of those privacy controls could be called dual-use controls. They became… There were certain security controls, and my favorite example is the AT2 control, awareness and training. That control, AT2, used to be called Security Awareness and Training. Well, it turns out-

John Verry (01:10:02):

Security Awareness and Privacy Training. Exactly.

Ron Ross (01:10:05):

Obviously, [crosstalk 01:10:05] We dropped the term Security Awareness Training, and made it just Awareness Training. And then we integrated a little bit of a privacy flavor into that security control. Those become dual-use controls. And this had a huge impact, we could now be more efficient in how we were constructing our control set, and we now have a fully integrate… In fact, this is the unique NIST product here. This is our IP, so to speak. I believe we have the first and only control catalog in the world that is fully integrated with security and privacy controls in the same catalog. I know that there, ISO- [crosstalk 01:10:41]

John Verry (01:10:41):

No, ISO didn’t, ISO didn’t for sure. ISO took it, and they… There’s an ISO 27701, which recommends extensions to both the 27001 clauses, as well as the 27002 controls.

Ron Ross (01:10:54):

Now, the reason I think this was an important design decision, is because everything at the end of the day is going back to the system. We are tied to the system, we’re tied to the technology. So it’s always been about technology, people, processes, and all those things collectively.

Ron Ross (01:11:11):

So traditionally, privacy has had more of a role in the policy and procedures area, but let’s face it, privacy controls now are working their way into the technology. And you can see this every day on your smartphone. When you download that new app on your smartphone, what’s the first thing they do? Well, you got to agree to all these pages and pages of privacy-

John Verry (01:11:31):

[crosstalk 01:11:31].

Ron Ross (01:11:31):

And none of us… Well, I can’t say none of us, but most of us don’t read all that stuff. We just click, “Okay.”

John Verry (01:11:39):

None of us read them.

Ron Ross (01:11:40):

I may be giving away my firstborn child, for all I know. But the thing is, you’re seeing more-

John Verry (01:11:45):

But I want to play Magic Jewels, the next level.

Ron Ross (01:11:49):

Exactly. But you’re seeing people more… More and more, people or customers are becoming more aware and more nuanced in their understanding of this. And so instead of having an automatic opt-in, you want to have the overall concept of least privileged, least functionality. You want to not opt anything in unless you specifically opt yourself into some of these things. So you don’t, by default, get all these privacy considerations off the table.

Ron Ross (01:12:14):

So we felt that if you really want to bring people together, the two disciplines are different, but they have a common overlap. Security and privacy have a common denominator when it comes to unauthorized disclosure of information. In fact, if you go look at the Fair Information Practice Principles, that’s not the NIST FIPS that’s the International FIPPS. One of the eight FIPPS, the Fair Information Practice Principles, is actually security. And so, when it comes to unauthorized disclosure of information, specifically, personally identifiable information, we are in lockstep with our privacy brothers and sisters.

Ron Ross (01:12:52):

Now, privacy goes beyond that, though. Privacy is actually concerned with the authorized use of PII. How much information can I collect on you? How long can I keep it? What can I do with it? That’s what we brought together in 853, and that’s why you can’t just look at things from the unauthorized disclosure point of view. You have to look at it from, what can authorized individuals do with all of the data that’s about me, when that’s being processed, stored, and transmitted in these myriad of systems that we have today, that are bringing us all together and communicating worldwide.

John Verry (01:13:28):

Yeah. One of the things that I was excited to see and interested to see, and I hadn’t realized it, to be blunt with you, is how good a job 853 did with privacy. And when I jumped in there, I was like, “Oh, I’m sure it’s old school privacy,” like you see with the Privacy Principles from the Trust Services Criteria, from the AICPA. Kind of the old school way of looking at it.

John Verry (01:13:49):

But I was surprised. You’ve got the disclosure and you’ve got the consent, and you’ve got the concept of Data Subject Access Requests. You might not call it a DSAR, you might not call it a ROPA, Record of Processing Activities, but you read what you’re said laying out there. And it basically said… it looks to me like if we did exactly what you said, we’d be meeting CCPA, we’d be meeting GDPR, we’d be meeting APAC. So yeah, I’m excited to see what you did in 5, too. Were there many changes in 5 from a privacy perspective?

Ron Ross (01:14:16):

No, I mean, we didn’t have anything. We never liked to make dramatic changes going from a final draft to a final, because we’d always liked to give our customers a little bit of an advanced look. We had to make some changes because when you get comments in… We got over 2000 comments in on the final draft.

John Verry (01:14:31):

Wow.

Ron Ross (01:14:31):

And usually the number of comments diminishes as we go from initial, to the mid-draft, to the last draft. So we were down at 2000, it’s a big document, it’s 483 pages, but there weren’t a lot of changes in the privacy. But what I can say is, it’s really brought the two communities closer together, the privacy community and the security community. You can… You mentioned our two frameworks. We have a privacy framework, we have the cybersecurity framework. And again, we’re updating all of the mappings to the controls in 53, those are going to be updated to the Rev. 5 controls for both frameworks.

Ron Ross (01:15:07):

So we are trying to give our customers all of the tools they need to try to get the best security and privacy programs implemented they possibly can within their limited resources, their… Everybody’s got a budget. Everybody’s got a budget to meet and we don’t have unlimited money to throw at these products, but we can do a really good job at becoming more efficient in how we attack these problems. Cause that’s, to me, that was our biggest contribution with Rev. 5, is making us look at… Opening up our aperture to our security folks on how important privacy is. And then our privacy brothers and sisters, letting them know, “Hey, we got your back. We’re giving you a foundation of solid security controls, and here’s some that actually do impact on the things that you care about with both unauthorized disclosure and authorized disclosure of PII.

John Verry (01:15:58):

Yeah look, I’m… I know that even a lot of the larger technology companies, the Oracles, Microsofts, Googles of the world have been pushing… They’re concerned that CCPA is going to do what SB314, the identity theft prevention stuff and breach notification laws, I don’t think they want to deal with 50 state standards. So I think they’d like to see a national standard, they’re lobbying for one. I think you guys put something out that would form the basis of an excellent national standard. Any thoughts on that?

Ron Ross (01:16:29):

Well, yeah this is always a problem. We talked about it earlier, about, you have many different frameworks, many different control sets, and so mappings and being able to have the same terminology and understand the different language, the lingo going across frameworks and control sets is really important. But I think our philosophy has always been, if you develop a good foundational set of controls, be it security controls or privacy controls, and you do a good implementation of those controls, and you can develop the evidence to show that you’ve done that… I call it due diligence. That should be transferable. You know, the… This gets down to transparency and traceability and having the ability to understand what the other person has done, and having the evidence to show that what they’ve done is credible, and then you being able to accept that.

Ron Ross (01:17:19):

I think that is what we try to do at NIST, is to develop the broadest and deepest set of controls. We did this for HIPAA. When the HIPAA security rule came out, they formed… They took our… A lot of our controls and they implemented those to show that what we’d had, was more than sufficient to cover the HIPAA security rule. And I think I… When industrial control systems… We had all of that work that came out, we developed a special pub for industrial control systems, the 800-82, but at the core of all of this are the controls in 853. Same with our supply chain guidance. Jon Boyens, working on the SP 800-161 that pub’s getting updated now with the Rev. 5 controls. If you provide good working components… This is not just a security control or a privacy control issue. If you’re building a car or a house, you’ve got to start with good fundamental components, good piece parts. And then you’ve got to have a good design, a good architecture, a good plan. If you have those two things and you put competent people in charge of building those houses, or those airplanes, or those bridges, or those security or privacy plans, or those systems, you’re going to have a much better outcome than not. And that’s kind of what our philosophy has been at NIST.

John Verry (01:18:35):

Yeah, oh I… And I can see that. And that’s where that document we talked about before, kind of, helping people visualize all of this into this cohesive… You guys have a vision of this as a cohesive, unified, holistic program that I think, if… Somebody has to work from outside of the NIST to see that right now. But I-

Ron Ross (01:18:57):

Very true. That gets back to your original point about, we are short one document, right?

John Verry (01:19:03):

Yeah. Yes, I would agree, I would agree. Now speaking of documents, because you kind of crossed over to 882, which is an interesting document, we’ve used that one. And it ties into… Although 800-82, I don’t think specifically is framed this way, it ties into that concept of IoT security because a lot of the SCADA systems now have an IoT component to them, and you guys have also produced 8228 and 8259, two other very good documents with regards to that. But they’re more informative documents than they are standards, right? They’re like, hey, things you should be thinking about if you’re using IoT. And if you’re… If you’re developing devices, here’s a couple good ideas that you should be thinking about.

John Verry (01:19:41):

Someone like… I don’t know if you guys, kind of, stay in touch with other entities, like… ENISA, I think, has put out some good guidance on IoT that we use sometimes when we’re testing IoT devices, any thoughts? Is NIST moving towards maybe some more prescriptive guidance, maybe some more 853 linked guidance relating to IoT security? Because, I think, as you alluded to earlier with 5G and AI and this… I mean, what’s the number we’re going to have, some… How many billion, 50 billion devices with 75 quintillion-

Ron Ross (01:20:14):

Yeah, it’s… It’s a big number.

John Verry (01:20:15):

Bytes of data per day being generated by these devices?

Ron Ross (01:20:19):

Look, I think to answer your question… Is that, we have a team, an IoT security team working on some really good guidance. Whether it’s prescriptive or not, again, you’ll notice that we don’t produce a lot of FIPS. We produce a lot of special publications and an IR’s, inter-agency reports.

John Verry (01:20:36):

Can I ask you a question there?

Ron Ross (01:20:38):

Sure.

John Verry (01:20:38):

So you differentiate those in a way that I didn’t understand that they should be differentiated. Is a FIPS a standard, versus an SP is informational guidance? Is that how you differentiate it?

Ron Ross (01:20:49):

It’s… Yes. It’s kind of a complicated question that goes back to… In the old days, when legislation, when FISMA came out, it mandated the use of… It mandated the FIPS, the Federal Information Processing Standards. So when NIST produces a standard, it has the force of law behind that standard. Organizations have to use the standard, they have to implement things like in 199 and FIPS 200. If you look at special publications, those were never deemed to be mandatory in the sense that ONB has always said, you’re required to use the NIST standards and guidelines, but the guidance documents, the SPs, were always taken to be… You have to look at the content, but implement the content in the way that works for your organization.

Ron Ross (01:21:32):

And so again, it wasn’t that in the sense of being mandatory, like our FIPS… And our IRs, the Interagency Reports, those are documents that are more focused on some of the new R&D things going on, things that don’t rise to the level of an SP necessarily, or certainly not a FIPS, but there is that kind of mild distinction. Now, certain of our SPs, I would say, are a little bit more looking like FIPS with regard to how they’re looked at. 853 is a- [crosstalk 01:22:01]

John Verry (01:22:01):

Yeah, 853 to me is a lot different than 8228, right? To me, they’re totally different documents, totally different… The authoritative nature of 53 to me is very clear, where 8228 is not authoritative at all.

Ron Ross (01:22:17):

But in general, I think you can say across the board that NIST does not like to be in the mode of being prescriptive. We’ve got a bunch of… We’re scientists and engineers, and our job is to produce the best technical guidance we can. So that’s where we’ve always had a bright line between policy level things and technical level things. You don’t find NIST mandating policy level things. That would be… So when FedRAMP, for example, and GSA has the FedRAMP program, and they come up with their baselines, or someone does an overlay for a specific federal agency, or… Let’s say NARA had an overlay for the CUI type of requirement, that would be an individual agency level policy decision. And so mandates can come from anywhere, they can come from law, they can come from executive orders, they can come from OMB policy, but we don’t like to be put in the position. We’re not in the position of making policy. So, that’s always been kind of a clear line in the sand for us. So you mentioned the IoT, we have a great team working on IoT security, and there are going to be several documents coming out. And the idea there is, again, to get back to, what’s in our DNA at NIST is working with industry, being that we’re from the Department of Commerce. We’ve always wanted to work with industry, because, going back to our founding in 1901 where we didn’t have a first-class measurements standard, we had a second-rate measurement standard infrastructure at that time. And so it’s important for us to always work with industry, because that’s where the rubber meets the road, they’re doing the production, the innovation. And so all these measurement standards and all the things we do are used by industry for many, many different purposes.

Ron Ross (01:24:03):

That competitiveness is at the heart of all this, because if you’re competing worldwide, those measurement standards become very, very important. So for IoT, the thing I’ve always said about IoT or any type of technology, we’re always going to be in a position of seeing new technology, technological advances. We went through the smartphone revolution and we had the problem with two-factor authentication. We couldn’t fit our PIV cards or our CAC cards into the smartphone, so what did we do? Well, we went back and NIST did some R&D and came up with Derived Credentials, they were soft service put on the phone. Is that as strong a protection is having the separate token? Maybe, maybe not, but it was a practical solution that you could make a risk management decision about.

Ron Ross (01:24:51):

And so we’re always about looking at the new technology and figuring out how to apply fundamental cybersecurity concepts that have been around for 40 years, but applying them in the context of new technology. IoT is the same way. What makes this possible is that, whether it’s an IoT device, or a smartphone, or a tablet, or a super computer, or an industrial control system, they’re all driven by computers, even industrial control systems. There are a lot of analog stuff still around, but we’ve seen a migration from analog to digital. You know, it’s just the way it is. But at the heart of all that is the computer, and the computer is driven by firmware and software. And you have the stack, the system stack. So for me, if everything looks like a computer, that’s kind of the fundamental grounding that we can work with.

Ron Ross (01:25:42):

So with IoT devices, when you get to the extreme type of IoT device, maybe a sensor, no you can’t apply all those controls in that sensor, but you have to be able to look at each of those devices individually and say which of these fundamental cybersecurity principles applies to this particular device? It depends on what it’s doing, what it’s connected to, and the information flow and everything like that. But with good system architecture, and security architecture, and a good engineering approach, you can go through and look at every element, every component in that system, and you can make those risk-based… Engineers do that all the time as part of their engineering process. And we have to get back there, we can’t just throw our hands up and say, “Hey, we’ve got 50 billion devices now that we have to deal with. We don’t know where they’re being made, where they’re… What’s in them.”

Ron Ross (01:26:31):

I call this the great black box phenomenon. You look at that smartphone and you marvel about what it can do, or your tablet, but most people don’t have a clue what’s going on inside the black box. That’s not a good place to be when you’re pushing some of the most sensitive and critical data through those devices. And those devices are controlling, in some cases, life critical applications, and they’re being put into life critical systems. Whether it’s a power plant, or a medical device, or an automobile braking system. This is why cybersecurity is my favorite line of business, and it’s been that way for 30 years. And it’s a great-

John Verry (01:27:08):

And it’ll be that way for 30 more.

Ron Ross (01:27:10):

And for those young kids out there who are in elementary school, or high school, or even in college now, this is a great career field for you to consider. There’s… We have a cyber workforce framework at NIST that some of my colleagues have been working on. And it’s part of the National Cybersecurity Education framework, the NICE Initiative, they call it. And that framework has… There’s literally a job for everybody in the world who has different skills and different desires. Whether you want to be a policy writer, or you want to get down to writing secure code, or whether you’re a security engineer, or you want to do firewalls or whatever you want to do. If you look at that workforce framework, it defines the job, the skills, the things necessary, and that can provide a great thing for some of our young people to try to pursue these careers.

Ron Ross (01:28:04):

And we’re starting to reach out to the underserved communities now. We have a great shortage of cybersecurity professionals, and we really need to get everybody involved that has a desire, and give them the tools to do great things. I mean, that’s how I started, and I had the passion early and once I discovered this field, I never looked back and it’s been a… Every day I get up and I’m more excited than yesterday, and that’s a great place to be. And I hope more people can experience that.

John Verry (01:28:36):

Yeah. I can echo that. You and I have both been doing this longer than we probably care to admit, and I still love it every single day. And people are always surprised by how passionate I am and how excited I get to talk about it.

Ron Ross (01:28:46):

Very true.

John Verry (01:28:46):

Which is why I was excited to talk to you. So Dr. Ross, listen, you’ve been incredibly nice with your time today. Super appreciate you being here. Any last thoughts before I say goodbye?

Ron Ross (01:28:56):

No, I really appreciate you taking the time. You know, these podcasts are really important. They help us communicate our message to all of our customers, and really at the end of the day, all of you out there pay our salaries. We’re federal employees, taxpayers pay for our work. That’s why it’s all… I say it’s free on our NIST website, csrc.nist.gov, but you’ve really paid for it many times over. And I encourage everybody to go to the website, get involved with, either, using the guidance documents, the standards, or helping us as we evolve those standards and guidelines to the next generation. And again, thank you for helping us convey the message. I’m really a big fan of your podcast. I listen to them all the time, so keep up the good work.

John Verry (01:29:38):

Awesome. Thanks again, Doctor. Appreciate it.

Ron Ross (01:29:40):

Thank you very much.

John Verry (01:29:42):

You’ve been listening to The Virtual CISO Podcast. As you probably figured out we really enjoy information security, so if there’s a question we haven’t yet answered, or you need some help, you can reach us at [email protected]. And to ensure you never miss an episode, subscribe to the show in your favorite podcast player. Until next time, let’s be careful out there.

PART 4 OF 4 ENDS [01:30:24]