Introduction to IT and Cybersecurity
Time
1 hour 27 minutes
Difficulty
Advanced
CEU/CPE
5
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
00:04
Okay, so let's take a look at step for assess security control activities that have to happen here. We want to figure out the extent to which the controls are implemented correctly, Miss configuration or configuring with the fault or basic or non specific or appropriate configuration
00:24
control is only as good as its configurations. We want to make sure that's implemented correctly.
00:29
Isn't operating as it should. We installed It isn't working.
00:33
Uh, isn't producing the desired outcome. Sometimes we feel like one solution. I's gonna work and maybe it doesn't. So we've got to go back and examine that.
00:44
And ultimately, we want to make sure that it supports the security requirements for the system as a whole. And if you'll remember, uh, 800-30 told us we about conducting these assessments, prepare conduct and maintained so again that maintenance peace means ensure that we continue to operate within
01:03
that level
01:04
Now 800-53 A. Remember I said earlier, this is an enhancement document. This particular document is a guide for assessing the security controls in federal information systems and organizations. This is an approach to pen testing. Essentially
01:25
So, uh, again, now, It's not a technical document, but at a high level.
01:30
What are we going to do in order to make sure the security controls that we have in place meet the needs that we just talked about, that they're implemented, right? They're operating as they should and that they're giving us the desired result. So we're gonna look toe 800-53 a.
01:47
Get that information. We're gonna look at this on how we're gonna conduct the vulnerability assessments
01:52
and perhaps the pen tests. So three assessment methods interview examined and then test. So meet with the system owner. Find out the requirements, examined the system itself and then run it through a series of tests as agreed upon by the owner Act
02:12
This point,
02:13
we will have a document called the SAR. Completed the security assessment report Exactly what it sounds like. We conduct the security assessment. What are the results?
02:23
Well, if the results are good, great, we'll move on to authorization. But if the results are bad and, you know, maybe bad is is not the correct term. But if we find that the system does not meet our expectations and one way or another if we've discovered a vulnerability,
02:39
that's where the poem comes into place. The plan of action and milestones,
02:44
That's where we go and say, Okay, here's a particular vulnerability. Here's how we're gonna address it. Uh, here's the date that it should be completed and hear the objectives along the way that we will meet in order to accomplish those goals. And we will also go back and update the system security plan again
03:02
as we continue to move through.
03:06
All right. So let's look at this star. Uh, what is in the security assessment report? Well, the results of the security control assessment again, we document what we found and that becomes part of the sore. What we will do is implement. Is it correct or not?
03:23
Is it implemented correctly, operating as intended, producing desired results? You're seeing a trend there. I know.
03:29
Ah, And then ultimately, what do we expect? How are we going to correct it? If we found problems, what do we think should happen?
03:38
The Security Control assessor is the role that's responsible for accomplishing this piece. So as a result of vulnerability in the pen and test essentially what we're looking to do here if you're familiar with the term certification and accreditation and, you know, we're trying to get away from those terms per se,
03:57
but what we're really doing is a technical evaluation
04:00
off the system in a given context. We used to refer to that as certification, and that's what we're doing. Technical evaluation of the product in a specific security context. And if that's the case, then it becomes certified. It meets our requirements. If not, then we move forward.
04:19
We get some corrective actions in place. We fill out our poem,
04:24
and we have an approach to move forward either way.
04:27
Okay, Now, again, this plan of action and milestones document, Um, what are we gonna do? They are specific to vulnerability. So it's not just a broad, sort of, you know, ideally, we'd like to move this system towards this direction very particular. And each vulnerability would be addressed.
04:46
Hey,
04:47
um,
04:48
correct vulnerabilities in the system or deficiencies and reduce those vulnerabilities as much as possible again. When we talk about risk, you can't eliminate it. So what we have to figure out is what is our reasonable threshold of tolerance when we do put our mitigation strategy in place.
05:08
Can we live with the amount of risk that's left over?
05:11
And again? This goes back to the information system owner so you'll see the same roles come up again and again now, Like I said, you'll have that poem that will direct you on what to do if the system did not meet the certification requirements, the technical testing. However, if the system did or
05:29
it didn't, you applied the steps of the poem re test. And finally, it does meet the certification requirements. We then move into authorising the information system we use defer to refer to this piece of certification. And this is accreditation again. Get away from some of these terms. But ultimately what we're looking at here
05:48
is we're gonna put this system into production
05:50
into the element for which it was designed. So at this peace, we've got to make sure that
05:58
we review the information from the security assessment, the sore, the security assessment report. We look at the risks we think about the organization as a whole and how it's gonna continue to support the mission off our organization in its business processes. And we move forward. So
06:15
step five authorized information system is really Maur management geared.
06:20
Uh, and by that I mean it's past the technical certification process. The security requirements have been validated. Now it's up to senior management to make a decision. And at this point in time, once they authorize the system and we'd be looking at the authorising official
06:41
once we
06:43
reached this point the ao authorising official, except all the risks associated with this product. So even though it's past the technical evaluation, there's still some things that that senior officers want to look at as well as the information system officer.
06:59
So, wanna look at the plan of action and milestones? Let's go back and let's find out what vulnerabilities existed. Let's make sure that we met the plan of action. Let's make sure that it was verified that our actions corrected the vulnerability or at least mitigated the risks associated with that vulnerability as much as possible.
07:18
There's also a package called the security Authorization package will look at that over in the next slide. Essentially, it contains some of the documents, the documents we've already talked about these air, the pieces that the information system owner does. They go back and they look at these elements
07:35
and then ultimately we turn it over to our authorising official or authorization official.
07:41
And they're the ones that look at the risks and they say, Yes, we're gonna accept the risks associated with this product. Let's go ahead and put it out into production. Alright? So that security authorization package really consists of the system security plan. Remember, that's
07:59
the security requirements
08:01
and all the information that's been collected and updated as we've moved throughout the phases. The security assessment report. So that's the result of the vulnerability assessment. The penetration test looks at the poem, and all those documents together are called the SAP Security air system authorization package.
08:22
So the information, uh, system owner
08:24
looks at that.
08:26
Now we move on to the risk determination. Exceptions again. That's the authorization officials roll the authorization official or the designated representative of the A O is gonna produce a decision later.
08:41
Ah, yes or no. Essentially course it's gonna be more formalized than yes or no, but that's ultimately, when it comes down to, it will state the accreditation decision, and it will give the rationale. This is why we chose to move forward and accept the risk. This is why we chose not to also terms and conditions for authorizing this system.
09:00
A system very well may be authorized
09:03
toe work in one environment, but not in another or under one set of conditions or not another or toe hold one classifications of data, for instance. So all of that information would be included in the accreditation decision. Letter comes from the A. O or their designated rep,
09:20
And that leaves us two. Leads us to the final stage of the process where we monitor the security state off the system,
09:30
continuously tracking changes. This is where configuration and change management becomes so very important. We have implemented this system. It has passed our technical evaluation. Management has approved it. However, things change. The system may need to be updated. May need to be patched.
09:48
There may need to be modifications.
09:50
We have to make sure that there's a thorough process to control changes to the system, and we need to continue to make sure that it operates within the level of acceptable standards
10:03
here. We're gonna make sure that we monitor the controls on the system and the operation on an ongoing basis, which should be specified. That shouldn't just be sort of Ah, let's look at this thing. Now we should specify that as part of our configuration and change management strategy
10:22
Ah, we want to make sure that it continues to make compliance toe legislation,
10:26
executive orders, directives, policies, regulations and standards Basically, that we stay in compliance with as relevant to this particular system, 800-1 37. We really didn't talk about that. But this particular this document is gonna tell us exactly how
10:43
we conduct the continuous monitoring
10:46
and what the requirements are for these information systems off the federal government. The goal here is to produce an I S C m strategy, information security, continuous monitoring strategy and that we have a program in place.
11:05
And if you look at the next slide,
11:07
what are the processes in configuring this system? Define a continuous monitor monitoring strategy. That's a good place to start, right? What is our strategy? How are we going to approach this? And of course, that's going to go back to being driven by the category of the system.
11:24
Looking at the threats and bolt vulnerabilities. Theus assessment All of those elements that we've done.
11:30
So we take all of this information that we have collected, we go back and we look at the system security plan. We look at some of the information from our risk analysis and our risk assessment processes, and we figure out what the metrics are,
11:48
what are the frequencies and develop this? I s C M architecture. Now let me go back in stress to you is that we have considered this information from the get go. Remember back when we said, categorize the system than select security controls.
12:05
And we talked about selecting security controls that would allow us to plan for continuity of operations
12:11
that would allow us to plan for monitoring and so on. So it's not like we've created this system. It's out in the field and then we go, Oh, we should monitor this thing. The beauty of our M f is every step along the way. Security is our goal. So we planned for it. We build it,
12:31
we test for it and we monitor for it.
12:33
So all along the lines everything we've done has led up to this stage and to this stage continuing to be successful and at the point where it's not being able to correct and modify those changes. OK, so we should have a clearly defined plan for
12:50
the continuous monitoring off this system.
12:54
We want to make sure that we collect in, UH, security related information that we're able to respond to them effectively using the standard risk management techniques. Avoid risk transfer except risks reduce risks however, that may be, and that we continue
13:13
not just to monitor the system,
13:15
but we also monitor are monitoring policy. You monitor your monitoring if you will, but the idea there is as threats in the environment change, we may have to monitor more frequently when we make a change in response to a threat. We've gotta monitor and make sure that we continue to maintain our security posture.
13:35
So these are some guidelines for setting up in information security, continuous monitoring program,
13:39
just kind of bringing this all together. The risk management framework is specifically designed to help us again, going back to what we've said all along plan,
13:52
build, test,
13:54
implement and monitor a secure system. Okay, so six stages of the risk management process are all about taking our system development process, system development, life cycle and making it secure.
14:11
So ultimately, when we talk about the system development life cycle,
14:16
it's the stages we go, too. If you were a project manager, these would be the phases of the system development life cycle. You would start with initiation.
14:24
Initiation is usually about gathering information. It's usually about getting authorized for your project. It's getting some high level plans.
14:33
Then we go into designing the system. Then we actually develop or acquire the system. We implement those elements that we've planned for. It goes into operations and maintenance and then to disposal. So ultimately, what we want to do is we want to take the software development life cycle
14:52
and make sure that we understand how to implement the risk management framework
14:56
on top of this life cycle. If you will now miss Special Publication 864 rev to give us security considerations in the SCLC, so it doesn't matter this toe r m f. But it does tell you in each of the stages some things that you have to consider from a security perspective.
15:16
But if you really want to get a view for how this is important and where it kind of comes together.
15:22
What you have is you have the SCLC essentially initiate design, implement operations and maintenance and then disposal, never forgetting that secure disposal is every bit as important as any of the other elements. And you can see where the steps of the R M F fit in.
15:39
So what? The very initial process. What are you doing? You're, you know, from a risk management perspective you're identifying in evaluating your assets. So you're gonna categorize the system so that you understand what the requirements are gonna be in. Initiate
15:54
now with design. That's where we select the security completely controls. We're not putting them into place, but we're taking our categorization. We're looking at the value we've assigned or associate id the category of the system and figuring out how to protect the information in the system. Appropriately, we implement those controls
16:12
and we assess them
16:15
because we put him into place. Then we custom Before we would ever authorize a system, we would authorize that system. It's the final piece of implementation. And once it's authorized, then yes, it goes into operations and maintenance.
16:29
Then, of course, ongoing monitoring and, when necessary, a secure disposal. Hopefully, um, this has made meaningful to you the steps of the risk management frame. Or we have six steps categorizing information, selecting our controls, implementing those controls,
16:48
assessing our controls,
16:48
authorizing the system and then monitoring. Ultimately, what that comes together is to give us through the information in this particular lesson. Why we need the IMF would earthy regulations. And what are the drivers for the risk management framework, how we go about implementing it,
17:07
and then how we tie that into the software or system development life cycle.
17:11
I hope this class has been helpful for you again. Do consider looking at some of the other lessons that we have the CSS LP for Secure System Lifecycle practitioner
17:22
and also think about the sea risk for more information in risk management. Also, his conclusion of this class. I want to thank a good friend of mine, Kenneth Magee,
17:32
who's the president and owner of data security consulting and training and his email address and phone number very knowledgeable in our EMF and was gracious enough to provide some input for these slides. Thank you. You can. And I hope that this was helpful and meaningful to you all
Up Next
Applying the Risk Management Framework NIST 800-37a
The National Institute of Standards and Technology (NIST) established the Risk Management Framework (RMF) as a set of operational and procedural standards
Instructed By
Kelly Handerhan
Senior Instructor