Euro Security Watch with Mathew J. Schwartz

3rd Party Risk Management , Breach Notification , Digital Identity

Okta: 'We Made a Mistake' Over Data Breach Investigation

Lesson for Others to Learn: Your Subcontractor, Your Breach-Tracking Responsibility
Okta: 'We Made a Mistake' Over Data Breach Investigation
Okta's frequently asked questions regarding January 2022 compromise, published March 25

Life comes at you fast, especially when you're a breached business that may have exposed customer data or otherwise put the businesses paying for your product at risk.

See Also: Live Webinar | Navigating Identity Threats: Detection & Response Strategies for Modern Security Challenges

Okta, a publicly traded identity and access management vendor based in San Francisco, has been scrambling to say the right thing publicly since last Tuesday. That's when the Lapsus$ cybercrime group published on a Telegram channel screenshots, dated January, together with claims they'd been able to gain "superuser/admin" access to multiple systems used by Okta (see: Okta, Microsoft Confirm Breaches Connected to Lapsus$ Hack).

Initially, Okta appeared to try and blame the third-party contractor involved - Sykes Enterprises in Costa Rica, which is a subsidiary of Miami-based Sitel Group. Sykes provides customer support for Okta, and so has access to some Okta systems and customer information. Okta said that on Jan. 20 it had detected a potential intrusion at the contractor and, less than 24 hours later, had suspended the account involved and alerted Sitel Group, which said it was bringing in an outside digital forensic investigation team to probe the incident.

More than two months later, however, Okta said Tuesday that while it had received a summary of the incident from the digital forensic investigators hired by Sitel Group, it had yet to see a full report.

Multiple Missteps

Clearly, Okta dropped the ball on multiple fronts, including:

  • Response: How an organization responds to a breach says volumes about its security program and monitoring systems, as well as incident response and planning. To Okta's credit, it detected the breach. But it failed to follow this through to identifying the scope and fallout of the incident in a timely manner.
  • Ownership: Who inside Okta was meant to be in charge of tracking the breach investigation being run by Sitel Group, since it might have revealed an intrusion or customer data exposure and could very well have triggered breach notification requirements for U.S. or European customers?
  • Communications: Okta failed to control the breach message, especially after the Lapsus$ attackers on Tuesday first publicized their intrusion. Practicing effective crisis communications doesn't mean having to tell customers, employees or the general public every last detail. Instead, it requires rapidly saying "we've got experts probing this, we're moving quickly, we don't have all of the facts yet, we will be transparent and you can trust us," and then delivering on those promises.

Here's What Clarity Looks Like

Ironically, an Okta customer was already running laps around the company's response to the breach.

On Tuesday, Cloudflare published full details about its response to the apparent breach of Okta, as well as a clear explanation of what it believed had occurred, with Matthew Prince, CEO of Cloudflare, helping to publicize that blog post.

Cloudflare said that "it appeared that an Okta support employee with access to do things like force a password reset on an Okta customer account had been compromised." So Cloudflare reviewed everyone inside the company who had changed their Okta password since last December, since that change could have been made by an attacker seeking to take over the account. Cloudflare found 133 employees had changed their Okta password in that time frame. So, just to be cautious - and having detected no signs of a breach inside Cloudflare - the organization forced password resets for those 133 employees' Okta accounts and then told the employees what they had done and why.

Okta, meanwhile, published fuller details about the breach Wednesday, after Sitel Group on Tuesday finally shared a complete report into the investigation.

"I am greatly disappointed by the long period of time that transpired between our notification to Sitel and the issuance of the complete investigation report," Okta CSO David Bradbury said Wednesday. "Upon reflection, once we received the Sitel summary report, we should have moved more swiftly to understand its implications."

Bradbury reported that up to 2.5% of its enterprise customers - or 366 organizations - may have been affected by the breach.

Full-Throated Mea Culpa

On Friday, Okta issued a fresh FAQ in which it went a step further, relaying more breach details and issuing a robust mea culpa.

Source: Shutterstock

"We want to acknowledge that we made a mistake. Sitel is our service provider for which we are ultimately responsible," Okta said.

"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," it said.

"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," Okta added.

The company says it has now contacted both affected customers and unaffected customers, which it notes includes its HIPAA and FedRAMP customers.

While Okta's investigation is continuing, the good news is that the damage appears to be minimal. Notably, the firm says that the "super user" access available to support engineers, which the attackers accessed for five days, was designed to provide minimal access rights.

"Support engineers are able to facilitate the resetting of passwords and multifactor authentication factors for users but are unable to choose those passwords," Okta says. "In other words, an individual with this level of access could repeatedly trigger a password reset for users but would not be able to log in to the service."

Lessons to Learn

Following the breach, the value of Okta's stock on Monday morning was down about 15%.

But one upside for Okta is that any damage to its corporate image or value is likely temporary. There's almost no example of a publicly traded company in history ever seeing a long-term hit to its stock price owing to a data breach, except in some rare cases. These include cryptocurrency exchanges getting all of their bitcoins and other virtual assets stolen, as well as Yahoo having the misfortune of discovering two record-setting breaches after Verizon made a bid to buy the firm but had yet to close the deal.

For Okta, however, much of the fallout it's been dealing with could have been avoided at multiple points after it successfully detected the intrusion, had it better overseen and tracked the response effort.

Other businesses would do well to study the Okta breach, review their own incident response practices, run a tabletop exercise based on this type of scenario happening inside their own organization and make whatever refinements are required to ensure they don't get caught out in a similar way.



About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.eu, you agree to our use of cookies.