Everyone in the cybersecurity community agrees on the following: You can’t secure what you do not know. We all learned this with the recent Log4j incident. For this reason, IT security vendors knock on our doors at AT&T every day to show us new means for discovering inventory.
This is a good trend, and we recommend that every security team in every industrial sector take the time to build a more accurate inventory. The AT&T enterprise security experts on my team work on this every day, and it is a challenge.
But there’s another type of visibility gradually becoming more important to cybersecurity teams. It involves seeing what’s inside our systems and software. Just as enterprise security teams have wanted to look across a large network to find all the devices, systems and data, now they want to be able to look inside these components to understand how they were designed, implemented and built. They want to see the ingredients, so to speak.
This is not a new concept in business or even society. Allan Friedman, senior advisor at the Cybersecurity and Infrastructure Security Agency (CISA) at DHS, has joked in his presentations and talks that when you buy a Twinkie, the manufacturer shares the contents of what’s inside. This might seem innocuous until you realize that a Twinkie includes meat proteins. Vegetarians can see, just by looking at the ingredients, that they might stay away from this type of snack.
Friedman makes the strong case that if you can see inside a Twinkie, then we should be able to see inside our software. It’s hard to argue with the logic. IT teams across the world have spent critical hours, days and weeks locating vulnerable Log4j – an open-source logging utility used in countless other software packages.
Technology experts have warned that building a good list of ingredients, which is called a Software Bill of Materials (SBOM) for software and a Device Bill of Materials (DBOM) for devices, is not an easy task. Our experience at AT&T confirms the difficulty of such a task. Libraries, packages, routines, open-source, legacy code, networked components, configuration utilities, APIs, orchestration tools and so on – all complicate the construction of a bill of materials.
But we believe the security community should start to organize around the idea. Last May, the White House executive order on cybersecurity directed the Secretary of Commerce to establish national supply-chain guidance – including bills of materials for software purchasers. The National Telecommunications and Information Administration (NTIA) within the US Department of Commerce also has pushed on this idea. Its on-line resources explain the benefits of SBOMs for transparency, supply chains and more. And the CycloneDX community supports the many open-source and proprietary SBOM tools.
The DHS Information and Communications Technology Supply Chain Task Force also has established working groups focused on both a hardware and software bills of materials.
Standards have emerged for SBOMs, as well. The Software Identification (SWID) Tag is an ISO/IEC 19770 format that can be followed by software vendors, and the Software Package Data Exchange (SPDX) is an open-source machine-readable format. These standards work together and can be integrated into the software development lifecycle. SWID Tags, for example, give useful information about versions, developers and other artifacts about the software. The purpose is to increase understanding about the software.
As I said earlier, we all know that SBOMs are not easy. Driving accuracy and completeness in the data is a particular challenge. And the scale of open-source usage is wide and varying, so maintaining version information will be tough to accomplish at scale. Even keeping track of the security history of some piece of software is not easy to do. To date, no good solutions exist for tracking whether some code was involved in a prior vulnerability incident. So, we have some work to do as a community.
Despite these challenges, we recommend that security experts and practitioners begin to take this issue more seriously. Our research teams at AT&T have begun to examine SBOMs more carefully in their work. And we’ve begun preliminary discussions with our own procurement groups within AT&T to determine whether we can begin a process in the future of requesting SBOMs from our suppliers. Maybe with increased push on this topic, we will see some real progress.
