Developers: apply these 10 mitigations first to prevent supply chain attacks

DevOps leaders hoping to find a single cybersecurity risk framework that will prevent their work from experiencing the kinds of compromises that lead to supply chain attacks will have a hard time, according to a new research paper.

In a paper submitted to Cornell University’s arXiv site for academic manuscripts, the six researchers — four from North Carolina State University, one from Yahoo and one between positions — said they could rank the top tasks that application development teams should perform to blunt possible compromises in their work that might lead to their applications being used to attack users.

They did it by mapping the 114 reported techniques used in compromising three vital apps, SolarWinds Orion, log4J and XZ Utils, against the 73 recommended tasks listed in 10 software security frameworks, including the US NIST Secure Software Development Framework.

However, the researchers added, three mitigation factors were missing from all 10 frameworks. That suggests that no one framework will close all the potential holes in an application. The three missing elements are:

making sure open source software is sustainable;

having environmental scanning tools;

and making sure application partners report their vulnerabilities.

Johannes Ullrich, dean of research at the SANS Institute agreed.

“None of [the frameworks] is perfect,” he said in an email, “and that is OK. The software supply chain can’t be secured in isolation. DevOps leaders must talk to the rest of the enterprise to see where the gaps are that they need to fill. These frameworks are a starting point for that discussion.

“As for the three gaps, it depends a bit on the scope of your software supply chain security effort. For example, they [the researchers] do not consider ‘open source software’ a supplier, as there is no contractual relationship. I think there is a contractual relationship, even if often a weak one, governed by the various open source licenses. I don’t think that is fundamentally different compared to commercial software. Commercial suppliers may ‘disappear’ or stop supporting a particular piece of software at any time (which I think is where they are going with this control).”

Environmental Scanning Tools, another missing mitigation, is often part of vulnerability management, Ullrich added. But, he said, sometimes other activities can fill the gap. For example, ‘Response Partnership’ is often part of the incident response framework, and collaboration is often also part of threat intelligence.

“You can always find gaps in frameworks if you extend their use beyond what they are originally designed to do,” he concluded, “and again, they need to be consistently updated.”

Worst supply chain attacks

The paper, Closing the Chain: How to reduce your risk of being SolarWinds, log4J or XZ Utils, deals with three of the worst supply chain compromises in recent years.

Solar Winds: As we reported, Microsoft believed “at least 1,000 very skilled, very capable engineers” worked on the hack, which involved inserting malicious code dubbed Sunburst into the software updates for SolarWinds’ Orion network management suite. SolarWinds said about 18,000 firms downloaded the updates, and of them, about 100 were compromised;

Log4j: Attackers exploited a flaw (CVE-2021-44228), dubbed Log4Shell, in Apache’s open source log4j logging utility. It was rated 10 out of 10 on the CVSS vulnerability rating scale, and could lead to remote code execution (RCE) on underlying servers. Because of its ubiquity in a wide range of applications, it isn’t clear how many IT networks were compromised;

XZ Utils is a data compression utility, part of major Linux distributions. The installation of a backdoor was caught before it could do widespread damage, we reported last year.

The researchers wanted to prioritize all of the recommended tasks in 10 security software development frameworks by looking at the tactics threat actors used in these three hacks, indicating current framework tasks that could have mitigated those attacks. The work would also show gaps in the frameworks that leave code vulnerable to attacks.

They analyzed 106 cyber threat intelligence (CTI) reports of the techniques used in the three attacks, then mapped them to 73 best practice tasks in the frameworks that developers should be performing. Finally, they ranked priority tasks that would best mitigate the attack techniques.

While there were 114 unique attack techniques across the three hacks, 12 of them were common, including exploiting trusted relationships, obfuscating data, and compromising infrastructure. They also found that 27 of the recommended 73 best practices could have mitigated the three attacks.

However, they added, three of the 27 recommended mitigation tasks were not included in any of the frameworks; they included using sustainable open source software and the use of environmental scanning tools.

“Thus, software products would still be vulnerable to software supply chain attacks even if organizations adopted all recommended tasks,” they concluded.

Starter kit of mitigations

What the work did allow the researchers to do is create a ‘starter kit’ of 10 defensive tactics developers should adopt, based on the highest mitigation scores in their research. Taken from the Proactive Software Supply Chain Risk Management Framework (P-SSCRM), the 10 are:

role-based access control

continuous system monitoring

monitoring and controlling communications at the external boundary of the system and at key internal boundaries

monitoring changes to configuration settings

enabling authentication for employees and contractors

updating vulnerable dependencies when a fixed version is available

enumerating possible threat vectors through threat modelling and attack surface analysis

limiting the information flow across trust boundaries to participants in the supply chain

protecting information at rest

remediating vulnerabilities, prioritizing based upon risk.

These 10 mitigations apply to broader software security rather than being specific to the software supply chain security, the researchers added. “Before mitigating software supply chain attacks, common software security tasks should be addressed,” they emphasized.

In an interview, report co-author Sivana Hamer acknowledged that all of the 10 frameworks studied have gaps in the mitigations that should have applied to the three hacked applications. “None of the frameworks are supposed to provide a complete view of security,” she said. “All have a different notion, like one is more focused on build environments.”

The ‘starter kit’ of mitigations is the list of security tasks that developers should prioritize, she said.