[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?

[GauntletWizard]

A competent security response to this would have been "Yes, they compromised one of our support technicians. We've initiated an audit and are sending out e-mails containing all of the actions that support representative performed for each customer to that customer's administrator"

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

[Closi]

How it happened doesn't change the fact that they have been breached.

If I was a bank and claimed that I haven't been robbed, an insider just transferred billions of pounds out of the bank and then fled, I think everyone would rightly say "What are you talking about, you have been robbed!"

It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a bank robbery is a bank robbery.

In fact, the ability of an internal staff member to transfer lots of money out of the bank probably signifies a more significant and systemic issue - particularly if i've lost my money and the bank refuses to acknowledge they have been breached/robbed (it was just an internal rogue staff member, not a robbery! our security hasn't been breached!).

A bit of a stretched analogy - but i'm sure everyone gets the point. Security isn't just about technical security - it's the whole process involved in making sure these things don't happen. A banks 'technical' security might be great, but the bank would still be considered horribly insecure if a staff member can transfer any money out of an account. Equally an auth service might be 'technically' secure, but the ability of a single rogue staff member to impose a lot of damage suggests more systemic issues.

[haswell]

> It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a bank robbery is a bank robbery.

I have to respectfully disagree.

Yes, the end result may be the same, but even in a bank robbery, the how matters, and will drive different behaviors from everyone involved: the bank, law enforcement, and customers of that bank.

If as a customer, I learn that a guy in a stripey t-shirt holds a teller at gunpoint, my conclusion goes something like "that's a terrifying situation for the teller, and I hope they're ok". I'm probably not going to stop using that bank.

If on the other hand, I learn that there are systemic issues with bank security, and internal employees have been embezzling funds somehow, I'm probably going to think hard about whether this is a bank I want to do business with.

> Security isn't just about technical security - it's the whole process involved in making sure these things don't happen.

Yes, and when factors are involved that are out of the bank's control (e.g. a crazy person walks in with a gun), it might be fair to ask why the guy got inside to begin with, but the conclusions you draw about such an incident are far different than the conclusions you'd draw if internal employees were involved.

In case this wasn't clear from my earlier comment, I didn't mean to imply that an internal process issue makes any of this ok. But it does make it different than other types of breaches.

Bottom line: the how still matters, not because one type of problem is ok and the other isn't, but because the actions a customer should take / consider will be different depending on how the breach happened.

[Closi]

To be honest I think we are agreeing but arguing slightly different points.

The how matters, I agree, but it doesn’t change the fact that a breach is a breach.

Different breaches can have different severities, but they are still both breaches.

My issue isn’t on the severity of the breach, it’s that Okta are saying there wasn’t a breach.

[haswell]

Yeah, I think we're on the same page. The primary focus of my original reply was that the "how" really does matter. I agree that this is still a breach regardless.

[stevage]

I don't think anyone would call the second case a robbery, they'd call it embezzlement or fraud.

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

[Ozzie_osman]

Or at the very least, audit logs so they can see what that support engineer's account did during the period that the account was compromised.