According to Okta, they handed over the investigation of the incident to Sitel after identifying “an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider.”. Sitel did not provide details of their investigation to Okta until March 10th. They are saying this is the reasons for the delay in disclosure, but that is not making Okta customers very happy. From a client perspective many feel that although Okta did the right thing by informing Sitel, they also should have performed their own internal investigation and been much more transparent than they were.
The claim of an unsuccessful attempt by Okta caused the Lapsus$ group, who had previously claimed responsibility for the incident to post screenshots and state; "I'm STILL unsure how it's a [sic] unsuccessful attempt? Logged in to [sic] the SuperUser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful?" Not out of pattern for the group as they have shown a quick response to anything dismissal of their claims or anything that makes them think someone is looking to thwart their efforts.
Okta has now confirmed that around 366 (or 2.5%) of their clients were potentially impacted by the 5-day incident. One client, Cloudflare, found out they were impacted when Lpasus$ posted the screenshots they did. Their Security Incident and Response Team was notified that an existing account was shown in the screenshot, and they suspended the account quickly. The team then reviewed all changes to accounts related to authentication and found that 144 employee accounts matched the profile for having been tampered with. The forced resets of those accounts to ensure continued security.
The responses by Okta are clearly a public relations attempt at damage control. After all they are a service that is supposed to assist others prevent account compromise and yet, they were breached and clearly compromised. The problem is that even though some of their language is technically and legally accurate, to clients it has the appearance of deception and attempting to downplay the impact this would have on anyone using the service.
This lack of a clean message and the lack of notification of impacted clients is just another in a series of incidents where clients of a service provider are left in the dark after being impacted. We saw this with the Kronos ransomware event and now it is seen again with Okta. Most are making it clear they are not happy with how this was handled and point to the way Mandiant handled their breach during the SolarWinds supply chain attack event. This might be due to the way internal issues are handled, in way too many companies security issues and incidents are handled by identifying who is to blame instead of just taking ownership and resolving them. With Okta they appear to have sought to push the blame and fault back on Sitel instead of taking ownership of the issue and working to not only resolve it, but also ensure the security of their customers.
The blame/fault mentality creates an environment where mistakes, issues and events get hidden or not reported so they remain in the environment, or the full impact is never known until there is outside pressure. All out of fear of being blamed and punished. In an environment where ownership and not blame is encouraged, issues are reported, and corrected, a security first culture is better maintained. A few things are clean, there is a definite need for more transparency when it comes to any breach of a service provider and more companies need to stop trying to find the person to blame and just take ownership of company and their clients’ security.
