CompTIA CYSA+ CS0-002 – Risk Mitigation Part 4

7. Communicating Risk (OBJ 5.2)

Communicating risk. Now, one of your jobs as a cybersecurity analyst is to make sure you can explain risk in plain and simple language. Now, what do I mean by that? Well, let’s take the example of a denial of service attack. Let’s pretend you went into a meeting and there was a room with a bunch of executives in it and they look at you and say, hey, I heard you’re a new cybersecurity analyst. Tell me, I heard there’s a big threat out there of denial of service attacks. What exactly is that and how are we affected? Well, if you started saying the answer is something like this well, a denial of service attack is a type of cyber attack which is used to overwhelm a computer, a service or resource by providing extraneous information requests in a limited dumbertion of time.

Now, for example, during a Sin flood, there’s this three way handshake that’s compromised by an attacker after initiating the handshake by sending a Sin request. But they never return the act request and this doesn’t allow a complete or requested connection to occur. Is that really simple? Well, not really. Instead, if you’re talking to a bunch of executives, you need to change it into something more simple, something like this. A denial of service attack is a result of malicious activity against our public website. The site could become overloaded, it could prevent customers from accessing their accounts, and this could result in a loss of sales for up to 2 hours while we’re dealing with it and a potential loss of revenue of up to $25,000 based on our average daily sales volume.

Which one do you think is going to get you more money and more budget for your cybersecurity to be able to prevent a Dos attack? Probably the second one, right? Because the executives can understand that you put it in terms they understand. It’s this technical thing that you have now dumbed down, for lack of a better term, into simple things that affect them. It’s when your site becomes overloaded. This prevents your customers from accessing their account. They can’t give you money and we’re going to lose money, boss. Therefore you need to give me money so that we can go ahead and prevent these bosses from occurring. This is one of the main roles that you have, is to communicate risk in simple language so that your bosses and their executives can understand what they’re funding.

Because this communication is key, when you communicate, you need to think about who the receiver of that communication is. If you’re talking to another technician, the first answer was probably fine. But if you’re talking to executives and managers, the second answer is much, much better. Now, another way that we communicate is using something known as a risk register. A risk register is a document that highlights the results of risk assessments in an easily comprehensible format. Inside of this risk register, you’re going to document things like the impact in likelihood ratings, those high, medium and lows. We talked about the date you identified the risk, the description of the risk, the countermeasures and controls. Who is the risk owner and how are they going to decide if we’re going to accept mitigate transfer or avoid the risk.

And then we also need to think about the status, which of those are we doing and what is the plan of action. If it’s a mitigation, what controls are we putting in place? All of these are things you’re going to document inside that risk register. And the risk register really is a document for management and executives to look over and understand what their risk posture is across the organization. Now, this risk register needs to be shared between the different stakeholders so they can understand what risks are associated with the different workflows that they manage. Like I said, this is made for the managers and the executives. It’s not something you’re going to create and keep inside your own work group. You need to make sure this is widely understood where your risks are so they understand what risk they’re taking on any risk that’s being accepted.

They need to understand what that is because this is important for them. Now, another thing we want to document and communicate is our compensating controls. Now, what is a compensating control? Well, this is a type of security control that acts as a substitute for a principal control. Now, a principal control is just a primary control. When dealing with a compensating control, they’re going to provide you with the same or better level of protection, but they’re going to use a different methodology or technology. For example, if your risk management framework states that you have to install antivirus on all of your workstations, but for some reason you can’t install it on one of those, you might choose to install an antimalware solution instead.

Because antimalware also includes antivirus and this would then be a compassing control because it meets or exceeds the requirement having antivirus. Although you’re using a different technology antimalware in this particular situation. Another good example of this might be if you wanted to have long strong passwords for all of your systems, that is what your requirement is going to say. Everyone must have a 16 character long strong password. Well, that’s great, except some devices like SCADA and ICS might only support an eight character password. So you can’t get a long strong password on that system. But maybe you’re able to set up two factor authentication using a smart card and Pin. And if you can, that would be a compensating control because the compensating control here would be having two factor or multifactor authentication that is stronger than just using a password.

But we’re using a different technology. We’re still getting what we need out of the system. Now, the third thing we need to consider is exceptions. When we talk about exceptions, we need to think about exception management. When you’re dealing with all your policies and procedures, they’re going to say you need to do certain things, and sometimes you simply can’t. These are going to be listed as an exception. Exception management is a formal process that’s used to document each case where a function or asset is non compliant with the written policy and procedural controls. For example, you might have business processes and assets that are affected. You want to document that. If I have this exception where this thing can’t use a long, strong password, what is being affected by that? Then I might think about what personnel are involved.

Because I don’t have a long, strong password, we’re going to end up changing it every 30 days instead of every 60 days, because that way it gives us at least a little bit of a compensation. We might think about the reason for the exception. We have to have an exception for this system because it’s an old ICS SCADA system and it can’t support a long, strong password, and it can’t support two factor authentication. So we have to have an exception for it. Somebody might ask, Why can’t you just take the system offline? Well, this particular ICS Gator system might be running our entire manufacturing floor, and if we take it offline, we lose a million dollars a day in or activity. So we’re going to live with the fact that it only has an eight character password, right? These are the kind of things you have to think about in the real world.

We’re then going to look at a risk assessment. We’re going to look at that system and say, how bad is it by not having this one control? Do I have enough other controls that might mitigate it? Maybe. I took that ICS data system and I put it on its own VLAN, and it’s only accessible from the local network, not from the Internet. I put additional compensations in place, and when I do a risk assessment for it, I find out that this brings me down to a lower level of risk, and I’m willing to grant an exception. I might think about compensating controls that are being utilized. Again, because I couldn’t access the long, strong password, I put it on its own isolated network so nobody else can access that system directly. Next, we have the duration of the exception.

How long are we going to exist in this accepted state? In the case of this ICS Gada system, maybe we decide that we’re going to give them twelve months, because in that twelve months we’re going to have enough money and we have an upgrade coming, and that system is going to get replaced with this newer system that has better security. That’s the idea here. With the duration, we don’t want to let this run on indefinitely. But it has to be a reasonable amount of time so they can get the money and get the system replaced. And finally, what steps are needed to achieve compliance? In the case of my fictitious ICS SCADA example, we might need to upgrade from version two to version three, and that cost us a million dollars for the new system and take six months, months to install.

So here’s all the things we need to have budgeting in place. We need to have approval in place. We need to start ordering these things, and there’s this amount of lead time, and we can start going through all of those things. All of these are things you have to consider as you’re thinking about your exception management. Now, the final thing to think about when you’re talking about exception management is that if you have a certain policy or procedure that’s generating a lot of exception requests, you need to step back and start thinking about, do you need to redesign or reconsider that policy? Sometimes somebody has a great idea for a policy or procedure.

They say, this is going to save us time. This is going to save us money. This is going to make us more secure, whatever it is. But when you start putting into practice, you find out that your systems can’t support it. You don’t have the capability. You don’t have the knowledge. You don’t have the money or the resources, whatever it is. And so people start putting an exception request. If you get one or two requests, that’s probably okay. We can work with those. If you’re getting hundreds or thousands of requests across your organization, this probably means it’s a bad or stupid policy. So go back and look at it, and it’s possible you might want to redesign that.

8. Training and Exercises (OBJ 5.2)

Training and exercises. Earlier in the course, we talked a little bit about training and exercises. So some of this will be a review. We’re going to talk about tabletop exercises, penetration testing, and red, blue and white exercises. In this lesson, we are going to have some new information. So please don’t just skip ahead and watch this entire video. Now, when we talk about tabletop exercises, we mentioned before that these are exercises that use an instant scenario against a framework of controls or a red team. So what we’re going to do here is we are going to carry a discussion of simulated emergency situations and security events.

These are great because they’re really simple to set up, but they tend to be more theoretical in nature and they don’t provide practical evidence of what could go wrong during a real event. For example, how long will particular tasks take to complete? You really can’t gather that from a tabletop, but if you actually go through the actions and motions in something like a penetration test, you’ll be able to see that instead. Now, I’ve seen a lot of times when we’re doing tabletop exercises that people start using their magic wands. Now, this is a bad thing to do because you can start getting the effect that something that might take a real team 12 hours to do can really be solved in 30 minutes.

And so when something really happens, the manager start going well, in the tabletop, it only took us 30 minutes to solve. Why is it taking you 12 hours? I need this system up right now. And so you start getting this negative training, I call it. You start training your senior leaders to expect things to happen faster in the real world than they really can. So just be careful about that if you’re dealing with a tabletop exercise. Now, when you’re dealing with a penetration test, this is a test that uses active tools and security utilities to evaluate security. By simulating an attack on a system to verify that a threat really does exist, they actively test that threat and vulnerability. They bypass security controls and then finally exploit those vulnerabilities on a given system.

When you’re doing a penetration test, you are going to test the system to discover vulnerabilities or prove security controls are actually working as they’re supposed to. You’re also going to examine the system to identify any logical weaknesses that may be there inside the system architecture. And you’re going to interview personnel to gather information and see how prone they are to social engineering attacks. All of these are things you can do as part of a penetration test. Now, when you’re dealing with a penetration test, you have to make sure it is properly scoped and resourced before you can begin it. Now, what I mean by this is you have to figure out exactly what is going to be tested as part of the penetration test.

If you get a penetration tester to come in and test your organization. You say, just go at the entire organization. That’s not going to be very effective. Instead you should tell them, hey, I’m really concerned about my Windows domain controller. I want you to see if you can get root access on that and that would allow them to be able to identify exactly what your concerns are and verify your systems are working properly. Now, when you’re dealing with a penetration test, you can use either an internal team or an external team. I personally like to use third parties who are external to the organization or a separate internal red team. I don’t like to use my system administrators to conduct penetration tests. It’s not that they’re not smart enough to do it, it’s that they’re biased in their approach.

When you have a system administrator trying to pen test their own system, what ends up happening is they start trying to prove the system is secure instead of trying to prove the system can be attacked as a penetration tester. Our job is to be the bad guy. It’s to go in and find all the holes, we want to find all the weaknesses. And the system administrators tend to try to not do that because they’re trying to prove that their work that they did securing the system is adequate. And so it’s a different perspective and that’s why I much prefer a third party or an internal red team be used instead of system administrators. Now, if you want to learn more about Pen testing, as I said before, you should check out the CompTIA Pen test plus curriculum in that course.

There is a ton of information on how you can become a member of the penetration testing team and learning how to attack these systems from that outsider perspective. Now, the last thing we want to talk about in this lesson is our red teams, our blue teams and our white teams. When we talk about red teams, these are the hostile or attacking teams in a penetration test or an incident response exercise. If you hire that third party team, that is a red team, they’re trying to attack your systems. When we’re talking about blue teams, this is our defensive teams in a penetration test or an instant response exercise. This is our system administrators, this is our network defenders, this is our cybersecurity analysts like you. You’re going to be part of the blue team and then we have the white team.

This is the staff who administers, evaluates and supervises a penetration test or instant response exercise. They’re also going to be responsible for building the network if you’re going to be using a third party network as part of your test. Sometimes organizations don’t want to do active testing on their real live networks. So they’ll build a training ground and they’ll put their red teams and their blue teams. They have internal red teams and internal blue teams against each other in the simulated environment. Well, somebody has to build and support this entire ecosystem, and that’s what the white team will do. I like to think about the white team as the referees. They’re also going to be the ones who are going to report after the event and say, this is what the red team did well. This is what the blue team did well, and here’s what they both did not so well. That’s the role of the white team.

• Category: Uncategorized