Ticketmaster – When a third party supplier breach is not what it appears

Ticketmaster – When a third party supplier breach is not what it appears.

As many of us learnt whilst growing up, most of the time obfuscating facts to portrait yourself in a brighter light actually creates a bigger problem. Now as an adult I am not going to have my parents tell me off but doing wrong by misstating facts is still not wise as an adult.

Unfortunately not all citizens think this way and in some cases, upstanding corporate citizens do not either, enter Ticketmaster

Ticketmaster data breach

Recently Ticketmaster (not Ticketek, also breached though) “PR’d” an announcement that they had been a victim of a data breach through a third party. Nothing to see here, carry on.

It turns out that their third party supplier was “Snowflake” who I assume Ticketmaster use for Data analytics etc and is a well known and popular SaaS platform, from what Snowflake has released, their customers who are not using Multifactor authentication are being targeted by cyber criminals at the moment – hold on, do you mean some businesses do not use MFA? when storing citizen data?

Hold on there is a little more to this story ……

**** Edited 13/06/2024, Mandiant, the cyber security firm working with Snowflake has confirmed that it does not appear that Snowflake was breached. The credentials stolen were the result of poorly secured Snowflake client accounts, read here for more information.

You see Snowflake (not just Ticketmaster) was also the target of a cyber attack, again due to a poorly configured employee account, though they are not necessarily painting this event as a result of that breach….

I am certain there is more nuance, but, it seems that Ticketmaster have simply ‘pulled’ the ‘Third party supplier breach’ card from their Cards against Humanity deck and blamed their provider of Data analytics, where the actual truth is nothing like the headline, and, Snowflake for their part are also trying to move blame here.

Snowflake Data Breach

Snowflakes public announcement is linked here:

Considering though that Snowflake were also (updated: Snowflake was not breached, accounts that had been poorly secured were compromised) breached through a lack of basic security posture controls like an operator without Multifactor Authentication just goes to show how important it is to deploy the correct security defaults.

Snowflake for their part have also denied, and then admitted through a public statement that an employees account was not adequately secured (MFA?) but that no data was accessed, at the moment this is the official word.

Snowflake may claim that it was not the victim of a data breach, but the attackers’ claims and Snowflake’s own statement show otherwise, security researcher Kevin Beaumont points out: one of their employees’ accounts was not properly secured and the employee was infected with an infostealer.

Thus, the researcher says, while it tries to blame its customers for the activity of the threat actor, Snowflake too is responsible for the incident.

“Snowflake themselves fell into this trap, by both not using multi factor authentication on their demo environment and failing to disable a leaver’s access,” the researcher says.

From SecurityWeek online

Ticketmaster, Snowflake what should you have done?

The facts as far as I can determine (Sarcasm on) are: Businesses who DO NOT have sufficient security are a target – meaning customers who do not use MULTIFACTOR AUTHENTICATION….. Ticketmaster, Snowflake – you can do a lot better …..

First, tell the truth. Telling the truth keeps people on your side, when lies are the default position for a corporation, then there is a question about what else they will lie about. Telling truths may be painful, but it leads to positive improvements and change in business.

Technical controls that support

1. Every Identity must have Multifactor Authentication enabled except “Break Glass” accounts, reporting on changes to security controls must also be implemented and always enabled.
2. Automation should be inlace to ensure that your security baselines are always where you expect them to be and not going backwards.
3. In addition, Privileged Identity management for all accounts with access to administer infrastructure or data should be required
4. Finally, a model of Least Privilege Access should be adopted to reduce the potential “Blast Radius” from a credential being compromised or a malicious insider.

Please reach out to me if you wish any further information or have any questions here.