On May 12th, the Biden administration issued an Executive Order that was written to improve the overall security posture of software products that the government buys from the private sector. Recent events, such as the SolarWinds hack, contributed to the realization that such a move is necessary.
This Executive Order is a big deal. Of course, nothing will change overnight, but given the size and complexity of the software industry, as well as the overall culture behind software security (the culture of: “If the customer doesn’t see it — don’t spend money on it”), an Executive Order can probably yield the closest thing to immediate improvement that we could reasonably wish for. The US Government is a very large customer, and all major vendors will elect to comply with its requirements rather than cross it all off their addressable markets.
A lot has been written on how important it is for the government to use its buying power (if not its regulatory power) to drive vendors into shipping more secure products. Product security suffers from what could best be described as a market failure condition, which would call for such regulatory intervention.
To not overly repeat the mainstream media, I would like to focus on one unique aspect of the current Executive Order, and on how it can ignite a new trend that will change product and network security for the better. I’ll discuss true machine-readable security documentation.
The requirement for a Software Bill of Materials
The Executive Order requires that every software product is accompanied by a Software Bill of Materials (SBOM) which lists the third-party software modules that it contains. This is essential for the customer to monitor its exposure to supply-chain vulnerabilities. Let’s say that I ship software X, and that my software happens to utilize a library from a third party, say, the library L. I now need to worry not only about vulnerabilities found in my software X, but also about vulnerabilities found in L. If I am careless, I could keep maintaining my own software without incorporating patches that are made available for L by its vendor. If I am negligent, I would even not bother to check if there are any newly discovered vulnerabilities that need to be patched in L. If I am yet more negligent, I could even keep on using a stale end-of-life L library that is no longer maintained at all. However careless or negligent I am, the price is always to be paid eventually by my customer. The customer might not even know how reliant his security posture is on L. For what he knows, he only bought X. If that customer knew that its security posture relies on L as well, it could have put pressure on me to make sure I use a secure version of L in my product, or not use it at all. The customer, in other words, could use its buying power to improve what it gets. This situation is what the SBOM provision comes to solve. It forces me to disclose to my customers those additional dependencies that I subject them to, so they can exert their market power towards improving the quality of what they get.
The bigger picture: security documentation
The SBOM is a great idea, and its benefit is yet wider. Security documentation is in poor shape today. Security is not very well covered in product documentation. Technical specifications, like the RFCs published by the Internet Engineering Task Force (IETF), have sections titled ‘Security Considerations’ in them; product documentation usually doesn’t. Even answers to basic questions such as: “What are the exposure risks to the data processed by the product?” or “What could I do as a customer to minimize the attack surface of the product I’m using?” are seldom answered directly. If the customer is lucky, then there are tips scattered around the manuals, help pages, and readme files. If the customer is less lucky, as customers usually turn out to be in such cases, he will need to deduce this from other pieces of product information.
Any security-specific documentation that products will now have to be shipped with is an immense improvement, and will hopefully serve as a precedent for more. One day, hopefully, customers will require a clear manifest of the product’s attack surface: an enumeration of all interfaces and how those are protected. Cynicism aside, I am confident that once vendors actually produce such documents for their customers, they may become aware of some vulnerabilities of their products of which they were not aware before, and fix them on time.
Once we generate more security documents for products, the next step would be making those security documents truly machine-readable.
True machine-readable security documents
The Executive Order requires the SBOM document to be included with the product, without prescribing the precise format this document should take, but noting that it shall be ‘machine-readable’. Every vendor can use whatever format it desires, and ‘machine-readable’ is a definition that is wide enough to cover any document which is not a handwritten napkin (until it gets scanned). Nevertheless, we are likely to witness accelerated document evolution. Thousands of vendors will have to start producing those documents very shortly. It will take very few years, rather than decades, for the industry to converge onto a few stable forms (most likely the forms that will be used by the major consultancies and certification bodies, and in light of further instructions from the government). The standardization fora will soon enough take on the challenge of defining a standard schema, augmenting some work that has already been done.
When this happens, we will all be one large step into the future of true machine-readable security documentation. By ‘true machine-readable’ I refer to documents that machines can actually learn from, not just parse.
Once the SBOM document uses a true machine-readable format, it will be processed by risk management software packages. Such packages will take this input, along with assessment and prioritization from tools like Kenna or VulnDB, to draw a more accurate risk posture for the organization, based on the newly learned dependencies. Introducing automation into the process will also force the vendors into keeping those SBOM documents accurate and updated.
The prevalence of security documents that are truly machine-readable is a big deal. We are not just talking about a security document that is read by a management app instead of by a person; we are talking about a step in the direction of reducing one of the biggest headaches of security monitoring configuration: discovery.
A headache called discovery
The year is 1997, and I get to help improve the security of a large organization. One big challenge at the time was the connection of desktops using modems that were left in answer mode when unattended. I came prepared with instructions and scripts for securing those modems. Soon enough I learned that there was no place in the organization where all those modems were even registered. The one-month “secure the modems” project started with 3.5 weeks of running war-dialers — bots that dial all extensions to create the list of active modems, with just one short week left for actually securing them. Today we barely use modems, but corporate networks grow faster than anyone can keep record, and the trend (at least in tech companies) is to not restrict adoption of new technologies by people, unless necessary. Be it software packages, web services, connected devices or modems, discovery is always a challenge, and the place where many balls get dropped.
Much of the unaddressed attack surface in large systems is caused not by vulnerabilities of which you are unaware, but rather by functionality of which you are unaware. (No point Googling it; I made it up.)
Having mechanisms in place that enforce rigorous record-keeping of systems and their dependencies might not count as the latest core security tech, but can certainly prevent many security incidents.
Once we get into the habit of deploying systems that come with written manifests of their capabilities, there is no reason to stop at the SBOM. Some people suggest an intuitive extension into what they call a “Bill of Behaviors”, and one can easily think of other security-related properties that vendors could report about their systems. So much heuristics are used by security monitoring tools just because there is no clear statement of what an expected behavior of a system is. Using such heuristics not only implies missing alerts, but it also costs us in reduced sensitivity. Heuristics-based security monitors are configured for reduced sensitivity to overcome false-alerts; false-alerts that could easily kill any deployment of a security monitoring tool. Anyone deploying security monitoring tools will tell you that the Achilles’ heel of those tools is not in the quality of their monitoring technology, but in the complexity of the configuration management that is required to deploy them effectively. By targeting this complexity, we strengthen the weakest link.
Once true machine-readable security docs appear, and some standard for them emerges, security monitoring systems will happily start reading them. We will enjoy less heuristics involved in assessing what packages an installed piece of software may contain within it, or what network traffic is reasonable to see. Finally, once the overall security posture of a system is more deterministic and less reliant on heuristics, there will be an incentive for vendors to exceed the requirements of Executive Orders, and provide more such machine-readable manifests. This will assure them that their systems are not generating false alarms by security monitoring tools.
What about IoT?
So far, we’ve discussed typical corporate IT networks. Once the trend of machine-readable security documentation gains traction, it may also be adopted into IoT, where its value will be yet magnified.
In the IoT space, heuristics are more prevalent. It’s a relatively new domain where standards are fewer and fragmentation rules. There are good companies out there that built complete business models around trying to identify what’s running on an IoT network; even just recognizing what types of devices are involved. Security-wise, the IoT space today is where the IT space was two decades ago, with frequent use of weak authentication, use of old software stacks, and over-reliance on obscurity.
Clarity is a good friend of Security, and IoT networks could use much of it.
Summary: the role of the government
The space of IT security, for both corporate networks, home networks and IoT, leaves much to wish for. The market is motivated by functional features, with security taking the back seat. This is the case, to a large extent, because security is evident neither in its existence nor in its absence; a situation that is likely to prevail.
Moreover, product security suffers from significant information asymmetry. The vendor knows much more about the security of its product than the customer (even if such knowledge means knowing that he doesn’t really know, as is the case with many vendors). This asymmetry implies that customers cannot properly factor security into their buying decisions, diminishing the ability of the market to fuel improvements, as it does in other areas.
Such conditions, like the related public safety conditions, call for government intervention. In some cases this happens through regulation (e.g., with car seat belts). In softer cases, where life and death do not seem to be directly at stake, the government can still catalyze improvement by using its buying power. In our case, the primary interest of the government might be to protect itself, rather than the public, but the outcome is the same. (It is reasonable to expect that some of the benefit of that buying power, which the taxpayer enables, benefits back the taxpayer, so all is well.)
Forcing software products to come with a “Bill of Materials” is just part of the benefit of the Executive Order, but I argue that even this addition alone, once imposed on many large vendors, can ignite a multi-phase process of improvement:
- starting with one mandatory machine-readable SBOM document that has to be kept up to date,
- leading to machine-generated machine-readable documents, which are easier for the vendor to produce and refresh,
- to standards-based true machine-readable documents that can be used by security gear, both for SBOM and for other areas where positive attestation by the vendor can help reduce the use of heuristics in security monitoring,
- to an overall higher security posture by improving the accuracy and benefit of security monitoring and enforcement tools; accuracy that will also favor vendors.
We do not need an Executive Order for this, but we do need an Executive Order to build the critical mass of demand for machine-readable security documentation that will ignite this entire process.
Whatever the overall aspiration of the government is — I believe that it will get more than it bargained for.