Picture a scenario like so: your security engineers have just informed you that your web application has been breached – what do you do now? There are many questions that need to be answered and there’s no one simple solution, so that’s why we’ve decided that in this blog post, we will provide you a checklist centered around data breach investigation and mitigation. For the purposes of this blog post, we will assume that we are members of the information security part of a company needs to complete a couple of key tasks outlined by the CEO:

1. We need to ensure whether the data breach did indeed happen (confirm or deny the fact);
2. Figure out what impact the attacker(s) had on the infrastructure of our web application;
3. Figure out how to mitigate the impact or at least provide some high-level advice to the decision-makers in the company.

Phase 1 – Confirming the Data Breach

First off, we need to confirm whether the data breach indeed took place. At this phase, there’s bound to be a lot of scattering around and there might be a couple of theories what had happened before the task to investigate a data breach reaches the security team – once the head of security has clearance to investigate a possible data breach handed down from the CEO, the security team needs to get going. Here’s what we need to do:

1. Back up our web application and ensure the backup works in order to ensure that we can restore to a pre-backup investigation stage if necessary.
2. Get ahold of all of the logs pertaining to the server powering the web application (access.log, etc.)
3. If possible, determine the part of the web application that could have gotten affected by the data breach. If that’s not a feasible option, we need to determine at least some of the impact that the attacker had on our infrastructure. If we’re running a forum, check when was the last data backup pertaining to the forum taken – recently? Red flag. Also immediately check on all of the administrative logins – was there an account that has been accessed recently? Red flag. Log in to your server via FTP or via other measures, and check the modification times of the most critical files (the configuration file, etc.) – did they change recently? Do you recognize the changes? Are there any files that could have been added recently? Red flag.

Generally, confirming the data breach is relatively easy – if we are running a web application that lets users log in, most of the time users will start complaining that either someone accessed their account, either they’re not able to log in because their password has been recently changed, etc. Combine that with the actions specified above, and we should have enough data that lets us confirm or deny that the data breach did indeed occur.

Phase 2 – Securing Evidence

Once we have confirmed that the data breach did occur, we need to secure all of the evidence pertaining to it – the problems of users pertaining to logging in, strange data backups that have been taken, new files that could’ve been created, weird-looking access log entries, everything. The more evidence we will have, the better – the better we are at this stage, the more we will be prepared for what’s to come. At this stage, some people might also prefer to report the data breach to their local police agency – that might be a good idea as well. Once we’re accomplished on the second phase, we should move towards working on the data breach itself.

Phase 3 – Working on the Data Breach

This phase of the data breach investigation and mitigation is frequently the most difficult to accomplish, but also the most rewarding from a security standpoint. Once we have confirmed that a data breach did occur and gathered evidence, we need to complete the following steps:

• If possible, determine how did the attacker got into the web application. Following hacking or security forums might help – these forums frequently have sections related to “Databases”, “Data Breaches”, “Data Leaks”, or similar things, where hackers and script kiddies alike post leaked databases. If you see a thread pertaining to your web service (honestly, that happens more often than we’d like to think), open it up and have a read – attackers usually post their gems there.
• Once the part of the vulnerable application is identified, shut it down and investigate the code for any exploits or vulnerabilities – you might need an expert’s hand on this one, though. Searching your team up on leaked databases using an API or a data breach search engine at this stage might also be of immense help – attackers not only exploit vulnerabilities but also make use of credential-stuffing attacks to cause harm. Make use of the capabilities provided by data breach search engines and their APIs, and stay alert.
• Analyze any anomalies including the contents of log files, any recently added files, etc. Make a copy of them, then delete them.
• Satisfy any legal obligations the company might be bound on – including GDPR, providing notices to customers, etc.
• Finally, make sure to force a global password reset – only do so after completing all of the actions specified above, since otherwise, you might open doors for another data breach shortly after – plug the holes, then force a reset, so to say.

After you’ve completed all of the steps specified above, you’re almost set! It’s time for the final phase – the aftermath.

Phase 4 – The Aftermath

By now, the data breach has been confirmed, legal obligations met, passwords reset, evidence has been secured, and the authorities notified. All we need to do now is to confirm such a thing won’t happen again – and if it does, we must know how best to react. Incidents in the cyber space are a very delicate manner – one day you react to them, the other you deal with them again.

In order to protect both your team and your application from a data breach in the future, ensure that:

• The company you represent is using API solutions that let them scan through lists of public data breaches that have occurred in the past – by doing that, your team can quickly be alerted of data breaches that have occurred, and if they’re affected, change their passwords, or, better yet, if they see that the customers using a product built by the company re-used passwords in a data breach, tell customers they’re in danger and inform them to change all of their passwords immediately.
• The employees of the company you’re working at make use of a data breach scanner such as the one provided by BreachDirectory to quickly and easily assess the likelihood of identity theft threats posed to them.
• The company you’re at adheres to all applicable privacy laws and regulations (think GDPR and the like.)
• Consider suggesting that the company gets HIPAA (if the company is in the health sector) or, better yet, ISO 27001 certified. An ISO 27001 certification means that an organization is capable to manage the security of its assets (IP, cloud resources, and customer data.) ISO 27001 is a widely recognized standard – the sooner a company gets certified, the better it is for the customers, company staff, and investors alike.
• Consider employing Intrusion Detection, Prevention Systems, or, better yet, invest into a WAF – a Web Application Firewall is a good investment into the future of your application from the security standpoint because a WAF will always be able to fend off attacks like SQL injection, Cross-site Scripting, Cross-Site Request Forgery, and the like.
• Educate the staff at your company to never click on suspicious links to not fall prey to phishing attacks, secure the database behind your web application, and learn from data breaches that have occurred in the past to not repeat the mistakes of other developers.

There are many other things to take care of, but we have outlined a couple of the main ones – ensure that the company you’re working for meets at least a part of these standards, and you should be good to go!

Summary

In this blog, we have provided a checklist for data breach investigation and mitigation. The sooner the company you’re working at adheres to some (or all!) of the standards mentioned in this article, the better – as you’re working through the list, make sure to utilize data breach scanners to protect your team from identity theft attacks, implement the BreachDirectory API into your infrastructure to protect your team, and until next time!