One blessing of the Cybersecurity Executive Order

On May 12th, the Biden administration issued an Executive Order
<https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/>
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 <https://www.crn.com/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.

      Beyond SBOM

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:

 1. starting with one mandatory machine-readable SBOM document that has
    to be kept up to date,
 2. leading to machine-generated machine-readable documents, which are
    easier for the vendor to produce and refresh,
 3. 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,
 4. 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.

/This essay has also been published at: https://www.hbarel.com/