To paraphrase the tagline of Capital One's credit card ads: What's in your enterprise code?
For many companies, the answer to that question has brought considerable pain. At the end of 2020, the SolarWinds Orion software implemented by organizations from the US Treasury Department and the US Department of Homeland Security to cybersecurity firm FireEye offered a backdoor to the notorious APT29 cybercrime ring, aka Cozy Bear. In the aftermath of the widespread attack, its many victims learned of numerous security lapses by SolarWinds, from weak and leaked passwords to the failure to employ a CISO. More recently, a zero-day vulnerability in the widely used open source Apache Log4j utility exposed hundreds of millions of devices to possible compromise—creating a cybersecurity crisis of truly historic proportions.
When it comes to the code in your enterprise environment, what you don't know can definitely hurt you.
In our last blog on the findings of the JupiterOne 2022 State of Cyber Assets Report, we explored the breakdown of traditional methods for managing cyber asset risk. Now, in the fourth blog of our five-part series, we'll examine risks and challenges posed by virtually unmanageable software supply chain security.
Software is eating enterprise security
JupiterOne's analysis of over 20 million application assets at almost 1,300 organizations reveals the mounting pressures on security teams. In an era where organizations compete on digital transformation and agility, open source and commercial third-party software play an invaluable role in speeding the delivery of new services to employees and customers, accelerating innovation, and adapting to changing business needs. But the implications of this reliance should give cybersecurity professionals pause.
According to our findings, a full 91.3 percent of the code running in today's enterprises is developed by a third party. In other words, the overwhelming majority of applications are delivered through an external supply chain—leaving enterprises incredibly vulnerable to supply chain attacks. As seen with SolarWinds, where an FTP server had been secured using a password of "solarwinds123," you're only as secure as the weakest link in your supply chain—and some of those links may be weaker than you could imagine.
Consider the challenges this cosmopolitan environment poses for security teams. Only about 8.7 percent of code has change management trails to indicate in-house development, such as modules, functions, or pull requests (PRs). The rest of the changes are being made somewhere else, by someone else, through change management processes we can only hope are sound.
Meanwhile, the average security team is responsible for nearly 16,000 application assets, or an average of over 50 assets per human employee. Of these, nearly 16 percent are services, or applications that run with minimal human touch, including web app firewalls, autoscaling services, and event services. And it only takes one vulnerable asset to invite disaster.
Marc Andreessen was right: software has eaten the world—and security teams are paying the price.
Managing complexity to minimize software supply chain risks
The large number of third-party apps in the environment has vastly increased risk, but vendor consolidation isn't as straightforward as it may sound; organizations can't simply rip out that much of their existing code. At minimum, a focus on end-of-life procedures for legacy systems can help them prevent outdated systems from exposing entry points for attack.
Before Log4j hijacked the cybersecurity agenda, the greatest challenge security teams had faced was maintaining aging systems that add minimal value for the organization, but must be kept on security life support to prevent vulnerabilities. In many cases, the vendors behind these systems went out of business long ago, leaving them unsupported and unpatched. As IT is determining whether these systems are worth the resources and effort they consume, security risk should factor into the balance. If retiring the system can remove potentially vulnerable third-party software from the environment, that's reason enough to take action.
While reducing the number of vendors in the supply chain should be an ongoing priority for IT and security, the industry should also focus on addressing the situation as it currently exists. Technologies and practices such as attack surface management and software bills of materials (SBOMs) can help security teams understand and manage the risks in their environment even as it grows more complex and diverse. While a May 12, 2021 executive order requires federal agencies to ask their suppliers to provide SBOMs, this rule, already somewhat toothless within the government sector, is little help beyond it. Enterprises should take the initiative to push their own vendors toward greater transparency into the components, both proprietary and open source, that make up their products. Organizations that incorporate open source software into their own technologies and practices can reduce risk by becoming more involved and contributing to the projects they rely on.
In our next blog, we'll look at the findings of the JupiterOne 2022 State of Cyber Assets Report on orphaned assets, shadow IT, and the risks posed by their myriad connections to the broader enterprise. You can read the full report here.
