Hacker News Reader

Comment by the_duke | Hacker News Reader

There are so many red flags here, it's not even funny anymore.

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

View on HN

There are operational red flags but not the ones you mentioned. What a lot of people forget in these situations is that these are support agents and they need access to customer data to do their job. Additionally, I bet accessing 300 accounts per week is a totally normal thing for a support agent to do. Sure you could write some alarms that trigger in certain cases but it’s very hard to do without creating alarm fatigue.

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.

> these are support agents and they need access to customer data to do their job.

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

Yup. That's point #2 in my post :)

> deep access to all customer data

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

Definitely some flags and horrible communication, but will any customers actually leave? Changing an IdM provider can easily run into 7-figures for large organizations.

I could definitely see some bigger companies moving away after this. Lots of them hauled ass after the log4j chaos, for example.

And lot will stay, because one tenet of corporate security is to outsource whatever possible and make it someone else's problem, shifting the liability out of the house. Check box ticked.

Not always. It is difficult to hire people with a deep knowledge of complex systems such as the Windows suite and it makes sense, security wise to protect this insured of having chaos in your configurations.

An MS environment is today extraordinary complex and it is very easy to make a mistake setting it up, maintaining and integrating other stuff with it.

Most probably nobody wanted to be the messanger of the bad news, perhaps due to the fear of being made a scapegoat?

Their entire business is managing authentication and they don't use hardware tokens for all employees. Welcome to clown town.

Reply on news.ycombinator.com