Damage Control and Assessment

In this video, we’re talking about damage control and assessment. Now, no one wants it to happen, but it will. Some sort of disaster is going to hit you. Viruses, distributed denial-of-service attacks, ransomware, insider threats, USB drops, et cetera. Something’s going to happen to you at some point.

So the most important thing is to try and relax. After all, you did have some sort of plan in place to handle this type of situation, right?

Well, the thing is you always want to plan for the worst. And one of my first bosses, when I started doing IT, had a slogan. They used to say “hope for the best, plan for the worst.” Now that might sound a little pessimistic, but it’s actually a really useful mantra to have when it comes to IT work, network security, things like that. We always want to hope for the best. We want things to run properly. But we do need to plan for the worst because something is going to happen at some point. So some sort of disaster is going to happen at some point. And this could be anything.

It could be a malicious hacker attack, it can be insider threat, it could be accidental deletion, it could be hardware failure, we could have a flood, we could have a hurricane, we can have earthquake, power outages that wreck our equipment. Some sort of disaster is going to happen to us no matter how carefully we plan, how prepared we are, how much money we throw at these different problems, something is going to happen. That’s why we do need to plan for the worst. Even if most of these scenarios never come to light, we need to have some sort of plan just in case because that one time something happens and we’re not prepared for it, it could be devastating.

Now having some sort of plan worked out ahead of time is going to be crucial. These plans should cover a variety of situations. Our plans should be well documented and accessible. And our plan should be tested.

Now about your plan. There’s a lot of premade templates that online that can give you an idea or you can get it from different books. Now these are pretty good if you’re not sure where to start and you could use these kind of premade plans and build around it for whatever your use case is. Your plans should be made in conjunction and approved by management. Now for the reason this is, that I’ve seen a lot of IT people before come up with all these wonderful plans for how things are going to go if there’s a disaster and how they’ll recover, only to have management say, well, no, you can’t do that.

One, either we’re not going to give you the budget for it or, two, this goes against company policies or it might go against, say, if you’re a hospital, might go against HIPAA compliance, for example. Well, you can’t do that. That’s actually a violation of patient agreement - patient privacy. This is why we need to make sure it’s approved by management, ultimately, because management is the one that could approve or shut down our plans. Your plans should be established - should establish a chain of command. And this is generally to help who reports to who, and who needs to get involved with what, and who has authority to authorise what you need.

And in an emergency situation you do need to know this quickly because if there are things like, well, we need to pull this critical data server offline in order to avert disaster, well, turning off that server might, say, effect 100,000 customers for example. Well, just pulling the plug without getting authorization, well, that’ll probably get you fired. So you do need to know who you need to report to for what situation. Again, you need that authorization. You need to make sure that it’s going to be OK that you could do this. And your plan should be easy to follow it for everyone involved.

Now having an overly complex plan that other people don’t understand their part, that’s not going to do you any good. Your plan should be easy to follow for everyone.

Now different plans for different threats. There is no one size fits all when it comes to a plan. For example, if you’re infected with cryptoware, generally you want to isolate the original infected machine, preserve the infected file for decryption later, remove it from the network so it can’t spread throughout the network, et cetera. That doesn’t exactly translate to, say, you have distributed denial-of-service threat because in that case, if you’re getting a DDOS attack, you want to identify the offending IP addresses. You want to blacklist it, you want to sink hole them, and you want to contact your ISP to try and sink hole on their end.

Now what do you do if your server room catches fire, or there’s a flood, or there’s an earthquake? What do you do and who do you report to if there’s hardware data stolen, like your laptop gets stolen, someone breaks in your server room and starts pulling out the hard drives and runs off with it? You need to know who you need to report to. So, as you see, there’s different plans for different threats.