CYBERSECURITY

Okta: Hackers Accessed Just 2 Customer Tenants In Breach

Tenants Accessed And Apps Such As Slack And Jira Viewed For Only 2 Okta Clients

By Michael Novinson (MichaelNovinson) • April 19, 2022   

Only two Okta customers had their tenants accessed and applications like Slack and Jira viewed by Lapsus$ during the January cyberattack, the company revealed Tuesday.

“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,” Chief Security Officer David Bradbury writes in a blog post. Okta said in March that data for as many as 366 of its customers might have been “acted upon” following the Lapsus$ cyberattack.

A third-party forensic report produced on Okta’s behalf concluded the threat actor actively controlled a single workstation used by a Sitel support engineer for 25 consecutive minutes on Jan. 21, Bradbury writes. The blog post doesn’t identify the threat actor, but the breach first came to light on March 22 when Lapsus$ posted screenshots to its Telegram channel of Okta customer data.

Okta has notified the two customers whose tenants were accessed by Lapsus$, and Bradbury says that applications such as Slack and Jira that were viewed by the hackers can’t be used to perform actions in Okta customer tenants. Lapsus$ was unable to authenticate directly to any Okta accounts or perform configuration changes, MFA or password resets, or customer support impersonation events.

“We decided that the right thing to do for our customers (in March) was not to try and … make a bunch of optimistic assumptions about if everything went right,” Bradbury tells Okta CEO Todd McKinnon. “We wanted to be thorough, and we wanted to make sure that we were taking the most conservative angle on every dimension. And that’s how we landed on quite a large number of 366 customers.”

While Lapsus$ might have been able to access Okta’s Jira product, Jira developer Atlassian tells Information Security Media Group that it hasn’t found any evidence of a compromise to its systems or cloud products. In addition, an Atlassian spokesperson says the company doesn’t use Okta as an identity provider.

What Okta Did for Customers

The screenshots Lapsus$ published online were taken from a computer used by a Sitel employee. Okta contracted with Sitel Group for customer support work. Most Sitel support engineering tasks were conducted using an internally built application called SuperUser, which allowed a user to perform basic management functions on Okta customer tenants.

Bradbury says Okta shared logs from the SuperUser app with each of the 366 customers whose Okta tenant was accessed by Sitel between Jan. 16 and Jan. 21, and conducted meetings with Okta security staff to help customers understand their log data. These customers were provided with the final forensic report and a plan outlining the steps Okta will take to improve the security of its third-party processors.

“Customers have a lot of third parties too, and after they hear our perspective about what’s happened and start to build that trust back with us, they want to learn [from us] because they know that they have some of the same potential issues as well,” McKinnon tells Bradbury in the video conversation.

An Okta spokesperson tells ISMG that the company is thinking about the lessons learned in three key categories: technology, people and process, and customer response and communication. On the technology side, the spokesperson says, the company must ensure the technology environment used by third parties is commensurate with Okta’s.

On the people and process front, the spokesperson says, Okta is going beyond paperwork attestations of third-party environment security and focusing on in-person audits going forward. Okta is also taking steps to improve transparency and communication with customers, partners and the security ecosystem to be prepared in the event of another cyber incident, according to the spokesperson.

Reducing Third-Party Risk

Bradbury says Okta is determined to take corrective actions aimed at preventing similar breaches and improving the company’s ability to respond to security incidents. That starts with Okta reviewing its security processes and pushing for new ways to accelerate updates from third parties and internally for potential issues, according to Bradbury.

From a third-party risk management standpoint, Bradbury says Okta will require that third-parties who offer support services on the company’s behalf adopt zero trust security architectures and authenticate via Okta’s identity and access management product for all workplace applications. Okta has terminated its relationship with Sitel Group, Bradbury says. Sitel didn’t immediately respond to a request for comment.

“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,” Bradbury writes. “We recognize how critical Okta is to so many organizations and the individuals who rely on them, and are more determined than ever to deliver for them.”

In addition, Okta will now directly manage all third-party devices that access Okta’s customer support tools, which Bradbury says will provide more visibility to respond effectively to security incidents without relying on a third party. Having direct management over third-party devices will allow Okta to significantly reduce response times and report to customers with greater certainty on actual impact.

Okta is also modifying its customer support tool to limit what information a technical support engineer can view, Bradbury writes. The changes Okta is making will provide greater transparency about when the customer support tool is being used through the system log page in customer admin consoles. Finally, Okta is adopting new systems to help the company communicate more rapidly with customers.

“This is our issue to make sure it never happens again,” McKinnon tells Bradbury. “And we have to make sure that we fix the problem holistically and take steps to prevent anything like this from happening again. The detail that it happened to be a third party doesn’t absolve us from the responsibility, and that’s how we’re acting.”

Scythe Director of Threat Intelligence Jake Williams tells ISMG that Okta should be able to more rapidly investigate any future issues once it is managing the workstations used by support engineers. Williams also praises Okta for revamping its communication plans to better coordinate with customers.

But he says that Okta’s attempt to initially downplay the breach remains very concerning, and the company’s willingness to wait for months to receive a forensics report from Sitel Group indicates the lack of a real incident response process. Given the media attention and existing delay due to waiting on Sitel’s report, Williams tells ISMG he can’t fathom why Okta’s own investigation took this long.

“That itself may be further evidence of immature incident response processes,” Williams tells ISMG. “This event will be a case study in incident response missteps for years to come.”

Okta declined to directly respond to Williams’ comments.

•             Editor’s Note: This story has been updated to include comments from Jake Williams of Scythe, an Okta spokesperson, and a Jira spokesperson.

https://www.databreachtoday.com

Leave a Response

bahis canlı casino siteleri canlı bahis siteleri