171–180 of 336 posts
Earlier quoted context omitted.
Stuxnet?
Stuxnet targeted the uranium enrichment facility at Natanz run by the Iranian government. When does the US attack private enterprise?
Earlier quoted context omitted.
Okay, I'll bite; what about a github account? You don't generally own code you write for an employer, so why would you be an personal repos from a company machine? (Likewise, there's generally no good reason for the company to have access to personal repos, so those security domains should never overlap)
Even among engineers, most people don't think like a security engineer. I'm sure there are plenty of people who have access to their company's private repos through their personal GitHub accounts.
Earlier quoted context omitted.
Yes, but if after two months they’d found out that customer data had been compromised, that would be a little late for me to do anything about it.
What do you expect them to do? It sounds like you are complaining that they weren't able to instantly ascertain if customer data had been compromised.
What I’d expect is a note on the 24th that they’d kicked a threat actor of their Jira system, and that they had no reason to believe the rest of their systems were compromised, but that they were taking action to prevent it from happening again and starting a full investigation.
I get that the business might not want to do that if they are not certain there is any cause for alarm. Uncertainty might be even worse for some.
> The one service token and three accounts were not rotated because mistakenly it was believed they were unused. Eh? So why weren't they revoked entirely? I'm sure something's just unsaid there, or lost in communication or something, but as written that doesn't really make sense to me?
That is, I'd expect there was a flag in a database somewhere saying that those service accounts were "abandoned" or "cleaned up" or some other non-active status, but that this assertion was incorrect. Then they probably rotated all the passwords for active accounts, but skipped the inactive ones.
Speaking purely about PKI and certificate revocation, because that's the only similar context that I really know about, there is generally a difference between allowing certificates to expire, vs allowing them to be marked as "no longer used", vs fully revoking them: a certificate authority needs to do absolutely nothing in the first case, can choose to either do nothing or revoke in the second case, and must actively maintain and broadcast that revocation list for the third case. When someone says "hey I accidentally clobbered that private key can I please have a new cert for this new key," you generally don't add the old cert to the revocation list because why would you.
> we were (for the second time) the victim of a compromise of Okta’s systems I'm curious if they're rethinking being on Okta.
Okta deserves criticism for their failure, but this feels like CloudFlare punching down to shift blame for a miss on their part.
Thing about a data breach is once the data is out there - source code in this case - it’s out there for good and you have absolutely no control over who gets it. You can do as much post incident hardening as you want, and talk about it as much as you want, but the thing you’re trying to protect against, and blogging about how good you’re getting at preventing, has already happened. Can’t unscramble those eggs.
Writeups and actions like this from cloudflare are exactly why I trust them with my data and my business. Yes, they aren’t perfect. They do some things that I disagree with. But overall they prove themselves worthy of my trust, specifically because of the engineering mindset that the company shares, and how serious they take things like this. Thank you for the blog post!
Then, the advertisement worked. - Insist that you have better integrity than your competitors - share a few operational investigations after your latest security event what cloudflare doesnt do is provide their SOC risk analysis as a PCI/DSS payment card processor. Cloudflare doesnt explain why they ignored/failed to identify the elevated accounts or how those accounts became compromised to begin with. They just expl…
> The one service token and three accounts were not rotated because mistakenly it was believed they were unused. Eh? So why weren't they revoked entirely? I'm sure something's just unsaid there, or lost in communication or something, but as written that doesn't really make sense to me?
Betting they have a new item in their compromise runbook. :-)
Because if you take it exactly as it's written it's just too weird, I'm not a security expert with something to teach Cloudflare about err maybe don't leave secrets lying around that aren't actually needed for anything, that's not news to many people, and they surely have many actual security people for whom that would not even be a fizzbuzz interview question reviewing any kind of secret storage or revocation policy/procedure. And also the mentioned third-party audit.
Earlier quoted context omitted.
Yes, but if after two months they’d found out that customer data had been compromised, that would be a little late for me to do anything about it.
Had customer data been impacted we would have disclosed it immediately.
My concern was mostly around the situation where you believe it had not been, but it had.
Earlier quoted context omitted.
A Github account, for one possible example.
Okay, I'll bite; what about a github account? You don't generally own code you write for an employer, so why would you be an personal repos from a company machine? (Likewise, there's generally no good reason for the company to have access to personal repos, so those security domains should never overlap)
I think this is fairly common for people who work on open source projects.