Identity cloud provider Okta concluded its investigation into a recent breach of its systems by the Lapsus$ extortion group, which gained access to some of company's systems through a third-party contract firm and then revealed the compromise in March.

The breach impacted only two customers, with the hackers maintaining control of a single computer at contract firm Sitel for a 25-minute period, Okta said in the postmortem analysis published on Tuesday. While the identity and access management firm had initially considered as many as 366 customers at risk, the impact ended up being far less, David Bradbury, chief security officer at Okta, stated in the analysis.

The breach caused consternation within the security community because of the lack of notice from Okta and worries that access to the company's systems could undermine much of the security of its single sign-on (SSO) services — an issue of trust that Bradbury acknowledged.

"While the overall impact of the compromise has been determined to be significantly smaller than we initially scoped, we recognize the broad toll this kind of compromise can have on our customers and their trust in Okta," he said, adding: "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."

To head off attacks in the future, Okta intends to create more stringent security requirements for third-party contractors and have processes in place to confirm compliance. The company has already cut ties with Sitel, according to the postmortem report.

The Okta breach raised the profile of attacks on software supply chains and third-party providers, adding on to lessons from previous compromises such as SolarWinds and Kaseya, says Merritt Maxim, vice president at business intelligence firm Forrester Research. Third-party firms and service providers need to have measures in place to continuously assure customers that their services are secure, he says.

"This is an issue that has to be front and center for security organizations, to push beyond doing just security questionnaires for providers, to doing actual assessments and auditing of third parties," he says. "Simulate breaches and test your incident response plans, and rather than rely on the vendors to do it perfectly, you should be determining what you can do in response to a breach."

Conduct Your Own Investigation
When a breach happens in a third-party provider, such as Okta or its own third-party provider Sitel, companies either are left in the dark or must pursue their own investigation. Whether Okta knew of the breach and failed to notify customers for two months, or the company failed to understand that a contractor's computer had been compromised, businesses need to be ready to verify the details of an incident, members of Cloudflare's security team argued in a March blog post.

Cloudflare has to verify its own systems, since some of the screenshots in leaked by Lapsus$ group appeared to indicate that they may have had access to Cloudflare's instance of Okta. As soon as a provider is breached, companies should have a playbook in place to spell out the steps that need to be taken to assure the integrity of their systems, such as checking all passwords and verifying changes to multifactor authentication with special attention paid to any event initiated by the support group.

To facilitate future investigations, Cloudflare's security team recommended that companies store logs from third-party services on their own premises to have a verifiable copy.

"For years, it has been a struggle to work with different software as a service provider to get all the logs ourselves," says Joe Sullivan, chief security officer at Cloudflare. "Too many times in the past, we have thought there was a risk and we did not have the logs, so we are very proactive."

For its part, Okta maintains that the company did not know about the severity of the issue until March 17, when Sitel sent their summary report, which they then connected with the Lapsus$ screenshots a few days later. "We recognized what appeared to be a connection to the January failed takeover attempt we observed and reported to Sitel," an Okta spokesman said. "We've publicly said we didn't understand the extent of the Sitel compromise in January, and if we had, our actions would have been different."

Cloud Rife With Single Points of Failure
The incident also underscores that while cloud providers typically raise their customers' level of security, the cloud attracts attacks because so much access is concentrated in a small number of providers. Companies should always start by conducting a threat assessment to understand the risks presented by any infrastructure that they move to the cloud, Sullivan says.

"You look at what is the worst that could happen, and how do you mitigate that risk," he says. "If a compromise of a system could lead to a bunch of customer data getting exposed or intellectual property being accessed, then you need to go further."

In the end, while the cloud model asserts that responsibility for security is shared, companies need to understand that that they need to take their fate into their own collective hands, says Forrester Research's Maxim.

"Don't assume that the vendor is going to take care of security and will do it all perfectly," he says. "Have the right playbooks and policies ready to go, so if there is an incident, you can take action whether the vendor is ready or not."

For its own part, Okta plans to directly manage even third-party devices that access its customer-support tools so as to maximize visibility into potential security threats, and it will limit the amount of information that support personnel can view, Bradbury said in the company's postmortem analysis. In addition, as a third-party provider itself, Okta plans to review how to better communicate incidents with its customers.

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