3 Access Security Lessons Learned from the Marriott Data Breach

Originally published by Authomize here.

Written by Gabriel Avner, Authomize.

For the third time in less than five years, international hotel corporation Marriott is back in the news with yet another data breach.

According to reports out of Databreaches.net who broke the story, Marriott was the victim of a social engineering attack where the hackers convinced an employee at the hotel near BWI Airport to give them access to his computer. The thieves then made off with 20GB of data that included some credit card details, as well as personal identifying information (PII) belonging to people who had stayed at the hotel.

The overall sensitivity of the data remains a debate as Marriott’s communications team has denied that anything of high value was taken.

Negotiations between the hackers and Marriott appear to have failed, with the hotelier refusing to pay. No word yet from the criminals if they intend to publish anything beyond the scraps that they sent out to Databreaches.net for proof of their activities.

Finding themselves in the headlines again for what by all appearances is a fairly limited incident is suboptimal for Marriott.

Nobody can really confirm the identities of the hackers who hit Marriott this time around. In the past they have been targeted by Chinese intelligence (Starwood hack) where 500 million people had their information stolen. In the 2020 incident with a much smaller 5.2 million folks compromised, the guilty party appears to be criminal in nature.

This time around it is hard to tell who is really behind the breach. For the more conspiracy minded-among us, BWI is only about 20 minutes away from Ft. Meade and the ransom could have been a cover, but there is no evidence one way or another.

What Can We Learn From the Marriott Hacks?

Regardless of whoever is behind this round, it is clear that hotel chains like Marriott are ideal targets for malicious hackers.

They hold tons of PII, payment information, do not have the same regulatory security standards as say a financial or healthcare organization, and have very wide attack surfaces with so many employees having (hopefully) varying levels of access.

In this case, the hackers did not have to find a vulnerability in the code or try to brute force anything. They used a bit of skullduggery to abuse a legitimate user’s real credentials, helping them reach real data and get Marriott back in the headlines.

Given all of these incentives for continued attacks against Marriott (the goose that keeps on giving) and similar organizations, what can we learn from these hacks?

1. MFA is Not Enough

In the 2020 attack, legitimate stolen credentials were reportedly used to access the data.

Multi-Factor Authentication could have been used to reduce the risk of that breach by adding an additional layer of protection, but as we see here in this latest case, authentication has its limits.

The human is still a vulnerable factor here, and a well targeted social engineering attack can overcome some of these added security measures.

On a technical level, an attacker could set up a fake MFA page that would capture the one time password (OTP) that the targeted user would input to access their account. Or they could go the old fashioned route and just trick the user into giving them the desired access as we saw in this latest go at Marriott.

These kinds of social engineering tricks are not uncommon. Last year hackers used a victim’s Slack to communicate with EA Games’ helpdesk to skirt around the MFA protections, having claimed to have lost their phone at a party over the weekend.

MFA like all forms of authentication is very valuable, but it is only the first step and requires being backed up with defense in-depth that provides real security.

2. The Bigger the Organization, More Opportunities for Hacks

Hacks, like most kinds of offense, are a numbers game. The more attacks that you can launch at a target, statistically the greater chances that you will have to eventually succeed.

For hackers, every identity in the organization is an opportunity to make their breach. The bigger the organization, the more opportunities they have to phish or find stolen credentials for someone in your organization and worm their way into your data.

As organizations have sped towards the cloud, they have accumulated heaps of new identities for each of the new apps and services that they are using, quickly multiplying the number of creds that must be secured against compromise. This has created a significant challenge for security teams that have to handle both securing access via those exponentially expanding quantities of identities and monitor for when they show up on a bin site or dark web marketplace.

3. Identify and Protect Your Sensitive Assets

Based on the mix bag of more and less sensitive assets that the hackers appear to have made off with in this breach, it would seem that the blue team did not do enough to identify what was more sensitive.

In general, assets deemed as sensitive are generally going to be financials, credit card or other customer information, source code or IP, or access to your development pipeline among many other bits.

Understanding what is sensitive and requires extra security attention is very important, but it is also hard to do at scale — especially from a prioritization perspective.

3 Tips for Mitigating Risks to Your Identity and Access Layer

Given these takeaways, there are a number of steps that you can take to make your organization a harder nut to crack for hackers attempting to target your identity and access layer.

1. Reduce Privileges to Narrow the Attack Surface — Principle of Least Privilege

Attackers, insider or external, cannot access assets that they do not have privileges to access.

Especially in cloud environments like Software-as-a-Service (SaaS) and Infrastructure-as-a-Service (IaaS), access privileges are the microsegmentation that you used to have in your network. The way that we do this is by adhering to the Principle of Least Privilege that calls for only provisioning the minimal amount of access privileges necessary to get a job done. No more, no less.

The more that you limit an identity’s access privileges, the more you narrow your attack surface that a malicious actor can take advantage of in reaching deeper inside your organization’s data. This way, when an attacker gains an initial beachhead inside your organization by compromising an identity, they will only have access to a limited quantity of assets.

Think of it as controlling the blast radius from a security incident when one or more of your organization’s many credentials get popped.

2. Understand Who Else Has Access to Your Environments

We are all increasingly interdependent on partners and vendors, so their security is our security.

Ask how the other organizations that you are working with are securing their identities and access. Are they compliant with common regulations like SOC II, PCI-DSS, and so on? Do they have any Cloud Security Alliance certifications of audits? Do they have security tools and processes in place?

Also, be sure to understand what access you have granted them inside your apps and services. Can they see your CRM, development pipeline (AWS & GitHub), or have any other kind of access that can leave you exposed?

Gaining visibility over what access external partners have requires looking outside of your identity management system and connecting directly to said apps and services to see the access privileges. If you are depending solely on your Identity Provider like Okta, then you are only seeing half the story.

3. Monitor Privilege Usage for All Apps and Services

It is not enough to simply know what the entitlements are for a given identity, either human or machine. You have to see how they are using their privileges.

Who is not using their privileges and can have them revoked without impacting their work? Why is someone from dev regularly accessing files from finance? Who has retained their privileges from an old position and now has a serious case of privilege sprawl? And why does Sally still have active access privileges even though she left the company six months ago?

Gaining this level of visibility requires a more granular understanding of your access privilege layer, but it can help to answer a lot of questions about the unknowns in your environments.

Stay a Step Ahead of the Headlines

Marriott has had a rough go of it the past couple of years, and this write up is not meant to add insult to injury.

In at least two cases that we know about, the hotelier has had its identities and access abused by hackers, leading to them ending up with legal and reputational pains that you wouldn’t wish on your competitors.

Hacks can and will happen. Our goal should be to make it as difficult for hackers to find ways to escalate their privilege, and let them leave with as little as possible.

Hopefully following some of these tips can help your organization give a hacker a bad day and avoid some of the pitfalls that have befallen others.