Risk Management Framework (RMF) Overview

This blog post is a transcript of Alpine Security’s Risk Management Framework (RMF) Overview video, which covers an overview of RMF, as defined by NIST 800-37r2. Each step in the process is discussed at a high level:

  1. Categorize

  2. Select

  3. Implement

  4. Assess

  5. Authorize

  6. Monitor

An example of the Security Categorization for an Information Type of PHI is provided:

Security Categorization (PHI) = (confidentiality, High), (integrity, High), (availability, Low)

NIST 800-37r2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf

Alpine Security Certified Authorization Professional (CAP) course: https://www.alpinesecurity.com/training/isc2/certified-authorization-professional-cap

The CAP course fulfills DoD 8570 IAM Level 1 and 2 requirements: https://www.alpinesecurity.com/training/dod-8570-approved-training

Complete RMF Overview Transcript

This is Christian Espinosa with Alpine Security. This video provides a high level overview of the risk management framework or RMF. RMF is a risk management framework used primarily by the Department of Defense and the US government. It is defined by NIST 800-37 the latest revision as version two, which you can see in the top of the PowerPoint page here, the presentation. The process has six main steps and we're going to go through those steps at a very high level. Really, there's like a seventh step not listed here and that is preparation. Generally, it's a good idea to prepare for something before you just start it. You're not always going to be able to prepare as well as you should, but some preparation is better than none. So the first step, and I'll just kind of run through these from a high level and then we'll dig into them a little more detail.

The first step is to categorize the information system and there's a couple inputs that go into the categorization and you can see them on the chart here. There's the architecture description, so the architecture reference models, the system boundaries is extremely important. So how that system interfaces with other systems and what defines the boundary. There's also organizational inputs that play a role in the categorization. This could have ... It could be laws, directives, it could be how you handle protected health information, like HIPAA, for instance, et cetera. That's the categorization and those two inputs go into that, the architecture description and the organizational inputs.

Then we have select controls. So we categorize our system, we select the security controls for the system, then we implement those controls, then we assess the controls effectiveness. Then somebody makes a decision to accept the risk and authorize a system on the network, and then we want to continuously monitor to make sure that the controls we chose are actually effective. So that's the six steps, and we'll go into a little more detail on each of them. Also, it's important to realize that RMF, as the "F" stands for is a framework, not a regulation. So not ... It's important to realize that because different bodies of the government or defense organizations use RMF differently. They don't follow the exact same methods. The Army may do it one way. The Air Force may do it another way, and even within the Air Force, for instance, two units within the Air Force may do it differently.

So the first step, and this is where we go into a little more information. The first step is to categorize information system, and this is to categorize the system and the information on that system that's processed, stored or transmitted. We typically do the categorization based on the three tenants of information, security, confidentiality, integrity and availability or the CIA triad. This is very similar to a business impact analysis in which you identify critical systems, except a business impact analysis typically focuses on the maximum tolerable downtime, the recovery time objective, and the recovery point objective. With RMF, we're focused on security, so the security objectives are CIA, confidentiality, integrity, availability, and then we look at the impact values and we rate those low, moderate, or high. Remember, risk is the intersection of the impact and the probability.

Then we assign a security category, which is the bottom of the page here. The security category category or SC, is assigned per information type or per information system, and it is designed for the confidentiality, integrity and availability. Those Xs shown here are replaced with low, moderate, or high, and this helps us determine how to best implement controls to protect that data. A little bit more about information types, it's a confusing topic. There are lots of categories or types of information that could be privacy. It could be medical such as PHI, it could be intellectual property. It could be classified information, et cetera, and there could be a law or directive or something that requires information to be protected a specific way. The example we have below here is for Protected Health information or PHI. Our security category for PHI is confidentiality of high.

We don't want someone to be able to steal our protected health information. Integrity of high, we don't want someone to be able to go in there and alter my medical records, for instance. But the availability can be low. It's not like a patient has to have their records accessed all the time, and these could change based on the use case, but this is just a general example. The next step is selecting the security controls. This is defined by NIST 800-53. The latest revision is five. In this step of RMF, we're selecting an initial set of baseline controls for the system based on the categorization classification we did before. We want to consider tailoring and supplementing the baseline set of controls based on risk or local conditions.

An example would be if this were a weapon system, for instance; let's say it's a a drone aircraft. We would have a baseline set of security controls for that drone aircraft, but if that drone aircraft flies to an enemy territory, depending on the enemy and the country it's flying in, we may need to add additional controls. That's the local condition we're talking about. At the bottom here, this is an example, an excerpt of the families of controls in 800-53. So this is what you would choose for your security controls.

Step three is very simple. You implement the controls that you chose in step two. You also want to document how you implement them. Step four, you assess the controls. You've categorized the system, you've chosen some controls, you implement the controls, and now you want to assess those controls to see if they're actually implemented as intended and producing the desired results. Are they actually reducing the risk? This is a very important step. A companion guide to NIST 800-53 is NIST 800-53A, which gives you some guidance on how to assess the controls that you chose in 800-53, or just assess controls in general. Here's an excerpt for that. This is from 800-53A, and you can see here it tells you how to do an assessment of the control information system backup, and it walks you through this process and this methodology you can apply to any control.

It gives it to you at the very bottom there, which is important, the assessment methods and objectives so you can examine, you can interview and you can test. Typically, when you do an audit you need some artifacts from a combination of those to substantiate the control is actually working.

The next step, step five is to authorize the information system. When we've gone through the first four steps, now we're getting to the point where we know the controls are working properly because we've assessed them. So somebody with the right authority has to make the decision to authorize the system to operate in a normal environment. They are accepting the risk formally for this system.

The next step is to monitor. You need to monitor the security controls. This is step six. Once the system is in operations, it's not like that's it. It's not like a "Set and forget," you have to continuously monitor it because risks change. What may have been a low risk today or a low rated risk could change to critical tomorrow, or if there's a different mission for this system; depending on type of system, if the system has been used in a different capacity, the risk may change as well. You have to continually monitor the controls and make sure they're still effective. Environments change, risk change, likelihood of exploits change. So it's important to monitor this routinely. Typically with RMF, most organizations monitor this once a year or reassess this once a year. I personally think it should be a little more frequent, especially with a critical system.

So this is a summation of what we talked about. This is the picture we basically started with at the beginning. We talked about the inputs into step one, categorization; the architecture description, the organizational inputs. Then we moved on to step two. We're going to select the controls based on how we categorized the information system or information types. Step three, we're going to implement the controls we chose or selected, and step two ... Step four, we're going to assess to make sure those security controls that we implemented in step three are actually effective. Remember step two, a guide for that is 800-53. Step four 800-53-A. Then we're going to authorize it in step five. Somebody formally has to accept the risk that this system can operate in this environment, and then step six, we want to monitor the controls to make sure that they are effective over time and with different conditions.

This process repeats itself, because risk is not a thing you just do once and forget about it. It's something you have to continuously assess. Hopefully you found this video useful. It was just intended to be a quick overview of RMF, which is a framework, not a regulation, like we talked about. If you have any questions about the video, any comments, any suggestions or would like a future video, please leave it beneath this video. Also, please subscribe to our channel. We also have a class on the risk management framework. It is the Certified Authorization Professional class. If you're interested in learning more about risk management framework and this whole process, the class is a four day class. I will put the link beneath this video. Thanks, and have a great day working with the risk management framework.


Christian’s shadow during a hike in Utah

Christian Espinosa is Alpine Security's CEO/Founder. He holds over 25 certifications, including the CISSP, CCISO, and PMP. Christian is a US Air Force veteran with a BS in Engineering from the US Air Force Academy and MBA from Webster University. Christian holds multiple patents on cybersecurity attack and defense. Major recent projects include penetration testing and assessments of commercial aircraft, medical device penetration testing, and numerous incident response projects. When Christian isn’t protecting us from cybercriminals, he climbs mountains, rocks out to Nightwish, seeks personal development, travels the world, and competes in Ironman triathlons.