Dive Brief:

• Companies implement zero-trust architecture through software, but it can fail when that software is untrustworthy, said Ed Skoudis, fellow and director at the SANS Institute and Cyber Ranges, during the RSA Conference Thursday.
• "If you update that software, using mechanisms that don't ensure the integrity of that software, you've got a problem," he said. "Your zero-trust architecture is trusting software that's not trustworthy."
• The attacks against SolarWinds and Microsoft Exchange highlighted the conundrum, but supply chain attacks are only one way of undermining software integrity, said Skoudis. Open source, a tool that enables break-neck development speed, threatens software integrity.

Dive Insight:

Software integrity is tricky to ensure as developers use what is available to them, just as malicious actors do. 

Researchers observed 174 malicious software packages used in open source supply chain attacks, including NotPetya, in "The Backstabber's Knife Collection," a paper observing the various ways bad actors could inject malware into open source projects, which Skoudis referenced. 

Upwards of 30 tech companies could be compromised by taking advantage of the blind trust between customers and open source code, according to Alex Birsan's dependency confusion research released in February. None of the packages —  which include Node's npm and the npm registry, Python's pip using Python Package Index and RubyGems — can guarantee an upload is free of malware. 

Birsan found he could create public packages using the same name as packages privately held by companies. "He was able to trick the public package management solutions into pulling in his code," said Skoudis. "This truly is a big and foundational problem." 

Languages such as Python and RubyGems are dynamic and easy to use, which make them ideal for developers and cybercriminals. However, "I don't think you're going to make your choice on software development environments based on this kind of attack," said Skoudis. 

Companies can configure their package management for internal private packages, which Microsoft has guidance for. 

Companies with closed development environments dependent on private packages should configure their management tools to disregard searching for private packages in public environments, said Skoudis.

Closed source is not simply more secure than open source because each has their respective dependencies. Inventory tools will uncover those dependencies, but "when a closed source project has dependencies on other closed source projects, that's much harder for us to see," said Skoudis. 

To combat software insecurities, Skoudis recommended beginning with software inventory and a software bill of materials requirement. "It essentially says, here's the ingredients that go into making your software," and companies should demand the bill of materials from their software providers. Companies need file integrity management solutions, which are readily available, yet organizations inadequately deploy them. 

If a sophisticated threat actor is involved, the layers of inventory, bills of materials and file integrity management might fall short. Skoudis recommends filling the gaps with threat hunting.  

But "what if you do threat hunting, and your threat hunters don't discover anything?" said Skoudis. In these cases, companies employ "purple teaming," where blue and red teams are cooperating and benefiting each other.