How to improve your incident response plan

old books
Credit: Christian Siedler

Incident response plans are, in many ways, like family relics. These written instructions, which detail how firms should adequately detect, respond and limit the effects of an information security incident, are highly valued by some, and yet all too often left gathering dust in the cupboard. To many, they remain untried and untested for years, and thus most are unfit for purpose when that untimely data breach becomes reality.

Experts say that a robust incident response plan today should include a policy that specifically defines what constitutes an incident, and that this document should provide a specific, step-by-step guide as to how firms respond to an incident. By following these guidelines, organizations hope to limit the damage of an attack, and reduce the high costs and lengthy recovery time that are usually associated with data breaches.

Yet for all of this, incident response plans divide the InfoSec community. eBay was heavily criticized for its failure to respond to its data breach last year, while many IR plans are often considered to be ill-thought out, or ill-equipped, for today’s world. Worse still, some firms don’t even have one.

[ RELATED: Reviewing incident response plans for data risk preparedness ]

For example, a study from PAC -- polling 200 people from companies with more than 1,000 employees in UK, France and Germany -- found that nearly 40 percent of firms did not have an IR plan. And of those with IR plans, only 30 percent said that they tested and updated these regularly, a concern given the evolving threat landscape.

Indeed, citing the rise of Advanced Persistent Threat (APT) attacks, growing cyber-criminal activity and under-investment in protection and detection, cryptography expert Bruce Schneier said in 2014 that it was the decade of “response”.

Yet sadly, this is taking time to catch-on; a report from AT&T last month indicated that while 81 percent of IT professionals said their firms did have incident response plans in place, only 31 percent of these believed that these were actually effective. Clearly there is work to be done.

IR plan faults

The problem for most companies is that even if they have IR plans, they’re often not fit for purpose.

McKinsey reports that most organizations “don’t truly operationalize their IR plans, which are ineffective due to poor design or implementation, or both.”

The firm says that such documentation is often “out of date” and “generic”, and “not useful for guiding specific activities during a crisis.”

In addition, the consultancy said that these plans can be created by one department, but not implemented by others. Developing such plans in silos not only damages a businesses’ response, but it can also inhibit sharing relevant knowledge and best practices.

McKinsey adds that IR decision-making “is often based on tribal knowledge and existing relationships”, with organizations typically relying on one to two “go-to” people to guide the organization through the crisis. This can result in a single point of failure when the resident expert is not available, or does not have the capacity to lead the response.

Dane Warren, CISO at UK-based product testing company Intertek, tells CSO Online it is difficult to tell why certain incident response plans fail.

“[It’s] hard to say, without knowing the company. However, it is easy to say that an effective IR plan is paramount is any organization – even if it only used for preparation.”

But James Mckinlay, principal security consultant at Praetorian Consulting International and former head of information security at Worldline Global UK&I, tells CSO that often faults are down to departmental issues.

“Not involving everybody that will be needed, internal communications, external communications, law enforcement, legal, hr, executives, risk director, CISO, client relationships”.

What your plan should look like

When creating your IR plan, InfoSec pros say you should set out to define its purpose, the role each team plays in an incident, as well as the lifecycle of the plan itself. Simulation exercises are also encouraged to stress-test these processes, and to prevent business confusion as to each department’s role and responsibility.  

This is critical because IR plans must involve multiple departments, including information security, legal and compliance, human resources, and communications. A core team of cross-departmental reps should also be selected to take the lead in responding to incidents. Some say that one executive should be responsible for the plan and its integration across the business.

Warren believes that security teams can get ahead in this process by understanding the business and where its core assets are.

“Understand your business, and understand what needs to be protected. Aligning these two things will give you the basis for subsequent activities in an incident response scenario,” says Warren.

[ ALSO: Incident response matters ]

“Clearly defined roles and responsibilities are key. Ensuring that people are trained to effectively perform those roles and responsibilities is essential. A clear communication plan, based on the severity, is a must. This may include the general public, customers, internal staff, government officials, and / or suppliers.”

Mckinlay adds that preparation is key, as is having the right leader.

“To prepare a decent incident response plan requires quite a bit of research and tailoring to the company in question.

“Testing a plan, like testing Business Continuity Plans or Disaster Recovery Plans, requires either a very smart proactive security leader or an audit finding that dictates a test.

“Because responsibility for having an incident response plan is likely to fall to the information security manager they have to understand a good one involves a lot of other people and areas outside of IT and security.”

SANS, meanwhile, believes there are six key phases to developing a successful IR plan:

  • Preparation– Preparing users and IT to handle potential incidents should they happen
  • Identification– Figuring out what is meant by a “security incident”, and which events should be acted upon, and which should be ignored
  • Containment– Isolating attacked systems to prevent further damage
  • Eradication– Finding and eliminating the root cause (essentially removing affected systems from production)
  • Recovery– Permitting affected systems, once fixed, back into the production environment
  • Lessons learned – Writing everything down and reviewing and analyzing with all team members so you can improve future incident response efforts

Team and skills

Other InfoSec professionals highlight the importance of having a good security team; At a London conference last year, SANS instructor Steve Armstrong said an incident response team should almost be like Scooby Doo’s team - with different people bringing different skills.

Armstrong said that an effective incident response plan should see “geeks that love to geek, leaders that love to lead and managers that love to manage” but he admitted that this isn't always the case. He said that plans often fall down on communication alone.

Armstrong added that a strong Digital Forensics and Incident Response (DFIR) plan relies on workers sending good intelligence and statistics onto managers, who in turn translate this in business language for company leaders. However, Armstrong warned that any disconnection along the way would see “risk comprehension and funding go away”, with “directors no longer engaged in what’s happening.”

Instead, he urged CISOs to follow the much-publicized OODA (Observe, Orient, Detect, and Act) loop, which was used by air force, to become more fast and agile. This approach is also favored by Schneier.

For example, Armstrong said that a sysadmin or IT security team could observe an intruder on the network, decide a plan of action and then remediate. He urged firms to think about their plan, their communication (for example, how are they going to communicate if their network has become a hostile environment?) and how they can scale up operations. The whole plan, said Armstrong, needs to involve all departments.

This, however, requires skilled personnel and Armstrong warned between perceived skills and actual capability.

“Attackers can see the inefficiencies of your team – they know you're not Bruce Lee. So you've got to make sure you look at the team, look objectively at what they're capable of doing. If they're not [up to speed], look to infill with help, or onsite training.”

So take that incident response plan off the shelf; a robust plan is very much achievable, so long as you get the right processes in place, the right people on-board and that you test it regularly to ensure it is fit for purpose. What are you waiting for?

This story, "How to improve your incident response plan" was originally published by CSO.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon