The more proactive you are, the less of an impact any breach will have on your operations.
The initial phases of a breach are often the most critical: The intruder is counting on your confusion, your lack of a plan or a clear chain of authority, and any early missteps. Given that it’s only a matter of time before a breach happens, what can you do after encountering an incident to minimize the damage?
For businesses of all sizes, incident response planning infrastructures have gotten very complex, with many interconnected relationships that might not be immediately obvious — until something goes wrong. Here’s how you can prepare for an incident in a well-thought-out and organized manner.
Set up your taskforce
The first step is figuring out who should be part of the planning process and who should be an official member of your incident response taskforce. The two groups aren’t necessarily the same people, as even some highly-skilled planners aren’t good at being in the thick of things in the moment.
As Daniel Bryant writes, “Because developers have a better understanding of the ingredients they have put into the code, they likely have a better understanding of all the dependencies downstream.” That represents an important change, because traditionally, developers were often not included in these kinds of conversations. The more complex your application’s infrastructure, the more you need the developer perspective.
Once you have your people in place, the next step a business can do is make use of an incident management tool to automate and centralize all the information and communication among the various departments that will be responding to the breach. At a minimum, you need to set and document a clear series of processes and run a drill in order to identify deficiencies in your plan.
Part of your plan is to do quick troubleshooting and root-cause identification. “Observability is critical to getting to the bottom of the problem,” says Bryant. Ideally, in your business, you should identify the particular people that excel at this skill and make sure they are included in your incident response taskforce as I mentioned above.
Know your bottlenecks
Make sure you account for the various components that make up your online production systems. Don’t leave anything out, which means careful analysis and pre-testing as much as you can.
One common practice is to employ what is called chaos engineering. Too often, we don’t think about our IT infrastructure holistically, and when a breach happens, we try to just plug that particular problem and move on. Chaos engineering forces us to move into a more global view and zero in on the weak points before a potential hacker does.
Keep a clear head
Finally, keep up with patching your systems. As we’ve recently discussed, even a few days’ delay can cause disaster if a hacker worms their way into your network.
The most difficult time to think logically and methodically is during an emergency situation. With this in mind, the more proactive you are, the less of an impact any breach will have on your operations.