The Travelex ransomware attack: Are you prepared for extended downtime?
On 31st December Travelex suffered a cyber-attack. Its physical stores continue to operate but its website has been down since. As a result, several partners who use its currency services including Sainsbury’s Bank, Barclays, HSBC, Virgin Money & Tesco Bank have been affected.
When significant incidents like this occur, its useful to review them to see how you might deal with something similar. What lessons can we learn from this Travelex cyber-attack?
What happened/the timeline
The attack began on New Year’s Eve 2019. The timing itself is interesting because staff levels are likely to be low on New Year’s Eve and New Year’s Day is a Bank Holiday. Under GDPR a personal data breach must be reported to the ICO within 72 hours. If it is not possible to assemble the Crisis Management Team on New Year’s Day, there is little time left before a disclosure is required. The timing for the attack therefore put additional time pressure on Travelex.
Its first public announcements of an issue came on the 2nd of Jan via social media:
Although this attack appeared to be a ransomware attack (and it was reported to be ransomware: https://www.computerweekly.com/news/252476220/Suspected-ransomware-attack-causes-worldwide-disruption-for-Travelex) , Travelex did not say it was specifically ransomware and referred to the incident as a “virus”.
At this point, there was no corresponding message on the Travelex website. It was still displaying an error page.
On the 4th of January, this was updated to a “Planned Maintenance” message.
On the 7th of Jan, the Sodinokibi ransomware gang contacted the BBC to claim it is behind the attack and has a ransom demand of $6m. The gang claims to have downloaded 5GB of sensitive data. "The deadline for doubling the payment is two days. Then another seven days and the sale of the entire base." Assuming these assertions are true, the motive behind the admission is to force Travelex to act and pay the ransom.
Travelex updated the statement on its website on the 7th of Jan to confirm the attack was indeed ransomware.
The ICO reported that it had not received a data breach report from Travelex (which it should within 72 hours of becoming aware of the breach, if personal data is breached).
It updated its statement again on the 8th of Jan – this time with more customer-centric messaging about the disruption, customer service and how to access their currency services.
The first lesson we can take from this incident is the importance of social media channels.
Travelex maintain Twitter and Facebook accounts and post regularly, if infrequently.
One of the first places a customer will look for information about an incident is the company website and social media. If the site is not available, social channels are your only channel to communicate.
After Travelex posted its statement on the 2nd of Jan it was dealing with customers services issues directly on Facebook and Twitter.
Some businesses choose to opt out of social media if it doesn’t add value and drive revenue but incidents like this prove the value – if only for crisis communications.
Brevity vs detail
It is interesting that in its first announcement, Travelex does not refer to the incident as a ransomware attack.
One of the challenges in Crisis Communications is balancing clarity and brevity with detail.
A one sentence response of “We have suffered a cyber attack and are dealing with the incident.” is brief and clear but doesn’t have sufficient detail. A two page, technical root-cause analysis has detail, but lacks clarity so important information may be lost in the weeds.
This balance of brevity vs detail also affects another important aspect of Crisis Comms – speed.
Speed of response
The first public message on social media was on the 2nd of Jan, two days after the start of the incident on the 31st of December. That is a long time, even considering the Bank Holiday.
We generally don’t expect a lot of detail from an initial announcement, just acknowledgement of the issue.
Pre-prepared, and pre-approved messages speed up the process of getting this first message out. Its first announcement was fairly standard, if limited disclosure: “customer data not compromised”, “Internal and external specialists working continuously” “We apologise to all our customers for any inconvenience caused as a result.”
This bare minimum detail and could have been provided sooner.
After that first announcement, a longer, more considered announcement can then give more detail about the specifics of the incident, what has been affected and how the problem is being resolved.
This may have been the intention of Travelex, but is appears their hand was forced to divulge that this was indeed ransomware because the attackers themselves reported it to the BBC. The result is the impression that Travelex were intentionally withholding that detail.
We return to brevity vs clarity. Choosing to use the term “virus” in communications rather than “ransomware” might have been because it is more widely understood. But another important factor in Crisis Comms is honesty and transparency. You should not withhold information that would be damaging if revealed later.
When Travelex updated its statement on the 7th of Jan it was quickly criticised on social media for including comments about its own financial performance:
“The company is working to resume normal operations as quickly as possible and does not currently anticipate any material financial impact for the Finablr Group.”
Its updated statement on the 9th of Januarty rectified that with a more apologetic tone and customer-centric message. In our opinion – this is a vastly better statement.
Travelex also has an additional layer of complexity to deal with.
It provides currency exchange services for several partner banks who also need to inform their customers about the issue. Several of the banks simply have a notice on their websites to say that online foreign currency services are temporarily unavailable. HSBC actually names Travelex as the cause of the issue.
Different parties will require different levels of detail and types of message, so Crisis Communications needs to cater to staff, customers, suppliers, partners and the press.
Disclosure for ransomware
Ransomware has been a difficult topic for GDPR personal data breach disclosures. It is specifically mentioned by the ICO in its guidance on what constitutes a data breach:
“In short, there will be a personal data breach whenever any personal data is lost, destroyed, corrupted or disclosed; if someone accesses the data or passes it on without proper authorisation; or if the data is made unavailable, for example, when it has been encrypted by ransomware, or accidentally lost or destroyed.”
But, if data has only been encrypted and never exfiltrated by the criminals, the risk to the people whose data was lost is low. That means you do not necessarily have to inform the ICO about the breach.
If the criminals did have access to that data, the risk the “people’s rights and freedoms” is high and will require disclosure.
The difficulty with ransomware attacks is that if data can be encrypted it can also be viewed and removed. But this is less easy to confirm.
Travelex’s statement on the 7th of Jan makes their position on this clear. They say some data was encrypted, but not personal data and they don’t have evidence of exfiltration. This is at odds with the statement from the attackers.
The lesson we can take here is to ask, if you were in the same situation: “how long it would take to find out if data has been exfiltrated?”
Lessons for dealing with a large-scale cyber incident
Finally, here are some other observations and lessons take:
- Patch and update. Sadly, the way to prevent this attack seems to be as simple as patching and updating. If you look back at the most disruptive and profitable ransomware over the last 7 years, most could be avoided by taking this relatively simple step.
- Dealing with ransomware is very difficult. Cyber commentators weighing in in Twitter have acknowledged this, even as they criticise Travelex. Dealing with this kind of incident is highly stressful and difficult. You would not want to be in this position, therefore…
- You need to have a plan. You need to know how you would respond in advance. The last thing you want to do is to be learning how to respond, as you are responding.
- Be prepared for a significant outage. This type of incident is the most troubling for IT resilience. There are few things that can cause downtime for over a week, this is one of them. A week of downtime here for a website is massive. Other causes of downtime like human error, hardware failure, software failure are fixed quickly, without significant disruption. Major disasters like fires and floods can have a similar impact but often, there is goodwill from partners and customers. That is because they can affect lots of businesses at the same time and because they are a disaster that happens to you. Cyber-attacks however carry the implication that your downtime was caused by a lack of competence or care.