By Arun Balakrishnan, Sr. Director Product Management
Photo by Markus Spiske on Unsplash
Identity credentials and source code are critical assets that can create major risks for your organization when exposed by breaches of third-party cloud service companies that provide identity management and software composition analysis. Know the risks of pushing your crown jewels into other services running in the cloud.
When allegations appeared on Twitter on March 22 that cloud identity services provider Okta had been breached, the tech world held its breath. CEO Todd McKinnon tweeted, “In late January 2022, Okta detected an attempt to compromise the account of a third-party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor.” Speculation continued to run wild on Twitter that the breach may have affected other companies, leading them to instruct employees to reset their passwords and identity information.
The caution is understandable. Okta is used by thousands of companies, including some of the world’s largest enterprises, for identity and access management of employee credentials used to log into and stay logged into all types of systems. Okta stores user identities, passwords, and other data for numerous critical systems including SaaS (CRM, finance, HR), PaaS (developer platforms, serverless computing, etc.) and IaaS (cloud servers, cloud networking systems, cloud databases).
As one of the world’s largest identity and access management (IAM) providers, Okta has always had a giant target on their back; any successful breach could yield a treasure trove of data that could be used to pivot to attacks on many other enterprises and their systems. Making matters worse, a known Ransomware group claimed credit for the breach. An IAM provider is a potential vector for Ransomware that would be particularly hard to address because IAM occupies such a position of trust in the technology stack and software supply chain.
Breaches happen, even to companies like Okta that put a priority on security. This breach could have happened to almost any company, and more of these types of breaches on key cloud-services companies are likely coming. Nation-state actors will target cloud-based providers of critical services like Okta in the future, and are likely already doing so now. The larger question that remains, however, is that of risk assumed by enterprises when pushing so much valuable information into a third-party cloud services providers environment.
Storing critically important identity data with a third-party vendor means that you are trusting that vendor with your crown jewels. But you may have limited visibility into risks facing your crown jewels. We don’t have a lot of details about the Okta breach. However, several security vulnerabilities recently disclosed would have allowed attackers to break out of supposedly secure containers and penetrate hosts in public compute clouds or major container orchestration platforms (Kubernetes). So even if the third-party vendor you trust with your crown jewels does everything right, your jewels still might not be safe — due to vulnerabilities in the cloud itself.
Okta claims that this breach resulted from problems with a third-party customer support engineering provider that appears to have had privileged access to some Okta systems. This is another potential risk faced by handing over crown jewels to a third-party; you don’t know who else has access to critical systems or to your sensitive information.
The source code of your applications hosted in your cloud is another crown jewel, and constitutes an added potential vector for supply chain attacks or serious breaches. Pushing your source code into multiple third-party services beyond your code repository provider increases the risks of compromise and expands the potential attack surface on both your source code and on your organization. Most CISOs and security practitioners do not realize that their software composition analysis tool or other cloud-based security scanners suck in all source code and process scans in the cloud before shipping results back.
There is an alternative approach that safeguards your source code. At ShiftLeft we elected to use an agent-based architecture that does not require us to upload all your source code into our systems. Instead of the code itself, we upload a graph representation of your code (we call it a code graph) with all sensitive information removed. (You can read more about how this works in this blog post — Why your code is a graph.)
By abstracting away your code and only pulling a graph that we can analyze, we ensure that attackers cannot steal your code via our tool or use our system to implant malicious unauthorized code into your applications and repositories. This is both more efficient and more secure. It minimizes the attack surface and exposure to supply chain attacks, breaches and other malicious activity.
Cloud computing has revolutionized the ways we build and run applications. It has enabled microservices and radically reduced costs of creating companies and technology stacks. Reverting to the old world where everything critical runs on your premises on servers and on hardware controlled directly by your team would be an absolute non-starter. That said, we need to acknowledge the potential risks of storing our most sensitive information in services we do not control. Then, we must make intelligent choices about how much risk we wish to undertake based on the potential impact of a breach. Every additional exposure of your crown jewels in a third-party service in the cloud is an expansion of your attack surface and should only occur after a conscious decision based on risks and benefits.
To get a demo of static analysis of custom code, open-source dependencies, and secrets, visit shiftleft.io/request-demo/.
Top comments (0)