Ticketmaster UK recently announced that customer credit card and personal data had been compromised. This was due to a security breach at their third-party customer service technology provider, Inbenta. In accordance with GDPR requirements Ticketmaster have notified the Information Commissioner’s Office (ICO), are conducting an investigation, and have also provided Identity Theft Protection services to their affected customers. This is all very much in keeping with the new stringent privacy rules we are all subject to now. It is also not the first time that Ticketmaster have had security breaches or poor data protection policies in place. For example, as recently as 2013, their subsidiary GetMeIn sent passwords in plain text when users requested a password reset, rather than using a “magic link” to enable a user to generate a new password. Due to the re-use of passwords between sites this was a huge potential breach, given how easy it was at the time for a hacker to also gain control of webmail accounts.
Whilst the detail of their forensic investigation is unlikely to be revealed what is interesting here from a SAM perspective is that the vulnerability that was exploited existed in software on the 3rd-party’s systems, not Ticketmaster’s own. This is the reality of Third Party Risk and why formal assessment of that risk is becoming an area of focus for compliance teams. Based on the statements from both Inbenta and Ticketmaster there is a difference in opinion between the two companies as to who is ultimately responsible. From a compliance perspective, however, the responsible party is Ticketmaster, because it is their customers’ data that’s been compromised.
The SAM angle
Broadly speaking, such issues are a concern for IT Security & Compliance teams who should be reviewing the processes in place at third parties to ensure software is patched in a timely fashion.This is required by PCI-DSS regulations in order for the organisation to process card payments. However, there is also a role to be played by a Software Asset Manager. SAM Managers have rich inventory data which is of use to IT Security Teams. Their tools may also have software lifecycle data which can be used to determine which applications will no longer receive security patches. This begs the question, should a SAM team, as part of a Third Party Risk Review, audit the systems of the third party? If you’re closely aligned with your IT Security & Compliance team you may well already be doing this for your own systems. Could this be a scenario where we come up against other SAM Managers in an Audit Defence battle? Does the hunted get to turn hunter? Should software audit rights be built into third party contracts? Let me know your thoughts in the comments or the forum
Many thanks to David Foxen (aka @SAMBeastDavid) for bringing this subject to my attention, and suggesting the SAM angle to it.