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 well 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 catalogue and define all of our assets and we look at these assets and we have
to consider what are the vulnerabilities so we can use tools to help us out here.
For example the famous the SB 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 CTE.
Now this is administered by a organization called the Mieder corporation.
And you can go check that out anytime you want.
Now the nice thing about the CV 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 8.
Earlier you 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 CDs 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 tend to do a lot of searching within the CBD itself.
So once we use these types of tools and we've gone through our different assets and we 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 Ness's 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 Ness's 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 the bad people would do.
However they do look for vulnerabilities and then they report it to you and then testing really is the
best way to determine what your vulnerabilities actually are for your network.
So once you'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 has to be a bit of fuzziness here but we'll keep them separate with the 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 what we're going to call adversarial type of threats an 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 type
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 had 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 Forth is going to be environmental and environmental and just as
it sounds.
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 challenge is 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 OK well I found a risk so I'm going to go try to deal
with that I'm going to apply some security control to that risk.
Now 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 risk 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 controlled 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.
Well for example if we're going to do a mitigation Let's say I've got a web server and this web server
just exposed to the Internet you know not the smartest thing to do.
What I could do at this web server is put it into for example of DNC 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 is 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 and certain situations.
I'm just going to accept the risk.
Let me go.
Obvious here.
I accept the risk that a meteor 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 where were 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've started to realize
that if somebody hacked me and got this information I would have the 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've decided how you're going to act on all this stuff.
You've got a big job with thousands if not tens 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 a 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 NIST and this is the Espey 837 document this is called their risk management framework.
And the other source is I guess a CA's risk I.T. 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 naughties that happen
and then you just keep doing this over and over and over again for as long as you've got a job.
So if we take a look at NIST you can see there's a circular aspect to their risk management framework.
Now if we switch over to the CA's risk I.T. infrastructure you'll see they also there's a bit more like
a triangle but it's still the 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 appliance security controls.
You'll see some form of monitoring where we're watching things to make sure things don't happen.
We have a response when naughty things do and then we just start reassessing all over again.