Okta Concludes Lapsus$ Investigation, Promises More Third-Party Controls

Identity cloud provider Okta has concluded its investigation into a recent breach of its systems by the dollar extortion group Lapsus, which gained access to some of the company’s systems through a company under -third-party contractor then revealed the compromise in March.

The breach only affected two customers, with the hackers maintaining control of a single computer at contractor Sitel for a 25-minute period, Okta said in post-mortem analysis released Tuesday. While the identity and access management company initially considered up to 366 at-risk customers, the impact ended up being much less, David Bradbury, chief security officer at Okta, said in the analysis.

The breach caused consternation in the security community due to Okta’s lack of notification and fears that accessing the company’s systems could compromise much of the security of its authentication services. unique (SSO) – a trust issue that Bradbury acknowledged.

“While the overall impact of the trade-off has been determined to be significantly less than we originally anticipated, we recognize the heavy toll this type of trade-off can have on our customers and their trust in Okta,” he said. he said, adding, “The findings of the final forensic report do not diminish our resolve to take corrective action designed to prevent similar occurrences and improve our ability to respond to security incidents.”

To ward off attacks in the future, Okta intends to create more stringent security requirements for third-party contractors and put processes in place to confirm compliance. The company has already severed ties with Sitel, according to the post-mortem report.

Okta’s breach raised the profile of attacks against software supply chains and third-party vendors, adding to lessons from previous compromises such as SolarWinds and Kaseya, said Merritt Maxim, the intelligence firm’s vice president. Economics Forrester Research. Third-party companies and service providers must put measures in place to continually assure customers that their services are secure, he says.

“This is an issue that needs to be front and center for security organizations, to move beyond simple vendor security questionnaires, to performing real third-party assessments and audits,” he said. he declares. “Make breaches and test your incident response plans, and rather than relying on vendors to do it perfectly, you should figure out what you can do in response to a breach.”

Conduct your own investigation
When a breach occurs at a third-party provider, such as Okta or its own third-party provider Sitel, companies are either left in the dark or have to pursue their own investigation. Whether Okta knew of the breach and did not notify customers for two months, or the company did not realize that a contractor’s computer had been compromised, companies must be prepared. verify details of an incident, members of Cloudflare’s security team argued in a March blog post.

Cloudflare needs to check its own systems, as some of the screenshots leaked by the Lapsus$ group seemed to indicate that they may have had access to Cloudflare’s Okta instance. As soon as a provider is breached, companies should have a manual in place to spell out the steps to follow to ensure the integrity of their systems, such as verifying all passwords and verifying changes to the multi-factor authentication paying particular attention to any event initiated by the support group.

To facilitate future investigations, Cloudflare’s security team has recommended that companies store logs from third-party services on their own premises to have an auditable copy.

“For years, it was difficult working with different software as a service provider to get all the logs ourselves,” says Joe Sullivan, director of security at Cloudflare. “Too many times in the past we thought there was a risk and we didn’t have the logs, so we’re very proactive.”

For its part, Okta argues that the company had no knowledge of the seriousness of the problem until March 17, when Sitel sent its summary report, which it then associated with screenshots of Lapsus$ a few days later. “We have recognized what appeared to be a connection to the failed takeover attempt in January that we observed and reported to Sitel,” an Okta spokesperson said. “We publicly stated that we did not understand the extent of the Sitel compromise in January, and had we done so, our actions would have been different.”

Cloud Rife with single points of failure
The incident also highlights that while cloud providers generally increase the level of security for their customers, the cloud attracts attacks because so much access is concentrated among a small number of providers. Companies should always start by performing a threat assessment to understand the risks presented by any infrastructure they migrate to the cloud, Sullivan says.

“You look at the worst that could happen and how do you mitigate that risk,” he says. “If compromising a system can lead to exposure of a bunch of customer data or access to intellectual property, then you need to go further.”

Ultimately, while the cloud model asserts that the responsibility for security is shared, organizations must understand that they must collectively take control of their destiny, says Maxim of Forrester Research.

“Don’t assume the vendor is going to take care of security and they’ll do it perfectly,” he says. “Have the right playbooks and policies ready to go, so in the event of an incident, you can take action whether the vendor is ready or not.”

For its part, Okta plans to directly manage even third-party devices that access its customer support tools to maximize visibility into potential security threats, and this will limit the amount of information support staff can see, a said Bradbury in the company’s post-mortem analysis. Additionally, as a third-party vendor itself, Okta plans to review how best to communicate incidents with its customers.

Editor’s note: This story was updated on April 21 with a quote from an Okta spokesperson.