Preempt a Cybersecurity Disaster by Writing a Mock Breach Notification Letter

Ask the Experts Blog Series

No one in the security industry should be surprised to know the cost of a data breach keeps rising, and the longer it takes to contain one, the more it will cost your organization. In 2018 IBM cited that the average cost of a data breach has reached USD 3.86 million globally. This includes the cost of technical investigations and recovery, notifications, legal and regulatory activities, and fines—in addition to lost business and reputation.

In fact, the impact to your customers might be more serious than you think. A Harris Poll found that 75 percent of consumers won’t do business with a company if they don’t trust it to protect their data. And there is the reputational damage of a large breach or a mega breach (the theft of more than a million records, of which 16 such events occurred in 2017). In fact, it’s often impossible to respond to a mega breach and still restore your business to pre-breach levels.

Learning from the mistakes that haven’t been made yet

Working backward from a breach that hasn’t occurred yet will illuminate the weaknesses in your disaster plan, so you can take action now—rather than when you’re in a breach recovery.

If you wait until a major security incident happens, you’ll be untangling the mess while under duress, and trying to explain how such a thing could happen. For the price of your attention and willingness to uncover uncomfortable truths, you can make the difference between successfully handling a breach before it becomes a disaster—rather than the alternative, which no one wants to think about.

What’s the worst thing that could happen?

To get you in the right frame of mind, plan on writing a mock breach notification letter. What are your “crown jewels” and the most valuable information assets your company has that could be stolen? Is it your source code? Your patents? Your customers’ credit card data?

It’s likely there are many jewels, and their theft would cause an irrecoverable and devastating loss to your organization.

The Mega Breach

Let’s start by examining recent mega breaches and consider whether the same thing could happen to your organization. Understand that what’s publically shared is never the full story, but it’s a starting place to learn.

If you were already in the middle of a serious breach—one that affected the core of your business—your orgaization would be under duress and buying capabilities in a hurry. They would probably be throwing money at the problem—approving overtime, bringing in outside help, hiring experts and consultants—and trying to add technical visibility after the fact to understand what happened and what to do.

Who should participate?

If your organization had a serious breach, who would be on the mitigation team? Can you get those individuals to agree to work through the process? If not, or if your organization is large, consider starting at the division or grass-roots level. Think about more than just who would write the actual letter—it’s more than just your incident response (IR) and SOC teams.  Many will be involved in an actual breach mitigation. Start by getting people from non-technical departments—as high up in the organization as possible:

• Public relations, to handle external-facing messaging: Consider and draft your PR responses in advance, such as preliminary statements and reviewing what you would and wouldn’t disclose.
• Legal, to make sure notification and compliance are handled in accordance with your business locations.
• Risk management, to make sure every item on the risk register is covered.
• Sales, to understand what customers are saying. (Sales is directly impacted whenever there is a security incident.)
• Client management, to provide feedback on customer notification processes.
• Application owners, to understand likely issues with visibility or configuration.
• Crisis management, to supply expertise on mitigating all types of threats and disasters; they also often provide coordination and communication during a crisis.

Who should be responsible for what?

As you discuss your mock breach notification letter, one item you’ll want to cover is who is responsible for various aspects of your organization’s response. Pay close attention to three things: pauses in discussion, finger pointing, and assumptions—everyone has a different view on where the responsibilities lie.

Most likely your organization has made big investments in technology, so everyone might assume that your SOC has all it needs to handle whatever happens. It would probably be wise to educate them in a candid and respectful way on gaps that still exist and how they all have a part in esuring the organization is secure. It’s also important to articulate how long it takes to perform basic analysis and incident response (IR)—be honest and share the gritty details.

Along with determining responsibility for every aspect of a breach is having a complete understanding of your breach detection capabilities. For example:

• Does your organization have the technical capability to identify when a breach is happening?
• Does your organization have network, application, or logging blind spots?
• Can you reliably rule out false positives?
• How does your SOC prioritize work?
• Can you distinguish normal user behavior patterns from abnormal?
• When you’ve discovered an actual breach, can you identify “patient zero” (the entry point or first infected system)?
• Can you quickly identify compromised assets and identify and contact those responsible for those assets?
• How much time is spent on building an incident timeline, including all IP addresses, hosts, and users involved, and can this be reliably recreated?

There is much more to a breach than the technical solutions. You also need to ask:

• Who is going to manage the external and internal messaging?
• Who is going to talk to law enforcement?
• Who is going to talk to the media and provide updates? Will you need a technical representative?
• Where do you go for answers for every kind of question?

What should I write in the breach letter?

The point of this exercise is to ask the hard questions about what to do if your organization experiences a major breach. Writing the letter is the easy part.

You’ll likely discover that you need to do a lot of internal communication as well to address the gaps and pain points in your organization. These internal communications need to be in plain language so that everyone in your organization can understand—especially executives who may not have a background in breach response and security operations. You’ll need to explain not only the technical aspects and incident response, but also the long-term impact of a breach, and what it could mean to everyone in the organization. Don’t wait until after an event, and then regret that you didn’t bring up these issues before. And don’t be in a position of answering to those saying they didn’t think any of this could ever happen.

What can I learn from this exercise?

When you socialize what you already know about security breaches and invite others to contribute, you’ll undoubtedly expose weaknesses in your systems, procedures, policies, and responsibilities. Now is the time to start addressing those weaknesses—not when you are in the middle of disaster mitigation.

It might take months to build your plan, and even longer to execute it. This exercise is a starting point—a way to ensure the right people are in the loop about where you are today and where you need to go to keep the bad actors at bay and respond when the bad day arrives.

If your organization is trying to keep a handle on breaches by manually analyzing and correlating individual log files, and chasing events from point solutions, you’re fighting a losing battle. The data is buried too deeply to enable quick access, and it’s too disparate to quickly correlate. But there are modern solutions for user and entity behavior analytics (UEBA) for these mundane time-consuming tasks—freeing you to focus on larger problems such as who provides the catering and energy drinks.

———————————————————–