The Risk Management Framework - Part 1

Video Activity

In this lesson, Subject Matter Expert (SME) Kelly Handerhan discusses NIST Special Publication (SP) 800-37, "Guide for the Security Certification and Accreditation of Federal Information Systems", that was created as part of NIST's responsibility under FISMA to develop standards and guidelines for the requirements and process steps for the certific...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

1 hour 27 minutes
Video Description

In this lesson, Subject Matter Expert (SME) Kelly Handerhan discusses NIST Special Publication (SP) 800-37, "Guide for the Security Certification and Accreditation of Federal Information Systems", that was created as part of NIST's responsibility under FISMA to develop standards and guidelines for the requirements and process steps for the certification, accreditation, and monitoring of information systems. Handerhan explains the use and usefulness of other NIST SP documents in the RMF process. You will learn: - the six Risk Management Framework (RMF) phases - the role of the Information System Owner - when and how to create and update the System Security Plan (SSP) - how to develop a Plan of Actions and Milestones (POAM) to document weaknesses and vulnerabilities and to set mitigation milestones - how to develop a Minimum Security Baseline (MSB) - how to select and implement security control activities - documentation requirements and methods - contingency planning for federal agency systems' continuity ("systems" goes beyond just computer systems) - how to develop a Business Impact Analysis - the three phases of continuity - the differences between recovery and reconstitution - rules and responsibilities of the incident response team in a contingency environment - incident analysis and returning to an operational state - understanding and using the "plan, do, check, act" model THE DISCUSSION OF IMPORTANT RMF DOCUMENTS AND USING THE RMF CONTINUES IN LESSON 2.

Video Transcription
All right, so let's go ahead and move on to part two and let's get into mist 800-37 in the risk management framework. The big piece that we're gonna look at us, we're gonna look at step by step the six elements. Ah, step one. We're gonna categorize the information system
and just going back to the previous section. You know, that we're gonna use Phipps 1 99 We're gonna use Miss
Special Publication 800-60.
We're gonna then move into selecting security controls. We're gonna implement those security controls, assess them, authorized the information system and then monitor the security controls. Ongoing monitoring so important. And then in this section, we're going to just tie it all together by looking at how
that would affect us in the system development process.
So let's go ahead and get started. This is just a visual off the risk management framework throughout. Ah, and it would matter to the security life cycle, as specified in this state 100-39. But what you can see is we start with categorizing the information system
again. Risk management will always start with
identify, evaluate your assets So in this first piece, we're gonna define the criticality or sensitivity of information. When we talk about criticality. Normally we're talking about time sensitivity,
eso, for instance. How much money do I lose for every hour this process is down.
That's what we would be looking at with criticality with sensitivity. We're usually talking Maura about privacy and a loss of confidentiality. All right, so we're gonna determine the criticality and sensitivity of our information system according to worst case,
uh, and how this would affect the impact or how this what the impact would be
to our mission or to the organization or businesses a hole. So we're gonna focus here, but you can see visually, the entire process is
all right. So Step one categorized the information system. Anything that provides value to your organization needs to be protected and secured in some way or another. The amount of value that it provides to the organization, along with the threats and internal vulnerabilities
would drive that amount of security, of course, to be higher.
So when we talk about its value, the things that we also think about magnitude of harm and probability, you know, getting these go back to those elements of risk, right? Probability, impact. So on. All right,
Phipps 1 99 was where we got the information on categorizing federal systems.
And remember, we looked at the C I A triad in relation to low medium high. So what would be the impact if there's a loss of confidentiality? What would be the impact loss of integrity and loss of availability? And then we use that and aggregated to get the value of the system as a whole.
And then we go to nest 800-60
to figure out how we're gonna map the security controls to those particular categories, the person or the individual. Let's actually say the role that would be responsible for the first step in the R M F process is the information system owner. It's the owner's job to categorize the system. They're the one that
they're the ones that own that system that should be most familiar with that system
and should be able to identify the value internally of the information there. There are various steps that you would go through in order to categorize the system, and again, this kind of pulls from 1 99 and 800-60. But the first step we're gonna figure out is what type of information
they're different types of information is a single type.
Um, is it processed on? This system is stored on this system. Does this system forward? That information is it used to transmit? Ultimately, we have to figure out what pipe
the second piece that we have to do is we figure out the impact values.
Third, what is the security categorization
and then fourth, What is the overall impact level of the system from highest across the three objectives? Remember that idea? The high water mark. So even if availability, for instance might be rated as low if there's, ah high impact for confidentiality, the system as a whole would be
considered to be high in this particular process. And one of things we're gonna talk about with the risk management framework
will be creating some documents. And what do these documents do? Whether they created, what do they look like? So the essential heart and soul of the risk management framework is a document a document called the SSP, the system's security plan.
This is a document that gets created in step one and is updated all the way throughout all the way up through Step six where we're monitoring. So this is a living, breathing document that is continuously updated.
So in the system security plan Ah, the first piece is that the security requirements or the purpose of it, is to summarize the security requirements for the system based on its category. Okay, so it's a high impact system would, or the needs that we have in order to secure it.
What are the controls that are currently in place? Because often you're applying this Orin F not to a system that's being developed, but maybe to a system that's already in use that's already out in production, for instance. So are there security mechanisms that are in place already? Are there some that are planned?
Then we have to look at the initial risk assessment
again, going back to the assessment. What is it worth? What are the threats? Vulnerabilities? What are the probabilities and impacts will do that, using both qualitative and quantitative analysis and ultimately, when we use that term assessment, so risk assessment and privacy impact assessment,
ultimately, what we're looking to do is come up with the value
now again. Qualitative values where we start. But what we're really looking for is a quantitative value that's numeric based. That's objective. It's It's rooted, in fact, because that's what will make our mitigating strategies. That's what will make our decisions on. Okay,
other things that we have to consider that are part of this SSP and let me just stress the SSP is created in Step one, but it's not completed. So in step one, we're not necessarily doing our contingency planning an incident response planning that's coming down the line. But these would all be elements
off the SSP, so we're just getting started here.
All right, we'll talk about interconnection agreements. Maybe we are partnered with another agency and their systems connect to our network and our network or our systems connected their network. We have that interconnectivity. We need an agreement to define the requirements there,
and once again, the information system owner is going to have is going to be the role that's responsible for creating this SSP. Something else that gets developed here, although not really updated, is the poem which stands for Plan of Action and milestones.
Now, we'll look at these a little bit more as we move along later, because we'll really start to use this, especially when we start doing assessments.
But what we're gonna have is we're gonna have a plan of action in milestones that ultimately is gonna address specific security concerns and help us express a plan. Ah, plan of action, as a matter of fact, but it's gonna help us address how we're going to approach these vulnerabilities.
So ultimately what you can see is this is the essential structure of a poem.
So it's gonna be on a weakness or vulnerability by vulnerability basis. So what do we have to do? We have to make sure that when we identify a weakness or vulnerability that gets documented,
who's responsible or actually accountable was a better word to use because that's ultimate accountability. Uh, how many resource is air necessary? We talked about the idea of milestones. So we're gonna schedule a completion date when this should be resolved and the milestones air those significant steps along the way
that will lead us to the completion of the resolution. So
will set out milestones, which really you're just significant dates, timelines that we want to hit. And then if there are any changes to those milestones, why document? And again, this is a living, breathing document. We're gonna continue to update it throughout the process. Ah, where was the weakness? First identified. And where is it?
What phase or what? Stage in the process our way.
So this document has created it addresses particular and specific vulnerabilities and what we're gonna do about him. What is our status status? Whatever our objectives and goals to meet. So we'll develop those in step one, categorize the system, but we're not really gonna use them and update them
until we move forward a little bit.
Although let me just say you can detect a weakness at any stage of the risk management framework processes, right? I mean, even very early on. Like we said, this might be a system that's already out in production. So when you go to even step one, categorize the system
you might realize, Wait a minute. This is a higher category that has initially been assigned,
and it's vulnerable based on what it's covering. So even though our primary focus is not the poem in step one.
It can be updated. It should be created. We've categorized the information system. We know what the value of data is that should be produced. We have the value of the system, if you will. We've categorized it. The next thing is based on that category. We have to select the security controls. What do we do?
Have a high value system. How do we protect it
here? Our purpose is gonna be to determine that Msb again. That's a term we talked about earlier. The minimum security Baseline Minimum security Baseline. What is the least,
uh, or the lowest amount of security? That is acceptable, right? Remember we said our baselines, air starting points. This isn't where we want to be necessarily. But at the very least, this is what needs to be applied.
We're also going toe update the SSB here because we're going to figure out what controls are the controls in place sufficient? Great. That still gets documented or new controls necessary. And they very well may be so essentially here. We're still in the planning stages of figuring out Well, where should we go?
So once again,
we take the input of the SSP which was created in security. In categorized the system,
we update it more to include suggested controls. Now, when we're figuring out the minimum security baselines, we have to take in mind that the environment which it operates is hugely important.
What is the organization as a whole? Do
what sort of functionality is necessary because again, there's always a trade off of functionality or performance and security
threats and vulnerabilities. Right? And think about it from an organizational process
or an organizational standpoint,
business process standpoint and information systems standpoint. Remember the multi tiered architecture we gotta think about it from organizational perspective, process, perspective and individual system perspective.
And again, what information is on that system?
Is it stored permanently as a temporary? Is it transmitted through a system? All of these elements will play into the baseline.
We're gonna use the system security plan. We're gonna update that we may continue to update the poem, right, Because again, we're looking at security controls, and we may once again identify that a security control currently in place is vulnerable or perhaps even a plan. Security control
may be vulnerable,
so we're gonna continue to update the poem. Uh, this particular step, we would go back to the Phipps 200 missed 853 again to provide us guidance. Okay, Now, the activities that will accomplish as a result of step two,
we're gonna figure out the common control identification again.
Is this a common control? Is it a system specific? Control is a hybrid control. Remember, the big difference there is in heritability. If it's an inheritable control, it's considered to be a common control. All right, then we're going to figure out what security mechanisms we're gonna put in place
to accomplish in to meet that minimum security baseline.
Uh, also at this level. How are we gonna monitor? We're not doing the monitoring at this face, but we are figuring out how we're gonna monitor. What are some key metrics that we're going to examine? How are we gonna met? Monitor. How frequently
are we gonna monitor? What tools do we have it at our exposure?
What are the results we expect from monitoring? That's gonna be clearly defined. Here it Step two. And then finally, we're gonna take that system security plan, and we're going to get approval for that document because right now, it should be completed. We've categorized the system and we've selected our controls.
the desired result is the approval. But that may not happen. So if it doesn't happen, if it doesn't get signed off on, then we go back and we examine the issues. Maybe we go back and we look at our poem and we find out what vulnerabilities kept this from being approved. How we can make those changes
because ultimately, the desired result is the SSP.
All right now they have approved our system security plan. Um, what we're gonna design looks good. We got our plan. We got sign off from our authorising official or his designated representative. Now we're gonna implement. Now we're gonna build the security mechanisms into the product
into the system itself.
So all the controls that we've found planned for this is where we build them. Remember, we plan for security now we build security, we cast to make sure it's secure. We authorize on whether or not it's secure and we monitor to make sure it continues to be secure.
Every single phase of risk management framework
revolves around security. We cannot build a secure product if we haven't planned for the security of the product. Also, if we don't build it inherently secure, then we're not gonna be able to get a good assessment. Leading authorization. Once again,
I have to stress the importance of designing a secure product
rather than designing a product and trying to make it secure later.
All right, so implementing the security controls off course, we're gonna implement the controls we've planned for. But also, this is where we document I'm gonna say that word again. Document? Because we tend tech hate to document. But obviously, a very important part of this process
is that we document the decisions, the design
implementations. We go back, and we update that system security plan again. That S s P may have been completed at the end of face, too, but we continue to update as necessary. So we're going to document our plans. What are the details? How are we gonna do it, right?
Not just we're gonna implement security, but what does that mean? And how is it actually accomplished?
what we're going to do after we talk about the our EMF is we're gonna take the IMF and map it to the system development life cycle because that's what really gives all of this meaning until you use this in development of a system, it's it's all just theory and concept.
So ultimately, we're going to make sure that the R N F shows us how to implement security throughout
tons of publications that are available. I don't know that we've addressed Missed 800-30 and 70. I don't think we have because it really is a more technical document that talks about it. Specifically is a checklist for developers programmers
to make sure that the actual technical security requirements have been implemented. So
that's a little bit more of a technical document. There's also 800-1 60 not to be confused with 800-60 which we've talked about, but this covers the system security engineering process is, um, it's a very, very valuable document. If you are a system security engineer,
I would also mention that we, uh,
do provide a class called Certified Secure System Lifecycle practitioners, C. E S S L. P. And I don't know if that's one that you're familiar with. The same organization that puts out the C. I S s p exam, which is I s C Square. They have put out the C E S s L. P.
So the idea is to be basically, it focuses on
exactly what we're talking about here, implementing security throughout the software development life cycle. But in that particular class, it focuses on the actual engineering aspect. So it is a little bit more technical, perhaps in a risk management framework class. So there's another commercial for you.
All right, so a little bit more technical document. And I think I said that you'll be completed with the SSP previously. Honestly, you continue to update it. You would really haven't formalized here. As far as
you're not putting anything new, you're just updating. I don't know if I explain that well, but ultimately, between the last two phases we're working on Consolidated is consolidating and being complete. Missed 834. Revision one
Contingency Planning guide for federal Information systems.
This is another document that's very, very important for the particular step of implementation.
Because again if during the design and the implementation of the controls, you don't plan for unfortunate circumstances, you don't provide a means of recovery or a means of howto handle a violation of the system security policy. Or, um,
you don't have, uh, means to address continuity issues, whatever that may be. Ultimately, if you don't implement those into your design, you're gonna find that they're not as effective. So when we look, ATT missed 800-34. This specifically deals with contingency planning
and contingency planning.
You know, again, a system doesn't have to just be a computer. We could talk about an agency as a whole, could conceivably be a system.
You know, a network could be a system, an enclave could be a system. So don't just think about a computer system. You know, the definition of system really is just a connection of inter related elements working together. So, you know, that could be a very broad definition.
But one of the critical pieces that we have got to think about is continuity of operations,
a za matter of fact, Um, just coincidentally today I was just reading the news, and one of our major airlines has been shut down and been offline for about five hours due to computer glitches. So no planes leaving. Um
our um,
New York Stock Exchange has been shut down because of computer glitches that, as of right now, have been deemed to be unrelated. We'll see where that goes. But the bottom line is regardless of your plans, regardless of the defensive mechanisms,
there's always the potential. There's always risk that's left over.
So what happens? What happens if we're unable to generate income for five hours, or for five days or five months or whatever? What happens if the's systems that are critical to a mission out in the field are unavailable? We've gotta have that contingency planning in place. So
within this document it talks about something that's very essential
business impact analysis that should be part of every continuity strategy. And quite honestly, it is the most important piece of any continuity strategy with the B I. A. Does is it identifies and prioritizes
systems based on criticality.
I'll say that again because it's such an important definition. It identifies and prioritizes systems based on criticality.
Now, a couple of things, first of all, it identifies
everything I didn't say identifies critical systems, I said. It identifies systems everything. What I try to say is any time you're doing an assessment. Always start with identifying. Identify your assets. First, identify your process is first in the business impact analysis,
then prioritize them.
If you try to just identify what's critical. What you're gonna do is you're going to discount certain elements because they may not seem critical.
Only if you identify everything can you really step back and taken objective. Look as to whether something is critical or not. You know, I can't tell you how many times that I, as a cz being involved with business continuity and recovery processes, have looked at something and said, Oh, that's not that important that can wait
yet to have another department tell me that their operations will be suspended without that piece of software or that system or whatever. So the point I want to make is the first step with your B I a identify,
then prioritize
the next thing business processes and systems. It's not an I T specific requirements. This part of your business continuity plan. It may not be all technology driven, so think about the processes that going place, and then the last piece you identifying prioritize based on criticality
criticality has to do with, um,
again? Time sensitivity.
What do we lose? The longer that this element is gone?
If this system is down, what does it cost us? Sometimes it costs us money.
You know, I read some estimate that for every 15 minutes Amazon was down, they lost upwards of $2 million. Don't quote me on that. I can't swear that's accurate. I just came across that and it stuck with me. That's a very critical service, right? Their web presence is essential to them, is very, very critical.
But it could also be damage other than financial. You know,
out in the field, I've got a mission critical system that becomes in operable. We could look a loss of life, confidentiality of information. So, you know, it doesn't always have to be dollar amount. But that business impact analysis lets us know what systems we have and how critical they are to us.
All right, then, when we talk about continuity, three phases of continuity,
activation and notification, which simply means we need to get into the process of continuity. Now we've had a breach. We've had a failure. We have had some element that moves us into phase one. Okay. And if we're in phase one of disaster or continuity,
how do we notify our staff?
And how far? Just because we implement phase one doesn't mean we're going to do face two and three and four and so on. So notification would essentially say, Look, we're gonna implement our continuity process through face three, whatever that may be.
Now recovery is always about restoring those most critical elements that were identified in the B I. A.
So recovery means getting most critical back online
reconstitution means giving us back to a state of permanent operation. Sometimes in recovery, you're using duct tape and band aids, right? We're just trying to patch this thing together to get what's critical back running.
But we're still in ah, hobbled state, right? This isn't where we want to operate.
The emergency is on Lee over. Once you've completed reconstitution,
everything's back
back to a state of permanence.
Now, roles and responsibilities do not forget how important it is to clearly delineate out the responsibilities of your team, and often you want to get sign off. You want acknowledgment that if individuals who is responsible for restoring this system
and we might use a memorandum of agreement just to say We're of understanding to say, Look, this is my expectation for you
in the event that we're operating under some sort of contingency environment. Sign off on this so that there's no misunderstanding would be very clear again. You know, whether it's continuity for individual systems or for an organization as a whole, this is essential to the long term help
we've seen time and time again. Disasters, knockout critical infrastructure destroyed businesses. And it could be as basic as the loss of one business process taking the entire business down. We need to be very aware of that. And this is part of what we have to plan for and then really
implement for in Stage three
now, also very closely related because often contingency plans are initiated from a security incident. But nest 800-61 revision One talks about how we're gonna handle and respond to incidents in our environments. A so preparation,
detection and analysis
contain, eradicate and recover. And then what we do post incident. So first thing we have to do is figure out we're in an incident that could be violation analysis. Step back.
You know, many times what could appear to be malicious is just a normal function that maybe isn't common. Could be an accidental access, or it could be a wide variety of things. So we have to step back and make sure that we have the means in place to detect and analyze. Then,
okay, we'll figure out this is an incident. Maybe this is a cyber attack of some nature.
How are we gonna contain it? Will stop the bleeding. Let's limit the scope of this attack.
Then let's eradicate or get rid of the source.
And then let's get back on line back to the state that we were
so important. Once again.
Document, document, Document. How did this happen? Well, if we know how it happened, that will bring us one step closer from four to preventing it from happening in the future.
incident handling is a complex
um essential part to any organization. It cannot be entered into lightly.
You need a well qualified incident response team. They need to have a well defined set of procedures and processes in place.
None of this is going to be done well without the first piece, the preparation. And I think also I would add to this.
There's a team of people that should respond to incidents and everyone else should not. We need to make that very clear, especially if you're thinking about collecting evidence, maybe to present in court. And even though it may not appear that that's necessary, you never know
would've breach will tell you. You know, you look in and think OK, well, this seems like improper access, No big deal.
But then the deeper you dig, you can find out. Maybe there is criminal activity. Your incident Response team should be trained in such a manner that they know exactly how to do the investigation without destroying or corrupting the evidence. Normal users do knots we wanna have, in addition to the policies of how to collect this evidence
what to do.
We also want to make it very clear what other users the untrained users should do if they suspect that an incident has happened. And normally what that should be is called the appropriate parties. They can document what they've seen, but I certainly don't want,
you know, John Smith off the floor, going in dusting for fingerprints, right? So we have to be very clear
in our response again. We have to plan and implement elements that will help us with these procedures. We can't look at. This is an afterthought. We have to before thinking, which is why this is listed under the implementation phase. Now,
after we implement the controls,
did they work? I don't know if any of you forked with project management or with quality management. There is a plan, not a plan. It's a It's a model created by W. E. Dimming, and it's called the P D. C. A model. The plan Do Check Act model.
And it's very important because it really applies throughout, whether it's quality management, security, management, whatever.
But you can see the plan Do check Act model here plan the 1st 2 pieces Do
check to see if it worked and then act upon it if it worked, authorized and then it goes into monitoring. If it doesn't, you go right back into the planning pieces. So the plan do check out models very appropriate here. So from a Czech perspective, now we're on to Step four, which is actually to assess the security controls
that we've implemented.
Did it work? Are they effective?
Are they operating as intended? Maybe we haven't had a breach. That doesn't mean that things were implemented properly.
Do they meet the security requirements again? This is the verify part. This is where we do our vulnerability assessments and our penetration tests. Because ultimately what we want to be able to say is we planned the controls. We implemented them well. They stood upto are testing.
This system is ready to go.
Let's sign off on it. Let's move it the operations and continue to monitor.
Up Next
Risk Management Framework

The National Institute of Standards and Technology (NIST) established the Risk Management Framework (RMF) as a set of operational and procedural standards or guidelines that a US government agency must follow to ensure the compliance of its data systems.

Instructed By