Security takeaways from the Marriott breach

Last week, we dove into the basic facts of what happened during the Marriott data breach. This week, it’s time to analyze what went wrong at Marriott to see what we can learn from it. Let’s jump in!

Lack of multifactor authentication

One of Marriott’s failures was that not all accounts that could access the cardholder data environment had multifactor authentication (MFA). If multifactor authentication was implemented on all accounts, then the attackers would not have been able to access the card databases unless they also had access to the secondary factors of authentication (such as an authentication app or security token). The lack of multifactor authentication meant that once the attacker gained access to the passwords, they could easily make their way into the database.

Marriott stated that Starwood had assured it that MFA was in place in the cardholder environment, with two independent PCI DSS audits indicating that MFA was deployed. In this case, it’s hard to fault Marriott when two PCI DSS audits indicated that the appropriate protections were in place. This seems to come down to a mistake on behalf of the auditors.

Logging and monitoring failures

The cardholder data environment contains incredibly sensitive data, so any privileged accounts accessing it should be carefully monitored. While Marriot did have a security operations center, it had not assessed the logging practices associated with the cardholder data environment. It turned out that access to systems or applications within the cardholder data environment wasn’t being logged at all. This meant that Marriott wasn’t alerted when the attacker gained access to the sensitive system, so Marriott wasn’t able to mitigate the attack early.

Another important logging failure is that the server wasn’t logging the creation of files, which allowed the attacker to export databases without being detected. On top of this, Marriott only had alerts set up for specific queries on databases that contained payment card data—it wasn’t sending alerts for access to databases that contained some of the personal information that was breached. While it does make sense to have increased security on the payment card information, the personal data was still sensitive information that could impact the affected individuals, so it should have also had alerts.

Lack of whitelisting

One way that Marriott could have prevented the breach is if it had hardened its servers through whitelisting. If it had restricted access to sensitive systems so that only IP addresses listed on its whitelist could gain access, then the attackers could have been blocked.

Encryption issues

When it comes to encryption, things get a little weird. Only the payment card data and some passport numbers were “encrypted”. Personal data, plus many other passport numbers were stored in plaintext. This is obviously bad, because it means that anyone with access to the files has access to the sensitive personal information.

For years, Marriott as well as many of those who investigated the incident have claimed that the payment card data and some of the passport numbers were encrypted by AES-128, which is a secure algorithm. However, in April 2024, Marriott released an update stating that they were actually hashed with the SHA-1 algorithm, not encrypted. We’re not sure why exactly this only came out years after the fact, but it’s a little odd, because hashing and encryption are fairly different cryptographic techniques that provide differing properties to the data. On top of this, SHA-1 is an old algorithm that is no longer considered secure in many applications.

Sign up for our upcoming CISSP BootCamp!