[different_sort]

Maybe I’m just an unimpressed security professional but I’ve still not seen evidence I’d call a breach. At least not a significant one if you want to argue sublantics.

Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.

[ev1]

I do security (albeit not CISO or compliance-style, but commercial anticheat), and in my opinion, if a support agent's account was used by a third party to view anything about my account without permission - any undisclosed email address or name, their system was compromised and it is a data breach.

IMO, support agents also should not have the ability to view or access a customer's account without some form of time limited, auto-resetting-to-opted-out default confirmation that support can view the account from an existing logged in admin.

[kichik]

Yeah, the screenshots they admit are real clearly show Slack, JIRA and AWS being open. What did the attackers see there? Were the customers whose data was viewed notified? How can Okta tell if that data is sensitive or not without taking to their customers?

[jclulow]

If through compromising those workers outside parties gain access to sensitive systems, and that situation is not promptly detected and corrected, then the system _is_ compromised.

Okta is not just a bunch of software, it's also staff and processes, and the result is a trusted service they provide to customers. If that service is compromised, it doesn't really seem to matter how?

[haswell]

> If that service is compromised, it doesn't really seem to matter how?

I hear what you're saying, but the how does really matter, and will change how customers perceive the issue and make decisions about how to react.

e.g. "databases were open to the Internet and all data has been siphoned" lands quite differently than "a staff member abused their privileges but the scope of abuse was limited to xyz".

If I'm a customer, it tells me a lot about what Okta needs to do next, and how much I should freak out right now. It's still extremely problematic that a staff member (1st or 3rd party) could abuse such privileges, and I immediately have questions about how those privileges were abused and to what actual effect, but it's a fundamentally different problem than other types of breaches.

[mardifoufs]

If you follow the lapsus telegram, you will see they are claiming they got AWS API keys from the corporate slack. That might be more dangerous than accessing the support console

[MattGaiser]

I can see a Slack breach being far more damaging than policy should effectively permit it to be because plenty of people use it to share things they technically should not.

[ckozlowski]

Without proper separation of duties to limit blast radius, it's just as damaging as a software vulnerability. It sounds like that's the real issue here: Compromise of a support engineer lead to far more access than should have been permissible.

[Eyas]

Right, but their claim is that there were proper separations that successfully did limit the blast radius.