Okta Lapsus$ Compromise: How To Make Sure You’re Protected
On Tuesday, March 22, 2022, identity-as-a-service (IDaaS) provider Okta announced that it had detected an attempt to compromise the account of a partner in January 2022. The announcement came after the hacking group Lapsus$ posted screenshots of a computer used by one of Okta’s third-party customer support engineers. As one of the largest IDaaS providers with over 15,000 customer organizations globally, this incident means that many Okta customers may need to take some specific steps in response to this incident.
After reviewing the information provided by Okta and others since Tuesday, here are our initial conclusions:
- Specific details remain unclear. Lapsus$ posted screenshots and additional data indicating that they had access to the laptop of a third-party contractor customer support engineer. Okta has indicated that hackers gained access to the support engineer’s laptop by leveraging the Remote Desktop Protocol (RDP). Okta’s investigation indicated there was a valid five-day window between January 16 to January 21, 2022, where an attacker had access to the support engineer’s laptop, but Okta stated that it first learned of the incident on January 20, so the timeline has confused some, especially on what was happening prior to January 20.
- Okta’s statements have only added ambiguity. The initial statement of the breach came early on March 22 from the Twitter account of Okta CEO Todd McKinnon. Okta’s chief security officer followed that with this statement: “There are no corrective actions that need to be taken by our customers.” Okta then issued a secondary statement indicating that, in fact, approximately 2.5% of Okta’s customers (~366 customers) “have potentially been impacted and whose data may have been viewed or acted upon.” These conflicting statements have frustrated customers, many of them tech vendors, so much so that one vendor launched its own investigation into the incident.
- Software and labor (outsourcing) supply chain attacks are here to stay. Forbes has since reported that the compromised laptop was of a support engineer who worked for Sykes Enterprises, which provides outsourced tech support for Okta customers and other software vendors. While Okta stated that third-party support engineers cannot create/delete users or download customer databases (which is a good data protection measure), Okta added that the third-party support engineers have the ability to send password reset emails to the email accounts associated with the Okta account, and they have the ability to remove MFA factors, but hackers cannot enroll their own MFA factor. These support engineers also cannot choose the new password or view the password. The support team’s ability to reset passwords or remove MFA opens the potential for data theft if hackers are working in concert with a malicious insider. This incident further demonstrates the growing cyber risks within the software supply chain.
- This isn’t the first time IDaaS providers were attacked, and it won’t be the last. IDaaS providers are a high-profile hacking target because they serve as the access point into an organization’s applications and data and manage login and authentication flows. In 2017, Okta competitor OneLogin (since acquired by One Identity) suffered a data breach, so Okta is not the first IDaaS vendor to be attacked. As organizations move more identity services into the cloud (including Active Directory and user stores), organizations should not rely solely on IDaaS vendor assurances about the underlying security measures. Instead, you should be supplementing your IDaaS deployment with other security control measures, such as requiring MFA for all users, initiating ongoing monitoring and analytics, and deploying privileged identity management for your IDaaS system admins and any user with elevated privileges on the IDaaS tenant.
Take The Following Steps To Ensure Your Organization Isn’t At Risk
We suggest that identity and access management (IAM) teams take the following proactive measures, even if you aren’t using Okta, given that Lapsus$ could very well be targeting other IDaaS vendors:
- Force password resets for all accounts with password and MFA changes since December 2021. Inform users this is going to happen and why. Yes, it will create some end-user frustration and possibly increase help desk calls during the reset process, but it’s still a best practice to follow as it will help reduce any ongoing problems from accounts that may have been compromised in the past two months.
- Look beyond the Okta-specified time frame for signs of compromise in your environment. Okta says the intrusion was limited to a five-day window in January 2022. You should extend your changes beyond Okta’s specified time frame out of an abundance of caution.
- Review the research on the tools, tactics, and procedures of the attack. Microsoft recently released a deep dive on this attacker and its operations that includes specific recommendations to take. This attacker pays employees of companies for access, or employees of suppliers and partners. This group also participates in incident response calls while investigations are underway to understand how much the organization knows about the breach.
- Demand attestation from platform and service providers now. Don’t wait for the contract renewal cycle to understand their contractual responsibilities and the specific measures in place to keep you safe in the event of a SolarWinds- or Kaseya-style attack. Ask your providers for assurances and demand written attestation of 1) their gating and QA process for pushing updates to your environment, 2) processes for assessing and securing their code and their update servers, and 3) the architecture and processes in place to prevent lateral movement in their environments that would lead attackers like Lapsus$ to your data. Third-party monitoring of providers’ environments — whenever possible and allowed — also goes a long way in allowing your firm to discover security issues, potentially even before your providers and sub-processors discover them.
- Revisit your public-facing breach notification and response playbook. How you communicate and respond following a security incident or breach sets the tone for your recovery. It’s not the crime, but the perceived cover-up or suspicion of internal chaos that makes an already difficult situation worse. Include in your incident response tabletop exercises when to activate customer-facing response actions, what those actions entail, and who produces FAQs for employees and statements for customers. Identify and train your key spokespeople. Determine how and where you will disseminate information; a single location on your website that is easy to find is ideal and one of multiple channels you may use. Plan for how you will hear from and field questions from concerned customers. Above all, know your audience to tailor your communications more effectively to address their needs and concerns.
- Add a planned and audited timeline to your own and third-party forensic investigations. This incident is embarrassing because it’s being disclosed two months after initial discovery. Maintaining an internal track on forensic investigations helps avoid potential delays in disclosures.
- Implement continuous third-party monitoring. Many organizations implemented third-party monitoring (continuously getting and analyzing logs from third-party systems) to identify potential threats and anomalous activities early on. Using security analytics platforms that utilize machine learning techniques to detect log file anomalies can reduce detection times.
- Conduct privileged identity access re-certifications and monitoring. Privileged identities, especially when used by third-party employees, are very powerful. This mandates that access to privileged (administrative user, database administrator, etc.) credentials should be controlled (using a PIM solution such as BeyondTrust, CyberArk, or Delinea) via a credential vault. In addition, the PIM solution should monitor and analyze any suspicious access to your privileged accounts and systems. Machine-learning-based, privileged threat analytics can help here, as well as applying Zero Trust principles with all administrator access to your key systems.