Cyber security incidents have transitioned from potential risks to operational certainties. The constant noise of attempted cyber intrusions, security lapses and IT service events requires all organisations to have some form of IT service management. Yet waiting amongst all these everyday events and minor incidents lies the big one; the big fish security incident which, if not managed properly, could take the organisation down, or at the very least result in severe data losses, operational disruptions, and reputational damage.
Today it is not possible to stop every security attack, but a good security incident response plan will limit the damage done, reduce cyber insurance premiums and better safeguard the return to business as usual.
These plans should hopefully only be used infrequently but when they do, they need to work quickly, and they need to work well. So, what do we need to do to make sure they work when most needed?
Understand when and how the plan should be used
Be clear on what the plan needs to achieve; typically bringing people and available information together to make informed decisions. This requires analysis of the range of potential security incident scenarios and what would be required at each point across the incident lifecycle of detect, access, respond and recover. As the incident develops a wider range of internal and external stakeholders, of increasing seniority, will need to be involved. Breaking these into functional layers (Gold, Silver and Bronze teams) with severity thresholds between each will ensure proportionality. Stakeholders also need to be clear what their role is, and what it is not, and to have rehearsed it.
Build on existing structures
When setting out to design a security incident response plan it is tempting to design a special ‘big red button’ process for major cyber attacks. Yet most organisations will already have many valuable structures that can be brought together in time of need. For example, IT service management and any form of security event management (or better still a Security Operations Centre or SOC), should already be performing incident and event triage of lower severity incidents. At the other end of the scale the executive or senior leadership team will be used to making decisions on pressing strategic matters. Instead of building a new approach it makes more sense to bind these existing structures into a scalable process to take an emerging security incident (such as a detected network intrusion) from technical teams through escalated management layers.
Whilst a cyber security incident or data breach will be the priority for security professionals, others in the organisation will also have threatening incidents on their own radar. It is worth considering whether the same security incident management plan, or at least the upward escalation parts of it, can be common across multiple disciplines. For example, once a security incident, IT incident or business continuity disruption reaches a certain threshold of severity they could all flow into the same major incident management structure and use the same mechanism for senior management invocation. This means it will be more familiar, and better understood.
Ensure ownership, expertise and maintenance
All being well the security incident plan won’t be regularly used so documents may only be referred to infrequently and most participants naturally will not think about it until it is needed. Without technical ownership it is easy to build a new process only for it to become outdated as the organisation changes.
To deal with this a senior manager should be accountable for the organisation’s overall major incident arrangements. To get buy-in for this level of support it might be necessary to illustrate some examples of the potential consequences of a large security incident; unfortunately, we are not short of these. Senior managers should also be shown some of the challenging decisions they may need to make. They will become engaged once they realise that they might need to decide whether to pay ransomware, disconnect their IT operations from the internet or hold a press conference to apologise for loss of personal records.
Make testing and exercising part of the business calendar
All plans should be confirmed as being fit for purpose through a series of tests or exercises. Like a play, rehearsal is necessary to make sure you perform on the day. This should start with tabletop walkthroughs before moving on to more rigorous simulation exercises. Separate teams (such as the SOC or the Major Incident Management group) can be exercised one by one but for complete assurance the full incident response system should be rehearsed. This will require one exercise scenario to flow from the initial incident identification, its triage and assessment and then to management decisions. Whilst such exercising will take considerable effort and expertise to design and deliver they are the only way to provide real confidence that the plan will work effectively. It also raises awareness and advocacy levels in the leadership as they have their own stories of what it felt like to take part in the exercise and the learning they took from it.
Finally, after every exercise or invocation there should be a commitment to capture the lessons learned, make improvements, and strengthen the response for next time.
Today all organisations need a security incident management plan. A practical approach focusing on the points discussed above should allow a plan to be created and then iterated over time.
Sam Lascelles is a resilience and security expert at PA Consulting