IT pros need to require software bills of materials for the networking software used in their enterprises to guard against potential threats.
As the Log4J crisis made clear, understanding what is in the software unpinning your applications is crucial to understanding your security posture. This is no less true of your network services.
Enterprise-network infrastructure is still very much about hardware in data center and LAN and WAN, but now it is becoming more and more about software.
In this era of software-defined networks, an ever-increasing number of network appliances are just proprietary software running on generic switching hardware or even a plain vanilla x86 server with extra network cards. That shift in emphasis from the hard to the soft has made the software stacks running the network a new source of risk and worry for cybersecurity.
The ability of IT to deliver access to services, and by extension the integrity of enterprise data, is built on a foundation of network and network-management software. But what is that foundation built on? Even the network team probably doesn’t know.
Let’s look at three different types of network software found in the enterprise: open source, proprietary with embedded open source, and fully proprietary.
Open Source You Know About
Open-source software (OSS) network components abound—ClearOS, Open vSwitch, ONOS, DeNT, pfSense, SoNIC, Stratum, Untangle, to name some—and commercial offerings are wrapped around them. The number of options for switching, routing, and security is growing, and the individual packages are maturing. Throw in the much broader set of tools available for network monitoring and management—Cacti, Checkmk, Nagios, Pandora, Prometheus, Zabbix—and the number of possibilities increases dramatically.
The thing is, enterprises mostly don’t know what is actually in all these tools. And even if any given tool doesn’t have some known vulnerability within it, a lá log4j, it certainly could be vulnerable to the next such compromise that comes along. And there could be an uncomfortably long interval between the time an exploit of that vulnerability is found in the wild and the time that information reaches IT.
Not everyone is going to audit all their code to find out whether it contains vulnerable components, but everyone should be gearing up to do or consume automated code analyses on these kinds of systems. Thanks to a push by the federal government, soon there will be a way to discover what code is used: Software bills of materials (SBOMs), which are detailed listings of all the components that go into a software package, including third-party components.
Open Source You Maybe Don’t Know About
Consider that OSS is probably tucked in under the covers of some of the proprietary software in your network. This was a major piece of the log4j mess: OSS had been used in all sorts of in-house and commercial applications. The developers may know about it, but the folks on the network team likely do not.
The same thing could be happening with all kinds of proprietary network tools and platforms, with any of dozens of other commonly used OSS projects: math libraries, graphics libraries, databases, etc. In the name of speed and innovation, software developers rarely work entirely from scratch any more, and one big software package may lean on scores of other ones.
Hidden Proprietary Stacks
Sometimes the hidden dependency is in other proprietary software, not an OSS package. Consider the many, many vulnerabilities revealed in the last decade affecting commercial TCP/IP stacks: Ripple20, a set of vulnerabilities affecting the Treck TCP/IP stack; Name:Wreck, a set of vulnerabilities affecting, among other stacks, Express Logic (now Microsoft) NetX and Siemens Nucleus Net time; and TCP/IP stacks used in broadly deployed IOT devices. This type of vulnerability can also affect the security of network infrastructure.
No one is suggesting at this point that every IT shop can review every line of code in every application for security issues. However, the federal government is taking a lead on some aspects of this problem by requiring vendors to attest to following secure development practices or show where they don’t, how they mitigate the risks, and when they will. And they must, when requested, produce a full SBOM.
Enterprises should be clamoring to see SBOMs for software they buy and run, especially those things on which they build their network infrastructure.
