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.
“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.”
According to the blog post, Cloudflare uses Okta internally to manage employee identities but not for any customer-related accounts.
What Incident Response Should Look For
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.
Actions to Harden Your Environment
While investigations are under way to determine which customers are affected by the breach into Okta, and how they are impacted, security teams should also think about hardening their environment to make it harder for newer attacks to succeed, wrote Cycode CTO Ronen Slavin. Steps include looking for increased privileges in Okta logs that may suggest insider threat or compromised accounts; turning off features that enable Okta support to access their instances; enforcing multi-factor authentication and IP range restrictions; forcing all users to log back in; and refreshing persistent authentication tokens like OAUTH.
Slavin also notes that this particular group appears to be looking for source code, so security teams should be hardening the development environment by auditing for excess privileges and removing any outliers. Establishing least privilege policies minimizes the adversary’s ability to move laterally.
Source: www.darkreading.com