Inside the Head of Information Security's Mind - Handling a Data Breach

This article tells the story of my experience handling data breaches in companies. From the very first moment of awareness to the last step of the incident response plan (IRP), we will go through each step, discuss areas for improvement and cover some mistakes to avoid.

Note: If you would like to suggest an improvement or simply get in touch, you can reach me at contact@lionsec.lu.

Introduction

The day is going as usual, nothing special on the horizon, apart from the constant fires to put out (yes, a Head of InfoSec is a bit like a firefighter). In short, as a former (and dearly missed) colleague used to say: “The sun is shining, the birds are singing, all is well!”. And then, it all starts with an internal notification.

🎧 Support: “David, there’s someone on the phone saying they want to speak to the Head of InfoSec, can you call them back?”

🧠 HoIS: “Hmmm, probably another sales call, but I still have to check.”

📞 The caller: “Are you the HoIS? We have found a data leak concerning you on the dark web, and… it’s bad.”

📞 HoIS: (After hearing the list of internal assets that had leaked) - “Could you please send me an email from your domain so I can verify your identity?”

A little later…

🧠 HoIS: “S***, it happened.”

The plan: “The only thing that matters”

When a leak (or a cyberattack in general) is confirmed, between rising blood pressure, sweating and the later arrival of your first grey hair (yes, literally), the dreaded event had finally happened, the day after the first Information Security Committee in front of the Executive Committee members. I had just started working for my client, the first risk register presented the day before included this very risk, and since we can all “fix everything by yesterday” (as everyone knows!), it had to happen at that exact moment.

So it was time to activate the incident response plan. Yes… but wait, where was that plan?!

It didn’t exist. And yet, at that very moment, time stands still and nothing else matters.

The battle begins

Crisis meeting: you need to get together with the various stakeholders to define the next steps. This obviously means knowing where to meet (especially when every meeting room is taken), who to bring in (without offending anyone you might have forgotten), how to reach them (an emergency channel, especially if your usual means of communication are affected), who should communicate and how (because you are no longer alone at this point) and, of course, what the next steps are (assuming they have been formalised and the teams trained for this kind of situation, ideally across different scenarios).

Note: Knowing where and how to meet also helps avoid tipping off the surrounding teams, who might see you rushing around everywhere, without explanation, with visible worry on your face. Controlling internal and external communications at this point is more than crucial.

All of this may make you smile today, especially since the situation ended well, but knowing that many organisations are in this situation today (and above all, the level of pressure when it happens) quickly changes your perspective.

Stay humble, don’t panic, and move forward

It would be a flat-out lie to claim that the pressure wasn’t there for everyone. Strangely enough, the CEO was probably the only one in the room putting things into perspective (which was exemplary on his part). Data breaches happen to every organisation; just take a look at this site listing cyberattacks in France. You can also get an overview of attacks worldwide on Check Point’s interactive map. They happen every day, and quite often a data breach is not the result of a single person’s mistake, but rather of a chain of bad practices and lapses in due diligence (just like most attacks today follow a chain of techniques as defined by the MITRE attack matrix).

Note: In this kind of situation, rule #1 is not to give in to panic. Easier said than done, and yet so true.

Indeed, panic will always be a natural reaction to this kind of confirmed event (since we are not talking about a simple detected incident), but it is above all amplified when an organisation is not prepared for it, with no plan, which was the case here.

The response steps

In this case, the plan didn’t exist; however, that doesn’t stop you from following a classic incident response procedure to frame how the steps unfold. Let’s go over them below, the CISSP way, in 7 steps (the “DRMRRRL” mnemonic for those in the know):

1 - Detection: This is about identifying the incident. Although it had been confirmed by evidence provided by the caller, we still needed to verify the source of the leak (SIEM, EDR, firewall, logs…). In any case, a seasoned technical team will usually already have a pretty good idea.

2 - Response: Activate the response team, internal and/or a CSIRT. Government-run CSIRTs are available to help companies respond to this type of incident. There is one in every region, and in France you can find yours on the CERT-FR page. For Luxembourg, there is GOVCERT.

3 - Mitigation: Once the source of the leak has been identified and the right skills are available, you need to mitigate it (reduce the risks) by containing the breach (isolating the affected host, shutting it down, an EDR action or a custom script, etc.). The goal is to put out the fire and plug the breach.

4 - Reporting: This is not about writing a report (that starts from the very beginning), but rather about communicating with the legal stakeholders (because yes, you are no longer alone). These include management, legal, the authorities, customers and regulators, within the legal deadlines (for example, GDPR within 72h for the initial notification, and 24h at most for DORA and NIS2 after becoming aware of it). No, nobody “feels like telling”, but don’t forget that regulators often have more options for action than malicious actors :)

5 - Recovery: Bring the production systems back to normal operation once the threat has been eradicated.

6 - Remediation: Analyse the root cause and make sure it doesn’t happen again on the system involved or on others (leaked credentials to change immediately, misconfigurations to fix across the board, or cloned source code to fix quickly). Yes, this part can be gruelling.

7 - Lessons learned: It is tempting to skip this step, relieved that production is back up and the threat has been removed. Yet that is a serious mistake. The point is to meet again, with a clear head, to truly understand the source of the problem and how it happened, and to update the policies, the procedures, the incident response plan and potentially the business continuity plan (BCP). Not forgetting to train the teams through a security awareness programme.

This cycle repeats endlessly with every confirmed incident to make your plans more robust, always with continuous improvement in mind.

No blame, just lessons

Another very human trait: it is fairly common to try to find someone to blame as the detection phase progresses. This is also a mistake to avoid, because we can never be sure of anything until the lessons learned phase, once we have an overall view of the events.

Once again, a cyberattack rarely comes down to a simple event (point A to point B), but rather to a succession of bad practices, whether operational or managerial. Moreover, as mentioned above, no organisation is spared. It is no longer a question of “if” it will happen, but rather “when”.

Final advice

The list of tips could be endless, and everything depends heavily on your organisation, culture, environments and know-how. I will nevertheless list some of them below, based on the data breaches I have had to handle:

A HoIS should make formalising and/or reviewing the IRP, and training the teams, one of their top priorities, including soon after joining a company.
- If time is short (which it always is, it goes without saying), a simple document and a tabletop exercise would be better than nothing.
Know your assets: I cannot stress this point enough, and yet it is far too often overlooked. It is of paramount importance (and a future article will be dedicated to it) to know your assets and to have solid inventories. Imagine a data breach happening without full visibility of your estate: things would be much more complicated.
- This also means making sure that, at the very least, your critical systems are backed up and regularly tested.
The CTO does not orchestrate the incident response: it is tempting for a CTO to want to control every aspect of the response plan (and that is even normal); however, a CTO is not the most suitable person to coordinate these activities, especially the non-technical ones (plan steps, reporting to regulators, preserving evidence, etc.). Here, the HoIS is the conductor. It is also crucial not to have the HoIS report to the CTO: the role is critical and must remain independent. Otherwise, tensions could unfortunately arise.
As soon as the incident is confirmed, taking notes is crucial. You will have to account to your customers and regulators, including ones you may not expect (such as France’s OFAC, the national anti-cybercrime office, for example). Keep a careful record of events, dates and times, contacts and/or teams in chronological order, as well as the assets you interacted with and the actions taken.
Preserve the evidence: logs, artefacts (for example: malware, scripts, phishing emails, IP addresses, etc.), including dates and times.
In the specific case of ransomware, there is still “one last chance” thanks to the No More Ransom platform, which offers free decryptors. A platform that, unfortunately, is still too little known.
Likewise, as a HoIS, you won’t have the final say (it belongs to the Executive Committee members), but always advise against paying a ransom. You have no guarantee of getting your data back, nor that the malicious actor has definitely “left the building”. On a side note, one platform puts a great deal of effort into collecting conversations (often anonymised) between victim organisations and ransom demanders. Some of them are chilling.
To orchestrate things globally and independently, crisis management solutions such as F24 exist. They are very useful for guaranteeing communication channels completely separate from the ones you normally use (Teams, Outlook, Zoom, etc.), planning tasks with their respective owners, and keeping your documents and plans somewhere disconnected from your information system.
Don’t skip the final lessons learned step. It is the best way to prevent the same problem from happening again in the future.
Control your internal and external communications: this point is essential to avoid creating panic or rumours internally, and to protect your reputation with robust communications approved by legal.
- It should be said that, in any case, social media and some unscrupulous journalists will not do you any favours.
Once again, don’t give in to panic. It will make you lose precious time, which we are all short of.

Conclusion

We have seen that managing a crisis is never an easy task, and that drawing up a plan and training the teams for this kind of situation are crucial steps. Like certain illnesses, we avoid thinking about it until it shows up, and as the saying goes: “Prevention is better than cure”. Trust your teams: I witnessed strong collaboration during those difficult times. This process is not based solely on technology or figures, it takes a lot of human effort. Know your assets and your communications, back up and test your critical systems, and stay vigilant, because the day it happens, you will need to be ready.

Contact

For any suggestions or simply to get in touch: contact@lionsec.lu.