President Biden's National Cybersecurity Strategy (published on March 2) starts out by recognizing the obvious - digital technologies have become an integral part of nearly every aspect of American life. The next observation is still obvious, but more important - that cybersecurity is essential to the proper functioning of the American economy. The crux, however, is how, exactly, the Biden Administration plans to guide/direct/assist those improvements in cybersecurity and what teeth and/or resources it is willing to put into achieving them.
Across its five pillars, the Strategy spans the right themes:
- Defend critical infrastructure
- Disrupt and dismantle threat actors
- Shape market forces to drive security and resilience
- Invest in a resilient future
- Forge international partnerships to pursue shared goals
There are no surprises there–and there shouldn't be.
It's when you get into the details of the National Cybersecurity Strategy that we find a lot to analyze, and draw conclusions from.
Establishing Liability for Software Products and Services
Across its 35 pages, we find one of its most crucial paragraphs nestled in page 21, which introduces the idea of liability for software publishers and states that the White House will "work with Congress and the private sector to develop legislation establishing liability for software products and services".
Conceptually, this represents a radical change for software supply chain security, though it’s important to note that this text, by itself, does not establish liability. Congressional action is required to modify the legal landscape in the way the Strategy proposes.
That said, just the mere fact that the Strategy includes this idea of liability represents a critical harbinger of the fact that the legislative effort needed to bring this liability into being could be coming soon.
The potential for such liability will surely come as unwelcome news for those who design, build, and sell anything that contains software (which, admittedly, is just about everything). It would carry with it a fundamental change in the economics of the software industry (and those industries that depend on it). But just a few lines farther down in the document, the Strategy provides an escape hatch:
"To begin to shape standards of care for secure software development, the Administration will drive the development of an adaptable safe harbor framework to shield from liability companies that securely develop and maintain their software products and services."
So, what does that mean, exactly?
Put simply, organizations can avoid being crushed by this veritable freight-train of liability by meeting certain standards for secure software development. Which standards? We expect the Strategy to link directly to the Biden Administration's Executive Order (“EO”) 14028 (issued in 2021), which itself links to NIST's Secure Software Development Framework.
As pretty much anyone involved in product security knows, there is already a rapidly accelerating trend towards complying with those exact standards, owing to enforcement mechanisms connected to EO 14028. These mechanisms are focused on software sold to the U.S. government, but they are being quickly adopted more broadly in the private sector either to avoid competitive disadvantage or because the practices wrapped up in these standards actually offer a fairly robust means of achieving substantive gains in for-real cybersecurity.
While it is disappointing that we’re needing to rely on the government to start mandating a perceived minimum security standard, it will likely, over time, improve the industry. Initial versions of the PCI standards were viewed as “a box to check” for compliance, but they have ultimately changed how organizations think about security. That is, they are now often going above and beyond the bare minimum. This is something we need to see more of in product security, and not just those products associated with critical infrastructure.
Without question, the most talked-about element of these emerging practices is the SBOM - the Software Bill of Materials.
The Rise of the SBOM to the National Stage
You don’t have to travel far - we’re still still on page 21 - to see the specific secure software development practices that the Administration plans to actively encourage. The second item in that list is the SBOM.
This is an excellent example of a security practice that has the potential to up the security game, though not in isolation. Some SBOM providers seem to suggest that the SBOM, all by itself, is sufficient to meet the compliance requirements in EO14028 (and, accordingly, the NIST SSDF). It’s not. Rather, it is the artifact through which one can demonstrate compliance with the requirements in the SSDF. It’s also, more importantly, a means for developers and owners to quickly learn whether (and when) the various components in their software have been updated and learn whether any of those components are vulnerable to recently disclosed vulnerabilities.
The quintessential example is log4j. When that vulnerability was disclosed, most owners/operators had no idea whether their software used log4j and was vulnerable to the exploit. It took months for some to figure it out for all the systems across their enterprise. Well-built SBOMs would bring the time required for that exercise from months down to minutes.
The good news is that, as more companies adopt the SBOM (both creating them for their own products and insisting upon getting them for the products they buy), we start to see a sort of “network effect,” wherein the SBOMs become increasingly useful in providing transparency into software - which may, in the end, be the only realistic way to tackle the challenge of supply chain cybersecurity.
Now, flip the page to pg. 22 and there's another interesting development in the National Cybersecurity Strategy:
“When companies make contractual commitments to follow cybersecurity best practices to the Federal Government, they must live up to them. The Civil Cyber-Fraud Initiative (CCFI) uses DOJ authorities under the False Claims Act to pursue civil actions against government grantees and contractors who fail to meet cybersecurity obligations. The CCFI will hold accountable entities or individuals that put U.S. information or systems at risk by knowingly providing deficient cybersecurity products or services, knowingly misrepresenting their cybersecurity practices or protocols, or knowingly violating obligations to monitor and report cyber incidents and breaches.”
This document invokes the Civil Cyber-Fraud initiative. That's a DoJ program to sue government contractors who (among other things) knowingly misrepresent their cybersecurity practices, which then references the requirements of EO 14028.
Now, what does this mean?
Self-Attestations and EO 14028
Invoking the DoJ program was already a possibility, given its mere existence since its launch about 18 months ago. But, what's important here is that the White House is saying, front-and-center, that they will use this in targeting malfeasant government contractors, specifically in the context of EO 14028.
Remember that the Executive Order requires government contractors selling software to the government to self-attest that they comply with EO 14028. Now, government contractors who knowingly misrepresent their compliance will be subject to civil fraud lawsuits.
