Nothing fills out the “worst-case scenario” column quite like a data breach. For the countless teams out there who work hard to protect their customers’ data, the idea of compromising that trust is a nightmare.
Data breaches are on a lot of minds lately with the 2017 Equifax data breach, which exposed personal data from 143 million American consumers. The company, security industry, and regulators have a huge task of working out the details on how something like this happens.
At Statuspage, we talk a lot about transparency, trust, and letting the right people know when things go wrong. Transparency around crises is a core part of our philosophy here at Atlassian and Statuspage. While we’re typically talking about these thing in relation to outages and downtime instead of data breaches, there are a lot of overlapping themes. The benchmarks of a great downtime response strategy aren’t all that different from a great data breach response strategy. We fancy ourselves experts at incident response best practices, we figured it would be interesting to take a look at data breach response best practices and see where we can notice some overlap.
A brief look at incident response vs. data breach response
For the most part, downtime is more tolerable and less troubling than a data breach. A few minutes of an unscheduled outage is usually more palatable than even a hint of a data breach. Teams will even purposefully take their service offline to prevent a breach from spreading in some cases. Because of this, most systems are built to prioritize data safety over perfect uptime. We’ve talked plenty about how downtime is inevitable and shooting for 100% uptime shouldn’t be the goal. That’s partly because 100% data protection should be the goal. Think about it. Would you rather your bank’s mobile app went down for a day or lost your transaction history for a day? It’s pretty clear that in the web service hierarchy of needs, data protection trumps uptime. And that’s OK.
Because of the heightened sensitivity to data, we see a lot more regulatory activity around data breaches. Regulators mostly leave it up to organizations on how they’ll announce downtime and service interruptions. But they have a lot to say, understandably so, about how teams should respond to data breaches.
Data breach response regulatory summary (slightly less boring than it sounds)
The Equifax breach has a lot of folks calling for updates to how regulators patrol breach response. Although there are varying opinion on whether the current rules go far enough, it’s worth taking stock of where things stand now.
Right now, there is little national oversight on how companies handle data privacy. When it comes to notifying consumers that their data has been stolen, laws vary state to state and differ in how much time and how much information companies are required to divulge. Equifax is based in Georgia, a state where there is no timeline specified for when a company must notify customers about a breach.
California’s law, enacted in 2002, was the first in the country and became the template for most other states whose lawmakers adopted similar regulations. The main paragraph of California’s law is here (note: if you’re like us and the legal-ese makes your brain hurt, fear not, we break it down in plain English in the next section).
“(a) Any agency that owns or licenses computerized data that includes personal information shall disclose any breach of the security of the system following discovery or notification of the breach in the security of the data to any resident of California (1) whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person, or, (2) whose encrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person and the encryption key or security credential was, or is reasonably believed to have been, acquired by an unauthorized person and the agency that owns or licenses the encrypted information has a reasonable belief that the encryption key or security credential could render that personal information readable or useable. The disclosure shall be made in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement, as provided in subdivision (c), or any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system.”
Now, in English:
Who this applies to? Any person or group who owns or licenses computerized data that includes personal information.
Which has undergone what? Any breach of the security of the system.
Has to do what? Disclose the breach to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person. The same applies if this is encrypted information if there is a known or reasonable belief that the encryption key was also compromised. Basically, if there’s any sort of proof — or reasonable belief — that someone unauthorized was ever able to view private info, they need to notify them.
By when? The most expedient time possible and without unreasonable delay. By now you should be working with law enforcement, who may advise you on when to send the announcement.
Sounds simple enough. But how do these notifications need to be sent? And what should they say? Thankfully, the legislation includes a template which advises the following information be included:
- What happened
- What information was involved
- What’s being done
- What you can do
- Other important information
- Where to find more information
It’s important that these are the regulations for California. While other states drew inspiration from these guidelines, it’s worth noting that these change for users in different states and countries. Please do your own research and contact your own experts and lawyers if you need to put any of this into practice.
The research: 100 breach notifications
Now that we have a handle on what constitutes a breach and what a breach response looks like, let’s have a look at how organizations approach these announcements.
To get a better idea of how teams draft these response letters, we downloaded 100 of the most recent sample responses that were filed recently with the State of California. Filed breach response samples are public record and posted on the state’s Department of Justice website.
Reading these hundreds of pages of breach notification was eye-opening (and a little eye-straining). It’s surprising how much good breach response measures have in common with incident response strategies. It’s also interesting how much variety there was in both the type of organization affected (hospitals, hotels, insurance companies, law offices) and the catalyst of the breach (phishing scams, lost devices, break-ins).
In no particular order, here are a handful of our observations from this research:
- Some teams added a nice plain-English FAQ to the response. This seems helpful. It’s good to keep in mind that your customers aren’t lawyers, and they’ll be quickly skimming for answers to immediate questions.
- Many companies mention they they’ve retained the services of a forensic investigation firm. Some say the name of the firm, others are vague: “a leading cybersecurity firm” “well-respected forensics firms.” If possible, it’s nice to let people know who is working on their behalf.
- Many also note they’re working with law enforcement, but it’s not always clear if they are and/or what the status of any investigation is. Law enforcement can give guidelines on how much transparency you can deliver about what’s happening and how to give periodic updates.
- A handful of the breaches stem from a breach in third-party vendors. This underscores what we’ve always talked about regarding incidents with third-party service providers: if it affects your customers, it’s your responsibility. Your customers don’t care if it technically wasn’t your fault. It’s important to vet your vendors ahead of time. But if there is an incident, take responsibility without throwing your vendor under the but and dodging the blame.
- In some cases, one third-party outage triggered several breach notifications across other companies who used that service.
- Some teams do a nice job of specifically relaying what happened (phishing, malware, etc.). Others are pretty vague, printing statements like “individual obtained access to our system” or “sophisticated cyber-attack” It’s easy to see how this would be frustrating to a customer. How did they get access?How did you learn about the incident? What was so sophisticated about it? What are the steps you took to make sure it doesn’t happen again? To be fair, a lot of these teams are working with law enforcement, lawyers, and private investigators; all of whom might have really good reasons for keeping things on the vague side. As a customer, we would hope for more details than this eventually. In incident response, we always advocate being as specific as possible without compromising trust or finger-pointing.
- One interesting notice stemmed from an over-the-phone scam. Basically someone called the company’s IT office impostering employees. They somehow had enough info to get login credentials reset then access the system. A good reminder to keep your guard up even when you aren’t dealing with keyboards and screens.
- It’s not all sophisticated cyber-attacks. Several companies had data breaches due to physical break-ins or on-person robberies. Good reminder to keep your physical security up to par.
- One organization went above and beyond, filing a detailed, and helpful, breach response when an employee’s cell phone was stolen. Even though the phone was password protected and the company immediately wiped the data on the phone (and there was no other evidence the data had been accessed) the company did the right thing and notified its customers the proper way. We can see how easy it would be to say “it’s just a missing phone, they didn’t even have my pin, what’s the big deal?” This is a good example of taking it on the chin and putting the customer first.
Closing thoughts
Obviously this is a complicated topic, and you should talk to real experts if a data breach happens to your company. It’s important let the lawyers and law enforcement do their jobs.
If you’re interested in learning more, here are some helpful links:
- The Equifax Data Breach: What to Do
- Security Breach Notification Laws
- Comparison of US State and Federal Security Breach Notification Laws
- Cybersecurity Incident & Important Consumer Information
As people trust cloud companies to keep more and more of their info online, it’s going to be easy to take that trust for granted. Just like smart incident communication, smart data breach communication means putting yourself in the customer’s shoes. It’s about trying to make the best experience possible for the customer. Even if it’s a worst-case scenario kind of day.