Hello and welcome to Risk Chats with Affirm. I'm your host, Paul Marshall. Today we're speaking with Dr. Ron Ross from NIST about cybersecurity, updates to some of the special publications, 137 and 153.
And we'll talk about in general the concerns that technology and cybersecurity bring to any organization and how you can follow NIST's frameworks to help you combat these risks. Hello and welcome to the podcast. I'm happy to have today with us Dr. Ron Ross from NIST and he's going to be talking to us about some RISC frameworks.
So good afternoon. How are you doing? Paul, I'm very well. Thank you.
Thanks for having you today. Absolutely. And as usual, Tal is our co-host. Glad to be here, Paul.
I'm looking forward to the conversation. Okay. Why don't we start off with Dr. Ross.
Just give us a little bit of background about yourself and what you do. Sure. Ron Ross from NIST and as most people know, the National Institute of Standards and Technology is 3,000 or so scientists and engineers. We have a very diverse set of laboratories from physics to chemistry to fire and building safety.
I happen to be in the information technology lab. That's where the home of our two cybersecurity divisions. We have a computer security division which works on the fundamentals of the cybersecurity things like encryption, the FISMA publications, risk management frameworks, our controls. And then we have an applied cybersecurity division which takes those fundamentals and they apply them to the verticals, for example, healthcare, finance.
We have a National Cyber Security Center of Excellence working with industry to bring real problems into the NCCOE and then try to come up with cost-effective solutions that can help our citizens do a better job protecting the information. Our primary focus on my team is the Federal Information Security Modernization Act of 2014. And we are charged at NIST of developing the standards and the guidelines that can help federal agencies comply with the law. And that legislation is actually an update from the 2003 original FISMA legislation.
So that keeps us busy with many, many different standards and guidelines. And what we do on our team is only a small part of what the other cybersecurity groups do at NIST. We have a very large portfolio, lots of standards and guidelines on our website, csrc.nist.gov if anybody's looking. And we're just glad to be able to serve the people and do our jobs.
Great. Well, let's just talk a little bit at a high level here and then we'll get into some of the actual publications a little bit. But why don't you tell us, kind of from your perspective, you know, just in general, why is risk management important, especially in this sort of tech revolution in the world and all the vulnerabilities that are out there these days? Yeah, it's a great question.
I think risk management's been around since people have been walking the earth, so we've always been doing some form of risk management. And I think the thing that really energizes me with this new challenge of the technology revolution, we're literally living through the greatest revolution of technology ever. And, you know, we've protected our country for the last 243 years in kinetic space through the military has kinetic weapons, the tanks, the ships and the personnel carriers and all the aircraft that defend the country in kinetic space. But today, this technology revolution has introduced a very new set of threat factors coming in cyberspace.
And the fact that we're pushing computers into everything that matters, whether it's a pacemaker in your chest, it could be your automobile, which has hundreds of computers, not just controlling entertainment systems now, but actually controlling safety critical systems like brakes. And you've got power plants and financial systems and there's everything in the world. And we have now this whole new brave world of Internet of Things, the IOTs, where basically those computers are going down to the sensor level. And with all of that comes complexity.
You have trillions of lines of software and code being written to drive these devices. You have billions of devices from your things around the house to all the things in the federal government and the Fortune 500 companies and your homes with Alexa and all that technology. And all of that complexity, all of that capability, very powerful capability, is all interconnected now through the Internet. And with that complexity comes a huge new set of not just known vulnerabilities, but vulnerabilities that are unknown, that are kind of hiding in that complexity.
So how you defend the country in the 21st century with cyber attacks and cyber warfare, where a lot of these things are hidden in that hardware and that software complexity. That's what really makes this interesting and challenging, and that's really what drives our passion for risk management at NIST. So, actually, just a corollary to that, but, you know, it's not just cyber attacks, but, you know, for your money and your things, right? But it's also just privacy in general, right?
Well, we'll get into privacy later, but that's... We've elevated privacy to an equal status with cybersecurity. FISMA really focused on cybersecurity. Privacy's been around a long time, too.
I think the first thing in the federal space was the privacy after 1974. That goes back a long way. And, of course, we have OMB policies, and there's a lot of work on privacy. We're building a privacy framework now at NIST that's going to be equivalent to our cybersecurity framework.
So there's a huge effort, and it is critically important. When you think about the basic freedoms that we have in this country as being part of a great country that we are, it really depends on having good security and good privacy. And with our huge digital footprints today, you can't be off the grid anymore and operate in society. And so having good standards and guidance for security and privacy, making sure those are co-equal in their levels of importance, that's one of the things we'll get into later about how we're driving that privacy into all of our key FISMA publications.
So they are co-equal, and they're very critical in that regard. All right. So with your publications, what are the updates to the framework that you'd like to share with the listeners right now? What are the major changes?
Well, we started this whole journey back in 2003 with the original FISMA legislation, and we created a vision back then that really had multiple documents, but it started with the risk management framework in our security controls document. And the RMF initial, I call that RMF 1.0 because everything now has to be 1.0 or 2.0. That's the way we talk about things. The original RMF was basically a set of guardrails.
It was a process to help our federal agencies understand what kind of risks are they facing within the context of information systems and their information, the federal information, and what kind of controls do they need to implement to actually protect that information. And then from that point on, we said, after you've implemented those controls, how do we know that what you've done is effective? So we have the whole assessment measurement and all that. And then we come to this notion of risk-based decisions.
We call it an authorization decision. Really, all that is is a senior leader understanding what the risks are and accepting those risks and then moving forward with the operations. So that's kind of how we started all of the RMF process. It had six steps, and it all started with understanding the criticality of your data.
And then once you understood that, one of our first standards that we wrote was FIPS 199. I called it the Great Triage Standard. It basically takes something from battlefield medicine where you treat the sucking chest wounds before the hangnails. And so all of our federal agencies, they look at the criticality of data, and they really rate it as either high, moderate, or low.
And then that drives the initial set of controls that we provide in our baselines. And then they've got the usual flexibility to do all the things like catering, coming up with a good set of controls that work for that particular federal agency based on their missions and their business operations. All those six steps were solid for the last decade plus. But we realized when we went to do our 837 revision 2, that's called RMF 2.0, one of the key things we learned over the last decade is that sometimes the communication from the upper part of the organization, like the C-suite, down through the management chain to the operational level, left something to be desired.
Everybody was talking about cybersecurity in the C-suite. You read the papers every day. Your neighbors are getting attacked. How do we improve the communication, the command and control from the top of the organization, the governance, and then the mission business processes that come out of that governance layer all the way down to the systems, and the people actually have to implement controls to do the level of protection necessary to be able to effectively manage risk?
That's where we added that organizational prepare step. If you look at the traditional RMF, it's got the wheel, the six steps. And we put this one right in the center, the prepare step, for a reason, because that is the step that engages senior leaders. And I talk about stakeholders.
Those would be everybody from the secretary of the department at the federal agency to their mission business owners and the bureaus. That's the level of interaction that we're trying to push to make sure that with cyber, since it's such a critical part of mission success, because we have total dependency on this technology. And if the technology fails, our missions are going to fail. So how do we get those folks in the room?
Not so we can make the conversation about us as security people or privacy people. The conversation is always about mission and business success. And how do we bring that discussion to the boardroom and say, we're here to help you be successful. But in order for us to do that, you have to engage and tell us what's important to you from the mission perspective.
And that's what that prepare step really is all about. It talks about risk management strategy. I think you might have some discussion later about that, the risk tolerance. All of those things are things that can only happen at the senior leadership level, and they can't be pushed down to the system owner level.
So right along those lines, I haven't been involved with many FISBA evaluations, where it seems like when evaluators are coming in, there's an awful lot of focus on minimum compliance. The controls are mandatory, and it doesn't seem like there's a lot of opportunity for senior leaders to make decisions for cost-benefit trade-offs given their business plans and their systems. But it's do you have it or you don't from the evaluator's perspective. So how does your work and the strategies and the framework enable senior leaders to make risk management decisions and trade-offs based on their appetite and the types of systems and data and business that they're engaged in?
In RMF 2.0, we did something really important. In addition to integrating privacy into the framework and supply chain risk, we also decided that there needed to be another way to decide what security controls go into your systems. Right now, we have the baseline approach, where you do the categorization. You say, my data is high, moderate or low, impact.
Where impact is the impact of mission or business if it's compromised. And that starts with a set of controls. We give you a starting set of controls, and then you kind of tweak those controls based upon your specific needs, mission, business operations, environments where you operate. We said, what if we flip that bottom-up approach, and we start from more of an engineering or lifecycle approach?
What if we said, hey, let's bring the stakeholders in early? What mission or business is important to you as a senior leader? What kind of a system or technology are you going to ask us to build to support that mission? And then let's get you involved in defining the requirements for whatever the capability that system is going to be from a functional standpoint?
And then a subset of those requirements, then we will carve out and call those security requirements. So that's the way the senior leaders get around the table to define what's the capability I need to have from this technology to support the mission? How are we going to protect it? That becomes part of the early discussion, and it's part of requirements engineering.
Some people remember first, a trade-based discussion. You talked about how much risk am I willing to take and how much is it going to cost me to satisfy 100 security requirements versus 50. Where's that sweet spot? And so that discussion takes place in a negotiated fashion.
But you see, it's not happening at the end of the training. This is happening early on. So the senior leaders end up coming to that decision with their technical experts. And they say, okay, this is about the range of protection I think we can afford.
I think this is reasonable within our risk tolerance. And, you know, risk tolerance can be different based on the mission of the business. And that's where you nail that down. So after that, you've got a set of secure requirements, and you go out to the catalog and just pick whatever controls are going to satisfy those requirements.
It's a much more targeted way of doing business. And it also ensures that those senior leaders own it at the front end. Right. Or because, you know, as opposed to now, you might say, I have this suite of tools and applications and things that I'm using to do my mission.
And when you come in and look at the security, you realize, oh, you know, all this privacy is at risk or all these different data, you know, this data is at risk. I didn't realize that. If I want to know that up front, I want to know how to properly invest in the security required or do a different approach. And it allows the ROI discussion to take place at an appropriate time.
You can't, once the system is going through the life cycle, and you're getting redeployed by that system so many times in the federal government, at the end of the process, they say, oh, we need an ATO, an authorization to operate. And they say, well, we didn't start that early, so now we're going to go back and wait six or nine months. And the odds of you getting that right after the fact are very, very low. Because you can't add security in at the end of the process.
Some of this stuff has to be embedded in the technology, in the architecture, in the design. And those kind of things just can't happen at 30,000 feet after the fact. So we're now giving agencies two different methods to select their control. They can still use the baseline, and some people are more comfortable with that.
But then, we're like the DOD. They're building a weapon system. They can't do all those auditing controls in the AU family. There's not enough onboard storage to collect all the audit data in some of these weapons.
So they go from the top down. Now, I would argue that you can end up with very good solutions. They can look very different. But still, they can satisfy the risk management strategy and be able to work in that range of things that senior leaders are comfortable with.
And they're part of the process now. They're not sitting here outside of the discussion, which I think is a real improvement from what we had before. Right. So just a little bit more on that.
Just discuss how this publication or some of the other ones really help leaders really develop a good risk management strategy or understand their risk tolerance a little bit. What kind of tools does it provide to them? Well, risk tolerance and risk management strategy. You hear about risk thresholds.
All these words are just words. And I'm just listening to some of the sessions today in the ERM discussion. And again, trying to define those. They're kind of a value management today and all the things that we deal with in the whole notion of ERM and enterprise risk management.
To me, what 837 does is it gives you a structured and discipline process on how to look at when you do a risk assessment, for example, which a risk assessment is part of a risk management process. We assess risk, then we respond to risk, then we provide treatments to the risks, and then we monitor risks over time. And all of that is done in some kind of a frame, a context of the organization. But when you look at risk assessments, and this is why I have great hope that ERM and the risk management framework can come together in a kind of a bonding, because a risk assessment still always has four components.
You look at the threats, you look at the vulnerabilities, you look at the impact if the threat actually exploits the vulnerability, and there's some likelihood that's going to happen. Now, that can be true for the cyber security space. That can be true for privacy. That can be true for supply chain.
It can be true for almost anything where a threat, it may not be a cyber threat, it can be the threat of a hurricane or a natural disaster, or there can be risk in developing a new technology. All of those things, that's why we have generic items within our risk assessment functions, and that's what allows us these tools that we're building primarily for cyber security and privacy. It gives the senior leaders a structure, I call it guardrails. It allows them to have tangible things they can look at.
So when you talk about my risk management strategy, my risk tolerance, well, what is the context that we're talking about? We're talking about, in this case, cyber threats. We're talking about determined adversaries that have capabilities, intentions, and they're targeting you. And what are the kinds of things, the vulnerabilities that may exist in your systems, which your people are telling you you have?
It personalizes it, and then you can see the mission impact. Like at OPM, if the Chinese get into that database and they steal all 22 and a half million records of SF86 data, that's a huge deal, and it's very impactful. And it's nice to be able to talk about these things not after they happen and the horses are out of the barn. Let's have these discussions before the fact.
Let's project what that attack would look like, how it would impact the organization. And that's really why we're giving those senior leaders tools to try to talk like pixels in a television set today. If you've got a high definition, you have a lot more density of pixels. It gives you a much crisper view.
In the old days, we had very few pixels, and it was very little to work with. Now we're giving people greater tools to increase the level of clarity of what they're dealing with. That's a good analogy. Actually, one more thing on this, and then I think we want to talk about the other publication.
So in the beginning, we did say that this revision does include cyber privacy and supply chain. Well, this is really one of our major objectives. We committed about two or three years ago to integrating privacy, not just addressing privacy. We started addressing privacy back in 2013 with our 853 Revision 4.
We have a whole appendix of privacy controls. It was stuck in an appendix. Our goal was to make privacy co-equal and important to cybersecurity. And to do that, we were committed to integrating privacy into every one of our current FISMA pubs.
So the first one we chose was the risk management framework. And so we sat down with our privacy. We have a great privacy team led by Nemi Leftowitz at NIST, and she has a whole team of privacy professionals. And we worked with them.
We said, here's our current risk management framework for cybersecurity. Can you use that same framework to manage privacy risk? Because we have our privacy controls. So I'm going to say, here's our current risk management framework for cybersecurity.
Obviously, you can say either yes or no, but we went through every step in the RMF and all the tasks and all the activities, one by one. And some things worked perfectly well, other things we had to do a little shaving and adjusting here or there. But when we were done, those privacy professionals were confident that they could use the new RMF 2.0 to manage privacy risks based on the same things we were doing with the old RMF. Supply chain, the same thing.
Supply chain is about bringing in services or components from a very wide and deep supply chain. You have to understand what kind of risks come into the organization by buying those products and services. And again, the fact that we have a generic RMF in principle allows us to bring in these other vertical things like the supply chain and privacy that look a lot like cybersecurity. They're all stovepipes, but now when you bring them in to a common framework, they look a lot more alike than they do different.
So that experiment worked really well, and that's RMF 2.0 and 837F2. And we're doing the same thing for 853, by the way. Speaking of 53, revision 5, if you were Vegas, what day should I bet on that? We're going to see that.
Well, I'm not a betting person myself. The science doesn't prove it out. Yeah, for scientists and engineers, this is a very frustrating situation. Obviously, the federal government is a large organization, and we do have the Office of Management of Budget provides oversight for everything we do under FISMA and all the Privacy Act and all those things.
And the fact that we're now integrating privacy into our flagship controls publication, that has to be reviewed by the people who are in charge of the oversight, and that just happens to be that OMB is a big place. There's the federal CIO, and out of that office comes the A1, the circular A130, which is the Federal Policy for Cybersecurity and Privacy, and there's actually a privacy branch, which resides in another part of OMB called the, it's the Office of Information and Regulatory Affairs. It just happens to live in that organization. So that's, it's there now, and they're going through and trying to look at all the privacy content.
It just takes time. You make it sound like your projection is a very long time. I'm always a glass-half-full kind of guy. So the only thing I can tell you, it's been there for about 10 months.
And it's kind of slowed us down a little bit, because we, in the business that we're in, with cyberspace and cyber threats, even though standards in general is kind of a slow, cumbersome process. At NIST, we work pretty rapidly with our SBs and our FIPS and all those things. We do it through all the public review, but we do it in a way that is always on the edge. We're on the cutting edge.
And so, you know, it's... Well, you do that. These documents are living documents. And so, you know, once we get by this hurdle, there's about five or six other publications that are going to drop very quickly after that, because 853 is one of our flagship documents.
Ref4 has been downloaded or accessed over 20 million times since 2013. So, yeah. So, it's kind of a centerpiece. But once that gets approved, it'll be worth the wait, because now we're operating with...
We have one privacy family in the new 5305. We had eight privacy families. Now we've got one. But a lot of those privacy controls disappeared into our program management family.
Those are the controls that work at the enterprise level. So, the ERM folks will be very interested in that, because at ERM, you're going to recognize a lot of those controls that are the risk management strategy. Those operate at a senior level. And speaking about the ERM folks, when they do implementation, they recognize that risk management exists at every program level.
That's what managers do to do their job. They have their resources. They have their objectives. And assessing the rest.
They allocate resources and maximize results and outcomes. So, as they're working throughout the different programs, they inevitably are going to have some contact with the CIO's office. And they come in, and they're bringing their ERM framework, and they say, hey, CIO and CISO, we're going to be putting together an agency-wide profile of risk. And here's our risk management framework.
It seems like most CISOs and CIOs will say, risk management? I'll show you risk management. And then you bring out two or three different binders of implementation at 53 and 37. Right.
And the ERM person will all start saying, well, okay, how do we connect? How do we connect what's happening in 853 and 837 with the enterprise-level program? Because while you'll have hundreds and potentially hundreds of risks that you've identified in a SAS to prioritize their monitoring, the ERM profile does not want 400 CIOs. So how do we make a juncture between effective CIO and CISO operations of risk management and make sure that those risks that are appropriate at the enterprise business performance level come up without having the ERM people try to bring down to the CISO something that is either redundant or it's just not necessary because of all of the existing NIST requirements and risk management framework.
So if you're a glass-half-empty guy, you're going to look at that as a train wreck. But if you're like me, glass-half-full guy, I'm going to look at that as an opportunity. And one of the things that we've done at NIST, and our ERM folks, they recognize, since they live at NIST, and we obviously do ERM at NIST a bit large, and that's all the things that are ongoing in the last two or three years of developing and maturing that capability. We also, they live in the same organization that develops the risk management framework.
So they were very aware of all the things that you just mentioned, that the CISO and the CIO, that's part of the way they roll. That's how they've been doing business for the last 15 or so years. So how do you reconcile these two worlds? Well, one of the things I just talked about is we've been doing this grand experiment with the RMF, the risk management framework, which started with cybersecurity as a silo, and we're expanding our portfolio now bringing in things like privacy and supply chain.
Now you might say, well, why are you doing that? Well, we're trying to demonstrate that the RMF has basic fundamental components that can be applied in other areas besides cybersecurity. We've proven that can be the case with privacy and supply chain. So the answer to the next level is, how does that interface now with the larger ERM concepts?
Because you have to go back, and what gives me hope is that as I was saying earlier, we have things that are part of any part of risk management, whether it's ERM or just general risk management, it has basically four pieces to it. It's got a framing component where you establish the context of what this organization is all about and how we do business, and then you move into the kind of the three core aspects. You assess risk, you respond to those risks, or some people call it risk treatment, and then you move into a risk monitoring mode over time. Once you've done all you can do, now you've got to monitor your risks over time.
And that's kind of a cyclical life cycle type process. But that's a generic set of components. Isos standards, talking about that, 31,000, there's a lot of general, you come down to our risk assessment process. We look at threats, we look at vulnerabilities, we look at mission, business impact, and the likelihood.
Again, four generic pieces. I believe that what ERM is developing at the enterprise level, there will be a lot of overlap and commonality that we'll be able to sit down with those folks and say, here's what we've done as we expand our risk management framework. We're watching what you're doing from the top down. Let's see where we have that overlap.
Look at it like a Venn diagram. Two circles are coming together. The question is, how much overlap is there within those two circles if we get closer together? You'd like to maximize that common ground in the center.
Because if we can do that, then we can negotiate the edges, if you will, where we can't quite come to reconcile those differences. But I believe that we're both coming at this from fresh perspectives, we're both doing it with good intentions, and it's just that we're coming at it from a little bit of different perspectives at different places in the organization. But the RMF works up from the senior leader level all the way down to the trenches. So we've got the experience of coming from the top of the organization all the way down to the bits and the bytes.
And we can add value that way. But I think that's an experiment worth looking at, because it could be helpful for both communities. So just to wrap it up, following on that, what are some future areas you potentially could see adding to the framework model the way you guys put this out? Well, I would like to see us, first of all, engage more closely with the ERM community.
That's going to be the first step. And we're already doing that. The fact that I'm here today, and we're speaking at a firm events and luncheons and all that, what we're trying to do is expose the ERM community to the details of what we've done on the RMF side. And that's the start of a dialogue.
I still think there may be other opportunities to expand the RMF risk management portfolio, bringing in things that we haven't addressed yet. There are things like natural disasters. There's all kinds of threats out there that are not cyber threats. Even privacy and cybersecurity, those are still running kind of the same lane.
But we're managing a whole portfolio of risks that go well beyond reputation risks. There's all kinds of things. There's programmatic risks. There's financial risks.
There are just a long list of things that senior leaders have to deal with every day. My goal is to try to make their life easier so they have enough transparency and traceability. Those are the two T's that I talk about that lead to greater trust. In order for you to make good risk-based decisions, you've got to be able to trust the information that's coming up through all these processes.
And it can't be such that it overwhelms the senior leaders so they don't know what the heck they're looking at. It's got to be trustworthy information. That comes from traceability and transparency of any type of risk-based process. Right.
Well, Dr. Ross, thanks for coming out. Thank you so much. Thank you guys for having me.
I appreciate it. Thank you. That's our show. Thanks for tuning in.
Check us out. Firm.org. Have all our podcasts there. We're getting ready for the new year.
We'll have plenty of interesting guests coming up soon here. Always look for new ones. So if you have any ideas, drop us a note. Until next time, this is Paul Marshall signing off for Risk Chats with Firm.
Thank you.