Is Your Data Breach Response Plan Good Enough? Stress Test It!

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

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 clients are 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.

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 that 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.

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.

Conclusion

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.

***** Rich Blumberg is the Director of Data Breach Response at IDT911 Consulting. He has more than 10 years of data breach and crisis management experience, and has personally handled more than 2,000 client breaches. Prior to his role at IDT911, Blumberg spent 14 years at Equifax, focused mainly on data breach response. Eric Hodge is the Director of Consulting at IDT911. He has nearly two decades of technology management and cybersecurity consulting experience. Prior to joining IDT911, he held roles at Protiviti (formerly Arthur Andersen) and Jefferson Wells, as well as worked to build cybersecurity practices at two other consulting firms.