This article discusses how Secure Ideas ranks findings within their reports.
How should I communicate a security incident?
Guidance for how to address a security incident on your company FAQ page.
If you are in the unfortunate situation of having to disclose an information security breach to the public, you may be asking yourself the best way to respond. You may have some regulatory or legal requirement to disclose the breach to customers or law enforcement, so the first thing you need to do is find out what you are required to disclose. But aside from that, what kind of information should you put on your website? This article is meant to provide some guidance on how best to address the public's most common questions, for example on a website's Frequently Asked Questions (FAQ) page.
It should go without saying that breaches have become a common occurrence, and there is a precedent for responding openly and honestly about what happened. That is the type of response that tends to get the best public reaction in what is otherwise bad press. Below is a set of questions that you might address on your public-facing website along with guidance on how best to answer them:
This is where you succinctly state the What, When, and Who of the incident: What happened, When did you notice, and Who did it impact. Some organizations will also make a statement about how protecting customer data is a top priority, but that seems contradictory in the middle of disclosing how you just lost that data, so we think it is usually best to leave that out. An example statement could be along the lines of:
On May 7, 2020, we learned of a data security incident in which customer information was stolen.
If additional information has already been publicly disclosed, such as how the attacker stole the data (e.g. malware, phishing attack, etc…) then this may be stated here.
What customer data was compromised?
This is where you elaborate on what type of data was compromised and how much of it, provided you have that information. This can be a tricky question because you don't want to tip your hand to your attacker and give them additional information about what they stole. Typically you will list the following items:
- Contact information, including name, phone number, email address
- Passwords. It is okay to indicate that passwords were hashed or encrypted.
- Security questions and answers
- A description of any payment information that was taken, such as credit card or partial credit card number.
- Any other highly sensitive information that was taken, such as SSN
- Other personal information that is less likely to be used in a follow-up attack, such as order information or user profile information.
Exactly how you word your response will depend on how much you know about the attack. For example, if you have mostly complete information, your response could be something like:
Based on what we know to date, the following information was taken for approximately 7,000 customers:
- Email address, first and last name
- Hashed (encrypted) passwords
- Order information, such as the date of the last order and number of items ordered.
If you don't know what was taken or for how many users, then state what you know for sure, that the extent of the breach is still under investigation, and that you will update this page when you get a more accurate assessment.
Was my Credit Card compromised?
If sensitive data such as credit cards or passwords were stolen, then your customers are going to want to know if they, personally, were impacted. If you accept credit card information on your website, then you should answer this question even if it is handled by a third-party payment processor. An example answer for a company that leverages a third-party payment processor may be:
No. Though we accept credit card payments, they are processed by a third party. We don't store your credit card information in our database or on our servers.
Was my Password compromised?
This can be a tough question because many companies do not store passwords according to the latest best practices and there is a good chance this fact will become obvious and embarrassing. Even if the passwords were hashed/encrypted, were they properly salted and hashed with a modern recommended hashing algorithm (such as bcrypt or pbkdf2)? If you were doing everything right, your answer might look something like:
We use a strong hashing algorithm and security best practices to store passwords in a manner that is very difficult to reverse. The hashed version of customer passwords was taken during this incident. Though an attacker cannot read your password out of it, today's computing power may eventually be able to reverse it, so we require that all of our customers change their passwords within the next 30 days.
Maybe you aren't so lucky to be using the latest industry recommendations. For example, perhaps you are maintaining a legacy system that is still storing passwords using a weak hashing algorithm. In this case, ethically there is no choice but to fess up and give your customers the best chance of avoiding future identity theft. An answer more like this might be appropriate:
Though we use a secure hashing algorithm to store passwords, it is a legacy system and unfortunately, today's computing power is able to crack the passwords within a short period of time. To prevent unauthorized access, we have locked all user accounts and are requiring a password reset before users can log on. In addition, we recommend that if you use this same password in other places that you also change those. We apologize for the inconvenience.
What are you doing to address this data breach?
This is where you can explain some of the steps that you may be taking to address this particular breach. This may include reiterating over the fact that you are requiring password resets but should also include statements such as doing an internal review, or bringing in a third party expert, or bolstering your defenses, and so on. This is also a good place to describe how and when affected customers are being notified.
How will you ensure that this does not happen again?
This is another tough question because this is where you make your commitment to doing better. This is arguably the only answer where it really makes sense to state that you are committed to protecting your customers' data. You want to reassure your customers that you learned from this experience and that you will make effective and lasting improvements. A convincing statement could be along the lines of:
We are embarrassed by this turn of events because we really do value our customers and the privacy of their information. This incident should never have happened, and we are taking steps to minimize the risk of future security incidents. Some of the improvements we are focused on include:
- A complete review of perimeter defenses such as our firewall rules
- Improvements to internal logging, monitoring, security events notifications
- More rigorous security test coverage of our application code
- Better secure software development and architecture training
- More frequent 3rd party penetration testing
We hope that our customers see these measures as a testament to our dedication to securing their information.