Okta Source Code Breach: How to Evaluate the Impact & Protect your Organization

What happened in the Okta source code breach?

Okta, a leading provider of authentication services and Identity and Access Management (IAM) solutions, confirmed that its private GitHub repositories were hacked this month. According to an email notification reported by BleepingComputer, and later confirmed by Okta security post, the incident involves threat actors stealing Okta's source code. The leaked Okta source code pertains to the Workforce Identity Cloud repository and does not pertain to any Auth0 (Customer Identity Cloud) products.

Zscaler’s cloud is not at risk

After a thorough investigation, ThreatLabz determined that Zscaler has not been impacted by the Okta breach. While Zscaler does use Okta internally for employees as an Identity Provider (IDP), all access to our production environments requires multiple additional factors including hardware tokens not provided by Okta. You can read our security trust post here.

Source Code Repository Security

Source code repositories should undergo periodic and systematic security assessments to ensure the confidentiality and integrity of the codebase. Developer and administrator access  control audits, server and platform patching, and configuration reviews should be periodically performed to ensure that repositories are secure and that data is not lost or compromised.

Assumed-breach scenarios and red team exercises should be leveraged against your code repositories to assess the impact of a successful external attack. The feedback from such activities should be used to strengthen security posture, inform incident response capabilities, and prepare for real-life incidents such as one reported by Okta.

Consider the following with respect to securing your code repositories from compromise:

• Ensure that your source control software is up to date with the latest security patches.
• Leverage strict Role Based Access Control (RBAC) and MFA for your internal repositories, with access limited to authorized users with full audit trail. 
• Protect access to the code in repositories using tokens or keys. Frequently rotate these keys, and revoke them when they are no longer needed.
• Perform routine scans on repositories to ensure that there are no secrets in code. This reduces the likelihood of further security impact after an initial compromise of the environment.

ThreatLabz’ SOC playbook for Okta and Code Repositories

We are sharing our SOC playbook that organizations can leverage to perform assessment and response activities for this type of breach. 

The Zscaler Security team has developed Security Operations Center (SOC) playbooks for identity (IDP) providers and Code Repositories such as GitHub. This playbook provides security analysts and researchers fast track access to threat identification and remediation at the user level. Suspicious behaviors trigger a security action workflow: for example, moving a user to a higher-access security group, changing multi-factor authentication methods, unauthorized access to our code repositories  or other anomalous and potentially dangerous user behaviors.

A review of identity provider logs for indicators of compromise associated with this attack should include the following steps:

• Review Okta admin/super admin account audit logs.
• Review cloud admin/super admin account audit logs.
• Review all executive accounts including MFA method changes.
• Review new Okta account creations and compare against employee onboarding.
• Review full Okta config to check for API access, logging configs, etc. 
• Identify Okta accounts where MFA was disabled. Identify the user and root cause of the disablement. Re-enable MFA for those accounts.
• Reset password for Okta admins.
• Reset 2-factor authentication for Okta superadmins.
• Rotate Okta-generated API tokens.
• Verify Okta Support access is disabled.
• Verify Directory Debugger access is disabled.
• Review all critical users' access levels.

Security Operations Center (SOC) Detection Rules for Okta and Github

The process to enable Threat Detection for Identity Provider (IDP) like Okta using a SOC Playbook should be well-defined with specific workflows and actions. Okta has pre-built log ingestion modules for many of the common SIEM solutions. Once events are ingested, a number of queries can be created and easily leveraged for signs of a potential compromise or other suspicious activities. While they are not a comprehensive set of queries, they serve as a solid starting point for a security investigation.
 

Similarly, you may want to monitor your Github logs for suspicious activity to ensure that a similar breach does not happen to your organization. Here are some suggested queries. Please refer to relevant MITRE ATT&CK TTPs for your code repositories.

Guidance and Best Practices

Following are some of the recommendations to enhance your security posture against similar scenarios involving your Identity Provider (IDP) and Source code repositories to protect your organization:

• Ensure MFA is enabled for all users. Consider MFA methods not facilitated by your primary Identity Provider (IDP) for critical systems including hardware-based tokens.
• Continuously monitor your Source Code Repositories such as Github logs for suspicious activity. 
• Granular Role Based Access Control (RBAC) for your Source Code Repositories, Build Systems and Crown-Jewels to ensure only authorized users have access to the systems.
• Continually review policies and procedures with any organization involved in your supply chain. Many organizations could be potentially impacted by this type of incident.
• Run security incident preparedness exercises for incidents just like this (a primary Identity Provider compromise, or an internal codebase compromise) to understand how to respond and what to communicate to whom and when.

How can Zscaler protect organizations against this kind of attack?

The Zscaler platform is built on a holistic zero trust architecture that offers defense-in-depth against supply chain and compromised user attacks, mitigating incidents such as this in the following ways:

• Minimize the attack surface by making internal apps invisible to the internet.
• Prevent compromise by using cloud native proxy architecture to inspect all traffic inline and at scale, enforcing consistent security policies. This is critical in blocking the prevalent Adversary-in-The-Middle (AiTM) phishing campaign that is actively targeting organization’s Github credentials with ability to bypass MFA.
• Stop lateral movement by connecting users directly to applications (rather than the network) to reduce the attack surface, and contain threats by using deception and workload segmentation.
• Stop data loss by inspecting data-at-rest (SaaS) and all internet-bound traffic, including encrypted channels, to prevent data theft including code repositories.

About ThreatLabz

ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, research.zscaler.com.