News of data leaks involving sensitive user information, including usernames and passwords, makes media headlines with alarming frequency. Authentication details are valuable information for cybercriminals, who can use them to gain further information and for identity theft.
If your web application stores user data, it’s at risk of having that information stolen. Of course, it’s best to have security precautions in place to ensure that data doesn’t leak, or that it’s useless even if it does, but what should a business do once it believes that its username and password database has been made publicly available?
Data theft can be be hugely damaging to a company’s reputation, but if the company handles itself well, the damage can be limited — it needn’t be a catastrophe.
Data theft is a risk for any company that does business online. Forward-thinking companies have processes in place to handle security incidents. Think about the potential risks and have a well-rehearsed process ready.
Create an incident response team with clearly defined roles: who is responsible for investigating the leak, who for communicating with users and the media, who for implementing mitigation measures?
Determine That The Data Leak Is Genuine
In some cases, criminals will create fake user data leaks in an effort to damage a company’s reputation or distract attention from a genuine attack. Take a close look at the data and compare it to internal records.
Conduct A Preliminary Investigation
The first step in an investigation should be to create an immediate backup of the company’s data. Once the breach is discovered, attackers may seek to remove evidence from servers to hide their identity and the route they used to compromise the network. A copy of relevant data will help with immediate mitigation steps and the deeper investigation that should happen once the immediate risk is removed.
The next step is to determine exactly what has been leaked and how it was leaked. Log analysis is the most valuable tool in this scenario. Unusual patterns of access are often the key to discovering how the attacker was able to infiltrate the network. All relevant servers should be scrutinized for malware infection, anomalous access patterns, unexpected changes to files, and anything else out of the ordinary.
You might not like to think about it, but insider threats are often a major factor in data and financial theft. Consider the possibility and act accordingly.
Once you’ve discovered the immediate source of the breach, act quickly to close it. In the worst cases, that might mean removing a server or service from the web altogether, but malware removal, key and authentication credential resets, updates to vulnerable software, and so on may be sufficient.
It’s important to be confident that the source of the breach has been discovered and mitigated — there’s little point in moving to the next step if the hackers can simply access new data using the same route.
Authentication Credential Reset And User Notification
If there is any evidence that attackers have been able to access authentication credentials, a forced password reset should be implemented immediately.
At this point, users should be informed of the breach and given any relevant information. Be as open as possible without creating further risk.
Data leaks cause damage to a company’s reputation, so it can be tempting to keep it secret. Failing to disclose is a mistake. Users have a right to know their private data has been leaked. I’ve come across companies that perform ethical contortions to justify non-disclosure, but you can be sure that it will come out sooner or later. If, several months in the future, users discover that their data was leaked and the company kept it a secret, the damage will be much greater than a prompt disclosure (even if the leak is the result of embarrassingly incompetent security).
Conduct A Comprehensive Investigation
The preliminary investigation is intended to discover the immediate source of the leak and mitigate it. A post-incident investigation should focus on identifying the technologies and processes that lead to the leak being possible in the first place. Often, it’s something as simple as an ineffective update policy, but it may well be a deeper issue with a company’s security culture and incentives.
Publish A Detailed Post Mortem
Security incident post mortems show that the company understands what went wrong and have put processes in place to make sure it doesn’t happen again. They’re a combination mea culpa and technical report.
The ideal security incident post mortem includes a description of the incident, any lasting risks to users, what the company did to address the immediate problem, and details of how they will prevent such incidents happening in the future.
A security incident that leads to user data leaking onto the open internet poses a serious reputation and financial risk to companies that depend on user trust, but unless the cause is gross incompetence, and provided the company is honest about what happened, data leaks needn’t be a disaster.