CompTIA CYSA+ CS0-002 – Detection and Containment Part 1

1. Detection and Containment (Introduction)

In this section of the course, we’re going to continue our discussion of incident responses by focusing on two phases the detection and analysis phase and the containment phase. We’re going to be covering domain three and domains four in this section of the course, specifically focusing on objectives 4. 2, mostly with a little bit of 3. 1 thrown in. Now objective 3. 1 states that given a scenario, you must analyze data as part of security monitoring activities. This is going to be focused on the concept of an impact analysis during the detection and analysis phase of your incident response. Our other objective, objective 4. 2, is the main one we’re going to focus on though. In this section it states that given a scenario, you must apply the appropriate incident response procedures.

As I said, though, in this section of the course, we’re only going to be focused on two phases the detection and analysis phase and the containment phase. And therefore, we’re going to focus on those portions of this objective inside of this section of the course. Now, as we start this section of the course, we’re going to start with a concept known as the OODA LoopUp. This is the observe, orient, decide and act cycle, and it is a great framework to use during your detection and analysis phase. After that, we’re going to talk about defensive capabilities and different courses of action that are available to us to use when we’re responding to a given incident.

Then we’ll talk specifically about how incident detection and analysis is performed and how we can use that information to conduct an impact analysis to determine the true risk of the event that we’re trying to respond against. Next, we’ll cover the methods used to conduct incident classification as well as the different factors that are used to classify them. Finally, we’re going to talk about containment, which is how we might use isolation or segmentation to prevent the spread of an infection or an incident across all of our networks in our systems. So let’s continue our discussions on incident responses by moving into the detection and analysis phase and the containment phase.

2. OODA Loop (OBJ 4.2)

The UDA Loop. In this lesson, we are going to talk all about the UDA Loop. Now, before we do that, let me give you a quick exam tip. This lesson on the Udaloop is not required for the exam for the Cysaplus Two exam objectives. Now, that means you’re not going to get any questions on the exam about the UDA Loop, but we are going to cover it because it is a common framework that is used in the cybersecurity world when you’re conducting an instant response. Now, the UDA Loop is a decision making model that was created by Colonel John Boyd to help responders think clearly during the fog of war. When we talk about the OODA Loop, we’re talking about the fact that you have to go through four stages.

This is observe, orient, decide and act. Let’s talk about each of these real quick. First, we’re going to observe. When we observe, we want to identify the problem or threat and get an overall understanding of the internal and external environment. In the corporate world. This can be equated to data gathering where all of the information regarding the current organizational state, any competitors and market is collected, or whatever you’re dealing with in an incident, you’re gathering all of those details. Our key focus here during the observed step is to gather as much information as we can because we have to understand the world is complex. All this data becomes a snapshot in time and it has to be treated as such when we go forward for later analysis.

Therefore, we always want to gather whatever information we can as quickly as possible and not succumb to paralysis by analysis. Then we move into our second step, which is orient. Now, orient involves reflecting on what has been found during observations and considering what should be done next. During this orientation phase, we want to reflect on what we found during our observation phase and then consider what should we do next. This requires a significant level of situational awareness and understanding in order for us to make a good conscious decision. Now, when you’re dealing with an instant response, sometimes you are going to have some unconscious or instinctual decisions as well.

This still happens inside the orient phase, but really we are focused on thinking about what our course of action is going to be. We’re taking the information we gather from Observe and we’re coming up with different solutions and plans that we can move forward with based on our orientation. Our third step is then to decide. Now, when we decide, we are making suggestions towards an action or response plan while taking into consideration all the potential outcomes. This decision phase makes these suggestions and then we could figure out what we want to do from here. This can be accomplished through meetings or discussions, and all of these things are going to be focused around creating a roadmap or a plan for the entire organization and for the entire incident response.

Finally, we’re going to act. When we act, we are going to carry out the decision and the related changes that need to be made in response to that decision. This allows us to then see what’s being done and based on what we see as being done, we then can start over again with the observed phase. This way, this cycle happens over and over again. We observe some information, we take in data, we orient ourselves by understanding it and creating situational awareness. Then we decide to take some kind of action and then we act on it. After we act, we then need to observe again to see if what we did worked or if we have to adjust fire again. That’s the idea of this Udoloop. And our whole idea here is for us to be able to stop just overthinking things and take some action.

This way, we want to stop ourselves from reacting to what the adversary is doing and we instead want to take the initiative. This way we can do that with a measured response and get ahead of the adversary. If our OODA loop is shorter and faster than the adversaries, we can move quicker and we could take the advantage and move forward from there. Now, one of the biggest elements of the UDA loop is that it stresses agility. Now, during the observation part of the cycle, we shouldn’t be dominating ourselves with that. We need to just get information in and then move into the other three parts of the cycle. The reason for this is we don’t want to become overcome by paralysis by analysis.

In that observation phase, it is really easy to say I can’t make a decision yet, I need to gather more details. But when you do that, you are wasting valuable time. Instead, take a small action and then observe again. That way, as you’re going through this loop and going through your observe, orient, decide and act, you’re constantly making these small changes and actions. That allows you to start getting momentum and collecting additional data as you go. This will help you go through each stage quickly and make sure that you’re getting to where you need to be and helping deal with this response. So what might this look like in the real world during an instant response? Well, let’s walk through the four steps and see what it might look like.

First, observe. For example, as you’re observing, you might see an alert in your scene that’s been created due to an employee clicking on a link in an email. Maybe there’s a phishing campaign going on and somebody clicked that link. That is your first indication and that’s an observation. Then you need to orient yourself. You need to identify what user permissions that person had, any changes that may have happened on that system after clicking the link. And what are the potential goals for the attacker? Again, we’re trying to gain situational awareness about the data that we observed, then we need to decide on something. What plan are we going to attack with? Well, if we have to decide, we may look at how this user system was compromised.

What malware was installed by the attacker, and how we’re going to isolate that system based on those courses of actions we’ve come up with during orient. We can then make a decision and go after those things, and then we’re going to act. We’re going to go and take those actions on the user system. We might isolate the user system by the incident responder, and then begin to observe again. Four additional indicators to make sure we got everything out of that system. And that’s the idea of this Udoloo. As we go through those four steps, we then need to restart the loop and do it again. And we’re going to keep doing that over and over until the incident is fully resolved. This way, we can continue to observe, orient, decide and act.

3. Defensive Capabilities (OBJ 4.2)

Defensive capabilities. In this lesson, we’re going to talk about the different types of defensive capabilities. Now, every organization has different defensive capabilities, so you have to ask yourself what defensive capabilities does your organization have? Now when we talk about defensive capabilities, these are outlined inside the intelligencedriven Computer Network Defense, informed by analysis and adversary campaigns and intrusion kill chains. This is a document that came from Lockheed Martin and it is a very popular one to use inside the cybersecurity world. This document is only about 14 pages long, so if you want to read it, you can Google intelligence Driven Computer Network Defense, Lockheed Martin, and it will come up immediately in your browser.

Now I would recommend going through and reading this, not necessarily for the exam, but just for the fact that it’s going to be helpful to you in the real world. We’re going to cover what you need to know for the exam in this lesson though. Now, when we talk about these different things that we can do as defensive capabilities, there are a handful of them. We have things like detect, destroy, degrade, disrupt, deny and deceive. Let’s talk about what each of those mean. First we have detect, and this is going to identify the presence of an adversary or the resources at their disposal. Essentially when you go through your scene and you look at the alerts, that’s your ability to detect an adversary in your network, that is a defensive capability, and usually the first one you’re going to use, then we have destroy.

Now, destroy is going to render an adversary’s resources permanently useless or ineffective. For most of us in a commercial organization, we are not going to be using destroy. But if you happen to work for the government or you work for the military, they have the ability to destroy, which essentially would be a hack back, and they’d be able to take down somebody else’s system who is attacking them. Next, we have degrade. Degrade is going to reduce an adversary’s capabilities or functionality, perhaps temporarily. For example, maybe you’ve identified that a particular adversary is attacking you from a virtual private network with a certain IP range. You could block that range and that would degrade their ability.

But it’s only going to do that temporarily because they’re going to be able to go and get new services from another IP range and then reattack you again. The next offensive capability we have is disruption. When you disrupt something, you’re trying to interrupt an adversary’s communications or frustrate or confuse their efforts. Again, you can do this by blocking their IP address. You might add a second factor of authentication or something else. Anything you do that is going to interrupt their ability to communicate or frustrate or confuse their efforts would be considered disruption. After that, we have deny. When we deny, we are preventing an adversary from learning about your capabilities or accessing your information assets.

Deny is the best thing. We want to make sure we keep the bad guy out. And that is what deny is all about. In addition to keeping them out of our systems, we also want to keep them from knowing about our systems. And if we can deny their ability to learn what IP ranges we’re using, what type of servers or software we’re using, that is going to help us in defending our networks. And finally, we have deceive. Deceive is where we’re going to supply false information to distort the adversary’s understanding and awareness. If you use something like a honey pot or you start sending out false documents for them to steal from you, that would be a deception mechanism under the deceived category.

Now, as you go through and you look at the Lockheed Martin white paper, there’s a chart that looks like this. And they show you the different phases going down the left side based on the kill chain, such as reconnaissance, weaponization, delivery, exploitation, installation, C two, and action on objectives. And then going across to the right, you’ll see detect, deny, disrupt, degrade, deceive, and destroy. And then you can map out which technologies you have in each of these categories. For example, if I’m using web analytics, that is a detection technology that’s going to be focused on the reconnaissance phase. If I have a network intrusion detection system that might detect things in the we aponization phase.

If I’m using something like a vigilant user, that’ll be something where we’re going to detect things in the delivery phase. And you can see how this chart starts filling out based on the different technologies we’re going to use. Now, this is particularly set up for your organization. So you can use this as a template and then modify it based on your own defensive capabilities. Again, notice the destroy column. It is completely empty here. That’s because I’m a commercial organization. I don’t have the legal authority to hack back against an adversary, so therefore, I cannot destroy them. I can only detect, deny, disrupt, degrade, and deceive them. If you work for the military, though, you might have the legal legal authority to hack back, and that would allow you to have some destroy options. But for me, I don’t have those. And that’s why my chart looks like this.

4. Detection and Analysis (OBJ 4.2)

Detection and analysis. In this lesson, we are going to talk more about detection and analysis. Detection analysis is one of our phases of incident response. And in this phase we’re going to determine if an incident has taken place. We’re going to triage it, which means we’re going to categorize it and prioritize it, and then we’re going to notify relevant stakeholders. Now, most organizations are going to use ASEAN as their central repository of data for use in the detection and analysis phase. And so if you have a properly tuned seam, you’re going to be able to generate a lot of different alerts. When those alerts are gotten, you then have to go through and analyze those alerts. For example, here on the screen you can see a seam. There’s a large number of real time events and alerts. And all of these need to be manually assessed and triaged.

When we triage them, we’re looking at them based on their priority, their category and possible investigation if they’re severe enough. Now, as we go through and we do this, we have to use our known indicator as a compromise. If we have a known indicator, a compromise, or IOC, we can use these to trigger an alert automatically for us. And if it’s a known IOC, we can then use that to automatically categorize and prioritize that particular event. Because, for instance, if I have a known IOC for a nation state actor, that’s pretty serious, it might automatically flag that, categorize it and put it as a high priority for us to immediately act upon. Now, when you’re dealing with indicators of compromise, these don’t have to just be technical, they could be both technical and nontechnical.

And there’s lots of different IOCs that you can use as you’re going through your detection phases. For example, if I’m using anti malware software, this can actually generate an alert based on a signature definition being matched, showing us there’s a virus or malware on that given system. If we’re using a network intrusion detection system or a network intrusion prevention system, we can generate alerts automatically based on automated port scans that are being detected or other such things that match our signatures. If we have a host based intrusion detection system or a host based intrusion prevention system, we can generate alerts based on a cryptographic hash for important files that are being changed. For example, if I’m looking at Explorer exe, I know what that file should look like.

And if it’s hash changes, that means the integrity has been compromised and that should generate an alert. If I’m looking through the system logs, I can be looking in the Windows event logs, for example, for any log on events with new credentials or any multiple failed login attempts. All of those could be indicators of compromise that I would want to generate an alert for. If I’m looking through my network device logs, I could be looking at firewall log entries for any drop connections that were going towards a block port. If I’m looking for a security information event management system logs I have lots of different alerts that are generated based on different anomalous behavior and all of those could be tied to different signatures and possibly be indicators of compromise.

If I’m looking at flow control devices I might look at the amount of flow that’s being sent over the network. If there’s more flow going outbound of the network that could indicate a data exfiltration in progress and that could be an indicator of compromise. If there’s a lot of information coming into my network that might be a denial of service attempt. If I look at internal personnel this is one of my more nontechnical indicators of compromise. If I start looking at what employees say or do they might have witnessed a breach, for instance that would be a nontechnical indicator of compromise. If I look at people outside the organization sometimes I have a third party who tells us they’ve seen some sort of our information that’s out on the web.

And if that’s the case we may have been victims of a data breach. For example, if there was a big massive data breach and some security researcher found it they could come and tell us and they are somebody who’s outside our organization. And finally, we have Cyber Threat Intelligence as one of our sources. These are third party research and vulnerability databases that gather information about the state of the industry and they may find information about our systems as well and be able to tell us about that or that might be a good source of information to develop our own IOCs to look for those things inside of our seams.

Now, once the indicators are compromised or detected our incident handlers need to work quickly and effectively to classify the indicators into one of three categories benign, suspicious or malicious. If something is benign that essentially means we have a false positive. The analyst looks at that indicator they weigh the evidence they see and they determine that it’s nothing to worry about. Now, when the incident handler determines that something was indeed an incident it’s called malicious and incident response might begin. Now, if the incident handler is unsure they could classify this as suspicious and they can pass it up for further analysis by a more senior analyst if they need to. Now, another thing we can use as we’re going through all these indicators of compromise is automation.

This process is essentially a triage function after all. And with today’s technology a lot of this triage is being handled automatically through automation. But there is still a lot of work that must be done by a real, living, breathing human who can make the right decisions. Now, after all, automation can help us but it can’t eliminate this important function of incident handling by using a living, breathing, thinking human to do that work. So you may be wondering, how does an incident handler make the decision to classify a certain indicator into one of those three categories? Well, they begin by having a good profile of a network or a system. As I said before, if you know what normal looks like, then it’s easier to know if something is abnormal when you see it.

Using file integrity hashes, understanding your network’s baseline activity and knowing what the average memory and system processing resources used by a machine are can go a long way in understanding if something is within limits or if it’s abnormal. Now remember, no one person can know everything about a system, but an incident handler should be able to know who to call with the right expertise for a certain system. For example, if you’re working as an incident handler and you’re trying to determine if a particular SQL statement was malicious, suspicious, or benign, you might request the assistance of a database administrator who has more specialized knowledge in this area and can help you classify it correctly. Another thing that incident handlers use is event correlation.

By correlating an event across multiple systems, services, applications, or networks, the incident handler can look at the different logs and determine the exact effects that occurred. For example, maybe a host log showed that it attempted to connect to a database server to conduct an SQL injection. Well, if you correlate that event with the logs of the database server, you could see if the attack was successful. If it wasn’t, then you may just recommend disconnecting and reimaging the host which tried to do this attack. But if the attack was successful, you may now be launching a full Instant Response, starting with that database server. We’re going to dig deeper into this as we cover the later phases of the Instant response lifecycle. In the next section of this course, you.

• Category: Uncategorized