Allan Friedman’s vision of the SBOM is Kubrickian indeed.
Stanley Kubrick made films that looked with deep introspection into the future of our society, often as a polite and sometimes troubling warning of things to come. Like Kubrick, the cybersecurity expert Allan Friedman is calling attention to how we build software, and the implications for securing critical infrastructure are huge.
While I was at Black Hat I had the opportunity to sit-in on Allan Friedman’s Session How I Learned to Stop Worrying and Love the SBOM, and Allan made a good case for how CxO’s can prevent the software sprawl that I often talk about. In the spirit of moving towards simplicity in environments and understanding attribution in cybersecurity, having a software bill of materials can give us more transparency into how our internal or external software is being developed. Transparency that translates to more secure and resilient software.
If you’re not familiar with the SBOM the premise is simple: organizations that use external code libraries or binaries maintain an active list of all of the binaries and code libraries they’ve included in a standardized machine-readable format. For data security the benefit is a faster and more proactive security response as CVEs come out due to the insight that SBOM gives into software dependency stacks, and better intelligence on other security issues with specific code and zero-day vulnerabilities.
Understanding what’s operating in your infrastructure is paramount to being able to manage and operate that infrastructure effectively.
The concept of a software bill of materials isn’t without its critics. Seth Rosenblatt over at The Parallax has a valuable article that highlights issues industry stakeholders have regarding the notion of SBOM, including some who suggest that documenting the composition of software is simply too big a project. I simply disagree, and here’s why: if you’re committed to building secure and scalable software, being meticulous is actually a requirement. This is why we look to automation, so that we can maintain velocity while building strong tests and structure to keep our software honest.
For legacy code the task of retrospectively auditing the provenance of that code could look momentous, but we don’t need to boil the ocean here. Software like Black Duck, Aqua, and other dependency management and CVE tools can help, especially if they build support for the SBOM into their output.
We Can Make the SBOM Real
Crafting a machine-readable industry standard feels like a tough nut to crack, but having spent the last 3 years working on standards such as STIX/TAXII I can tell you it is achievable. Making the SBOM a reality will require the industry to stand up and get involved.
New Context works with customers in highly regulated industries and critical infrastructure. The addition of SBOMs to our collective toolkit will help us keep the connected world safe. We’re working towards the creation of standards focused on the unique architectures of each industry, and prioritizing which standards to adopt. We’re partnering with our customers, and gathering input from their users and operators, moving towards technology that will ultimately streamline workflows.
New Context works with customers in highly regulated industries and critical infrastructure, and SBOMs help us fulfill our mission to keep the connected world safe.
Moving SBOM forward and encouraging knowledge-sharing between business and government can reduce the chances of a catastrophic breach. Remember, big cyber attacks often lead to new industry regulation.
Many CxOs see software as the greatest risk in the security posture of their organization, so as SBOM matures we will build it into the framework of our LS/IQ dashboard to track our clients’ progress as they adapt their processes to reduce risk.
For the projects we work on in IIoT, we’re finding cyber security is now connected to personal safety. New Context is working to secure devices that if breached can lead to physical harm and the loss of life, and we need only to look to the attack of a petrochemical plant in Saudi Arabia this Spring to see how much is at risk.
As we deploy IoT into smart cities, utility grids, and our highways, the stakes for making sure they are secure will be paramount. As these devices are added to the mix the value of concepts like the SBOM grow exponentially. The NTIA said it best:
“This challenge is compounded by the growth in Internet of Things devices, as companies add “smart” features or connectivity without clear visibility into a product’s underlying software components…while the majority of libraries and components do not have known vulnerabilities, many do, and the sheer quantity of software means that some software products ship with out-of-date components that may never be updated.”
-David J. Redl, Assistant Secretary for Communications and Information and NTIA Administrator
In June Mr. Redl announced NTIA’s multi-stakeholder process to encourage software component transparency because today’s apps, programs, and firmware heavily rely on code from numerous vendors to function. Learning more about the multi-stakeholder process is worth a read. (Incidentally, New Context are actively participating in two of the five NTIA SBOM working groups to help make the SBOM a reality.)
We are already deploying resources to help-out with SBOM, and I’m hoping that our partners and peers follow along and lend their expertise. If you’re interested in working on SBOM connect with the NTIA Software Transparency Group or the team at New Context. Together we can build a set of standards to automate and strengthen our ability to build secure software.