The recent Ticketmaster breach is perhaps the first large-scale breach in our brave new GDPR-regulated world, and it warrants further analysis. As the dust has settled each party has spun the story in a different way, and there has been far more public disclosure of exactly what happened compared to previous large-scale breaches.
So, who are the players and what have they said?
Monzo, a UK-based banking startup and credit-card issuer first reported the breach to Ticketmaster.
Ticketmaster are the largest seller of entertainment & sports tickets worldwide. They have pointed the finger of blame at a third-party supplier, Inbenta, who provide them with automated customer support services.
Ticketmaster’s statement lays the blame firmly at the door of Inbenta, with no mention of Inbenta’s assertion that the code was created at Ticketmaster’s request, or that it was used, without Inbenta’s knowledge, on the payment page.
Monzo have provided a very detailed statement on how they discovered the breach and persuaded Ticketmaster that it was real, despite Ticketmaster flatly denying there was an issue.
Out of the three companies their conduct has been the most customer-focused – they immediately and unilaterally reissued 6,000 replacement credit cards. Subsequently, following card issuer Mastercard’s “Account Data Compromise Alert”, they’ve replaced all potentially affected cards.
These differing statements are the public face of the increasingly-important requirement for Third Party Supplier Risk Management.
Third Party Supplier Risk Management
Stated simply and from an IT Security & Compliance perspective, third-party supplier risk management is concerned with measuring and controlling risk associated with using a 3rd party to provide services to customers. In this case, Ticketmaster provided access to their systems to Inbenta in order to provide Ticketmaster customers with customer support services.
This 3rd party access needs to be controlled in order to provide to the customer the same level of data protection they would have enjoyed had the 3rd party not been involved. Typically the required level of protection is defined by laws and regulations such as GPDR & PCI-DSS. The latter regulation has highly detailed and mature requirements for protecting card data and is therefore particularly relevant to this breach.
The SAM angle – code vulnerability reporting
Often, SAM functions tend to focus solely on managing proprietary software from major vendors. Strictly speaking, however, in-house production final code should be stored in the Definitive Media Library, as per the ITIL Configuration and Release Management standard, and therefore be in the remit of a SAM team. In conjunction with other functions there is also a case to state that bespoke code should be included in a software inventory, thereby enabling a SAM team to identify where potentially-compromised code is installed. A SAM Manager’s most important stakeholder in this scenario is the IT Security & Compliance Team as they will have the tools to identify code vulnerabilities. However, there is some movement in the SAM tools market with players such as Snow including vulnerability reporting in their products. In Snow’s case this data comes direct from the industry-standard NIST vulnerability database. Flexera also provide vulnerability reporting, and Matrix42 recently acquired EgoSecure to strengthen their offering in this area.
Due to the nature of this breach it is unlikely that even a fully-integrated SAM & IT Security team would have spotted it. However, as applications increasingly rely on 3rd party code and Open Source libraries there is an opportunity for the SAM team to provide additional value and raise their profile beyond being “those IT people who manage our Microsoft agreement”. As the GDPR-initiated compliance journey continues over the coming years there are likely to be more of these opportunities for SAM Managers, alongside other role changes such as SaaS Subscription Management.