4 ms·

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

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 hadn’t the breach been detected earlier? And if the tool was not used earlier, how can they be so sure the breach occurred in 2014? It isn't unthinkable that the new tool alerted them to a problem, and during investigation discovered evidence that the vulnerability had been abused in the past. > It is almost impossible to imagine a scenario in which an external hacker is able to gain access to the primary encryption keys. Why? The argument seems to be: the primary encryption key is important, and thus will be most carefully guarded, so it is unthinkable that it would actually be exposed. 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.

heartbreak 8y ago
> 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.
- ec109685 8y ago
  Marriot replaced his system at Starwood with theirs (and he didn’t agree with that) so his technology was laid off :)
- laurentl 8y ago
  More like someone with "CTO of Starwood" on his resume at a time when "Starwood IT hacked" is the main headline. I tend to agree with his conclusion: without further information, it's useless to speculate about how it happened. But his effort to spin an alternative narrative is, at best, self-serving.
lowercased 8y ago
> 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, and another 5 had come and gone (and had had access to the same key) in the previous 6 months. I know not all companies are run like that, but I suspect it's closer to the norm. Even in places where they want to be more secure, enforcing security policies often becomes an after thought to more important tasks (in places I've seen/worked).
- will4274 8y ago
  > 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 them, you can't trust your service, period. It's normal for operators and developers to occasionally have access to sensitive data (e.g. when your service crashes, somebody has to look at the crash dump). Such access should be restricted (requiring approval) and logged, of course, but it's difficult to eliminate entirely at scale. It's good to rotate keys on a regular basis - but an annual key rotation doesn't seem negligent to me for a key used to encrypt session data, which is necessarily long-lived.
  - bdhess 8y ago
    > Such access should be restricted (requiring approval) and logged, of course, but it's difficult to eliminate entirely at scale. It’s not clear how you could practically enforce this requirement if devs just have the raw key on their workstations.
    - hanniabu 8y ago
      Would be nice to use a multi-sig so the dev would need their key which they always have access to plus a key from an approver.
qaq 8y ago
I think for most companies convenience trumps security. Like the current workplace is first I worked @ were keys for signing are stored in a special secure location on air gaped systems.
Dwolb 8y ago
Your first point lacks context of the next paragraph. Here’s the two paragraphs combined which changes the meaning. >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 is difficult to imagine how an architectural or platform vulnerability would not have been discovered or exploited sooner. He’s saying it’s most likely this exploit has been discovered earlier than 2014. This is even more aggressive than your point which was >>It does not mean that. It means that we don't know of any exploited vulnerabilities before that point.
hn_throwaway_99 8y ago
Honestly, after seeing this article upvoted so high and then reading it, I was relieved to see these comments. At it's root, security for always-on networked systems is extremely difficult, even at tech-first companies with an ingrained "security culture", nevermind a hospitality company like Starwood where "IT" is another department. And this guy comes forth with clueless statement after clueless statement about "The system was already operating securely for five years" and the one about the primary encryption keys. This whole article is incredibly self serving.
- barrow-rider 8y ago
  > This whole article is incredibly self serving. Mmmmhmmmm. It's executive CYA, and a public article for a public clusterfuck. 5 years ago is when this stuff probably started going sideways and those failures manifest later as massive outages, breaches, etc. Could be that the author IS WHY a lot of these issues cropped up later, so take proactive steps to blame others. Gotta keep that executive cachet high so that you can slide into a CTO role elsewhere.
tyingq 8y ago
"the article strikes me as an article written by someone who has a beef with Marriott" Another comment here references a post he made in 2016: https://www.linkedin.com/pulse/marriottstarwood-back-future-technology-decision-israel-del-rio/ https://www.linkedin.com/pulse/marriottstarwood-back-future-... Seems to be more of the same.

heartbreak 8y ago

> 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.

ec109685 8y ago
Marriot replaced his system at Starwood with theirs (and he didn’t agree with that) so his technology was laid off :)
laurentl 8y ago
More like someone with "CTO of Starwood" on his resume at a time when "Starwood IT hacked" is the main headline. I tend to agree with his conclusion: without further information, it's useless to speculate about how it happened. But his effort to spin an alternative narrative is, at best, self-serving.

lowercased 8y ago

> 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, and another 5 had come and gone (and had had access to the same key) in the previous 6 months. I know not all companies are run like that, but I suspect it's closer to the norm. Even in places where they want to be more secure, enforcing security policies often becomes an after thought to more important tasks (in places I've seen/worked).

will4274 8y ago
> 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 them, you can't trust your service, period. It's normal for operators and developers to occasionally have access to sensitive data (e.g. when your service crashes, somebody has to look at the crash dump). Such access should be restricted (requiring approval) and logged, of course, but it's difficult to eliminate entirely at scale. It's good to rotate keys on a regular basis - but an annual key rotation doesn't seem negligent to me for a key used to encrypt session data, which is necessarily long-lived.
- bdhess 8y ago
  > Such access should be restricted (requiring approval) and logged, of course, but it's difficult to eliminate entirely at scale. It’s not clear how you could practically enforce this requirement if devs just have the raw key on their workstations.
  - hanniabu 8y ago
    Would be nice to use a multi-sig so the dev would need their key which they always have access to plus a key from an approver.

qaq 8y ago

I think for most companies convenience trumps security. Like the current workplace is first I worked @ were keys for signing are stored in a special secure location on air gaped systems.

Dwolb 8y ago

Your first point lacks context of the next paragraph. Here’s the two paragraphs combined which changes the meaning. >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 is difficult to imagine how an architectural or platform vulnerability would not have been discovered or exploited sooner. He’s saying it’s most likely this exploit has been discovered earlier than 2014. This is even more aggressive than your point which was >>It does not mean that. It means that we don't know of any exploited vulnerabilities before that point.

hn_throwaway_99 8y ago

Honestly, after seeing this article upvoted so high and then reading it, I was relieved to see these comments. At it's root, security for always-on networked systems is extremely difficult, even at tech-first companies with an ingrained "security culture", nevermind a hospitality company like Starwood where "IT" is another department. And this guy comes forth with clueless statement after clueless statement about "The system was already operating securely for five years" and the one about the primary encryption keys. This whole article is incredibly self serving.

barrow-rider 8y ago
> This whole article is incredibly self serving. Mmmmhmmmm. It's executive CYA, and a public article for a public clusterfuck. 5 years ago is when this stuff probably started going sideways and those failures manifest later as massive outages, breaches, etc. Could be that the author IS WHY a lot of these issues cropped up later, so take proactive steps to blame others. Gotta keep that executive cachet high so that you can slide into a CTO role elsewhere.

tyingq 8y ago

"the article strikes me as an article written by someone who has a beef with Marriott" Another comment here references a post he made in 2016: https://www.linkedin.com/pulse/marriottstarwood-back-future-technology-decision-israel-del-rio/ https://www.linkedin.com/pulse/marriottstarwood-back-future-... Seems to be more of the same.