Alright, it's time to take a look at containment scoping and strategy and talk to so little bit about what that is. Now this is our introduction to the containment part of this skills path and one of the things that you have to understand here is containment is really not the same as eradication. I know that there is some confusion in the industry where people will get these two phases mixed up, but we wanted to make it clear that containment and eradication or not the same thing. Containment is more like a kind of figuring out where you are, where the threats are. If there's malware, an environment where it is where it spread to that type of thing, and we're trying to figure that out so that we can start to come up with a plan to eradicate, okay? So to begin with, it's more of a strategy than it is a step. Even though we kind of alliterate it as a step and we show it as a step, it's really more of a strategy. And then once you form the strategy, you can do certain steps to achieve whatever your organization defines as containment. Now this can drastically change from incident to incident, and it must be clearly defined in strategy and even in your incident response policies and procedural documents. You want to make sure that you've defined what containment means. There have been at least a few times where I've been inside environments, helping them handle incidents and they were very loose with the definition of containment and to them admit something that it really didn't mean to the rest of the world. So you had upper management looking at these reports thinking one thing was going on and thinking they were at one step in having this thread handle, then they weren't really at that step. So you need to make sure that your definition of containment. Number one it be good if you could align it with industry definitions, but at the very least it needs to be consistent throughout the organization. As long as the organization agrees with it and the whole organization knows what it is, then it's probably going to be fine. [COUGH] Now it needs finite beginning and end points, otherwise you could have an incident that goes on forever and you never reach the state of containment if you try to get two tight, would your containment definition? And one of the main mistakes that organizations make on that is you have to understand that containment does not have to be a 100% guarantee. That the unknown exposures or the threat is completely 100% identified and everywhere that you can't really, make that a quantitative statement and say for certain, because you'd really don't always know and you can't base it on it. So what you have to do is make sure that you come up with a definition of here or are containment steps. And you can base some that I'm what I'm going to tell you, but you should also look at your internal incident response policies and say look at, here's what the policy says should happen. Here's what containment means, let's do these things, let's get to this state, and once we've executed this plan, and we've got to this state, we are in containment and we can move on. It doesn't matter what you think might be going on or what you might have missed. You follow the procedure, you went through those steps that gets you to containment, and then you can move on to eradication, right? So make sure you keep that in mind. The definition of containment is important because that could be the thing that kind of keeps keeps you hung up there. Now there are goals, containment strategy should aim to do things like you want to make sure you, before anything else assess the operation line affect the state of devices and resources. Because part of containment strategy is you have to figure out where this thread has spread to wear isn't any organization, if it's an infection, if it's malware, how many devices are infected with this malware? How many files are infected, would it, where is the malware made it to, right? And it's really you can't do that until you do an assessment to find out the operational state of these devices and whether or not they are infected and you will have come up with some at least some beginner IOCs that you picked up in the identification phase that identifies that you've been compromised, right? So those can help you kind of get to containment wherever you see those indicators and that device is probably compromise, or that traffic or that file may be compromised. So at that point I once you've identified all of the things that you know to be affected. Based on the information that you have at the time, then you can start to kind of move around what your actual containment strategy is going to be. You also want to make sure you minimize or eliminate it spreading further, and part of doing that, You have to know where it already is. You know before you can contain something you have to see what is. If you spill water on the floor, and you can't see everywhere to waters reached, how can you contain it? But if you see where it is, and you know where to put the paper towels, you know what the card, and off to keep the water from going into other places, so you have to make sure that whole assessment pieces solid. Now a lot of this is going to require you to put proper visibility into your environment. Way before an incident happens. You want to make sure you determine the immediate steps to take next for containment to happen, and that's going to be based specifically on the other things that we just talked about. You also want to make sure you're protecting critical resources, and your effort to contain doesn't prevent are doesn't cause any other damage. For example, imagine if you knock over a small cup of water. All right, I'll keep using the floor analogy here, and then you jump to throw a bunch of paper towel on it to contain the incident, and in the process of you doing that. You knock over the water cooler, and now you've spilled and even much bigger amount of water on the floor, right? So you don't want to trip over yourself, or trip over your own environment by rushing to containment without having good scope and good handle, because you end up being that person or that group as an IR team, that knocks over the big water cooler, in an effort to clean up a spill from a small cup of water. Right, so that's why these things have the cabinets or to happen in order. You also want to make sure that you limit the scope, and define incident specific scope. In other words, what we mean by that, is you want to make sure that you scope out, what your containment efforts going to be. You don't want to be distracted by things that may be related to other incidents that you've not yet discovered. Because what happens is you end up with containment scope creep, where your containment effort just continues to creeping, and before you know it, you're weeks into the incident, and you're not anywhere near. Eradication or containment yet, so make sure you scope it and you stick with the scope, if you need to move on to something else, you can come back and do that. So let's talk about what we mean by assessing the operational state. Tools should be deployed. Memory forensics tools, live host based agents like things that run the machines. All of these things should be in place like now, right, in your environment, some of the stuff should already be there, because if you try to deploy it. Post incident or after the incidents happen, it may not do you very much good. Some of the tools, that is to say, if it's some infection that you think maybe like a rootkit or something like that. That's a kernel level rootkit, will guess what deploying tools are deploying agents to run on that device and look for things for you after that rootkits really gotta handle, is going to give you 0 assistance, and that would if you understand the nature of how rootkits actually work. So, if you have your stuff deployed ahead of time. And rootkit gets deployed, that puts you in a much better position to find it. Look at it, get its IOC, get it signature, and all that type of stuff. So you want to make sure that you have these things pretty deployed, even in your in your planning phase. Up yet are you want to ask these questions to the our team. Ask these questions to the network team, into the security teams, in all the other cyber operations teams,about these tools and things, because you don't want to wait until an incident before you start trying to take advantage of these, it leads to you eventually getting behind. Right so. You want to minimize the spreading of any threat. As we said, you using IOC's season benefis earlier, and detection or even maybe in identification depending on how early the IOC started to pop out. You want to identify the extent of the threat, using the IOC's you want to try to figure out right here, the things that we know here to patterns that we know about based on what we know, because that's really all you can ever based on not let anybody ever tell you that you're going to know 100% of what's going on in the environment at all times. Without, these things happening, because environments to change so identified extended threat using the IOC's that you have, and let you know about currently. And then maybe if you want to bring in some outsourced Intel, about those threats, or if that's a threat that's not in the industry, then maybe look at some out external Intel to help you identify other IOC's that maybe didn't show up in your initial detection. You want to also isolate systems which are known to be compromised. And this is part of the whole impact assessment, that we talked about doing earlier, it moving that system or isolating that system or take. In that system, offline is going to adversely affect day to day operations to a point of criticality, then maybe you don't do that. But you have to kind of go through your playbook do these what we like to call tabletop exercises and kind of plan this out, see what it would play out to kind of map these things out. You want to also collect memory dumps, hard drive images, traffic logs, all the other things that may be applicable to helping you to look for signs to see just how far this thread has spread, and you want to invoke any cloud services specific containment tools and protocols that you may need as well. I keep stressing this, don't forget to reach out to the cloud service provider and asking these questions in your planning phases. What tools do you have available to help us with incident response, here's what we normally do in our environment. What can you do to help us do that in your cloud environment since we don't have that layer two and layer one visibility like we do in our premise environment. So ask these questions early so that when you get into an incident, you have these things figured out already. Alright, as far as determining next steps, this always comes up. What do we do, we run into a situation, there's an incident we know some devices are affected, we've done our assessments, we ran our IOC checks, we know where things are. So what do you do to these effected systems? Do you shut down, do you disconnect them, do you continue memory forensics and studied the threat actors, what do you do at that point? Now if you shut it down, it could destroy the best evidence, because sometimes specifically in live attacks a lot of times the best evidence is actually in memory. And if you shut that system down without considering that you probably destroyed the best evidence, it could also break critical operational procedures and functions and will talk about this in one of the next skills pass here, coming right up where I'll give you some scenarios that I've worked on in real time and you will get to see how this impacted them? You could also disconnect the system from the network, but leave it running. Now while that's not as impactful as just shutting the whole system down, it still may be equally critical. If it's like a network or bandwidth or time sensitive operation going across the network across Internet to it from that system. Now, if you do either one of these top two things, it could alert the threat actors, well, okay? A third option is continue memory forensics, study the threat actor. This is not as likely to alert the threat actor, but it will likely allow threat actor to continue what they're doing, so if you really terrified of what they're doing and you want to stop it right away, now that kind of pushes you back up into the territory of the first two options. The point here is I'm not trying to tell you any one of these three options are going to work in every situation, but know what the outcome of these things are, so that when you're in a situation you could pick from these and apply the best solution to whatever that situation is. And then lastly you want to make sure that you ensure scope limiting, in other words, make sure that when you're scoping out your containment efforts and things of that nature, you limit that scope to that specific incident and the IoCs that you know about, right? You don't want to be in the process of going in and trying to do a containment, and then as you're doing containment, you're also constantly expanding the IoCs. If you at that point, and you're finding IoCs every hour while you're doing containment, that means you're really not ready to be in containment yet. You should still be in detection, okay? So you want to make sure that you don't put the cart before the horse, and jump into this too fast so make sure that as you scope this out that you actually doing containment activities and not doing other things, right? When you're at the end of this phase, you want to make sure you do get documentation and shoot the documentation details each contained threat. What if the containment happened, the resulting data will be critical for the next phase when you get into investigation and eradication, it will help those people do those things, if that's not you, if you're not part of that part of the effort. It's also useful for doing the lessons learned in that type thing as well, right? So I hope this skill session is being good for you. I'm looking forward to seeing you in some of the other ones as we move on through this path. Thank you.
