If you watch the previous episode, and I hope you did, we now know what risk really is. So it's time for us to start managing that risk. Now imagine you get hired by some company that suddenly said one day, you know, we should get more organized about our risk issues. And you walk into an infrastructure that has no organization on how to deal with risk. And that's what this episode is all about the whole idea of risk management. Now, risk management has a number of discrete parts to it.
But what I want to first off talk about is the idea of what we call risk identification or risk assessment. If you're going to be managing some risk, the first thing you're going to have to do with that risk assessment is no, well, what do we got? So the first step, the first thing we're going to have to do here is take a look and catalog and define all of the assets. Now this is part of what we're going to call a vulnerability assessment. Usually, risk assessment consists of a vulnerability assessment. And a threat assessment.
However, I need to warn you, in a lot of situations, you're literally doing both of these at the same time. So while I'm going to separate them in the real world, this is often done in one big job. So we go through and we catalog and define all of our assets. And we look at these assets. And we have to consider what are the vulnerabilities. So we could use tools to help us out here, for example, the famous ti sp 800 series documentation does a really good job helping us look at stuff like this.
So the downside to that particular document though, is that they tend to be very broad vulnerabilities. So they'll say things like our network is susceptible to being sniffed by somebody. Now, we don't want people to sniff so that is a vulnerability. But sniffing can be much more detailed than that. So we need to determine what type of vulnerabilities are allowing people to do that. Now.
One of the best places to go to is what's known as the common vulnerabilities and exposure database, known as CVE now, this is administered by an organization called the MITRE Corporation. And you can go check that out anytime you want. Now, the nice thing about the CVE is that it goes into a lot more detail in terms of vulnerabilities. Like for example, here's an example of a vulnerability that talks about the mail application that is built into Apple's iOS version eight or earlier. Yeah, I know it's a little bit dated, but it's a good example, can be susceptible to sniffing in certain situations. So that's the reason I like the CVS because it really nails down the vulnerabilities in great detail.
Now do keep in mind this is a massive database, as you might imagine, so you hit tend to do a lot of searching within the CV itself. So once we use these types of tools, and we've gone through our different assets, and we've catalogued them, and we've got a big list of potential vulnerabilities. The next thing we're going to do is use some more active tools. Probably one of the most powerful and popular vulnerability assessment tools is the infamous or famous nessus program. nessus is basically a program that you run within your local area network. And it will go out and check everything out for you and generate a document, which provides you a lot of detail in terms of the vulnerabilities that it finds tools like nessus are absolutely great.
But if you really want to get into the gold standard of determining your vulnerabilities, you're going to have to use something called penetration testing, or pen testing. pen testing simply means that an outside party of some form tries to do things to your network, they look for vulnerabilities. Now, they won't actually do the naughty stuff that bad people would do. However, they do look for vulnerabilities and then they report it to you. And pentesting really is the best way to determine what your vulnerabilities actually are for your network. So once we've gone through all this vulnerability assessment, the next thing we're going to be doing is going through a threat assessment.
Now again, I need to stress to you often vulnerability and threat assessment are done at the same time. Many times a vulnerability pretty much defines a threat. So there tends to be a bit of fuzziness here, but we'll keep them separate. With a threat assessment, what you're looking to do is to define the threats that are applicable to your particular infrastructure. So there's a lot of ways to break this down, I like to break it down into four groups. First are what we're going to call adversarial type of threats.
And adversarial threat would be a hacker or malware where somebody is intentionally doing naughtiness to your particular infrastructure. Second is going to be accidental. Now accidental is going to be things like a user accidentally typed something weird into a form and it causes your database to corrupt or an administrator inadvertently reformats a hard drive with a lot of data on it. These are people who have the rights and permissions, they're just using things a little bit wrong or accidentally to cause naughty things to happen. Third, is going to be structural structural stuff, like the Power Supply on your router dies, or you're have a problem with a monitor or a camera goes out, these are just the things that break. So equipment failures, the best place to look at that, although it could include software that fails to fourth is going to be environmental, and environmental.
Just as it sounds, there's going to be fires and earthquakes and air conditioners going out and all of those things that could potentially cause problems. Now keep in mind, these four breakdowns are just guidelines, nobody out there is going to tell you exactly how you go ahead and assess your threats. And you could probably think of some scenarios where there might be overlap between these different types of threats. Defining the vulnerabilities and threats is important because it lets us know where the risks are. Now the challenges, what are you going to do about it? And that's the goal of risk response.
Now, when you think about risk response, you go Okay, well, I found a risk. So I'm going to go try to deal with it. I'm going to apply some security control to that risk. I want you to think about that for a minute. That's not necessarily the best idea, because you're going to have this huge amount of risks that you've listed. And you've got likelihoods on there and you have impacts.
So you've given them a pecking order about how important they are. But just going in and automatically trying to mitigate them by applying a security control. And remember, mitigation means whatever we can do to reduce the likelihood or the impact of that particular risk may not be the most simple answer to your problem. So let's talk about your different opportunities when it comes to risk response. Now, the first one is mitigation. And mitigation is exactly what it sounds like.
That's the main thing we do with mitigation. That means we are going to do something to it probably apply security controls that reduce the likelihood and the impact of that particular risk. But that's not the only option like well, for example, if we're going to do a mitigation let's say I got to web server. And this web server is just exposed to the internet. Yeah, I know not the smartest thing to do. What I could do with this web server is put it into, for example, a DMZ, and therefore it's a little bit more protected.
That would be a great example of mitigation. Now, the next risk response we could do is called transference. transference basically means that you offload some of the likelihood and risk and impact on a third party. So a great example of that is that instead of monitoring and controlling our own web server, I go ahead and use a cloud based web server service. And then that way, I don't have to deal with the power supplies going out and bad internet connections, because those guys will take care of that for me. The third one's an interesting one.
The third one is called risk acceptance. Basically, you reach a point where the likelihood and the impact of the risk is less than the cost of actually trying to mitigate that particular risk. So on certain situations, I'm just going to accept the risk. Let me go obvious here, I accept the risk that a meteorite may come and hit my office and take out all my servers, it's just not worth the amount of protection. Fourth is avoidance. Now, avoidance is an interesting one.
When we talk about avoidance, what we're really saying is that this particular combination of likelihood and impact is so high that I simply don't want to deal with it. I don't want to mitigate it. I don't want to transfer it. I'm just not going to do it. Let's say I have a sneaker company and I sell sneakers for a living in that situation. Well, we're a little mom and pop and I always like to send you a birthday card on your birthday.
So I need your name and your home address and your birthday and all this personal identifiable information. And I'm starting to realize that if somebody hacked me and got this information, I would have a outrageous legal obligation. So I simply don't do it. What I do from here on in is I just get your name and your credit card number and a shipping address. And then I don't hold any of that because I don't want to be liable for all that type of information. Make sure you're comfortable with these four different types of risk response.
Now, you've got all of these cool risk response you can do. Think about this. You've got your vulnerabilities, you've got your threats, you've applied likelihoods and impacts. And you're you've decided how you're going to act on all this stuff. You've got a big job with thousands, if not 10s of thousands of different risks on your particular infrastructure. You need some kind of organization, some kind of methodology, some kind of framework that you can use to help you get yourself organized and get all this great risk management up and going.
And that's the job of a framework. A framework is nothing more than Then a workflow, a methodology, an idea of a process that helps you as a security professional deal with risk management. Now, there's a lot of frameworks out there. I mean, there are a lot of frameworks. If you ever want to scare yourself, type in risk management framework and do a google image search, you'll be impressed. But for me, there are two sources that I'm going to tend to turn to.
The first one is NIS T. And this is the sp 837. document. This is called their risk management framework. And the other source is is a CIA's risk IT infrastructure documentation. All of this is free and online and you can grab it. Now, everybody has a different way of dealing with this process. But basically, what it boils down to is, you're going to do some assessment, you're going to apply security controls, you're going to monitor the situation, you're going to respond to any noughties that happened, and then you just keep doing this over and over and over again for as long If you've got a job, so if we take a look at NIS T, as you can see, there's a circular aspect to their risk management framework.
Now, if we switch over to the ISC as IT infrastructure, you'll see they also there's a bit more like a triangle, but it's still this circular process. And every time you look at one of these, you're always going to be seeing the same thing. You will see some form of assessment, you'll see some form of implementation, applying security controls, you'll see some form of monitoring where we're watching things to make sure naughty things don't happen. We have a response when naughty things do and we just start reassessing all over again.