Cool Heads and Clear Minds: Getting Your Incident Response Plan Together

Written by

In 2018, serious cyber-attacks are inevitable. As a result, effective incident response is crucial to cybersecurity readiness. Phil Muncaster investigates

There were a few raised eyebrows when Dido Harding presented her keynote speech to attendees at this year’s Infosecurity Europe. Wasn’t she the CEO that presided over one of the most infamous data breaches of recent times at TalkTalk: one which stemmed from systemic security failings at the telco and was compounded by catastrophically poor incident response? As it turns out, her presentation was relatively well received: full of contrition over the mistakes that were made and packed with constructive suggestions for CISOs and board members on how to avoid them in the future.
Unfortunately, CEOs and boards the world over have yet to learn the same lessons as Harding. Yet increasingly companies are judged not just on whether they could have prevented an attack, but on how well they respond. Master the art of incident response and you could minimize the financial, reputational and regulatory impact of an attack while potentially even escaping with your job intact.

When, Not If
It’s well understood by most in the cybersecurity space today that their organization will inevitably be hit by a successful cyber-attack at some point. A UK government report earlier this year claimed that 43% of businesses experienced a cybersecurity breach or attack in the previous 12 months, while Risk Based Security claimed there were over 2300 reported breaches globally in the first half of the year alone, exposing 2.6 billion records. These stats are both likely to represent just the tip of the iceberg.

That’s not to mention the impact of ransomware, cryptojacking attacks, banking trojans and more. The cumulative effect of this new dynamic, weighted in favor of the attackers, is to emphasize the importance of incident response. Spot an attack early on in the kill chain and you could kick your adversary off the corporate network before they’ve had a chance to exfiltrate much data. If you’re too late for this, you could still notify customers before the cybercrime underground has had a chance to monetize the stolen information. 

The first step usually is to set up a workshop involving all stakeholders

The Arrival of the GDPR
Getting incident response right has been added extra urgency after the GDPR was passed – bringing with it a mandatory rule for notification of major breaches within 72 hours. UK data regulator the Information Commissioner’s Office (ICO) has a checklist which illustrates the kinds of things it expects. At the very least there should be “robust breach detection, investigation and internal reporting procedures in place,” with responsibility for managing breaches placed in the hands of a dedicated individual or team. Also key are processes to escalate incidents internally so the appropriate team can decide if a breach has occurred, and to inform affected customers “without undue delay” if the worst has indeed happened. Interestingly, the ICO claimed recently that organizations “are struggling with the concept of 72 hours” and that some breach reports are being sent incomplete.

The lesser known EU NIS Directive for CNI providers in the region also covers incident response, mandating organizations notify the authorities of any severe incident which might impact service levels “without undue delay,” and “take appropriate measures to prevent and minimize the impact of security incidents to ensure service continuity.” Both regulations come with major fines for non-compliance, of up to €20m or 4% of global annual turnover.

Learning from Others
It’s not hard to find examples of poor practice in this space over the past few years. Equifax is one of the most recent: fined £500,000 by the ICO for its failings. Aside from the fact that the attack came from an Apache Struts vulnerability which it knew about but failed to patch, its response to the breach of over 145 million consumers’ most sensitive personal credit details was poor. The firm took around six weeks to disclose, during which time some execs sold shares in the company. Then it directed users to a separate site to get info on the breach: a site some browsers flagged as a phishing threat. Customers reportedly even had a hard time getting the info they needed on whether their data was affected. Then the firm was forced to clarify T&Cs which some customers interpreted to mean that if they signed up to credit monitoring they would forfeit their chance to participate in class action suit.

Other examples include TalkTalk, which rushed almost too quickly to communicate with its customers following a 2015 breach, first speculating that four million customers may have been affected and erroneously suggesting the suspected theft was the result of a DDoS attack. It was also unclear whether customer data was encrypted. Meanwhile, a National Audit Office (NAO) report on the NHS response to WannaCry, which led to an estimated 19,000 cancelled operations and appointments, revealed the Department of Health’s plan had crucially not been tested at a local level. 

“As the NHS had not rehearsed for a national cyber-attack it was not immediately clear who should lead the response and there were problems with communications,” the report explained. “Many local organizations could not communicate with national NHS bodies by email as they had been infected by WannaCry or had shut down their email systems as a precaution.”

Elsewhere, Yahoo is notable for the sheer length of time it took to discover a catastrophic breach of customer data: three years from the 2013 date of the incident before it estimated one billion users were affected, and then almost another year before revealing the actual breach was three-times that size. In Uber’s case it was also ‘better late than never’ but with a twist. In this case, the firm infamously decided to pay off the hackers and keep a breach of 57 million users a secret.

Developing a Plan
So what does best practice look like when developing and executing an incident response plan? Experts agree that it’s vital to include stakeholders from all parts of the business including comms, legal, HR and others. SANS Institute instructor, Mathias Fuchs, tells Infosecurity that organizations must consider: a communications plan for dealing with press and shareholders, a predefined “circle of trust” governing internal information flows, preapproving any necessary changes like firewall blocks or proxy configuration as standard operating procedure and open lines of communication with law enforcement. It’s also important procurement is involved in planning as cloud providers must be chosen with incident response in mind, he adds.

“Assuming a sponsor inside the organization has already been defined, the first step usually is to set up a workshop involving all stakeholders. In my experience, no battle plan survives the first shot, so the key takeaway from this workshop usually is a common understanding of what the organization perceives as a major security incident as well as a basic understanding of where certain capabilities are located, i.e. insourced versus outsourced,” he says. 

“One of the most important and also complex facts for organizations to understand is that incident response can never be treated as a project. A project manager always assumes that he or she sets the pace and controls what happens. That is fundamentally different in a major incident, where at first the attacker is in full control of the situation. As a consequence, the major goal of successful incident response is getting back and staying in control as fast as possible.”

Once the plan has been drawn up, the organization needs to ensure it is constantly updated, according to PwC’s US cybersecurity and privacy leader, Sean Joyce.

“After an organization drafts this document internally, external partners should be engaged to ensure the plan addresses best practices, industry, regulatory, and legal requirements,” he tells Infosecurity. “As organizations respond to incidents or as cyber-threats evolve, they should evaluate the effectiveness of the plan and update accordingly. Organizations can further test the effectiveness of their plan through tabletop exercises which would provide opportunities for stakeholders to understand their roles and receive ongoing training.”
Processes and guidelines such as those from COBIT or NIST can help in crafting incident response, especially with remediation techniques, according to former ISACA Chapter president, Ramsés Gallego. He tells Infosecurity that organizations must also calculate their Recovery Time Objective (RTO) as well as a Recovery Point Objective (RPO).

“These disciplines are instrumental here and should never be crossed beyond. They are the moment (time) and step in processes (point) from where the company cannot recover its normal operations,” he continues. “It is like saying that from those moments onward, the company cannot go back to its desired state and will fail to proceed.”

The major goal of successful incident response is getting back and staying in control as fast as possible

Going Live 
Once they’ve developed an effective incident response plan, companies must stick to it when the bullets start to fly, according to Chris Hodson, director at the Institute of Information Security Professionals (IISP).
“I believe it was Mike Tyson who once said ‘everyone has a plan, until they’re punched in the face.’ It is important that your plans represent the potential in-scope threat events, which could damage your business,” he says. “Businesses need to understand ‘who does what’ and make sure that these people are on-point to execute the response plan. If it’s the CEO who speaks with the media, ensure they know precisely what to say – avoid them getting into discussions about types of attack or technical nomenclature.”

SANS Institute’s Fuchs adds that responders should not rush to kick an attacker out before they’ve got the full picture of what they were looking at and what has been exfiltrated.
“If they didn’t get what they were there for, they will return. Find better ways to detect them and avoid them getting back in the same way they did the first time,” he concludes

What’s hot on Infosecurity Magazine?