Open source has changed the way and speed companies make software. It also makes security a challenge, showcased by Log4j. 

"There is a lot that can go wrong when it comes to trust in any third-party software, regardless of whether it is open source or proprietary code," said Eric Byres, CEO of aDolus Technology, an OT software supply chain firm, and ISA fellow. 

This last year has shown how any kind of code is vulnerable to manipulation, he said: 

• The SolarWinds attack compromised the build process
• With Kaseya, malicious actors subbed bad code for good code
• With Log4j, widely used code contains exploitable vulnerabilities

Industry is making headway mitigating the risks of software supply chain attacks by boosting basic hygiene, the best form of defense. But companies need mechanisms for ensuring the integrity of the software and code they adopt. Sophisticated attacks are always a possibility, but the most constant threat in open source is blind trust.

"If you are going to embed an OSS project in your stack, it is helpful to use systems that were designed from the ground up to be easily auditable, and the companies behind them can afford to hire security researchers to audit them on a regular basis," said Ev Kontsevoy, CEO and co-founder of Teleport. 

While there are tools available to catch some of these risks, the root cause of an issue like Log4j is the continued conflict between productivity and security. "Managing open source dependencies, or building in-house requires time and effort which is always in short supply," said Kontsevoy. 

Proprietary code is not inherently more secure than open source. It too has dependencies with other closed source projects,  which can limit the visibility of inventory tools. 

The software bill of materials (SBOM) movement — which calls for an "ingredients list" of open source and proprietary software — is moving the needle toward a more rapid response in mitigation, but "SBOMs won't solve issues like Log4j," said Byres. "Mitigation of a vulnerability is impossible if you don't even know what software you are using."

If sophisticated threat actors are involved, a combination of inventory, SBOMs and file integrity management might fall short in protection. Organizations can use threat hunting to signal an indicator of compromise or exploitation attempts. 

Interim solutions

Security professionals expect mitigation for Log4j to take weeks to months, if not longer, partially due to how long it will take businesses to find Log4j throughout their networks. Similar to PrintNightmare this summer, there are vulnerabilities that fundamentally change how security operates, according to Jason Slagle, VP of technology at CNWR IT Consultants. 

"There have been a number of these, but printing running as the system users dates back to the beginning of Windows," he said. "In reality, it should have never been the case and we're trying to clean that up for now." 

For Log4j, the scope of the threat adds to its criticality. The software is everywhere, said Slagle. "Log4j is a fundamental component that solves a logging problem … As a result, you may end up having it because a component of a component you use is utilizing Log4j." The supply chain reliance adds to detection difficulties. 

When more interdependent components are introduced in an infrastructure solution or more code is added to an application, additional vulnerabilities will arise. "Interdependencies can multiply, either hiding a vulnerability or locking in a reliance on the underlying components," which will perpetuate a threat like Log4j, said Lewis Huynh, CSO of NinjaOne. 

This visibility issue arises for customers and vendors — everyone is figuring out if they use Log4j and if so, where. Byres is working with a software supplier in OT which told him a piece of their software is not in active development, so it can't detect if it contains Log4j. "The bottom line is that SBOMs are needed both for new software and the 20-year-old-legacy software that is so prevalent in OT today," he said. 

While experts agree SBOMs are a useful tool for these kinds of vulnerabilities, they are not the silver bullet to solve widespread security concerns.  

The risk of a poorly designed SBOM is alert fatigue, or if SBOMs are adopted in isolation, a security team "isn't going to see any impact," said Kontsevoy. 

The next push for SBOM iteration is to include more intelligent in gauging the quality of code, its origin and vulnerabilities, according to Byres.   

While companies wait for their vendors to issue patches, Slagle is seeing companies take interim defensive measures, including more modern Java or web application firewalls (WAFs). "Security is a set of layers, the goal here is to insert enough to give your vendors time to evaluate and assist," he said. 

WAFs will help block access to a network hosting the vulnerability, said Huynh. For Log4j, "if there is no requirement to allow remote calls across the internet a WAF can be configured to filter and block matches," which include:  

• jndi:dns://
• jndi:ldap://
• jndi:ldaps://
• jndi:rmi://
• jndi:iiop://

Slagle referenced the SIGred vulnerability, published in 2020 though it was years old, as a similar widespread issue like Log4j, though not as bad as 2014's Shellshock. 

"The industry was less scary back then, and I think that saved us," he said. "If Shellshock happened today, and time will tell if Log4j becomes it fully, we would have seen widespread ransomware deployment and exfiltration."