Full or Foolish Disclosure: 5 Parts of Good Breach Disclosure

I think it’s safe to say that everyone, except of course bad actors, will agree that it’s always best to avoid a security breach. CyCognito can help with that! Unfortunately, however, the reality is closer to that oft quoted adage, “it’s not if, but when.” So, it’s important to have a contingency plan for how to proceed if/when your company is the unfortunate victim of a breach, and it’s even better to create this plan before you actually need it.

Part of a good contingency plan is to consider what, when, where, and how your organization will disclose that a breach occurred, and that’s the topic of today’s blog. I opened the door to this topic with my writeup about the Accellion breach and how breach disclosures were handled during that event, and now I’m making good on the promise I gave to write more of a security practitioner’s guide to how I think breach disclosures should be handled. Note that this is absolutely, 100% not legal advice, and you should always involve your legal counsel in crafting your breach disclosure process. Rather, these are the observations and aspirations of someone who has been around this particular block a few times in security and seen a few things in terms of breach disclosures both as participant and observer. So without further ado, let’s dig in.

The power in being responsible

The first element to discuss is how to handle the issue of apologizing to your customers if they were impacted by the breach. In order to do this well—or decide if you need to do it at all—it’s important to clarify the difference between responsibility and fault. We live in a litigious society and it seems like any apology for a breach or, well, most anything these days, is met with blame and lawsuits even when it’s done with the best of intentions. As a counterpoint, not apologizing will also result in legal action when those impacted find out about it. And they always do. That being said, in my opinion, it’s better to disclose. By disclosing, you are taking responsibility and taking responsibility can help you gain control of the situation.

To be clear, being responsible doesn’t mean you are at fault or that you should be blamed, although you may find throughout the course of your investigations that your team wasn’t focused on the right things or paying attention to all of the things they should have been. But by being responsible you can move forward with integrity, focus on the aspects of the breach you can influence, and regain your customers’ trust much faster, all of which will ultimately help you recover more quickly, because you hold the power.

On the other hand, you can look at Accellion’s approach. They began their disclosure statement with: “In mid-December, Accellion was made aware of a P0 vulnerability in its legacy File Transfer Appliance (FTA) software.” The wording of this first part of the disclosure (“made aware” “legacy”) reads like this is totally out of their control. Do you now trust that this company doesn’t have other P0 vulnerabilities in its software? Do they sound like they are taking responsibility for their software or are they blame-shifting to abdicate responsibility for software they sold and supported right up until a sudden End-Of-Life a month after their disclosure? Fault is being the cause of the failure in question. A responsible organization takes charge of the situation to fix it, regardless of fault.

The 5 elements of good disclosure

What does good breach disclosure look like? Well, in a lot of ways it resembles a good apology because that is what it is. We’ve all seen plenty of bad apologies—in the media, in politics, even in business—but this time rather than give you an example o a poor disclosure, let’s take a look at an outline of the elements that will help you create one that will work well. A good apology has five parts

1. An expression of regret (not just a CYA)
2. An explanation of what went wrong (not hiding evidence)
3. Taking responsibility (not laying blame)
4. Making amends (not just making the issue disappear)
5. Request for forgiveness (not a demand for it)

1. An expression of regret (It’s hard to say, “We’re sorry.”)

Part one is perhaps the hardest part for an organization to do, because it can appear to open your organization to liability by accepting fault. It is important to realize that this is not the case; in fact, several states have adopted so-called “Apology Laws” for medical malpractice. In these cases, either full or partial protections are provided for, in essence, saying “I’m sorry.” This part of the disclosure could be considered optional in the case of a breach disclosure, especially if your legal counsel is set against it, but it’s a powerful gesture to your customers, and it’s my personal hope that it becomes a best practice. Back in 2013, when Target suffered it’s high profile breach, their CEO posted an excellent example of a breach disclosure

Figure 1. Screenshot from Target taking responsibility and saying sorry in their disclosure.

Contrast that with the lackluster December 2020 breach disclosed from T-Mobile.

Figure 2. A non-apology apology from T-Mobile’s December 2020 breach.

2. An explanation of what went wrong (Sooner or later the truth will come out)

If the first part of the disclosure was for customers impacted, the next step, explaining what went wrong, is the most important part for the cybersecurity community. Everyone can respond meaningfully if they know what happened. Too many times in an effort to minimize severity or disavow responsibility the details of the breach are so obfuscated that the information is useless. This technique is in stark contrast with the excellent example of full disclosure exhibited by FireEye when they suspected the SolarWinds breach may have compromised their penetration testing tools. This level of specificity and transparency is extraordinarily helpful to all concerned, and gave the industry important visibility into a breach that could have gone unchecked for even longer than it did. Hopefully further guidance around Section 2 of President Biden’s May 12 Executive Order on Improving the Nation’s Cybersecurity will help to remove legal and psychological barriers to sharing threat information like this in the future.

3. Taking responsibility (responsibility implies response ability)

The next part of a good disclosure is taking responsibility for the breach. This does not mean that the breach is your fault, but it does emphasize that protecting your company’s and your customer’s data is something that you fully own and take responsibility for. That is literally the job of cybersecurity. The great thing about taking responsibility is that it shows that you are in control of charting your organization’s course of action. Like the captain of a ship in a storm, it isn’t your fault the waves are high and the wind is blowing, but it is your responsibility to steer the ship as deftly as you can to a safe harbor. In a cyber attack, how your organization responds is your job. How your organization is seen to respond can sink your brand or buoy it through the rough weather. 

4. Making amends or mending a breach of trust.

Now that you have apologized for and acknowledged the breach, describing what happened as specifically as possible, and showing that your job is to “lead the data to safety,” your next step is to describe exactly what you are going to do. It is possible to rebuild customer trust by describing the actions you are taking to make this better, including details on the process, the systems fixed, and the things you can do for your customers like credit reports, fraud detection, and help lines for providing assistance. The easier you make it for your customers to get over the effects of a breach, the faster they will trust you with their data and business again.

5. Request for forgiveness (in an unforgiving world)

Asking for forgiveness may not be something that you choose to do in a breach disclosure.  Demanding forgiveness, on the other hand, isn’t ever really appropriate, and should be avoided at all costs. An example of this can be found throughout the 285 pages of testimony of former Equifax CEO Richard F. Smith in his 2017 hearing before Congress about the breach in September of that year. The biggest problem with Smith’s apology is that he never apologized for not correcting the things that were within his control, nor did he address the things that he and the company did wrong. He asks for forgiveness for the breach, while never taking responsibility for the messy breach response.

As those of us in cybersecurity know, every breach has the potential to negatively impact your company’s brand reputation, the trust of your partners and customers, and your stock price. While the first step should be doing your best to prevent breaches, and CyCognito certainly can help here, it’s important to also think about how to productively and appropriately respond if and when breaches occur. By communicating quickly about any incident, sincerely apologizing to customers, clearly detailing the breach to the cybersecurity community, and delineating the actions being taken to make amends, it is possible to rebuild the trust of users and shareholders alike.