Making sense of the Easyjet breach

Photo by Frederick Tubiermont on Unsplash

Upon seeing the news earlier today that the budget airline Easyjet had been breached, my reactions (in order) were “Woah”, followed by “Bloody hell”, and finally “Not this **** again!” 9 million affected users, of which over 2200 may have had their credit card credentials compromised. Obviously Easyjet have apologised; informed the ICO and police; and are in the process of contacting customers.

To my mind, this sounds eerily familiar to the MageCart attack that compromised British Airways back in 2018, leading to the breach of up to 380,000 customer’s data including payment card details. Unfortunately for BA, just 22 lines of code and a spoof domain cost them a £183 million GDPR fine, plus the additional costs of securing their systems and compensating customers.

Earlier today, they made an official announcement to the London Stock Exchange in relation to the breach, where you’ll spot the following quote from their CEO Johan Lundgren:

“We take the cyber security of our systems very seriously and have robust security measures in place to protect our customers’ personal information. However, this is an evolving threat as cyber attackers get ever more sophisticated.”

It’s easy to dismiss such a quote as a soundbite without substance (though it’s not as bad as former TalkTalk CEO Dido Harding saying that they weren’t required to encrypt data.) The sad reality of the situation is that Easyjet will have an Information Security function; and the people employed there will be professionals who are doing their hardest every day to keep their organisation secure. Easyjet themselves are PCI DSS compliant, meaning they must meet certain security standards for the processing of payment card data, which is then audited by an external assessor. The problem is, at the moment, there’s so much we still don’t know: How did the attackers gain access; when did they gain access, how long were they in there; and what was the mechanism of exfiltration? Until those details, and others become clear, it’s going to be hard to understand what went wrong, and subsequently where to point the finger of blame (Something the ICO will be thinking about also.)

Based on the limited amount of information we have thus far, this is what can be deduced:

  • The Magecart (or similar) malware is a possibility. A PCI DSS compliant organisation should not be storing cardholder data, and there’s no need for them to do so. Thus the loss of cardholder data would suggest a skimming type attack.
  • While only a tiny minority of customers had payment card details stolen, and there is no evidence that passport details were taken, significant amounts of information including name, email address, and travel destination were compromised. This potentially puts 9 million people at the risk of being socially engineered into giving away further details or being compromised themselves.

    If you are notified that you’re amongst those affected, use diligence when opening emails, especially anything purporting to relate to Easyjet or any bookings that you have made. Additionally, if you were one of the unlucky ones to have your card details stolen, pay close attention to your account, and consider contacting your bank to have a new card number issued.

As many of the companies suffering high profile breaches, including Easyjet, BA, Experian, and TalkTalk all have information security teams, what more can you do to keep your company safe and avoid joining the naughty list. Here’s five things to consider:

  • Employ a security culture, not a security team: It’s not enough to simply put someone into the organisation with security in the title and expect to be secure. Your executives need to have keeping the company and its data secure as a key business objective, and everyone from the CEO to the intern on their first day need to understand that not only do they have a role to play in doing that, keeping to company secure may come at the expense of doing things easier or cheaper.
  • Understand your threat vectors: As discussed in the Introduction to Risk, before you can go about securing your systems, you need to understand what your risks are, and their corresponding threat vectors. Given around 9 in 10 breaches are a result of social engineering or phishing, this has to be considered a substantial risk – especially with mature phishing awareness programmes having a 2%+ expected failure rate. Consider that – even if your staff are extremely aware of phishing, statistically 2 people in every 100 will get caught by a suitably crafted email.
  • Security, IT, and business functions must work together: Once the threats to the company have been identified, the next step is to begin managing the risks. In the aftermath of the Travelex breach, it was revealed that the vulnerability that was exploited was months old at the time of the breach, and external parties were notifying Travelex of its existence. If it takes you 24 hours to patch critical vulnerabilities in your perimeter, you’re probably taking too long. When a vulnerability becomes known Information Security, IT, and business functions need to quickly identify a suitable management plan and execute it with a minimum of delay.
  • Assurance on e-commerce systems should be effective: The world changes, so it’s not enough to do a penetration test on your e-commerce system when you install it and never check it again. Of course, assurance should be proportionate, but for a system handling financial transactions, aim for a mantra of comprehensive, intensive, and regular. Any findings that come as a result of this assurance work should then be remediated promptly. Practically this could mean:
    • Code reviews during development and use of a secure-coding standard;
    • Pre-release penetration test (either the initial release or after any changes);
    • Weekly (or daily) vulnerability scans; and
    • An in-service penetration test done at least annually.
  • Ensure your supply chain is secure: A secure supply chain goes beyond checking out your third parties. You should be understanding if you have any fourth party risk (Third parties that are also a third party to someone else in your supply chain.) Also, the security of third party code needs to be considered – linking to third party libraries introduces the risk of that library being compromised, while incorporating a local copy of a library creates the risk of your version becoming vulnerable to security issues.

In the days and weeks to come, more details will inevitably emerge about what went wrong at Easyjet, and we’ll explore these as they come up.


Leave a Comment

Your email address will not be published. Required fields are marked *