The Biden administration unveiled its National Cybersecurity Strategy last week: a groundbreaking policy proposal that marks an abrupt departure from a three-decade status quo in which the U.S. government let industry set its own rules for software and hardware under the right-sounding rubric of a “public-private partnership” for cyber.
The strategy recognizes that the “industry secure thyself” approach failed. The plan pointed out that markets impose inadequate costs on—and often reward—those entities that introduce vulnerable products or services into the digital ecosystem. Those poor software security practices “greatly increase systemic risk across the digital ecosystem and leave American citizens bearing the ultimate cost,” the Biden administration argued in its report. That’s why the strategy looks to shift liability from consumers and businesses to “those entities that fail to take reasonable precautions to secure their software.”
Before it can start to reshape the IT industry, the strategy needs some teeth – and sharp ones at that. And that means the federal government being prescriptive about the changes it wants to see – something Uncle Sam has long tried to avoid. Here are four ideas that Congress should write into law that will significantly improve the security of software supply chains and deployed applications and devices:
Require the industry to explain what’s in the software
We need to give end users the confidence that the software they license and use comes from the actual organizations or producers it claims to be from. This just makes sense. In the software business, the freewheeling use of third-party and open source components by software publishers has grown to epidemic proportions. That increases the attack surface of applications. It also exposes downstream users to software supply chain attacks via components they are unaware they rely on. Start by mandating the use of software bills of materials (SBOMs) to track the “ingredients” of applications and services. Additionally, technologies such as code signing can document the provenance of deployed software throughout the supply chain and hastens revocation of software components should suppliers become compromised. Congress needs to underwrite these efforts by passing new laws and regulations that clarify the need for more transparency around software provenance. And by software provenance, we mean the source, ownership and makeup of a software component and its associated data, as well as any changes to that software over time. Organizations in both the private and public sectors need to know which components power the applications and services they rely on and which organizations and even developers are behind those open source and third-party software components
Crack down on software tampering and malicious content
The attack on SolarWinds was a reminder of the risk posed by software tampering attacks by malicious actors working inside, or remotely compromising development teams. More than two years after that attack first came to light, few development organizations actively monitor for the kind of tampering seen in the SolarWinds attack. Many publishers tend to believe “better them than us,” rather than “that could be us!” As it looks to turn the policy proposals in the national strategy into law, Congress should look for ways to mandate monitoring for software tampering, unauthorized code modifications, and malicious code. In the same spirit that Congress requires food manufacturers to monitor their production lines for bacteria or other contaminants, software suppliers should have to attest to - and prove that their software development and release pipelines are free of bad actors and malware.
Take swift action to squash “celebrity” vulnerabilities
Identifying vulnerabilities in raw and compiled code has long been a priority for development organizations. However, not all vulnerabilities are equal. So-called “celebrity vulnerabilities'' include flaws that pose a serious cybersecurity risk and lurk in common components. We’re talking about the Log4Shell vulnerability. Another example: EternalBlue, an exploit for a vulnerability in Microsoft's implementation of the server message block (SMB) protocol that fueled the WannaCry and NotPetya wiper attacks. With the exception of federal IT systems and highly-regulated sectors like power generation and distribution, the federal government has few tools to compel private industry to take action against software flaws like these. That needs to change. Congress can help by requiring prompt action on high risk software vulnerabilities and heeding calls in the strategy to “reshape laws that govern liability for data losses and harm caused by cybersecurity errors, software vulnerabilities, and other risks created by software and digital technologies.” Such actions by Congress should compel organizations to attest that software delivered to customers is free of critical vulnerabilities like Log4Shell, and to disclose and remediate such flaws after they have been identified.
Get serious about cyber resilience
While it makes only passing references to the software supply chain, the national strategy frequently invokes the notion of software “resilience” and the need for greater resilience in the IT ecosystem. The plan does not mention the resilience of the underlying development processes and practices that produce the software and services sold to U.S. public and private sector organizations. Resilience, as a concept, implies the presence of development processes that focus on software quality and security – processes in which there’s frequent patching and developers are continually monitoring open source and third-party software quality in addition to that of internally developed code. Finally, resilience implies implementation of multiple coding strategies (for example: vulnerability mitigation techniques such as ASLR, DEP and others) that can impede the ability of any future vulnerabilities to cause harm .
Think of the recent attention given to the travails of Core-JS. It exposed the internet ecosystem’s heavy reliance on a ubiquitous open source library with some 9 billion downloads maintained by a lone, unpaid Russian developer. Modules like Core-JS pose a systemic risk to the internet’s ecosystem. Congress should take up the challenge they pose: articulating clear guidelines for the production of software that emphasizes the use of high quality and accountable third-party and open source software, as well as attention to development and build processes that eliminate the risks of compromises and attacks.
As it stands, the National Cybersecurity Strategy is a policy proposal and not much else. There’s reason to doubt whether any of the proposals in the strategy will make it into law – especially as large and wealthy firms spin up their legions of lobbyists to squash reform.
Still, if software publishers hope to win so-called “safe harbor” from lawsuits – as proposed in the strategy – the federal government should have to clear a high bar for the security of their software and hardware. It will fall to our elected representatives to set that bar. We should all hope they take that job seriously and pass laws that set the software security and quality bar high enough to require vendors to jump – rather than merely step over it.
Mario Vuksan, co-founder and CEO, ReversingLabs
