Is Your Data Breach Response Plan Good Enough? 3 Ways to Stress Test It

Commentary January 17, 2017 at 11:33 AM
Share & Print

As the chances of a data breach incident increase, savvy businesses have invested time and thought in a response plan. But plans never survive first contact with the enemy. Stress test your incident response plan to find and resolve its weaknesses while time is on your side.

According to the Ponemon Institute's 2016 Cost of Data Breach Study United States:

  • Lost business is the biggest financial consequence of a data breach. Taking steps to retain customers' trust reduces a breach's long-term financial impact.
  • The longer it takes to contain a breach the more costly it becomes. Breaches contained within 30 days of discovery cost an average of $5.24 million. If it takes more than 30 days to contain the breach, the average cost increases to $8.85 million.
  • The average breach in 2016 cost $221 per record. Having an incident response plan and team in place, employee training, board-level involvement and a CISO in position are associated with reducing the cost of data breach $56 per record.

As compelling as these conclusions are, advisory firms and their clients have even more reasons to establish a data breach incident response plan (IRP). Their role as hubs of sensitive information make them irresistible targets for thieves.

Awareness of the threats rightly galvanizes leadership to develop an IRP and to invest in cybersecurity services.

Simply Having an IRP on File Isn't Enough

The faster an incident is mitigated, the lower its costs, but speed can't be mandated by the plan. For this reason, your firm and clients should stress test your IRP on a semiannual or annual basis.

When facing a real breach, the time and resources spent in practice could well pay an attractive return on investment. Without fail, the exercise turns up shortcomings, confusion and inefficiencies. Ironing those out with a calm team is far more cost-effective than diverting cognitive capacity in the midst of a real incident.

Stress testing an IRP works best when you go through the motions as if your company were having an active data breach. Everyone who has a role on the response plan assembles in one room and, in the context of specific scenarios, discusses their actions and the order of operations. The goal is to get everyone familiar with their roles and responsibilities.

We've done a lot of breach response planning and testing, from typical tabletop exercises to call trees and testing the response team's reaction times. After these exercises, response teams regularly praise the experience and say that they feel more confident about their abilities to react in a real incident.

Make the Most of Your Stress Testing Exercises

1. Focus on the most likely scenarios.

You're more likely to encounter ransomware via a phishing email than a dedicated nation-state penetrating your firewall. As such, focus your stress test on the scenarios that are most likely and threaten the worst potential consequences.

By the time you work your way down to less likely and less costly threats, you'll have already covered the common elements of your response. Knowing how to adapt your plan to a specific threat is an expertise unto itself; one that won't emerge naturally in the planning phase.

The threat model, kill chain and consequences of ransomware will differ from stolen equipment. If your top two likely scenarios are similar, you're right to consider one stress test sufficient and use your remaining time to consider a somewhat less likely threat that could require a different response.

Ways to brainstorm stress-test scenarios

As a leader in your firm or company, you read news from industry associations, their publications and discussion forums. This is a great practice for keeping your security measures aligned with the most likely threats.

If you like your data fresher, contact your local U.S. Secret Service or FBI office. These folks rarely get calls from people who aren't in distress. They love to get involved on the prevention side. They're happy to discuss specific questions such as "What are the three biggest attacks that are going on these days for [financial institutions, insurance brokers or whatever industry your firm is in]?"

At a certain size, all companies include vulnerability assessment and penetration testing in their security operations. If getting your own vulnerability scanner would be overkill, commission a third party to conduct a penetration test or vulnerability assessment. Use the results to inform your choices when you stress test your IRP.

Take stock of your data housing and protection protocol. If it's hard for your organization to keep up to date on your client devices' patches, devise a test to determine what sort of patching frequency you can handle. Are your web servers or web applications out of date sometimes? Build a scenario around a penetration of your web-facing application and the SQL database behind it. Maybe PII gets exposed there; make that into a scenario.

As a standard part of data defense, you'll already have identified your most sensitive information assets. Ask for those assets' owners to help brainstorm scenarios where that data could be exposed.

Regardless, thieves are always a step ahead. As popular as ransomware or phishing are today, they may fall out of fashion in a year. For that reason, you've got to keep your people vigilant for what's coming next.

2. Make it more than a technical exercise.

By the time Target alerted its customers about its historic breach on Dec. 19, 2013, several days had already passed. In fact, Krebs on Security had published a report on the breach a week before Target's public announcement. The report turned out to be so accurate — down to details of how the theft likely occurred — that it revealed the extent of Target's delay before alerting customers. That delay likely impacted consumers' faith in the retailer, whose Q4 profits that year were just 54% of profits the previous year.

The delay was a consequence of Target's leadership treating the breach as a purely technical issue. It's not the responsibility of network administrators or software engineers to consider the expensive, sticky issues that follow a technical resolution: how to engage legal counsel, how to communicate with clients (in accordance with state mandates), how to interface with the press, etc.

Since non-technical staff must be involved in a real incident response, they should participate in stress-test activities, too. In addition to the board and IT, the incident response team must include: legal (internal and external), PR (internal and external), and HR (if employee data was exposed).

Here you have to strike a balance between internal staff and external specialists. Insiders will be more familiar with your company's history, mission, situation, sensitivities, etc. But they already have a full plate of responsibilities. Are you going to divert them to manage the response to an incident? Outside experts in breach response management can take on that extra work, and streamline the response with their expertise.

Leadership sets the tone

In the incident responses that we've been a part of, the teams who work together best understand their responsibilities and what needs to happen, and their leadership has taken responsibility for the crucial nature of the work.

The C-suite must set a tone for the exercise that accounts for possible real-world consequences. Conversations with peers, articles in trade magazines and presentations, and consultants' advice should all inform leadership's assessment of how the various departments in your organization can reduce risk during a breach.

3. Apply lessons learned.

The true benefit of a stress test is the analysis following the experience. The whole point is to make improvements to your plan — actually responding to what went wrong and reinforcing what went right.

Your breach response plan should include a commitment to assemble the incident response team to discuss the exercise, within a few days of the threat's conclusion. Someone has to be responsible for that component of the process; otherwise it will all fall through the cracks. Whoever led the incident response planning, or a business continuity planner, would be a good candidate. The individual should have a breadth of perspective of the business. A technician with a focused role won't suffice.

Many organizations have some kind of tracking application for internal process improvement; perhaps an annual audit or internal audit. The findings from those audits will be tagged, tracked and integrated into a workflow. Apply these tools to designate participants who will implement the incident response team's recommendations within a certain period of time.

As mentioned in the introduction, the benefits of organizing and testing your incident response plan could far outweigh the costs. Multiply this potential ROI by the growing chances of a data breach, and you have a strong argument for allocating some budget for an annual stress test at least. Finally, factor in the peace of mind your C-suite and incident response team will gain when they feel confident in their response plan, and we believe you'll arrive at a compelling argument to place stress tests near the top of your to-do list.

NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.

Related Stories

Resource Center