A Collaborative Approach to Meeting the Challenges in President Biden’s Executive Order on Improving US Cybersecurity
By Jason Keirstead, OASIS Open board member
On May 12, U.S. President Joe Biden signed the Executive Order on Improving the Nation’s Cyber Security, charging U.S. federal agencies to partner with the private sector to foster a more secure cyberspace and protect the nation from malicious cyber actors. As both a board member as well as an active participant, I believe that OASIS Open’s members and projects are uniquely qualified to facilitate this public-private partnership and help guide the creation of cybersecurity standards.
Securing the Software Supply Chain
One key aspect outlined in Section 4 of the Executive Order (EO) is securing the software supply chain. At issue here is the reality that the U.S. federal government—like nearly any other organization on the planet that uses computer technology in any form—relies on not just one but numerous types of software to process data and run operational equipment. The sources of the software can vary—from proprietary software purchased from vendors to open source software downloaded from Git repositories to custom software created by in-house developers. To make matters more complex, most software today is itself a compilation of pieces of code that come from a variety of sources, with each component being inherently subject to flaws and vulnerabilities. In order to secure the software supply chain, we need to be able to document the provenance of software code, i.e, its origin and path of development or, as it is phrased in the legal field, the code’s “chain of custody.”
One tool for documenting provenance is the Software Bill of Materials or “SBOM.” It’s a list of all the components that make up a codebase, the source of each component, the versions of those components, their patch status and the licenses that govern them. The concept of an SBOM is derived from manufacturing, where manufacturers keep detailed inventories of the parts that are used to build a product (such as a car) and the sources of those parts. Such bills of materials can be vital not only for production, procurement and maintenance purposes but also for initiating appropriate responses (e.g., a recall) when a part is found to be defective. Similarly, a software bill of materials is essential to responding quickly when vulnerabilities or security breaches are discovered in a piece of code.
Members at OASIS have, for quite some time, been working on a standard that will be a critical feeder into SBOMs—the Common Security Advisory Framework (CSAF). CSAF is a standard way for vendors and open source projects to report vulnerabilities in their products to the outside world. SBOMs and CSAF go hand in hand; in fact, without the information that originates in CSAF, an SBOM cannot fulfil its purpose with respect to cybersecurity.
Here’s an example of how SBOMs and CSAF create a cybersecurity feedback loop. Suppose you are managing Microsoft Windows. You’re using Python, and Python’s SBOM lists OpenSSL as a component. If the OpenSSL project issued a new CSAF advisory, the advisory could automatically cascade upstream to Python, and then cascade upstream again to Microsoft Windows. Microsoft could then issue its own CSAF advisory, essentially completing a virtuous feedback loop to help eliminate vulnerabilities throughout the supply chain.
Allan Friedman, the Director of Cybersecurity Initiatives at the US Department of Commerce, National Telecommunications and Information Administration (NTIA), is tasked with managing cybersecurity multi-stakeholder processes to bring together industry, academia, and the hacker community to tackle key security policy issues. He and his team are currently evaluating options for SBOM standards and policies and are already working closely with CSAF, because no matter how the standard gels, CSAF will play an essential role.
SBOMs Just Scratch the Surface of the EO Mandate
There is much, much more to the EO than SBOMs and the supply chain, and OASIS has much to offer in the other areas as well.
EO Section 2, for instance, is devoted to sharing threat intelligence. OASIS supports several standards that could play a role here, including:
- STIX, a language for expressing cyber threat and observable information.
- TAXII™ is an application layer protocol for the communication of cyber threat information in a simple and scalable manner.
- TAC is a common knowledge framework that enables semantic interoperability of threat actor contextual information and standardized vocabularies for threat actor characterization.
EO Section 3 deals with modernization. The SAML project is highly applicable here. Security Assertion Markup Language is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.
EO Section 6 addresses the government’s need for a uniform series of playbooks for responding to vulnerabilities and incidents. OpenC2 and CACAO are ready-made for this challenge. OpenC2 is a standardized language for the command and control of technologies that provide or support cyber defenses. By providing a common language for machine-to-machine communication, OpenC2 is vendor and application agnostic, enabling interoperability across a range of cyber security tools and applications. CACAO is a standard for defining and sharing cybersecurity playbooks, and how these playbooks can be created, documented, and shared in a structured and standardized way across organizational boundaries and technological solutions. It’s an ideal format for what the government wants to create.
EO Section 7 is focused on improving detection of vulnerability and incidents, which is what CSAF is all about, as I mentioned earlier.
And the OCA is relevant to all of it. The OCA (Open Cybersecurity Alliance) is an ideal forum for vendors and entities who want to participate in an ecosystem where cybersecurity products interoperate without the need for customized integrations. Using community-developed standards and practices, OCA is simplifying integration across the threat lifecycle. As regulations to implement the EO become codified by CISA, NIST, and other federal agencies, a standards-based and vendor-neutral approach will be required in order to facilitate a healthy and competitive cybersecurity marketplace. The OCA is an ideal forum where this kind of cross-industry collaboration can and should take place.
Beyond Standards: Orchestrating Harmony & Progress
Yes, many standards relevant to the EO are already in development under the OASIS umbrella. But the organization has more to offer this challenge than simply a library of projects: namely, its acumen for creating harmony and progress from heterogeneity and complexity.
OASIS Open is one of the most respected, non-profit standards bodies in the world. People and organizations join OASIS to advance projects for cybersecurity, blockchain, IoT, emergency management, cloud computing, legal data exchange, and much more. (You can check out all the projects here.) The priceless asset OASIS offers its communities is the ability to harness the power of global collaboration to advance the fair, transparent development of open source software and standards. That’s what it’s going to take to address the challenges laid out in the EO.
A common adage today is “it takes a village,” and I suppose that applies in the case of the EO. Certainly, industry has been given a mandate to help the U.S. government solve its cybersecurity challenges, but neither one nor many vendors with their proprietary solutions will be enough. Likewise, simply defining a standard—whether de facto or de jure—will not be enough. And although open source will certainly play a role (e.g., bridging the gap between a proprietary solution and the standard by building and testing reference implementations), open source alone can’t solve the problem either. Interoperability of solutions in this space, whether proprietary or open source, will require open standards that have been collaboratively built and designed with open integration in mind from the beginning.
It’s going to take a village—a harmonious combination of standards, vendor solutions, and open source—to accomplish this. Creating and nurturing that kind of village is precisely what OASIS does best.