Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was a senior VP of tech at Starwood: here’s my take on the guest data breach

phocuswire.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#41

Post by valiant-comma »

agotterer wrote: post #7

> It is almost impossible to imagine a scenario in which an external hacker is able to gain access to the primary encryption keys. I was reasonably sold on what was being said until that comment. Impossible is a strong word to use when it comes to computer security. It seems that everyone who has claimed that there system is unhackable, always ends up being hacked.

Agreed. He seemed to make a decent argument that the quantity of records + types of data exposed didn’t add up (based on his knowledge of the system), but this statement (about primary encryption keys) undermined the credibility of the overall piece.

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#42

Post by docker_up »

This is a masterclass of CYA. He takes a lot of effort to try to prove that the system he was in charge of wasn't the cause, even though his arguments are absurd ("if we accept Marriott’s statement that the breach began in 2014, the system would already have been operating securely for five years." It was operating for 5 years but there's nothing to prove that it was operating securely for 5 years.) He also handwaves and leads the readers down some detective story ("ergo it must have been the data warehouse!") and says "We really don't know if it was Valhalla and may never know!"

No wonder he's an executive, he is an expert CYA-ers!

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#43

Post by ec109685 »

heartbreak wrote: post #9
abhorrence wrote: post #2

This article seems full of points that a lay person might nod along with, yet don't hold up to scrutiny. > The fact is, if we accept Marriott’s statement that the breach began in 2014, the system would already have been operating securely for five years. It does not mean that. It means that we don't know of any exploited vulnerabilities before that point. > If the detection tool was used prior to this September, why…

> Ultimately the article strikes me as an article written by someone who has a beef with Marriott, and he ends noting that it's possible that the breach occurred not due to issues with design, but due to the layoffs of Starwood's technical staff. I agree with your first several points, but a lay-off beef is unlikely since the author hasn’t worked for Starwood in over a decade.

Marriot replaced his system at Starwood with theirs (and he didn’t agree with that) so his technology was laid off :)

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#44

Post by PeterisP »

will4274 wrote: post #25
lowercased wrote: post #14

Earlier quoted context omitted.

> It is almost impossible to imagine a scenario in which an external hacker is able to gain access to the primary encryption keys. I worked some place where lots data was encrypted with a key. The key hadn't changed in months - at least 6 months by the time I found it. I was told this same key would be used to encrypt web session data in a cookie. There were more than a dozen people who I knew had access to the key,…

> The key hadn't changed in months - at least 6 months by the time I found it. I was told this same key would be used to encrypt web session data in a cookie. There were more than a dozen people who I knew had access to the key, and another 5 had come and gone (and had had access to the same key) in the previous 6 months. What's so wrong with any of this? Software requires operators and developers. If you can't trust…

For keys that matter, good practice is that no one has direct access to the key. E.g. you have a process where there are ways to sign stuff with that key, and there are ways to gain access to that key if extraordinary circumstances arise, but in normal operation you should be able to make sure that you can revoke the ability to sign stuff from anyone, which requires you to be certain that they never ever had a chance to see, copy or write down private key material.

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#45

Post by charlesdm »

antonvs wrote: post #36
will4274 wrote: post #25

Earlier quoted context omitted.

> The key hadn't changed in months - at least 6 months by the time I found it. I was told this same key would be used to encrypt web session data in a cookie. There were more than a dozen people who I knew had access to the key, and another 5 had come and gone (and had had access to the same key) in the previous 6 months. What's so wrong with any of this? Software requires operators and developers. If you can't trust…

> What's so wrong with any of this? A very basic principle of security is the principle of least authority. To implement that, you don't use one key for many different purposes over a long period of time and give it to anyone who needs it. You use different keys for different purposes, and replace the keys periodically to help ensure that they're only available to a limited group. Another way to answer your question…

The short (and sad) answer is that no one really cares about security; they only care about it when something hits the fan.

Security isn't a revenue driver, only a cost. It's commonly known that most companies (small or large) vastly prefer investing in things that increase revenue and profit.

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#46

Post by arethuza »

PeterisP wrote: post #44
will4274 wrote: post #25

Earlier quoted context omitted.

> The key hadn't changed in months - at least 6 months by the time I found it. I was told this same key would be used to encrypt web session data in a cookie. There were more than a dozen people who I knew had access to the key, and another 5 had come and gone (and had had access to the same key) in the previous 6 months. What's so wrong with any of this? Software requires operators and developers. If you can't trust…

For keys that matter, good practice is that no one has direct access to the key. E.g. you have a process where there are ways to sign stuff with that key, and there are ways to gain access to that key if extraordinary circumstances arise, but in normal operation you should be able to make sure that you can revoke the ability to sign stuff from anyone, which requires you to be certain that they never ever had a chance…

Isn't that the point of HSMs where nobody can get access to retrieve the private key - all you can do is sign stuff with the key?

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#47

Post by PeterisP »

arethuza wrote: post #46
PeterisP wrote: post #44

Earlier quoted context omitted.

For keys that matter, good practice is that no one has direct access to the key. E.g. you have a process where there are ways to sign stuff with that key, and there are ways to gain access to that key if extraordinary circumstances arise, but in normal operation you should be able to make sure that you can revoke the ability to sign stuff from anyone, which requires you to be certain that they never ever had a chance…

Isn't that the point of HSMs where nobody can get access to retrieve the private key - all you can do is sign stuff with the key?

Yup, but even in cases where the expense of a proper HSM isn't warranted, you can set up a software solution/process that works in a similar manner to a HSM, just with less tamper-resistance.

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#48

Post by arethuza »

PeterisP wrote: post #47
arethuza wrote: post #46

Earlier quoted context omitted.

Isn't that the point of HSMs where nobody can get access to retrieve the private key - all you can do is sign stuff with the key?

Yup, but even in cases where the expense of a proper HSM isn't warranted, you can set up a software solution/process that works in a similar manner to a HSM, just with less tamper-resistance.

Of course even if you have HSMs there is still the issue of controlling access to the HSMs!

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#49

Post by bogomipz »

This person has not worked at Starwood in 12 years. Their qualifications for making any kind of insightful analysis are basically nil at this point. As if this weren't weren't absurd enough he goes on to make the following laughable statements:

>"It is almost impossible to imagine a scenario in which an external hacker is able to gain access to the primary encryption keys."

>"The fact is, if we accept Marriott’s statement that the breach began in 2014, the system would already have been operating securely for five years."

>"Israel del Rio is executive technology consultant and CTO at Quilmach."

As someone who has family affected by this breach it's upsetting to see to see this individual using this incident for their own self-promotion. However at least his new company Quilmach now knows he is completely clueless about technology. So I guess he did everyone a favor here. Israel del Rio - Executive Idiot.

Re: I was a senior VP of tech at Starwood: here’s my take on the guest data breach

#50

Post by lowercased »

antonvs wrote: post #36
will4274 wrote: post #25

Earlier quoted context omitted.

> The key hadn't changed in months - at least 6 months by the time I found it. I was told this same key would be used to encrypt web session data in a cookie. There were more than a dozen people who I knew had access to the key, and another 5 had come and gone (and had had access to the same key) in the previous 6 months. What's so wrong with any of this? Software requires operators and developers. If you can't trust…

> What's so wrong with any of this? A very basic principle of security is the principle of least authority. To implement that, you don't use one key for many different purposes over a long period of time and give it to anyone who needs it. You use different keys for different purposes, and replace the keys periodically to help ensure that they're only available to a limited group. Another way to answer your question…

There was no ability to tell who'd even seen the key. A colleague of mine 'got it', and when it was shown he had it, there was a "WTF? You're not supposed to have that? Where'd you get it?". It was checked in to version control. It was just in a project that only a few people were assigned to, but there was no restriction on who could view those projects.
Post reply on HN