Anyone who has had a leadership role in IT knows that when discussions about disaster recovery and business continuity start, your work life is about to become either a lot more interesting or a lot more complex. The trouble is, when other business functions think about incidents that could impact business operations, they invariably draw their attention towards the technology they rely on.
Craig Searle, one of the co-founders of security consultancy Hivint, discussed this challenge at the recent AusCERT 2017 conference. He discussed incident response by taking a non-technical view, suing clinical examples of how healthcare deals with crisis.
Describing himself as a "reformed nerd" Searle's focus is on co-ordinating incident response. That goes from creating frameworks to assisting business in the throes of an attack.
"Incident response fills a gap for an emotional need for technical guys to be the guys that come in and save the day," said Searle.
Unlike penetration testers who break into a business and highlight a specific risk, incident responders have a much broader scope, having to react to anything from a ransomware attack to a nation-state information breach.
"As an incident responder, you get to save the day. You only turn up when an organisation is having their worst day ever and you are the solution to that problem".
In contrast, incident managers must deal with management and communicating what is happening throughout an organisation. Often, this is challenging as the volume and velocity of information during an incident is substantial.
It's important to note, said Searle, that the fundamentals of infosec don’t change during an incident. It is largely a resources game where the odds are stacked in favour of the attacker.
Most cybersecurity incidents escalate into a crisis because of poor preparation, poor understanding and poor response. But it doesn’t need to be this way said Searle. But many incident responders immediately jump to a technical solution before evaluating the best course of action even though many of the issues are human or organisational.
This is where a luddite, or non-technical, manager can be crucial.
"They will provide focus," said Searle. "They will only solve the problem you need to solve. You don’t need to put out every single spot fire. You only need to pick the major one and solve that first".
They will also provide a sanity check around decisions, questioning things to make sure your actions are reasonable and don’t exacerbate the situation. They will also "guard the fan" said Searle, "preventing the shit from hitting the fan".
Most attacks fall into four categories that can be planned for. Denial of service, social media and website defacements, data breaches and exfiltration, and malware can all be anticipated and planned for.
Searle used the Center for Disease Control (CDC) Crisis Continuum as his model for incident response.
The model starts with the premise "Crisis doesn’t occur spontaneously; it is the final stage along a continuum of behavioural and emotional responses". Incidents escalate because of emotional and physiological responses. These can be identified and managed so incidents don’t escalate into crisis.
An important, and often under-considered, element of incident response is knowing when an incident is over. That means defining what "normal" means in your organisation. This means understanding things such as normal transaction volumes and their sources and what constitutes unusual activities - what Searle called "canaries and thresholds".
One of the things Searle noted was, when looking back at an incident later, many potential indicators were there but missed. For example, a spike in account lockouts could show an attempt to breach credentials. And while this might be managed by an IT system that doesn’t fail, it highlights that a business issue, rather than a technical one, might be an early indicator of an incident.
Read more: Security leadership and the role of AI
Following those early stages, there needs to be a communications plan that makes it easy to know who to tell that something might be happening. At this stage, there may be some anxiety but it's not clear that there's a major incident in progress that could escalate into a crisis.
If things continue to escalate, Searle says this is when things reach the "Something bad" moment. Often, there are a lot of conflicting ideas, many driven by emotion or innuendo that are not helpful in the resolution process.
"For the luddite perspective, this is your time to shine," said Searle.
The focus needs to be on answering "what do we know for sure?" This allows you to focus and solve the problem need to be solved. Mistakes made at this stage tend to compound massively later.
If things get past this point, you will reach the point where your incident becomes a crisis. Having lost control of a situation, often with limited understanding of what is happening, and they can react unpredictably and panic.
For the luddite incident manager, the goal needs to be on making data-driven decisions that focus on business priorities. But the luddite is not there to solve problems. Their role is to create an environment where the experts can do their job.
There will be some people in the business who have a desire to be involved in the incident response. Searle said it is important to give them a task that will engage them and provide you with a useful service. For example, if there is a micro-manager who could potentially interfere in the response, make them responsible for executive communication. This will appease their ego and fill a need in the response team.
Once the incident has resolved and you have returned to business as usual, it is important to conduct a review to assess what happened and how you responded in order to learn and improve.
Read more: Thought Leadership in Privacy