On an Ominous Friday the 13th, the UK Data Protection Regulator, the ICO, fined Ticketmaster UK Ltd £1.25million for a data protection breach that occurred over 9 weeks in 2018. In an interesting twist, some of the breach occurred pre-GDPR and some occurred post-GDPR. The 7-figure fine reflects the part of the breach that occurred post-GDPR. What is more interesting is the ICO has set an interesting precedent. Where an organisation is required to be compliant with a particular security standard (in this case PCI-DSS), they may assess a Controller/Processor’s adherence with that standard. If a Controller/Processor has failed to adhere to such a standard, this may have a direct impact on the level of any administrative fine. So whilst some may feel they can tick boxes on self-assessed standards such as Cyber Essentials, without actually doing any of the work, they may find that comes back to bite them in the event of a data breach.
Ticketmaster breach – what happened?
The ICO penalty notice lays out the nature of the breach in considerable detail (view full details here). For those of you who would like the abridged version carry on reading.
In what appears to be an attempt to improve the customer journey, a third party chat bot was included on various pages of Ticketmaster’s bookings website. Some of these pages included pages where customers input their payment details. This chat bot was hosted on a third party’s (Inbenta) servers and at some point an instance of the chat bot was hacked. The hacker injected code into the chatbot that then scraped data input by a user and subsequently sent it to a hacker. In the case of the Ticketmaster incident, the chat bot sat on a payment page. Yup, you guessed it, it then scraped the payment details. This credit card data (running into the thousands of cards) was then used in fraudulent transactions.
From the penalty notice, it seems that Ticketmaster attempted to deny they were the source of the fraud for a good nine weeks. This was however debunked when Visa provided information related to 37000 instances of fraud. Another “smoking gun” indicator was when a customer incorrectly entered their credit card details into Ticketmaster (they accidentally input an incorrect expiry date) and the hacker then attempted to use these incorrect details to perform a fraudulent transaction.
Ticketmaster were also told via Twitter that malicious code existed within an instance of their chatbot but their response seemed to fail to understand they had been breached:
06th May – Concerned Citizen: Inbenta’s website serves two different files … hosted on two different servers one of them has the infected line in it and the other one doesn’t.
The response…
09th May – Ticketmaster: this is not a virus, it’s the help widget that is found on our home page”
and then
09th May – Concerned Citizen: it has an extra line in it submitting information to a website hosted by an External person in the UAE and none of the other inbenta.js files used by other sites have this – this single one has been compromised.
This response was issued in May and the breach continued for well over another month. It seems only after Visa got involved, and a further month of investigation did Ticketmaster concede the chat bot was the source of the breach. It was only then they deemed they had “knowledge of a breach” – even though someone had told them about the Inbenta malicious code injection in early May and the incident had been ongoing for nine weeks.
As a result of the ICOs investigation, Ticketmaster were found wanting. It seems one of the main issues was that Ticketmaster had failed to comply with their own internal policy requirements and some of the requirements of PCI-DSS. The ICO stated:
“Although compliance with the PCI-DSS is not necessarily equivalent to compliance with the GDPR’s security principle, 13 as Ticketmaster processed card data and suffered a personal data breach, the ICO considered the extent to which Ticketmaster might have put in place measures that PCI-DSS required, particularly given the breach related to a lack of a particular control or process mandated by the standard.”
It should be noted Ticketmaster do not feel they are at fault but the ICO ultimately decided they were, and in my honest opinion I’m inclined to agree with the ICO. In the next section I go through some of the more salient points and highlight what you can do in your organisations to avoid a similar concert of errors.
So should I book an event with my security lead?
What can be reasonably anticipated?
Ticketmaster claims it could not have reasonably anticipated that a third party plugin on a payments page could be hacked. Personally, I don’t know how anyone could reasonably come to that conclusion.
The OWASP Application Security Top 10 since at least 2017 (so prior to the hack) has included the risk of Using Components with Known Vulnerabilities. It’s not just reasonably anticipated, it’s one of the Top 10 things organisations should be assessing, mitigating and monitoring. Strangely that reference wasn’t mentioned in the ICO notice (although several other [less established] sources were included).
More specifically for payment data, PCI-DSS exists because it’s reasonably anticipated that pages where cardholder data are processed are at a higher risk of compromise. The system components of the supporting infrastructure are in scope of PCI-DSS because it is reasonably anticipated this type of hack could occur.
What is a reasonable definition of “reasonably anticipated”? A good rule of thumb is to work on the principle that if the infrastructure is in-scope of a particular standard (e.g. PCI-DSS, HIPAA, SWIFT CSCF, etc) it’s at a higher risk of being hacked. If a vulnerability exists that is listed in one of the OWASP Top 10 lists, it should be considered the vulnerability is being [regularly] exploited in the wild. Therefore, it can be reasonably anticipated that high risk infrastructure with a high risk vulnerability has a high risk of being compromised.
Now, knowing what is reasonable to anticipate is ultimately going to be based on who was involved in the project. Sure, Dave in marketing may not have reasonably anticipated this but someone in Information Security should have known this. It’s therefore essential organisations ensure Information Security are ALWAYS a stakeholder in all projects – large or small. The question is not whether they should be involved or not but for information security to tell the project manager how much involvement is needed.
Listen to people telling you that you have been hacked!
I know, people don’t want to believe, let alone admit, their systems have security vulnerabilities. It means they now have to do something about the issue…and that can be expensive. But stonewalling and ignoring people or failing to properly investigate security vulnerabilities is a sure fire way to make things a lot more expensive after the [inevitable] breach
Many organisations have bug bounty programmes but even if you don’t have such a programme, at the very least make sure your customer channel managers have processes and procedures to make the information security team aware when a concerned citizen highlights a potential issue. That way the claim can then be [properly] investigated and, if confirmed, mitigated.
The tweeted response from Ticketmaster appears to completely misunderstand what they have been told by the concerned citizen and also suggests it didn’t get through to someone with solid information security knowledge and experience.
Sure, some people may be chancing their luck and an issue reported could be spurious. That’s down to a specialist application security professional to decide, not someone in IT.
Have a decent Incident Response Team
What was particularly of note from the penalty notice is that the Incident Response Team (apparently made up of members of a unnamed but reputable third party organisation) reported on the 8th June that they had:
scanned 117 terabytes of data to search for malware and found no indication of malware
Well no shit. That’s because they were looking in the wrong place! The investigation appears to have limited the focus to a particular set of infrastructure. Good incident response should not be limited. The incident responders should be free to go where the evidence takes them. A good incident responder from a third party should make that clear to the organisation who is hiring them.
When looking for indicators of compromise, don’t just run automated scans (or let third parties do that at exorbitant day rates) go back to the source. If its payment data that is affected, start at the payments infrastructure. Review the infrastructure and the associated risk assessments. It should have been pretty clear that a third party plugin on a payment page would be a prime candidate for source of the breach. Even more so, given someone has literally told you it’s infected with malware!
Have solid incident management procedures that also reviews change management data. This information is an amazing intelligence source and should highlight any thing that may have changed in the affected infrastructure just prior to a data breach. A new component would be a strong candidate for investigative follow-up.
Finally on this point. Make sure the people in the incident response team know what they’re doing. If they come from a third party, consider opting for a specialist niche organisation who provide specialists and have limited overheads over a bigger company who may send generalists in order to maximise profit margins.
Security cannot be achieved by contract alone!
Looking through the penalty notice, Ticketmaster appear to have attempted to rely on a contractual clause to avoid direct liability. The clause appears to require that the third party supplied the chat bot “free from all malware”. Firstly, this appears to be an unfair contract term as it generally accepted that such a state is not reasonable possible when it comes to the provision of Internet facing software. Secondly, it appears to be a lazy approach to securing third parties. Thirdly, the ICO said:
“The Commissioner does not accept that this contract offered an alternative appropriate level of security comparable with [other] solutions”
What needs to be in place are appropriate technical and organisational measures to detect the presence of malware. Ticketmaster could have implemented measures to protect the integrity of third party scripts. Such a measure available in 2016 (prior to the breach) was Sub Resource Integrity (SRI). Why Ticketmaster didn’t insist upon this during one of their ongoing due-diligence, I’m not sure? Even better, why not simply choose to not place the script on the payment page and completely avoid the risk compromise? In either case, relying on a contract and then abdicating responsibility for ongoing due-diligence is just asking for trouble.
To require or not to require
Ticketmaster appear to have stated that “lnbenta was at all material times well aware that the chat bot was to be used by Ticketmaster on its payment page”. This however did not wash with the ICO who responded that:
“Ticketmaster has failed to evidence a business requirement document, or other formal document (such as that in paragraph 3.48.2 above), by which Inbenta was clearly and unambiguously obliged to design the chat bot for use on the payment page of Ticketmaster’s website. The absence of a business requirement document is illustrative of Ticketmaster’s failure to secure the chat bot appropriately in all the circumstances.”
I cannot stress this enough. When procuring third party systems it is the PROCURING ORGANISATION’s responsibility to document the security requirements for the system. It is YOUR responsibility to determine the risk to YOUR organisation – this is NOT the vendor’s task. An organisation cannot rely on the idea that:
“We told them we were going to jump into a fire and they didn’t stop us”
Vendors provide tools. Some organisations may be happy with one level of risk, other organisations less so. Sure, ask the vendor whether they think a use case is appropriate but in the end, that still doesn’t matter because you’re still on the hook if it goes wrong!
Adhere to your own standards
Now on to the key takeaway, The ICO appears to have held Ticketmaster to PCI-DSS because, in lieu of a definitive GDPR definition of “appropriate technical and organisational measures to ensure a level of security appropriate to the risk”, the ICO have taken the standard expected of the Payment Card Industry who provide governance for the Payment Card Industry as “appropriate”. The implication of this is that Data Protection Regulators may now assess organisations against the standards they hold aloft as badges of honour to their customers that they are secure organisations.
What this means for organisations is the possibility if you’re breached and you attest to a particular standard, a Data Protection Regulator may independently assess your compliance to that standard.
Say you have self-attested to Cyber Essentials that you patch your systems within 14 days and your breach was as a result of an unpatched system…well you may have failed to apply appropriate technical and organisation measures appropriate to the risk. Similar situations could exist for holders of ISO 27001 et al. If you’re one of those organisations who literally have a document set provided by a third party and don’t actually practice what your policy docs preach, you could be in for a bit of a shock. Your senior management could be in for an even bigger shock if they didn’t actually know what was in that document set!
Have you got the Golden Ticket?
Every breach (and subsequent fine) is an opportunity to learn from someone else’s mistakes. This incident is no different. Don’t rely on contracts as your sole security control – that is a bonkers approach to security! Don’t let uncontrolled third party plug-ins sit on top of your infrastructure without first assessing and mitigating the associated risks. Above all, if you use a security standard, don’t just buy a document set and think all you have to do is bluff an external auditor with a binder every six months, implement it properly…
…and if you need help, get in contact, Fox Red Risk can help!
About Fox Red Risk
Fox Red Risk is a boutique data protection and cybersecurity consultancy and Managed Security Service Provider which, amongst other things, helps client organisations with implementing control frameworks for resilience, data protection and information security risk management. Call us on 020 8242 6047 or contact us via the website to discuss your needs.
22301 22301:2019 article 28 awareness bcms BIA business continuity calculating risk change management ciso controller cybersecurity data breach data privacy Data Protection data protection by design data protection officer data protection service Data Subject Access Request DPO DSAR GDPR incident management information security leadership monitoring operational resilience Outsourced DPO Privacy processor risk risk appetite risk management ROI security security as a service small business strategic strategy Subject Access Request tools training transparency vciso virtual ciso
