When You Discover A Data Breach

It’s not a matter if… it’s when. It always has been, but the proliferation of AI to automate tasks means that organisations – even smaller ones – are at risk of data breaches more than ever. Does your organisation know what to do if something is discovered? Having recently been on the receiving end of a breach notification as a customer, I thought I’d write a little about how I’d want an organisation to handle these scenarios.

The first priority is for your nominated incident response lead to start containment, as well as cataloguing evidence and decisions taken, so a clear timeline of everything that occurs can be built. One instinct might be to immediately delete or wipe affected systems such as virtual machines or containers; however this may also wipe evidence of how a vulnerability was exploited in the first place, which may prevent understanding of how to prevent future similar incidents. The incident response lead also likely needs to contact and bring on your business insurers and legal counsel, for example.

Next up, you need to work out what the scope of the breach is. What data, if any has been exfiltrated? What is the nature of that data, for example is it sensitive, personally identifiable information, how many customers or partners are affected, in what way, and so on? This will get you a picture of the nature of what you’re dealing with, and will help drive sending out factual information to potentially affected customers or partners. It may also drive decisions or even regional requirements to bring in external teams such as forensics, informing authorities (such as the ICO, FCA, and so on in the UK). Eventually, once you’ve gathered the facts and affected scope, you’ll need to tell affected parties such as customers or partners too, which can be a very humbling moment. Keep things factual, with actionable points such as requiring resetting of passwords, contacting credit card companies, and so on.

It can be a tense situation for any organisation to be in, so this is why planning ahead for scenarios like this pays dividends. Setting up contracts with organisations, or hiring response experts ahead of time on retainers who can help you in these scenarios is a sensible forward planning, and knowing who will lead incident responses, and the playbook to follow should be planned out now – rather than scrambling when an incident occurs.

As well as planning, the best thing your organisation can do is take preventative measures to minimise the risk of security breaches through your application’s software stack. Many breaches are a result of insecure software, outdated software stacks, or even undiscovered vulnerabilities. Finding these first – before attackers do – is far cheaper than having incident response after the fact. That’s where Roave can help, with preventative measures such as refactoring software with a security-focused mindset, organising pentesting, and vulnerability assessments. If you’d like to talk through where your risks are, get in touch.