Alright, let's go ahead and take a look at cleanup in relation to eradication. This sounds like it might be an out of place topic but if you really think about it, when you're going through the process of eradicating threats, there is going to be quite a few tools and things like that, that you might deploy into the environment for the simple concept of eradication that may not bidder through normal operations, you know, you might have added things. You definitely going to maybe re-do some of the network configuration, reroute some stuff, setup some things like that. You just want to make sure that you have a documented process for going through and kind of getting rid of those things, or rolling them back out of the environment. Really you want to think of it in terms of there's going to be host-based stuff. When we say host-based, this may be host-based, local or premise based, or it could be host-based in a whatever respective Cloud environment you utilizing as well. Sometimes these tools can be disruptive to deploy and believe it or not, they can also be disruptive to be removed or pulled back in so you want to consider that. Ideally, you want to do practice, run-throughs, and things like that when there's not an incident to see what the impact of deploying these tools would be and then what the impact of rolling those tools back will be. That's a very important thing to do ahead of time, you don't want to wait until you have an incident to see what the impact is going to be. This is something that we may talk about again in recoveries as well, because you're kind of going to be doing the same process of getting things back to normal operations, that's really the last step in doing that. In the process of that, it may mean disconnecting some things that you connected just for handling the incident, et cetera, and we want to see what that actually looks like. Now, there's probably or there could be some network changes, you could set up additional Span ports or mirror ports because you need to get a different view of traffic and how traffic is getting from one place to the other. You might have identified a thread that's trying to communicate in a certain way across the network, so you definitely could have set up some span ports or port mirroring, you could have change some routes to confuse a piece of malware in the sending its payload somewhere other than where it was intending, and all other things you might have done in the process of just containment or eradication. This is kind of your last jumping off point to get rid of that stuff before you move to recovery. There might be some significant changes to network monitoring. Like you might want to put some stops into monitor certain parts of the network or even certain devices more than you normally do, you want to remember to go back and undo that to put things again in a true, what we call normal operating state. That's very important to keep you from over utilizing resources and several other things. Remember, some systems may have been shut down because if you think about it one of the recommendations depending on the incident, is to shut a system completely down. That may or may not be the recommended action given the situation but if it is in those regards, you want to make sure that you've definitely went and got those systems back up. Consider the impact of bringing up a bunch of systems at once you might want to stagger down, you might want to bring them up in a specific order. For example, I've seen situations where people have bought up things like domain controllers after they bought up the host machines that depend on or communicate with those domain controllers. What ends up happening is the host machines are not authenticate properly because the domain controllers not up yet or are different variations that are. They have to communicate further across the network to other domain controllers that are kind of like their secondaries and it takes longer, and stuff can just get out of whack very easily if you don't consider that. But some heuristically generally, this reflects on how important documentation is, because you want to be able to definitely go back and see how you've deployed these things. It's harder to go back and try to real stuff back in if you don't have clear documentation as to what you rolled out, right? So the documentation is key to help you be able to cleanup in a very efficient and very fast manner. Because you know exactly where everything is, you follow that documentation and really just undo everything you did, right? Remember bringing up a large number systems instantaneously can be operationally impactful, so you want to be careful with that and consider what the impact is before you do it, for that reason alone. So hopefully, this was helpful for you and we look forward to seeing you again in another skill session.
