Things quickly made an abrupt turn as Okta and offered up a few explanations for the delay in their own internal investigation of the incident. Now the story was that a third-party support engineer at Sitel had their system compromised by Lapsus$ and their reach impacted roughly 366 Okta clients. The reason that Okta did not disclose this sooner was that they did not have the final report from Sitel before the release of the screenshots. New information from Okta and Sitel, at the time, now indicated that Lapsus$ had five days’ worth of access in Okta’s systems.
But wait, there’s more. Now Okta has finally completed their own internal forensic investigation of the initial event. This investigation is something that many feel should have been done as soon as Okta identified the unauthorized access back in January. The results of Okta’s own forensic investigation are very different than the March disclosures. Now they are saying that while Lapsus$ did have access to a small number of internal systems they only had that access for about 25 minutes. Okta further states that during this 25-minute period Lapsus$ was only able to make significant changes to two confirmed clients. Okta has notified these clients separately (as they should). In their transparency post on April 19th Okta says.
“During that limited window of time, the threat actor accessed two active customer tenants within the SuperUser application (whom we have separately notified), and viewed limited additional information in certain other applications like Slack and Jira that cannot be used to perform actions in Okta customer tenants.”
Okta is vowing to make some significant changes, especially in the area of vendor relationships. They have terminated their relationship with Sitel over this incident and the way it was handled by Sitel including the delay in reporting the findings of the Sitel investigation. They are also going to adopt a long overdue zero trust program with their “sub-processors” moving forward. They will also require vendors to use Okta’s own IDAM. Okta, after terminating the relationship with Sitel, is bringing the management of customer support devices in-house.
“Okta will now directly manage all devices of third parties that access our customer support tools, providing the necessary visibility to effectively respond to security incidents without relying on a third party. This will enable us to significantly reduce response times and report to customers with greater certainty on actual impact, rather than potential impact”
Sitel states that the breach was due to a legacy system in use by an acquired company, Sykes. The use of this system appears to be the root cause of the compromise of the support engineer’s device and all the trouble that followed.
The question we have for all of this is, if Lapsus$ had not posted screenshots, would we know any of these details? Okta played the original incident off as completely unsuccessful; Sitel/Sykes delayed the release of their findings to Okta and Okta only made public statements about the incident after the screenshots were public. Okta says they will adopt new communication practices for clients which might mean more transparency, but we will not hold our breath on that.
The Okta/Sitel incident does highlight something though at Okta and other companies. There seems to be a lack of proper vendor management present. Had Okta had proper policies to respond to a vendor issue, all the mess would have been avoided. Okta is moving to fill those gaps now, but there is going to be a cost in client trust. All companies should have systems and policies in place to assess and manage vendor risk. They should also monitor any and all vendor access into their environments, if they identify a possible issue with one, they should immediately begin their own independent and concurrent investigation to assess any impact. This should have been a lesson learned from incidents like the Oracle and Visual One support breaches, and even the Target breach, yet here we are seeing a secure access management company fall victim to the same things.
We do hope that this event makes positive changes at Okta, but we also hope this is an eye opener for other companies to assess their one third-party risk and for third-party service providers to review their systems and internal processes to ensure they are not putting their clients at un-due risk.
