Okta to directly manage third-party devices, modify customer support tools in wake of breach
Just two customers actually affected, but...
Okta has vowed to overhaul how it audits "sub-processors" and says it will directly manage all devices of third parties that access its customer support tools. The decision was revealed in its post-mortem of a breach that emerged publicly in March to huge customer concern -- and a backlash at how Okta communicated the incident.
The Okta post-mortem, published March 19, reveals that the breach was far from as bad as initially feared, with only two customers ultimately affected after a workstation at third-party contractor Sitel was hacked.
Direct management of third-party devices will give "visibility to effectively respond to security incidents without relying on a third party [and] significantly reduce response times and report to customers with greater certainty on actual impact, rather than potential impact" Okta said, adding: "We are making further modifications to our customer support tool to restrictively limit what information a technical support engineer can view."
The Okta post-mortem concluded attackers had control of the workstation for 25 minutes in total, on 21 January 2022. That's at odds with an initial report contracted from a forensic company by Okta that found there was a five-day window of time between January 16-21, 2022, where an attacker had access to the device.
Okta said this week in its post-mortem that during this limited period the intruder “accessed two active customer tenants within the SuperUser application… 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 said the Lapsus$ hackers were unable to “successfully” perform configuration changes, MFA authentication or password resets, or customer support impersonation. Nor was the intruder able to authenticate directly to any Okta accounts. The company said it has contacted the two affected customers directly.
Prior to the final Okta report, the firm said up to 366 customers could have been affected – after initially refusing to acknowledge a breach and saying the incident had been "contained by the subprocessor".
See also: Okta’s breach disclosure woes trigger ferocious debate
The most immediate effect of the Okta post-mortem has been the termination of Okta’s relationship with Sitel. Sitel released its own statement on the incident last month, where it revealed the compromised machine was part of the “legacy” Sykes network, which Sitel took over when it acquired Sykes in August 2021.
In the final Okta report, it also pledged to other changes to its third-party risk management approach, saying: "We will require that sub-processors who provide Support Services on Okta's behalf adopt ‘Zero Trust’ security architectures and that they authenticate via Okta’s IDAM solution for all workplace applications.”
“We are making further modifications to our customer support tool to restrictively limit what information a technical support engineer can view. These changes also provide greater transparency about when this tool is used in customer admin consoles (via System Log),” Okta concluded.
‘We made a mistake’
The fallout from this incident has been messy, with Okta being forced to backtrack on what happened during the incident. Earlier this month, in a detailed FAQ on the breach, in answer to the question of why Okta didn’t notify customers in January, the company said “we made a mistake”, adding: "In January, we did not know the extent of the Sitel issue – only that we detected and prevented an account takeover attempt and that Sitel had retained a third party forensic firm to investigate. At that time, we didn’t recognize that there was a risk to Okta and our customers. We should have more actively and forcefully compelled information from Sitel."
“In light of the evidence that we have gathered in the last week, it is clear that we would have made a different decision if we had been in possession of all of the facts that we have today.”
In the Okta post-mortem, chief security officer David Bradbury made a similar statement: “It pains us that, while Okta’s technology excelled during the incident, our efforts to communicate about events at Sitel fell short of our own and our customers’ expectations. The conclusions from the final forensic report do not lessen our determination to take corrective actions designed to prevent similar events and improve our ability to respond to security incidents. That starts with reviewing our security processes and pushing for new ways to accelerate updates from third parties and internally for potential issues, both big and small,” added Bradbury.
