What the Santander and TicketMaster hacks teach us.

Whilst the exact cause of the hacks has not been released officially, there are a number of clues from press releases that hint at the causes. Unfortunately, it is the same old, same old. Hackers took advantage of long known about weaknesses and ones that can be easily addressed. They were poor leavers process, too high a privilege for internal users and finally poor shared security model.

Unusually for a blog the reader can stop reading now and go there is nothing new to be learned here, and that is true. However, it is worth re-iterating some of the causes in the hope other companies can tighten up their security posture.

What we know so far

At the time of writing, no official announcement has been made. The suggested cause is that both companies use SnowFlake to store their data. Fingers have been pointed at SnowFlake but they have vehemently denied the issue saying both parties didn’t do enough to protect their data. This is the classic lack of shared security model.

Snowflake did admit that there was unusual activity around an old account that was used for demo purposes, but it was in another domain and did not have access to the production domain. This highlights a potential issue around the movers or leavers process.

Whether this is true for Snowflake or not, there is an issue that many organisations need to be aware of and that is who within the service provider has visibility into production data.

Shared Security Model

The functionality provided by almost every cloud service provider is intoxicating and to be fair they do provide good security. That security though is to protect their infrastructure and often it does not cover the application or data developed upon it.

The most common scenario is that strict permission rights and MFA are used by developers, support staff etc to access the cloud service. Basically, good security principals – tick.

For the end application users will login using username and password and there will not be a good permission structure. Therefore, it’s possible for an elevated account to be compromised and then have access to a lot of data.

It is that intoxication, drunkenness on all the functionality, means occasionally the security is assumed with trickle down to the end application.

This is where the Shared Security Model kicks in, it’s a way of reminding organisations that security needs to be shared between the cloud provider and the application.

Demo Account

The admission that there was unusual activity around an old demo account, may have been harmless in this case, should be headed as a warning. Good IAM practices would have likely prevented this from happening. Firstly, if the user had left or changed roles then the account should have been deleted or at worse disabled. Secondly regular access reviews should have highlighted that this account is not being used and therefore questions should have been asked.

It is likely the demo system was outside of the core set of applications for all users and therefore was likely viewed as a fringe use case. Regardless, it essential that account control and reviews on ALL applications are essential.

Developer Access

The discussion around the demo account does also raise an issue that is not often considered by organisations when purchasing systems. (A big cover of backside statement here is that there is no mention that this is the case with Snowflake).

Many a service provider will have administrators with the ability to view customer’s data. Within the vendor this can be developers, support staff, operations, solution architects, people in sales. The question that any prospective customer should ask is “Who will have access to my data?” The advice would also be, even after purchasing, to ask “Who has had access to my data?”. This may make the vendor squirm a little but it is worth it to know just how many extra people will have access to the data.

Many recent breaches have not come because of poor controls within an organisation’s implementation, but from vulnerabilities in the service provider.

Advice for the end users of TicketMaster and Santander

Unfortunately, all said and done, and whatever the cause of the breach, real users will feel vulnerable worrying about what has happened to their personal information.

The advice is to ensure that any passwords used are not replicated in other applications. If you are a user that has one password for everything (yes you know its wrong) change the password immediately and take the opportunity to create unique passwords for all your applications. If you haven’t already it might be worth investing in a password management tool. They are not expensive.

If there is concern about credit card information, do speak to your credit card provider. It may be painful for a few days changing information but cancelling the card and getting a new will ensure your safety from any financial theft.

Finally, do be on a look out for more spam and phishing attempts. Raise that suspicion level a bit higher.

Summary

It is an understatement to say that a breach is never a good thing, corporate reputations and consumers are hurt by them. What is essential is that lessons are learnt.

The disappointing thing with this breach is that well known IAM practices that have been developed because of many risky situations were not followed. Lessons learnt from the past have not been followed.

Hopefully the high profile nature and the amount of potential customer data stolen might act as a wakeup call to follow good tried and trusted practices

Disclaimer

Being human the author is able to generate content based off a small data set such as  https://www.informationweek.com/cyber-resilience/-it-wasn-t-me-snowflake-denies-attack-responsibility-admits-hack-of-former-worker.