Okay, so let's go ahead and take a look specifically at 51 99. And as you can see, 51 99 provides us with the standards for the security categorization. And essentially, what we get here is we get the definition of impact is being low, moderate or high. So what we're addressing here is
if we lose confidentiality or integrity or availability,
what would it mean to say it has a low impact, the medium medium impact in a high impact. So it's gonna have a low impact if it has a limited adverse effect.
Moderate is if it has a serious adverse attack effect. And, of course, if the impact would be severe or catastrophic than it's gonna be high, this a good little chart because it kind of helps you understand. Okay, so we've got the three elements of the C I A. Triad confidentiality, integrity and availability.
And then okay, So with confidentiality
to be classified or categorized is a better way of saying it categorized as having low impact. The unauthorized disclosure of information could be expected to have limited adverse effect.
All right, here's what it would be moderate in high so it's a good little chart to help. You kind of keep in mind the levels of impact
Now if it's 90 Not 1 99 also describes a low impact system, a moderate impact system and a high impact system. So again, the idea here is the degree of damage. Now, for a system to be a low impact system to be categorized as low impact,
that means all three elements of the C I A Triad
would be listed as low.
Ah, would essentially be any element is no higher than moderate and high. Any of the elements is high. I don't know if that makes sense, but what this comes that has to do with this something called the High Watermark, which is explained in Phipps 200. But ultimately what it says
the highest degree of impact is the impact at which that system is categorized. So let me give you an example. All right, so we've got a financial company that manages personal financial information, so think about that for a minute. That's gonna be very, very sensitive information.
All right, so we determined that if there's a loss of confidentiality,
that's obviously gonna be very high, right? Personal financial information Confidentiality laws will have a high impact, but also integrity compromise will have a high impact as well.
But we've decided that the availability is only of a moderate impact. So essentially, the high water mark says, whatever the highest level of impact is, that is true for the entire system. So in this instance, and I don't know if you can see the print that's in red,
the confidentiality is high. Integrity is high,
availability is moderate. Therefore, the high water mark states that the system's categorization would be high impact. So hopefully that makes sense. And again, that came from Phipps 200. And this particular standard is all about what are the minimum security requirements.
And let me go back to the idea of risk management, We said the very first step is to identify, evaluate your assets.
Because by understanding how valuable my assets are to me, I can make good decisions on how to protect them. Obviously, if I have a high impact system, I would be willing to spend more money to protect it than a low impact system.
So Phipps 200 essentially says, OK, let's take that categorization
that we looked at with 1 99 and let's figure out the minimum security requirements for each category. So what Phipps 200 does is it gives a 17 security related categories that they refer to as families. So 17 elements that affect security
from different types of controls.
Management, operational and technical controls. Usually, when we talk about a layer defense and we always want a layer defense, we don't want to rely too heavily on technical controls or just physical controls or just management controls,
management controls or policies. Procedures that we put in place
operational controls would be things like physical security. And then, of course, technical controls would be encryption, firewalls and all those elements. But ultimately,
Phipps 200 specifies the need for defense in depth gives us those 17 families, and it's going to talk about how we implement implement what we refer to as minimum baseline security, or you may hear it refer to his MSB
minimum security baseline. It just depends on the document that you're looking at.
So ultimately here are the 17 families that are part of Fits 200. These will map to the 70. I'm sorry, toothy 18 families that the risk management framework lists. However, risk management framework adds one more for program management.
Onley 17 from Phipps 200.
But again, Ah, so much overlap. You know, risk management framework doesn't stand alone. It uses all of these other documents as input to each of the elements there. So you can see the things that are going to affect security access control, configuration management, contingency planning, incident response,
personnel security, risk assessment. All of these different areas
these air considered to be families of security functions. Okay, So those are the two big Phipps documents that I would look at Phipps 1 99 and Phipps 200. So, once again, 1 99 was categorizing systems fits 200 was determining the minimum security Baseline.
Now we're gonna move over to some special publications that mist has given us,
uh, to further provide some input into the risk management framework. So here we start off with risk. 800-30 and again, very, very important document. When we look at 800-30. Revision one specifically. This is our guide for conducting risk assessments.
Everything revolves around the world of risk.
You know, security is a function of risk. Risk is essentially the precursor to security.
So ultimately, when we look at 800-30 we talk about how we go about conducting a risk assessment. What do we have? What's it worth? What are the threats and vulnerabilities? What air? The likelihood. Uh, what's the likelihood these threats would materialize? And if they do, so what sort of impact?
And we get that from the State 100-30.
Now, um, we also have, uh, missed 800-39. There is an element called assessing risk. Ah, from a special publication on risk management. So 800 s 39 has a little bit of input, but ultimately,
what are the risk assessment concepts
toe all three tiers in the risk management hierarchy? We haven't talked about the multi tier hierarchy, but we have to think about the organization as a whole. We have to think about individual business processes, and then we have to think about individual systems,
and our risk management approach and philosophy should be integrated. Should be a very holistic
approach. Rather than thinking, How do we secure this system. How do we secure this system in such a way that it enables us to meet the objectives for our organization as a whole?
That's the thought process again missed 800. Dash 30 tells us that when we're going to conduct a risk, we have three steps. We're gonna prepare for the assessment, conduct the assessment and maintain the assessment.
The idea there with maintenance is the risks as they exist today are gonna be different from the risks as they exist tomorrow, new risks will come off. Mitigation strategies will succeed or fail.
Our environment will change, So risk management is very much an ongoing process. Now, when we talk about these three, these three steps there are four elements that we look at in the context of risk. These air. Really, What risk is all about threats, vulnerabilities, likelihood and impact
threats? What are those negative forces that can negatively affect your assets? What air? There's negative forces that can calls lost to the value of your assets. And remember, our assets are not always tangible. Yeah, I have a system, and vandalism could damage that system.
But MME. Or more valuable than the system itself. It's the information
more valuable even than that is its effect on the business as a whole may be my company's reputation, So don't be narrow sighted when you're thinking about impact and when you're thinking about the assets and the potential for loss. There are many things that we as an organization value.
All right, so threats, negative impact on an asset vulnerabilities. What weakness do we have?
And it's the vulnerabilities that allow the threats to create the impact.
If we have no vulnerability, the threats don't matter.
Unfortunately, it's very difficult to have no vulnerability.
So another way to say that is,
and this is just conceptual. But threats, times, vulnerabilities, equal risk.
So if either of those is zero, there no threats, but you're very, very vulnerable.
If they're no threats, you still don't have a risk.
There are 1,000,000 threats, threats, threats, but you're invulnerable.
Well, there's no risk, so we don't generally talk about zero threats or zero vulnerabilities. But what we want to do is we want to look at the level of risk in relation to what are the vulnerabilities that we have and what are the threats that would exploit them.
Now, when we're looking at getting a value for risk to main pieces, we look at probability
that can also be expressed. His likelihood? An impact.
How often is the risk event gonna happen? And when it does happen, what will it cost me?
Okay, so those are the elements that are defined in mist 800. Dash 30 is part of our risk assessment.
And when we do look at the different types of assessments, we often start with a qualitative assessment. If I don't secure this network,
any network and you can think about this, what are some threats that are likely to materialize?
Okay, I've got 15 computers. Networks were connected to the Internet.
No security at all. Right now, what are some things that will happen?
Well, we're gonna have external compromise, will lose confidentiality of our information. We may become subject now of service attacks. We may have corrupted systems. And even in addition to that, we're still potentially gonna have hardware failures,
lost lines, things that don't necessarily indicate
a Nintendo. Chinna ll compromise, but that would still affect the CIA of my organization. Okay, what we're doing now is we're brainstorming right we're just thinking, Okay, this could happen. This could happen. All these negative impacts could come up
when your brain storming chances air Good. You're doing qualitative risk assessment.
Okay? Because what's gonna follow us, just going through enlisting outs and potential threats is we're gonna say OK, out of all of these things that we've just named what he thinks the most likely toe happen,
Let's say a compromise of integrity, more compromising confidentiality. Let's say we store health care information and we have no security. Well, that's a high value target. So we're gonna decide that. Yeah, probably. Our greatest concern is the privacy of information
that's qualitative. When you're using words like high medium load
when you're saying this is probably gonna happen or yeah, that makes sense. Those air very subjective terms in nature. That's qualitative analysis. Qualitative analysis is our starting point, and we must start with qualitative analysis. Let's brainstorm. Let's talk about the threats and vulnerabilities.
Let's get some things on paper up on a white board so that we can discuss it.
it's very difficult to make business decisions on purely qualitative analysis. So, for instance, okay, privacy is my top concern. How much money will I spend to protect these systems?
I don't know, because I don't know, a dollar value of the systems. I want to know a percent of likelihood that an attack would happen. And I would like to know the impact should the information be compromised, that is quantitative.
Quantitative, essentially is gonna back up, which he thought was true from qualitative and put numbers to it. Give me a dollars out. You know, I won't say that. Quantitative analysis always ends with the dollar number, because it doesn't.
most things in this world revolve around the dollar. And when we talk about loss and lost potential, almost always, you can track that down to money.
And what we're really looking to get out of the quantitative analysis is the basis for a cost benefit analysis.
I'm not gonna pay $50 for safe to protect a $20 bill. Right? So what quantitative analysis does is it gives me a dollar value frequently, uh, for the potential for loss, and I'll use that as the basis to determine what sort of mitigation strategy I wanna put in place.
So we need that quantitative analysis
Now you can have sort of a hybrid of the two Ah Cimini quantitative analysis so that ultimately you can rank these on scales and these scales are very, very subjective. They're just out there, but ultimately you're still sort of assigning numeric value. But, um,
most of the time I want to see a tangible dollar number, right? I want to know I have on 80% chance of losing $10,000. That's an $8000 value to me. I'm going to spend $12,000 to mitigate that risk, but I might spend five.
Okay, so that's what we're looking for from our types of assessments. Now our next n'est special publication, 800-39 here. I had just mentioned the three tiered approach to risk management and 800-39
eyes going to specify that three tiered approach. But it ultimately revolves around the idea
off managing information, security, risk
managing information, security risk and ultimately, with this all comes down to is let's get an understanding that no longer do we think of business risk and information security risk
because information security risk is business risk. Let's look at incorporating and getting a true understanding of the value of our information, our data, and understand how we protect that information in such a way that it continues to support the business. And the mission of the organization is a hole
we don't want too much. We don't want to little. We want to find the right amount
based on cost benefit analysis that continues to support and enhance the organization. So what this particular document does is it helps me to understand that,
that we don't implement security just for the sake of security, that it's all based on how we can benefit the organization. Another piece that it stresses is
integrate security into your system. Design and architecture and build and operations. And monitoring rather than thinking of security is an afterthought. So long we have asked ourselves to questions in relation to systems and software. First question is, does it work?
And what next 800 Dutch 39 essentially says we need to do is stop thinking about it like that? Does it work securely? Work does not work at all, and the way we make it work secure securely is that we focus on security throughout the entire system development life cycle. It's such an important concept
that we really haven't done very well.
Historically, the idea also is to get to our technicians and work with their technicians toe, understand how they can responsibly implement security in such a way again that it supports the overall organization. The thing that we want to stress about security,
there is always a trade off.
Security is never free.
It can cost dollars. Of course. You know, you got my new firewall. You're gonna drop thousands of dollars. Ah, you buy new system. It's gonna cost money. But often what we failed to overlook is the many other costs of security. You know, when you implement security within an organization,
usually there's a tradeoff for performance.
Security often slows things down,
you know, think about going through the airport today versus 15 years ago, before the events of September 11th pretty much just cruise through security at the airport, there was no taking off your shoes and all of these different things that we have to do today. Well, we needed enhanced security that slows us down
a performance we've got to find that balance between are necessary performance and the degree of security that we need is, well, there are times when we choose performance over security. As a matter of fact, I would say performance and ease of use are frequently
chosen over security. As a matter of fact, when you go and buy a product and you pull it out of the debate, the box nine times out of 10 it's focused on being something that's easy to set up and install. It just works, right? We've heard the phrase plug and play for years and years and years. 20 years now. Well,
the benefit of that, you know, it just appeals to people. You plug it in and you could go with it.
the reason you can plug it in and go with it is because it has no security. Security slows things down, so we've got to find that trade off
eso performance ease of use. We've got to think about backwards compatibility because the most secure elements today may not be compatible with our devices that are three years old, eight years old, whatever they may be,
and then a final cost. Uh four security is user acceptability.
Users don't like hassle
now. That's not to say that that's our primary concern. When we're implementing security is we don't want to slow, you know, aggravate our users. But what we have to do is we have to implement in such a security in such a way that it's a seamless as possible to the users, right. We want to minimize the exposure
that users have to our security controls.
We'd love these things that happen in the background as opposed to the user having to do this for security, that for security we'd like them to go about their normal business and have our applications interact securely with other applications. We'd like to implement a public key infrastructure so that
access to ah internal resource is happens is again smoothly
and seamlessly as possible. So, yes, user acceptability is a concern, and the easier we can make it on our users, the better off we'll be