
Marriott CEO shares post-mortem on last year's hack - wglb
https://www.zdnet.com/article/marriott-ceo-shares-post-mortem-on-last-years-hack/
======
guitarbill
This is basically a PR piece on how careful they're being and how "seriously"
they're treating it.

> Uncovering the full scope of the attack took significant forensic work, the
> CEO said. However, despite the RAT's presence on the Starwood IT system, at
> that point, there was no evidence that unauthorized parties had accessed
> customer data located in Starwood's guest reservation database.

> By the next month, in October, the forensic firm also found Mimikatz [...].
> The tool was most likely used to help hackers acquire passwords for other
> Starwood systems and help them move to other parts of the IT network.

> Yet again, investigators didn't find evidence that hackers had accessed
> customer data.

> Yet again, there was still no evidence of hackers accessing customer data.

With infrastructure so compromised, and so few protective measures, the
default assumption has to be some kind of customer data was accessed. Spin at
its worst.

And while I haven't watched the hearing, you'd expect a post-mortem to include
maybe how they gained access, and measures to fix it in future. Even if the
CEO didn't elaborate, you'd expect a reporter to ask similar questions, and at
least point out nothing was said.

~~~
judge2020
I also like how there's no mention of revoking the admins' credentials after
Guardium detected the anomaly. I would say it's obvious that they changed the
password, but then I may be giving them too much credit.

------
airstrike
> there was no evidence that unauthorized parties had accessed customer data
> located in Starwood's guest reservation database.

This has to be one of the most disingenuous phrases one could possibly utter
about an event like this. The fact that the attacker left no evidence (or that
you failed to identify whatever evidence was left behind) in no way assures
people that their data wasn't stolen. It's fallacious and it reeks of
negligence and a complete disregard for accountability.

I'm never staying at a Marriott again if I can help it. It's not much, but
it's better than nothing... Last year I hosted a corporate event at a Marriott
in NY and we paid north of $15k.

~~~
wvenable
Did you read the entire article? Once they had confirmed that customer data
was stolen, they informed the authorities and the public.

I don't think any company would do that differently.

~~~
time_for_toll
No he/she only wanted to boast about the $15k.

~~~
tomcatfish
It's the same point the current highest comment made:

Even though the system was compromised, they assumed the best case instead of
the worst case as would be expected with customer data.

The money seems to be a proof that their impact will be larger than just a
person who stays at a hotel twice a year.

~~~
wvenable
I don't think that's how to read it. They probably did not assume that at all.
But they are not going to go public with any information until they have
confirmation.

You're reading a postmortem and not necessary exactly what they were thinking
at the time.

------
jak92

      "The Guardium alert was triggered by a query from an 
      administrator's account to return the count of rows from a
      table in the database," Sorenson said.
    
      Such queries are considered dangerous because the software
      that runs on top of a database doesn't usually need to make   
      them.
    

Really?

~~~
ekimekim
"Dangerous" is probably the wrong word - anomalous is a better one. Most
software doesn't need to know, say, how many entries there are in the Users
table. It generally is querying for a specific user, or a range of users with
some particular property.

It sounds like they had some software watching for any out-of-the-ordinary
queries, which they then manually verified with the apparent person who was
executing them. When that person had no idea what they were talking about,
that's when the red flags went up.

~~~
sigi45
Your example with the user table is a little bit 'bad'. Because yes i like to
see statistics as an admin on how many user acounts are there :P

~~~
EpicEng
So you routinely log in as an admin and run sql queries directly on a
production DB? That seems quite a bit more "bad" than the example.

~~~
kakwa_
I do it several times per day. When you are maintaining a piece of garbage
application, completely undersized, absurdly opened in term of filtering and
extremely badly designed, it's the only way to manage this mess, not to
mention the times when I have to fix the DB by hand, replaying, with some
manual tweaks, queries normaly executed by the application.

And unfortunately, I don't think that's so uncommon.

~~~
josephg
I don't even think its bad practice.

I was the lone technical hire at a startup I was at a couple of years ago. We
ran our app on top of postgres, and I used a native macos postgres client to
keep an eye on our database (accessed via an SSH tunnel). The startup is very
high-touch with clients - we built personal relationships with our clients.

Unsurprisingly our CEO loved looking at the numbers and the data. We could see
conversion, and keep an eye on what our users were up to and how they were
using our product. I was the sole engineer and I was only working 3 days a
week. I didn't have time to build monitoring dashboards and all that; so
instead I spent half an hour teaching our CEO the basics of how to do postgres
read queries, and how to pull the results of a query out into CSV and into
excel. That was probably the most productive half hour of my time at that
startup - it was a huge enabler for him, allowing him to explore the data in
arbitrary ways. I showed him how to sort, filter, select specific fields and
join tables.

If I had instead built a specialised dashboard, it would have taken me away
from our product. And I wouldn't have any idea what queries to display - any
dashboard I made would have been worse for him than just querying the database
directly. I'm still convinced that I made the right call.

(We did eventually build a dedicated admin panel, but months later - only when
we actually needed it because some common tasks were too difficult through SQL
alone).

~~~
EpicEng
Nothing you describe there requires write/admin access though.

I'm not religious about this. My team automates anything we have to do more
than a couple of times, and from time to time we do have to manually alter
something in a prod db. Do it often/long enough though and someone _will_
screw something up.

------
elliekelly
> The Marriott CEO said again that investigative efforts have yet to uncover
> evidence to suggest that hackers gained access to the encryption key used to
> encrypt the payment card numbers, meaning that most of the compromised
> payment card numbers are still useless to attackers.

So the clearly sophisticated hacker(s) had access to the network for _four
years_ yet somehow forgot the private keys to decrypt the millions of records
they went through all that effort to steal?

~~~
linsomniac
I think you are misunderstanding... They got dumps of a couple of databases,
which they encrypted, downloaded, and presumably decrypted. Those dumps
themselves contained a credit card number that was encrypted by Marriott with
a key they don't think the attackers got.

That is my read of it anyway.

------
gwbas1c
What I really want to know is why wasn't this discovered as part of the due
diligence for the acquisition?

I thought it was normal to run a security audit of whatever systems a business
uses prior to the acquisition?

------
DaniloDias
It had never occurred to me to define a bunch of select * statements in
production that would trigger alerts. Brilliant.

------
rhizome
Long story short: he's not in prison.

