Cyber Incident Response – Boardroom Planning is key

Reacting immediately to a cyber event could save your reputation.

2019 is on track to be the worst year so far for data breaches, with billions of records exposed in the first six months. As a result, Incident Response (IR) is gaining more high-profile attention in the media and, crucially, in boardrooms across all industries. But according to PWC, less than 50% of global businesses have any plan in place to deal with a cyber breach, whether malicious or simply human error.

Ensuring that everyone in your business knows what to do as soon as a breach is detected is a critical priority that may save both your reputation and your bottom line. However, are your security professionals providing enough information and involving the right people to ensure management teams make sound investments and strategic decisions to shape incident response plans?

I remember once being asked if sending the IR team on a touch-typing course would be beneficial – the thinking being that they could out-type hackers during an attack. The joy of epic keyboard battles notwithstanding, it was apparent to me that the reality of incident response (and sometimes IT in general) hadn’t been made clear to a group of people who were key players in the process. Without naming and shaming, there are plenty of examples of public relations faux pas (to put it mildly) in the time following a major security incident, and they all demonstrate the importance of keeping your Top Brass informed. This article will give you a primer on a typical incident response process, which will hopefully add more context to what your public relations team may tell you to say, or why your technical team have locked you out of their office!

The anatomy of Incident Response

The incident response process can be described as having six phases:

Phase 1: Prepare

As you might imagine, this is the phase that requires the most attention and effort. Good preparation needs all areas of the organisation to contribute, and this process should be led by senior management, as the incident response process will either be dictated by, or dictate new, business processes. Preparation will involve everything from defining roles and responsibilities, to deciding a communications strategy, to implementing uniform and thorough log collection on your computing and network infrastructure. Remember the old adage: “Fail to prepare, prepare to fail”. In reality this is actually a continual process, so part of your initial preparation should be to define suitable processes by which you can onboard new systems and review measures for existing ones.

You should seek assistance here too; getting expert help to check how prepared you really are, and to seek out any gaps in your defences will pay dividends in the long run. The cyber threat landscape changes on a daily basis and reaching out to recognised experts is always a good option. You can also invest in cyber insurance or subscribe to a recognised incident response service, these are good options when you may not have the internal resources to handle a cyber event.

Phase 2: Identify

This phase is relatively short, but decisive, and is where the preparation starts to pay off. With this being the first ‘live’ step in the incident response process, it’s vital to start documenting everything being done. Your preparation should have included a standard format for documentation, and it should start with the basics; who’s handling the event, what time the event was first reported, what systems are affected, etc. Your responders will then start working through a predefined checklist to determine the state of the affected systems and compare them to an established baseline for what’s considered normal. (Notice that I’ve been using the word “event” rather than “incident”; part of your preparation should be to define what actually constitutes an incident and, until it’s confirmed that an event meets those criteria, it’s still just an event.) During this phase, responders will use the information gathered to determine the next steps, which may be to downgrade the event and exit the response process, monitor the event for a period of time to gather more data, or declare an incident and escalate.

Phase 3: Contain

If you reach this phase, it’s because you have an incident in progress. The natural response is to immediately try to contain the problem, but in order to do so effectively you must first confirm what type of incident you’re dealing with. While it may seem counter-intuitive that this isn’t performed during the ‘Identify’ phase, remember: during that phase you’re identifying the nature of the event, not the type of incident. A Distributed Denial of Service (DDoS) attack, corporate website defacement, and an unauthorised employee accessing sensitive corporate records are examples of potential incidents. Each of these examples warrants a very different response, so effective action requires effective classification of the incident. Likewise, incidents of some types might require notification of other parties, such as senior management, partners, customers, or even government bodies. Again, this will have been covered during your preparation phase, along with suitable immediate actions, such as disabling accounts, blocking traffic at the firewall, and so on. These actions come with risks and making a wrong decision could make matters worse, rather than better, so think about them carefully beforehand. An example of a poor response would be pulling the power on a compromised machine – it destroys valuable evidence and, while it may stop the incident in progress, the machine can’t be investigated while it’s off. Instead, it would be better to isolate the machine in a non-invasive way, such as blocking traffic at the firewall, so that malware can’t spread to other devices. This is important because it’s at this point that your responders will collect volatile system data, such as memory images, so the actions they take will do as little to upset that state as possible. Once your responders have confirmed that the incident has been contained, the process can move on to the next phase.

Phase 4: Eradicate

The incident cannot progress beyond this point, so it might not be until now that you can get much information from your responders. I can tell you from personal experience that having the CTO and CEO breathing down your neck while you’re trying to stop an incident is counterproductive; let your responders work and they can give you a more meaningful update during this phase. It’s now that the hunt begins for the root cause. The type of incident will dictate how to go about this, but an example would be finding an attacker’s malware implant on a machine, ensuring it’s copied in a forensic image, then restoring the machine to a known good state and tackling whatever vulnerability was exploited (e.g. installing missing patches). The last step in this phase is to run full analysis across all systems to ensure the vulnerability doesn’t exist elsewhere – assume it does, and assume the attacker already knows that.

Phase 5: Recover

Once the hole has been plugged and everything has been returned to a safe state, you’re ready to resume BAU activities. It’s prudent to continue more stringent monitoring during this phase, rather than standing-down immediately, in case of any repeat events. For instance, a DDoS attack may be a precursor to, or a distraction from, a network intrusion, which you’ll be in a better position to find and eliminate if you’re scrutinising your network logs more than usual.

Phase 6: Follow up

As much as you might want to wash your hands of the whole ordeal, the follow-up is just as necessary and important as the preparation, as it closes the loop. This is where the documentation and analysis pay dividends, as this phase is all about lessons learned that feed back into your IR preparation. Likewise, the documentation should be reviewed, written-up in a report, and safely stored as important reference material for any future incidents, or even regulatory audits.


As you can see, even describing the phases of incident response at a high level is quite involved – I could do an entire series on the preparation phase alone – but the benefits of having a solid plan in place far outweigh the hardships of getting there, because you can quickly regain control of a potentially dangerous situation. Ever the stoic, I’ll paraphrase Kipling: “If you can keep your head when all about you are losing theirs . . . yours is the Earth and everything that’s in it.”