CompTIA CYSA+ CS0-002 – Risk Mitigation Part 3

6. Risk Prioritization (OBJ 5.2)

Risk prioritization. Now we’re going to talk about risk prioritization in this lesson because it’s important to remember that not all risks are created equal. Once we determine what a risk is, we have to determine what we’re going to do about that risk. And this brings up the question of what should be done with a particular risk. Well, there’s lots of things you can do with it. In fact, there are four main areas you can mitigate that risk using risk mitigation. You can avoid that risk using risk avoidance, you can transfer that risk using risk transference and you can accept that risk using risk acceptance. We’re going to talk about each of these four in this lesson. But before we do, we have to talk about risk appetite.

Now you may or may not be familiar with the term risk appetite, but essentially what it means is how much risk is your organization willing to accept? For example, if you’re a big multibillion dollar company like Amazon, you might have a higher risk appetite where if there’s a risk that is a million dollars, you’ll take that risk because you can afford it. But if you’re a small company like me, we can’t afford to take a million dollar risk that would bankrupt our company. And so you have to have an idea in your organization what is your risk appetite? Some organizations are very heavy on their risk appetite. They’ll take on a lot of monetary risk or a lot more dangerous risk. If you’re somebody who has a very low risk appetite, you’re going to try to shun all risk and try to avoid it and mitigate it as much as possible.

Knowing this and knowing what your organizational culture is will help you determine which of these four things you’re going to do when you deal with risk and you’re probably going to do some of each of them. Now let’s go ahead and talk about each of these four. The first one is risk mitigation. Now risk mitigation is a risk response that reduces a risk to fit within an organization’s risk appetite. And so you can see why I thought it was important to talk about risk appetite. If you have a high risk appetite you might need very little mitigation. If you have a low risk appetite, you might need a lot of mitigation. Now when we talk about risk mitigation, this also brings up the idea of risk deterrence or risk reduction. This refers to controls that can either make a risk incident less likely or less costly.

So for example, if you’re worried about getting into an accident in your car, one of the risk mitigations you can do if you’re worried about hurting yourself in an accident is put on your seatbelt or drive a car with airbags. Both of those are not going to stop you from getting into that accident necessarily, but they will reduce the harm that would happen if you were in an accident because you’re mitigating that risk. Now another thing we might look at in the software world is patching our software. We do vulnerability assessments, we scan our network to find out what systems have not been patched. We find those systems and we apply the patch to them. That is going to reduce our risk. Does that protect our systems 100%? No, of course not.

There’s still risk to that system but you are getting a lot of those easy mitigations out of the way by patching those systems against known vulnerabilities. That is the idea of risk mitigation. Now the second category we have is known as risk avoidance. This is a risk response that involves ceasing an activity that presents risk. So I’ll give you a great example of this. My wife doesn’t like to fly. In fact she is petrified of small airplanes. She is afraid that if she gets into a Cessna it’s going to go up and crash down into a lake. Now her fear of these small planes is not unfounded though she actually had a friend who died when she was very young because their family died in one of these small plane crashes. And because of that my wife refuses to go onto a small plane. Now, I’ve been able to get her on larger planes.

She’ll go on a commercial plane because she feels they’re a little bit safer but she still doesn’t like them. But again, she is not going to go on a small plane. It is just it’s something she’s aside in her life. It’s not worth the risk. So she has avoided going on small planes her entire life and she refuses to go on them. She’ll go on a jumbo jet but she will not go on one of those suspects and that is the idea of risk avoidance. This risk to her is just so bad that she is not willing to take the chance at all and that is risk avoidance. Now unfortunately, risk avoidance is not really a valid solution most of the time because you simply can’t avoid all risks. There are some risks you can avoid but if you want to avoid all risk across everything, that’s just not possible.

So we’re going to have to combine some of these strategies as we go. The next one we’re going to talk about is risk transference. We talk about risk transference. This is a risk response that involves moving or sharing the responsibility of risk to another entity. Now what does this really mean? Well, let me give you a really easy example. I used the car example earlier. If you’re worried about getting into a car accident you can mitigate the risk by putting on your seatbelt to help yourself not get hurt as badly. That’s a mitigation. But if I wanted to transfer the risk of this car accident, what are one of the things that we all have for our cars? We have car insurance, right? So if I get into a car accident and I smash up the front of my car. I call up my insurance company, they write me a check and I get a new car or I get my car fixed.

I transferred the financial loss of that vehicle to the insurance company by paying them a monthly premium. They will then cover that risk for me. I transferred it and gave it to this other entity, this third party. And that’s the idea. Now, how does this apply in the cyber world? Well, there’s lots of ways we can do this. One of the ways is we can actually use cyber insurance. There are cyber insurance policies out there against data breaches. Now, your company can pay a policy to a cyber insurance company, and if you are hacked, they will pay for the response and they’ll pay for the cleanup and they’ll pay for any damages to your customers. That is one way to transfer that liability over to this third party using risk transference. Now, another way you can do risk transference is you can actually outsource the service.

Now, for example, I don’t host my own web servers anymore. We pay a third party, and that’s their job. They host our web servers for us. They host it in a place that has 24/7 power and electricity and good connectivity and all of those things, and they make sure they actually patch our servers against vulnerabilities and provide us those protections. Now, could we do it ourselves? Yes. But again, we’re a training company now. We’re not focused on running these systems anymore. I’ve done that in my career. I don’t want to have to have that responsibility and that extra baggage inside our company. We instead want to focus on providing you the best training, not on providing the best servers. We can outsource somebody else to provide those best servers for us.

And that’s the idea of risk transference, because they’re responsible for the maintenance, the upkeep, the patching, the software, all of that has been transferred to that organization. Now, I can’t transfer away the responsibility. If my servers get hacked, it’s still going to be my name. That looks bad because they’re going to say, oh, Deon training had a data breach and we are going to lose our reputation over it. But I can transfer away the liability and the cost associated with it because they’re responsible for that as part of our contract. Now, my organization is still going to take some tarnishing of our brand reputation if that happens. So we had to make sure we transferred it to a good organization. But that’s the idea here when you start talking about transference.

Now, even if you transfer the cost of the risk, again, you cannot transfer the reputational damage to your organization. As I was saying, I transfer away my web service to a third party company, but if we have a data breach, it’s still our company that’s going to have a tarnished reputation and we’re still going to take the heat for that. Now, they’re going to pay for all the data breach and they’re going to pay for all the cleanup and the response because that’s part of their contract. But my organization still is going to look back ad. I can’t simply say, hey, XYZ Company is at fault. You aren’t going to believe that it’s a student. You’re still looking at me because you are my customer. You weren’t their customer. And so that’s one of those risks that you have to think about when you’re doing risk transference.

Now, the final one we want to talk about is risk acceptance. Now, with risk acceptance, this is a risk response that involves determining what a risk is within the organization’s risk appetite. And there’s going to be no other countermeasures other than monitoring will be needed here. Now, what we’re talking about with risk acceptance is we simply say, I know this is risky, I know this is dangerous, but it’s a small enough danger that I’m going to take it. For instance, there is a risk that if you get on a commercial plane, it could crash. But it’s a small enough risk that most of us will get on a commercial plane and take that chance. Just like there’s a risk of you getting into a car accident when you go to work, you might take that risk. Now, you might also accept what’s left over in the risk.

So if I have my car, I already have car insurance to cover the cost. I already am wearing my seatbelt to mitigate that I have transference. I have mitigation, but I could still get into an accident and I could still get hurt. But I’m accepting that risk that’s left after I’ve transferred and mitigated the big areas of risk, which was the cost of replacing my car or the ability to actually get someplace. And I need to do that. So I have worn my seatbelt, I have an airbags, I have a safe car, and I’m going to go ahead and accept the risk of that risk. Now let’s talk about the exam for just a moment here. I want to give you a few quick tips in regards to choosing the best risk response. Now, the most common one you’re going to see is mitigation. Mitigation involves adding controls.

So whenever you think about mitigation, I want you to think about adding controls. Then we want to talk about avoidance. Avoidance is our least common one and it involves changing your course of action or the systems in use. So when I think about this, I like to think about changing plans. I planned on doing this, but I’m going to avoid it and I’m going to do something else instead. The next one we want to talk about is transference. Transference is all about moving the risk to a third party on the exam. This is almost always going to involve some kind of insurance policy being purchased. For example, my company offers a form of risk transference for our students who are afraid they might fail the exam.

If you go and buy your exam voucher from Deontraining. com, you can purchase an add on product that we have for an extra fee, and this gives you a new exam voucher if you fail the first time. Now, normally when you go to compt and you buy your exam voucher, you’ll pay full price and you’ll pay about $350. Once you buy that voucher, if you take the exam and fail it, you have to go buy another voucher before you can retake the exam. Well, with our add on product, you buy the voucher from us, and we charge you a little bit extra for this extra option. We call take two. This allows you to pay this upfront fee to us. That’s less than the cost of a new exam voucher we take on the risk for you that if you fail the exam, we will buy you a new voucher for the full $350. And so it saves you money if you fail.

But if you pass the first time, you pay us that extra money really for nothing, right? Because you didn’t crash your car. I think about it like car insurance. You pay for car insurance, hoping you never crash your car. It’s the same thing here. With this failed exam transference, you’re hoping that you’re not going to have to use it, but if you do, it’s a great thing to have. And so that’s the idea here. It’s a form of transference or insurance against you failing your exam. And so you’re buying that extra peace of mind to know that you’re going to have a second attempt if you need it. And then finally we have acceptance. Acceptance is when you accept the risk. It has to be less than the organizational’s risk appetite here. Normally we’re going to accept a risk for small things that are unlikely to happen.

For example, I accept the risk, then alien invasion may occur and put me out of business. I also believe that it’s going to be extremely unlikely that an alien invasion is going to happen. So I haven’t put forth any resources, thought, or planning into preparing for an alien invasion. Similarly, I haven’t planned for the end of the world or a zombie apocalypse. I just don’t think those things are big deals. On the other hand, as I said, I spent a good deal of money trying to add controls to protect our business from power outages, from flooding, from hurricanes, from earthquakes. Those are all things that we’re subject to by living in Puerto Rico. And so we have to have protections in place for those things. And those are things we are going to add controls to.

We’re not going to accept those and just say, oh, well, if a hurricane comes and we’re out of power for three months, we’ll just be out offline for three months. That wouldn’t be good for our customers. So we’re not going to do that. So this is the idea here. So what I want you to remember is on the exam, this little cheat sheet you see here, mitigation, controls, avoidance, changing plans, transference, insurance, and acceptance is for low risk activities.All right. Now, with all that in mind, let’s start talking about security control prioritization, because there are a million controls out there and you have to decide which ones you’re going to use. Now, there are three main areas we’re going to talk about with security controls. First, we have to talk about whether the control is required by a framework, a best practice, or regulation.

If it’s required by one of those three, it’s going to have a higher priority for us, and we’re going to do it, especially if it’s a regulation. Regulation means law. It means you can be fined or put out of business if you don’t do it. So you need to make sure you’re following those things. Second, we need to think about the cost of the control. This is going to require us to think both and what it costs us to get the control initially, as well as the ongoing maintenance and support for that control. If this control is going to cost me a million dollars a year and it’s going to protect something that costs me $10,000 a year, I’m not going to do it. I would accept that risk if it’s something that costs me $1,000 a year, but it protects me from a liability of $10,000 a year, I’m going to do that every single day because that is a great return on investment.

And so you want to make sure you think about your cost of control when you’re determining priority. And finally, we want to think about the amount of risk that a control mitigates. If I have a control that’s going to mitigate a lot of risk for me, that might have a higher priority than one, that only gives me a little bit of risk protection. Because, again, there are only so many dollars and only so many hours in the day for you to be able to use to mitigate things. So you have to make sure you’re making the best choices. Now, a control is going to have a higher priority whenever it’s part of a framework, a best practice, or is required for regulatory reasons. I’ve already mentioned that. That’s really important for us to think about. The next thing we have to think about again is the cost of control, right? All these things cost money.

Whether I’m using people to do it, that costs money too, because I have to pay their labor or some kind of software or hardware which I have to buy. All that costs money. And so I have to weigh the cost of the control. And then I also want to think about my return on my investment. So I think about this. There’s a term called RSOI, which is a return on security investment. As somebody who works in cybersecurity, you have to get very comfortable with selling the idea of what things you need to upper management because they’re going to have to budget for it and give you money. Security costs us money and we talk about RSOI. This is a metric that we use to calculate whether security control is worth the cost of deploying it and maintaining it. As I said, everything we buy costs money, everything we support costs money.

And so we have to figure that out. Now there’s a nice little equation that you can use to figure this out, and it’s called Ale minus al, m minus C divided by C and that’s going to equal your Rosi. Now, what am I talking about here? Well, Ale is my annual loss expectancy. Then I’m going to subtract what the annual loss expectancy would be if I had the mitigating control in place. That’s the ALM. When I have that, I then subtract the cost of the thing I bought. That’s the C. And then I take all of that divided by the cost. And when I do that, that will give me an Rosi, which essentially is a ratio that shows me, is this thing going to be valuable to me? And based on the Rosi, I can determine whether or not it’s worth getting that mitigation in place or if that mitigation isn’t very helpful.

Now, when I think about risk, I want to remember that risk is not always in opposition to an organization’s goals. Sometimes you have to accept some risk. You can’t make risk go away completely. And this is something I like to bring up a lot in my security plus class as well. I bring up this chart and it’s my operations versus security chart. If you’ve been working in security for any length of time, you probably have felt this in your real world. When you start having something that is very, very secure, what happens? Operations tends to go down. Why? Because all that extra security makes it more difficult for people to do their job. If I have to have two factor authentication on everything, I need to slow down and be able to have multifactor authentication that goes and texts my cell phone before I can log in.

And I need to encrypt everything that has more resources and overhead. All these different things that I do to protect the system. It slows everything down. Now that’s okay, we’re going to have to have some of that to make sure that we are getting a secure system. But there is no such thing as 100% secure system. In fact, the only 100% secure system is a system that is powered down. Because a hacker cannot attack a powered down system. But that power down system gives you zero operational capability. And so this is always a fight for us. Operations wants less controls. We want more controls for security. And so we have to have this balancing act. And we’re going to find ourselves someplace on that line, probably towards the middle. We’re not going to be at one end or the other because there has to be a trade off.

That brings us to the concept of what we call an engineering trade off. Now, an engineering trade off is an assessment of the benefit of the risk reduction against the increased complexity or cost in a system designer specification. Now, I can make the most secure system out there that nobody can ever hack into, but it would be so hard for you to use and it would be so slow and so cost prohibitive that I probably would never get my bosses to approve it, right? That’s the idea of an engineering trade off. So we make these trade offs and we say, okay, instead of having two factor authentication, we’re going to just use really long and strong passwords. Or it costs too much to issue smart cards for two factor authentication. So we’re going to use people’s cell phones, even though that’s not necessarily as secure. And so we make these different engineering trade offs based on cost.

Now, as we think about this, it all comes down to risk versus reward. If I’m at an organization, I should not spend a million dollars a year to protect a system that’s only valued at $50,000 per year, even if I could completely eliminate all the risks involved. Instead, it would make more sense to have that system compromised multiple times a year, up to 20 times a year before I would hit that million dollar mark, right? And so that’s why we have to think about these things. And we make these engineering tradeoffs. And as the security administrators, we don’t usually get to make the decisions for these engineering tradeoffs. That’s all done by the system architects. But we have to live with those trade offs. And so understanding what those trade offs are and understanding how you can mitigate some of those is going to help you in the real world.

• Category: Uncategorized