It feels like a lawyer heavily tweaked this to sound better than it really is.
That's just a reality of corporate disclosures, I'm afraid. No one is going to let something like this go to press without a full round of legal and PR editing.
Updated Okta Statement on Lapsus$
21–30 of 239 posts
Re: Updated Okta Statement on Lapsus$
#22It feels like a lawyer heavily tweaked this to sound better than it really is.
Re: Updated Okta Statement on Lapsus$
#23Lapsus has responded https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c...
Re: Updated Okta Statement on Lapsus$
#24Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...
I thought that a CF person (can’t remember if it was Prince or not) said in the main HN thread yesterday, that CF uses their own homegrown SSO internally, and Okta externally, but this blog article seems to infer the opposite…
Anyway, I likely misinterpreted yesterday’s comment..
Re: Updated Okta Statement on Lapsus$
#25Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...
the difference in level of detail and amount of information provided has been out of this world. Thank you!
Also a fun exercise in "Show don't tell" when it comes to transparency.
Okta writes "We are deeply committed to transparency" but shows none in their blogpost in contrast to CloudFlare, that doesn't write anything about transparency but displays a lot of it.
A bit like queuing for your internet providers customer support for 3 hour and hearing "We care about customer satisfaction" every five minutes.
Re: Updated Okta Statement on Lapsus$
#26> Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. This means they could have reset anybody’s credentials and logged in. There would a record of it if the audit logs are valid, but saying no act…
> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.
What if they have access to some users' emails and then can selectively fire off password reset emails to them? It's probably less likely, but could be a vector.
Re: Updated Okta Statement on Lapsus$
#27There were a lot of doomsday predictions in yesterday's thread before any real info had been shared, but it was always the more likely scenario that a support agent contracted through a vendor would have limited read access to their internal systems and wouldn't be able to cause any real damage.
you can do a lot of damage with read access depending on what you're able to read
Re: Updated Okta Statement on Lapsus$
#28> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit. What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned…
It is not ambiguous. Facilitate means help. If a user cannot trigger the reset, support engineers can (help them) do it.
Re: Updated Okta Statement on Lapsus$
#29I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is cons…
If somebody uses my laptop, my Gmail account is not compromised; I'm being dolphined. Of course 5 days is quite a long time, but this is just to clarify what you didn't understand.
If I use your laptop to get access to your Gmail isn't your Gmail account compromised? I might not have access to your Gmail username and passwords (and MFA), but I can read your email, I can send email as you, etc etc. I feel like I have compromised your gmail account.
If I steal your secure token and log into you through a cloned browser session and access your gmail have I compromised your gmail? It feels like it.
Maybe it is just a distinction without a difference.
Re: Updated Okta Statement on Lapsus$
#30Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...
I gotta say, I don't make technical decisions at the "we're using CF" level, but I've been incredibly impressed with their track record over the years. I often evangelize blog post writing and transparency at my company and this is exactly why. What a way to build trust. It's basically free advertising for technical folk by "putting their money where their mouth is."
I'd love to see more of this in the industry. CF is, IMO, industry leading here.