all right now, uh, missed 800-53. Revision forthis is a big one. Don't forget. In a little while, we'll also talk about 53 A, which is an enhancement to this. But right now, just focusing on 800-53 revision for
specifies several different elements in this particular special publication adresses security
and privacy controls for federal information systems and organizations. So that's a very broad idea is we've got to figure out the controls to put in place for our federal systems. So it addresses five essential concepts having a multi tiered risk management approach.
And I talked about this a little bit. We'll see this more crossing it the upcoming slide.
Then we'll talk about how security controls are structured. We'll talk about that minimum security, baseline
the designations of our controls. And then also just a reference to external service providers as well. S o this revision four was published in 2013. All right, so let's go ahead and jump into the idea of multi tiered risk management.
And again, I mentioned this earlier, and the idea is that when we're looking at risks,
we have to think about the organization as a whole, we have to think about individual missions which uphold the organization as a whole. And then we have to think about the individual systems that support the missions that support the organization. So when we look at the top tier
ah, the organization has all of our business and functions.
Ah, that ultimately, the thing about at the top, this is what drives our investment strategies and funding decisions. This is our Is the company gonna make it or not? Where does our company want to be? Strategically in five years? This is really the steering of the organization
right? This idea is we're looking at risk from an organization as a whole how to get the company to that next level, so to speak.
All right, now, the second tier, the mission and business processes themselves that support the organization as a whole. So when we're looking at these processes themselves, the first thing that we've gotta do is define with those processes are determined. The security categories, you know, was the impact,
uh, that the loss of these processes or
what impact would happen if these different elements were compromised
then, based on the categorization, the information is going to drive us to figure out again the idea of the baseline. What are the minimum security requirements that need to be incorporated into those elements? And how do we develop an architecture that will enable us to incorporate that security?
So when we look at the second tier, we're focusing on individual processes
within the organization as a whole, and in the third tier comes down to the individual systems,
so the systems are necessary to support the processes, but the process is thin, in turn, would support the organization. So the idea is, when you're looking at risk, you have to understand how the bottom tier effects the second tier affects the cop to you, right? You have to understand that
if all you're looking at is the top tier in the strategic directions and governance of the organization,
all of that's well and fine. But without individual systems and missions within the organization processes within the organization, it's not gonna happen. So ultimately, this three tiered approach is one of the things that missed 853 revision, four gifts. It's the next thing
n'est 800-53 describes the structure
off security controls, so ultimately the structures are well defined. I had mentioned earlier from Phipps 200 they listed out 17 families will now missed 800. Dash 53 extends that toe 18 families,
and in those particular families you'll see that they've added program management. But if you'll go back,
so what we saw before from Phipps, the exact same, uh, families were listed, and they have to character identification. And then, ultimately you'd be ableto take the security controls and, ideally, map those two baseline requirements based on each of those families.
All right, so now we look at the baseline controls or the control baselines. Rather, when we talk about a baseline, a good definition for a baseline is a minimum acceptable security configuration.
Obviously, we can tack on additional security is needed. But before a system that's placed in a certain category would connect to the network, for instance, the baseline security configuration has to be installed, has to be configured. Okay, so
when we talk about this, that's always a challenge for organizations. Is
figuring out what are those baseline settings? What are those baseline configurations and the fact that as risk continues, thio,
uh, fluctuate within the organization and again, his new risks appearing As the environment changes, we have to go back and assess our minimum security Baselines. What was good for yesterday is not gonna be good for tomorrow.
So ultimately, uh, nest 800. Dash 53 is going to give us some guidelines. They're gonna give us some guidelines on how we get started with this process. And you can also think of bass lines as that Our starting point, What is the basic security configuration we're going to start with?
And then we can assess
controls. As we move on,
you will get a thorough definition off security baseline configurations in this document that we're discussing this State 100-53 revision for but appendix D, as in Delta is all about the security baselines. That's something that you might want to dig into a little bit more in depth.
The next element Security control designations, uh, per missed 853. There are three designated types of controls. Their common controls, their systems specific controls and there are hybrids controls.
So common controls are those controls which could be inherited. Like, for instance, let's say that we have in our server room we have an environmental control that requires a sistah that the environment stay at a steady
50% humidity. OK, so that would be an environmental control in a specific area. That's a common control, because all of the systems that would be in that location would inherent that inherit that control
from the room environment, if that makes sense. Ultimately, when you think of common controls, those are ones that are inherited physical security,
you know. So this room requires, uh, biometric scan before entry in addition to physical key and password. Well, that would be inherited by all the systems within that room. So the focus on making it a common control is
whether or not it's something that would be inherited.
Now, system specific controls would be configured specifically on individual systems, would not have that hierarchy. And then again, there's always a hybrid a combination between the two. All right, the final element that will discuss in relation to Phipps 800-53
is, uh, what it states about our external service providers
now to me, this is just kind of common sense. But one of the things we know about common sense is sometimes it's uncommon. So the final element here expressly documents that external service providers that have any sort of interaction or involvement with their federal systems
providing us federal systems or
any sort of element must meet the same standards as the particular government agency for whom they provide work and service. So that's pretty much common. Sense 853 is a big input into risk management framework.
All right, and then we come to 800-60. So this particular nous standard or this publication, rather, is how we're gonna map the information systems to security categories. Okay, so here's what the system is, what category doesn't fall under, and that's what we look to
now. This goes very closely hand in hand with Phipps 1 99
again categorization of systems. So essentially, this is the document we would go to to figure out what our processes and make sure that we have a specific and structured methodology for identifying and categorizing correctly these information systems
again. The level of category, which we assign a system
is very much going to define and describe the minimum baseline security.
Okay, Um, so ultimately, if you want to sum it up, how we're going to get the system categorization based on how we're gonna use it,
what it's connected to
and it's aggregate information content. So
systems, depending on where they're used, obviously you're gonna have a much greater, uh, category of impact a system that's here in the office versus one that's out in the field, perhaps with their our service members conducting battles are actively involved in military strategy decisions.
systems that maintain weapons information. Obviously, a system that's used in that sort of environment will be treated very differently than one that's in an office or agency.
What is the system connected to? The global information grid is huge. It allows world wide exchange of information. So are you connected to the gig? Are you connected to the Internet? Do you have nothing but local connectivity? You know the best way to secure a network computer is taken off the network, so
a system may be categorized if it's local. Stand alone in one way.
But as it's connected to a different element
it might be categorized differently and then aggregate information content. Remember, we talked about that idea of high water mark so we might have information that's highly private, but low availability, low integrity.
Well, that's still ah, high level system based on the high water mark. So all of those elements are going to come into play
and make sure that we use all of that information to a sign of the security category.
Now that's going to sum up the inputs into the risk management framework. Now again, there are many others where elements are taken. Um, the baseline understandings of so many of Miss publications are used as a basis for Orin F. But
these are the ones that I would be most aware of these air
biggest drivers into what the risk management framework does. So again, just kind of a quick review. We have the two Phipps 1 99 and 201 99 is gonna tell us how to categorize systems, and two hundred's going to say OK, here, your categorizations, your categories,
how do you secure based on each category?
Then we move into the special publications where 800 deaths 30 tells us how to conduct risk assessments. 839 gives us. Ansari, 37 tells us how to apply our enough. That's coming up 800 s 39. It's how we manage risk. You know, that's risk management as a whole.
Give us the security controls. Give us a catalogue of security controls. Also 53 a tells us how to assess our systems like vulnerability assessments, which we'll talk about in just a few minutes. And then, of course, we just a second ago looked at missed 800-30.
Um, that goes hand in hand with Phipps 1 99
about mapping these these requirements two categories. So ultimately, what this is gonna lead into is the real meat of the material where we move forward and we talk about what is this risk management framework? Hopefully, in this first part, we've answered why we need a risk management framework
and what documents we're gonna use to establish it
in the next section. We're gonna talk about the six phases of R E M f and how we implement