Security Teams Need to Investigate the Okta Breach Themselves

For companies that rely on Okta for identity management or have Okta as part of their authentication stack, the latest report regarding an Okta breach is extremely disconcerting. Despite Okta’s assurances that it was a “relatively minor” event (per Okta CSO David Bradbury) and that there are no corrective actions customers need to take, security teams at organizations using Okta should engage in their own incident response exercise to verify whether they have been exposed.

Since a Cloudflare employee’s email address was included in the screenshots posted by the attack group claiming a breach, the Internet infrastructure company’s internal Security Incident Response Team launched an investigation, Cloudflare said in a blog post. The post details all the actions Cloudflare took to investigate, and it can be a helpful guide for any organizations trying to determine how they should proceed with the news of this breach.

Cloudflare’s SIRT checked the logs and found there were no relevant audit log events, such as password changes, associated with the employee whose email address was exposed, Cloudflare CTO John Graham-Cumming wrote, along with Lucas Ferreira, Cloudflare’s security operations engineering manager; and Daniel Stinson-Diess, a security engineer for detection and response. Access for that employee was temporarily suspended.

According to the blog post, Cloudflare uses Okta internally to manage employee identities but not for any customer-related accounts.

“In the case of the Okta compromise, it would not suffice to just change a user’s password,” Cloudflare’s security engineers wrote. “The attacker would also need to change the hardware (FIDO) token configured for the same user. As a result it would be easy to spot compromised accounts based on the associated hardware keys.”

SIRT reviewed its logs and its copy of Okta logs ingested into Cloudflare’s security information and event management system for “potential suspicious activities, including password resets over the past three months,” Graham-Cumming wrote. Every employee who had reset their password or modified their multifactor authentication methods since Dec. 1, 2021 had their passwords reset again by the company. The blog posts contains event types that security teams at other organizations can use to search through their own Okta System logs to verify their potential exposure. SIRT also reviewed its Google Workplace email logs.

“Make sure all password resets are valid or just assume they are all under suspicion and force a new password reset,” Graham-Cumming wrote in his recommendations on what security teams that rely on Okta should do at this time.