* a third party has barely restricted, deep access to all customer data
* the "SuperUser" app can apparently have logged in users idling around in a VM, waiting for someone to come along and use it without any automatic logout and re-authentication
* a single account accessing 300+ customers in a few days doesn't trigger any alerts
* they detect a compromise, and do absolutely nothing about it for months, except letting the third party order a security audit; they patiently wait for a report; they don't even audit the access logs
* only a screenshot posted online triggers an audit of access logs and a public response
* they still try to blame the third party and the security firm for their own (basically outrageous) inactivity
All of this by a company entrusted with the most critical gatekeeping functionality of systems, used by many large enterprises and expected to have top notch security.
The issue here is that 1) an employee was able to be phished and/or have malware installed on their device and 2) support agents should only have access to accounts where they have been assigned a ticket, and agents should have no control over which tickets they get assigned.
In these cases, the support agents should not have the ability to open support tickets or modify the companies on them - and then you can give them superuser access to companies with currently open support tickets (preferably those they are assigned only).
"All" is not correct, they outlined what data was in the Superuser utility. It certainly has access, but not "all" data.
> the "SuperUser" app can apparently have logged in users idling around in a VM, waiting for someone to come along and use it without any automatic logout and re-authentication
Well it was an employee laptop, not a VM (so the news says). But regardless of this, the question is what is the session length of superuser? It could be 20mn, it could be 1hr, it could be 8hr. There is some balance for security and usability of the team who actually uses that tool. Even if the session length is reasonably short, this was an insider willingly giving up access to their machine. So likely the insider logged in and sent the attackers a message saying "here you go" and let them work for as long as the session would last. Heck, the insider may even repeatedly login for them.
> a single account accessing 300+ customers in a few days doesn't trigger any alerts
Almost every support interaction would likely require the access of that customer in the superuser utility. Just a dozen cases an hour for an 8 hour day, is nearly 100 accounts accessed per day. That doesn't even seem like a lot of cases per hour.
I'm not saying Okta is in the right here. But throwing around a lot of FUD doesn't help the situation.
I am a very unhappy customer who is very interested in Keycloak.
Honestly, most of these companies would be better off using Google, Azure or AWS' SSO-as-a-Service product (if that's what you're hoping to get out of Keycloak).
That's not to say that I don't appreciate that there's an open-source alternative out there, however.
The thing is, your Keycloak instance is not going to matter to any hacker, particularly if it's inside a VPN and not reachable from the Internet - and while we're at it, fuck zero-trust because it is essentially the same level of stupidity as using Okta, you're once again putting all your eggs into the basket of whatever provider you choose.
Your SSO-as-a-service provider however? They're the juiciest target out there that is. Everyone from secret services over enemy nation states to your average cyber-criminal is looking to get access there. And as we've seen, all it takes is a couple teenagers and a couple thousand dollars.
Good network design costs a lot of money to set up, particularly to limit the scope of an attack (e.g. because the VPN software had a vulnerability), but it's orders of magnitude better in the long run than to outsource core IT to some incompetent fools with subcontractors.
The problem with this approach is that, repeated by hundreds of companies at scale, paints such a massive target on the vendor, that a breach becomes fundamentally inevitable.
I expect this sort of thing happens to all big auth providers, from AWS to Google; it's just dealt with more efficiently and discreetly.
And even now, they are not coming out and being honest like "we lied because we were scared about liability, but the person behethis decision has been fired". It's not good enough.
Sorry, but they have some serious work to do if they want to regain that trust. I for one, will not be using their services again.
The only rational reason I can come up with for this duplicitous talk is for the shareholders; with this double speak they can reduce just how much their shares fall. I'm not on a high horse, I'm positive that most of our orgs was do the same thing.
And I'm not surprised that they're just like all other large companies that choose money/PR over accuracy. What is maddening is that they made it so hard to zero in on required information to help us assess risk; they're at the center of a lot of security workflows, and accurate information is more critical from them than it is from others.
I fear for Auth0 and what it ~~may~~ will become under Okta's 'culture'.
Whenever you hear "Public Relations" just replace it with "Propaganda" since that is what is always was.
https://blog.apaonline.org/2020/07/06/recently-published-boo...
"How Propaganda Became Public Relations: Foucault and the Corporate Government of the Public is a philosophical investigation into the transformative effect propaganda has on us as individuals, on us as publics, and on society more broadly. I argue that propaganda does far worse than just lie to us: modern propaganda aims to transform us into the kind of subjects who carry out a particular line of conduct freely and as a key part of our identity. "
Every company engages in propaganda. The fact that you believe Okta from the start was because of their propaganda.
> We're not actually writing one here but it'll make the examples easier if we pretend we are. Just for the sake of example, I'm going to pick on NVIDIA because... Why not? Such a driver is clearly missing and really should happen soon. (Hint! Hint!) We're going to call this hypothetical new Vulkan driver NVK. It's short and obvious.
As I said in another comment thread about this event, I’ve been watching my leadership team’s response to this as we have deep Okta integration, therefore so do several of our customers using our platform.
Said response has been pretty interesting and amounted to: “it’s working isn’t it?” when shown this event and the disclosures. Both executive and functional Security leadership teams practically shrugged.
Very glad I’m not the one making that call.
That was plastered all over the HN and reddit threads a few days ago, no mention of it from Okta yet. Did that turn out to be bogus?
From the screenshot:
> I don't think storing AWS keys within Slack would comply to any of these standards?
1. They didn’t try to downplay the leak
2. Didn’t double down on the leak not being a big deal later
3. Didn’t specialize in authentication and security
This whole thing is like an exercise in plausible deniability, corporate double-speak, blame shifting and arrogance.
You could even say, they had a lapse of judgment. Sorry for the pun.
