The Interserve data breach: Not detecting an incident does not mean you’re in the clear

One of the many issues raised by the Information Commissioner’s Office (ICO) in their investigation into the Interserve data breach was the company’s response to the incident. The initial attack occurred as a result of a successful phishing scam, which led an employee to open a phishing email, download its content, and subsequently have malware installed on their workstation. Despite how vulnerable they were to cyber attack, there was no investigation by Interserve’s Information Security Team.

The rationale for this critical oversight was, according to the Interserve group, that its antivirus software had reported that the malware had been removed. This was not the case, and the cyber attacker retained access to a compromised account and moved onto the second phase of the attack. As a result, the special category data of up to 113,000 Interserve employees was breached, including information on ethnic origin, sexual orientation, bank accounts, and details of national insurance numbers.

Interserve’s lack of investigation by itself is certainly cause for concern; however, what made it especially damning (particularly in the eyes of the ICO investigation team) is that this course of action was in complete contravention of Interserve’s own Incident Management Standards. The company’s internal policy mandated that:

• Recovering from incidents should involve rebuilding systems or networks to a previously known secure state.
• Following recovery, information security specialists should undertake a root cause analysis on the incident and determine whether there were any indirect or lasting impacts from the initial malware attack, including whether malware remained on the system.

In short, none of this happened. The Interserve team only became aware of a prolonged attack after discovering a message on their server infrastructure a month later stating that it had been hacked, having ignored the company’s antivirus alert. ICO identified that, as well as not following protocol, Interserve used outdated software systems, had inadequate staff training, and ran poor risk assessments.

These were costly mistakes on Interserve’s part, costing them £4.4 million in ICO monetary penalties, and significantly more in reputational damage.  

Interserve’s data breach now serves as a cautionary tale that not detecting an incident does not mean none has occurred.

When ‘no incidents’ is a bad thing

It goes without saying that no company wants to be the victim of a cyber incident, especially considering the reputational, regulatory, and financial penalties that can accompany them. It is therefore unsurprising that organisations might not be willing to quantify the size of their cybersecurity problems, even if they are able to do so.

In this vein, some companies can be quick to claim that they have never even suffered an incident. In global insurer Hiscox’s 2020 Cyber Readiness report, 63% of businesses interviewed with fewer than ten employees said they had never been victims of any cyber incident at all. This seems staggeringly unlikely at first glance, but the reality becomes a little clearer when you consider that 49% of these companies had no formal cyber security role at all.

Rather than accepting that these companies have just been incredibly fortunate, it is worth considering the number of attacks and breaches that might have been missed. A lack of detection does not mean that there is an absence of incidents.

There is no benefit to taking a ‘head-in-the-sand’ approach to incident detection, other than perhaps some pleasing-looking metrics. Learning from incidents, however unpleasant they may be, is an opportunity for organisations to improve their own cybersecurity posture. Failing to detect an incident could lead to a persistent and sustained attack, a data breach and, as Interserve discovered, an expensive mess to clean up.

Perfecting the art of detection

At the heart of the issues discussed above is a failure to have reliable monitoring and detection capabilities. Being able to effectively identify threats is of paramount importance to be able to contain, eradicate and recover from a cyber incident.

As a starting point, an organisation needs to establish its strategy for monitoring and detection. Though there is a plethora of generic security tooling methods available, the main question to answer before implementing any solution is what needs to be monitored, and how.

Organisations can establish which systems need monitoring based on how much they contribute to services, how exposed they are to risk, and what data privacy compliance requirements surround them. They should then identify potential threats, and begin to develop an incident response plan. 

This groundwork is crucial in identifying which threats an organisation might face and where attacks might do the most damage. With this information in hand, companies will have a better idea of what they should be monitoring for, which threats should be prioritised, and what incident response plans should be in place. This allows penetration testing and response planning to happen in advance of — rather than after — a security breach. 

Selecting software systems and protocols

At this point, organisations should consider carefully what sort of monitoring system is most appropriate for them. These systems can be broken into two key categories:

• Intrusion detection system (IDS): designed to only provide an alert about a potential incident before a security operations centre (SOC) analyst investigates.
• Intrusion prevention system (IPS): blocks the attempted intrusion or otherwise remediates the incident automatically.

Both IDS and IPS have trade-offs, and it may be that some combination of the two is necessary, depending on the systems being protected. An IDS may seem less appealing on paper, but is very helpful in a scenario where a critical system needs to be available and blocking suspicious activity might severely impact usability. Equally, as Interserve’s case shows, relying blindly on technology and not performing a follow up investigation may also leave an organisation vulnerable to missing something vital, particularly if tooling is misconfigured.

Pro tip: Consider using privacy-enhancing technology to bolster your cyber security defences.

Once the monitoring and prevention approach has been established, it is time to begin configuring any chosen monitoring tools so that active incidents are detected and dealt with in real time. These tools will need to be carefully calibrated to ensure that they are able to identify suspicious activity via establishing a baseline for ‘normal’ patterns of behaviour. 

While choosing the right tools is important, these tools alone will not ensure that incidents are dealt with correctly – an organisation will always need to have a robust response process in place to underpin any technological solution and ensure employee personal data is protected. Companies often spend an inordinate amount of time developing a system to generate carefully calibrated alerts, but rely on monitoring teams that only work Monday-Friday. Alerts can easily be missed, leaving the organisation with a potentially fatal gap in their system. That is without even considering whether there are clear and documented processes around alert handling and prioritisation. 

What can we learn from the Interserve data breach?

The Interserve case teaches organisations an extremely valuable lesson. We have an instance of a company’s Information Security team receiving the requisite alerts from their system but then choosing not to act on them. This was a serious failing and underlines a point that everyone should be aware of: an organisation can have all the technology it desires, but, without the right processes in place, can remain exposed to dangerous cyber security challenges.