History

The Marriott Starwood Breach: Inheriting a Hack in a Merger

Marriott disclosed in 2018 that its Starwood guest database had been breached since 2014. Learn what was taken and why due diligence and logging matter.

By Zebra Hosting Cloud

On 30 November 2018, the hotel group Marriott International announced that its Starwood guest reservation database had been accessed without authorisation. The unusual part of the story was its length: the intrusion had begun in 2014, two years before Marriott even bought the Starwood brand. The incident became one of the best-known examples of how a company can take on hidden security debt when it acquires another.

What Marriott disclosed

Marriott said that it had received an alert from an internal security tool on 8 September 2018 about an attempt to access the Starwood reservation database in the United States. Investigators found that an unauthorised party had copied and encrypted information, and had been in the Starwood network since 2014. The database covered bookings made at Starwood-branded hotels, which included Sheraton, Westin and W Hotels, among others.

The initial announcement said that up to 500 million guests could have been affected. After further analysis, the company revised the figure in January 2019 to about 383 million guest records, noting that some of those records were duplicates and that a number of individuals had several. The information varied by guest and could include names, addresses, phone numbers, email addresses, passport numbers, dates of birth, travel details and booking information.

Passports and payment cards

Marriott said that about 5.25 million unencrypted passport numbers and roughly 20.3 million encrypted passport numbers were involved, along with a smaller number of payment card numbers that had been encrypted. The company said it could not rule out that the attackers had also taken the information needed to decrypt the encrypted data. Passport numbers are particularly sensitive because they are hard to change and can be used to create false identities.

How a breach can last four years

Marriott bought Starwood in September 2016. Press reporting and later regulatory findings described the Starwood network as having been compromised before the acquisition, and the intruders' presence was not discovered until well after the deal. That raises questions that any buyer should ask:

  • Have we reviewed the target's security, not just its finances?
  • Do we know what data its systems hold and where?
  • Are its logs retained and monitored, so that past intrusions can be found?
  • When do its systems move onto our own controls?

The UK Information Commissioner's Office said that Marriott had not done sufficient due diligence when acquiring Starwood and should have done more to secure its systems after the purchase.

Regulators respond

In July 2019 the ICO announced its intention to fine Marriott about 99 million pounds under the GDPR. After considering the representations from the company and the effects of the pandemic, it issued a final penalty of 18.4 million pounds in October 2020. Other regulators and lawsuits followed in several countries. It was one of the first large penalties issued under the GDPR.

What stands out

IssueWhat it shows
Access since 2014Long dwell time means long exposure
Unencrypted passportsSensitive fields need encryption at rest
Discovery by internal toolMonitoring works when it is turned on and watched
Inherited systemsSecurity debt travels with an acquisition

What encryption does and does not do

Marriott's statement that it could not rule out the theft of the decryption components is worth a closer look. Encryption protects data only as long as the key stays secret. If the keys are stored on the same system as the data, or can be reached by the same intruder, the encryption gives much less protection than people assume. Good practice is to keep keys in a separate, tightly controlled place and to restrict which systems can ask for them.

The fact that some passport numbers were not encrypted at all points to a second issue: fields were treated differently, depending on how they had been collected and stored. Over time, systems accumulate fields like these, and unless somebody maps what is held where, sensitive items end up with weaker protection than intended.

For a website, the equivalent is knowing every place your forms send data. A booking form, a contact form and an old newsletter plugin might each store personal details in different tables or in email inboxes. Reviewing them together, and collecting only what is needed, is the cheapest security improvement available.

The practical lesson for site owners

Small businesses inherit things too: a website built by a previous agency, a shop bought from another owner, a plugin installed years ago. When you take over any of these, treat it as unknown. Change every password and key, delete unused accounts and users, update all software, look for files you do not recognise and check what data is stored. When migrating a site to new hosting, a clean install is a good moment to remove old baggage.

If you are moving a website, our team handles the transfer for you; see the migration page for how it works, and our security overview for the habits worth setting up afterwards.