With Vendors Like These
By Ravi Nayyar
Dear, Oh Dear, Oh Dear
A flaw in [QNX] software made by BlackBerry has left two hundred million cars, along with critical hospital and factory equipment, vulnerable to hackers— and the company opted to keep it secret for months.
On Tuesday, BlackBerry announced that old but still widely used versions of one of its flagship products, an operating system called QNX, contain a vulnerability that could let hackers cripple devices that use it. But other companies affected by the same flaw, dubbed BadAlloc, went public with that news in May.
These are the opening paragraphs from a Politico article on BlackBerry’s abject failure of governance in refusing to go public about said flaw in QNX, instead preferring to stonewall federal agencies rightly concerned by national security and cyber supply chain risks borne from the widespread usage of QNX.
To understand the chronology of the QNX matter, note that Microsoft announced the flaw on 29 April 2021. Despite the prior urging of the US Cybersecurity & Infrastructure Security Agency and the Pentagon, BlackBerry only coughed up an alert on 17 August 2021.
Insert golf clap.
Supply Chain Risk
QNX is arguably critical software, not just because it is used in critical infrastructure, but because of the sheer number of devices around the world (and in space) running it. Attackers need only exploit one flaw in QNX to compromise scores of devices running that particular version of QNX.
The issue of flawed critical software putting critical infrastructure at risk of compromise reminds one of the National Institute of Standards and Technology’s (‘NIST’) warning that:
reliance on technology, communication, and interconnectivity has changed and expanded the potential vulnerabilities and increased potential risk to operations. For example, as technology and the data it produces and processes are increasingly used to deliver critical services and support business/mission decisions, the potential impacts of a cybersecurity incident on an organization, the health and safety of individuals, the environment, communities, and the broader economy and society should be considered.
Echoing NIST’s reference to impacts of breaches on the environment, broader economy and society, the Commonwealth Department of Home Affairs (‘the Department’) points to negative externalities, created by a vendor’s suboptimal cyber resilience processes, being transmitted throughout a cyber supply chain.
Little wonder that a flaw in a piece of software relied on by, well, an awful lot of entities across sectors can create serious downstream effects.
Ask the people of Ukraine: NotPetya initially spread via the compromised update mechanism for the M.E.Doc accounting software, virtually ubiquitous in the country.
Or, for a more recent example, ask the companies and government agencies breached in the SolarWinds campaign: SUNBURST spread via the Orion network monitoring software’s compromised update channel.
Negative externalities stemming from vendors dropping the ball are amplified when (per the Department) ‘end users almost always have less capability to manage cyber security risk compared to the technology companies that supplied the software or device’.
Such externalities are also amplified by, in the case of QNX, the vendor’s ‘resist[ance]’ to publicly announcing a flaw in their code despite being unable to determine how many entities are affected by the flaw (because the vendor licenses the software to OEMs who use it to build their own products).
Are SBOMs and SBOBs the Answer?
The article touts Software Bills of Materials (‘SBOMs’) as a solution, particularly when the vendor cannot identify every affected end user because of supply chain realities.
Per section 10(j) of President Biden’s Executive Order on Improving the Nation’s Cybersecurity, an SBOM is defined as:
a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging.
The subsection then details the benefits of SBOMs for multiple stakeholders in supply chains:
- software developers can cross-check their products’ SBOMs with open source code libraries to check for vulnerabilities borne from their products’ open source components;
- buyers can leverage SBOMs to drive more efficient and granular supply chain risk management because they have a better idea of the actual code which they are purchasing; and
- end users can cross-check SBOMs for code they deploy with vulnerability disclosures by the developers themselves or third parties to more swiftly identify sources of cyber risk and mitigate them through patching, vital if the affected software runs on equipment which cannot afford much downtime.
It has even been recommended that SBOMs are complemented by ‘Software Bills of Behaviours’ (‘SBOBs’). SBOBs describe what the normal operation of the software should look like, such as what domains or IP addresses the software will connect to. This can help accelerate risk identification and drive earlier incident response because the victim is better able to identify and thus prosecute anomalous activity on their networks.
Given the above, sure, if vendors do a BlackBerry, SBOMs and SBOBs are a great insurance policy for end users to manage cyber supply chain risk. They need not rely on vendors' governance processes to kick in and for vendors themselves to put out an an alert. Instead, end users can rely on third party researchers and in-house security teams to gather threat intelligence which can be cross-checked with SBOMs and SBOBs to develop situational awareness.
But one could also point out that detailed product disclosures at the point of sale — via SBOMs and SBOBs — are merely part of the solution.
What about breach/product vulnerability notification regimes that apply to vendors? Vendors would be likely to know more about their products and systems than security researchers, including flaws that may not have been discovered by these third parties. So, any recalcitrance on the part of vendors when it comes to disclosure and information sharing should not be left unchecked by the law.
Otherwise, where's the incentive for vendors to do the right thing and alert the ecosystem about the wonderful new supply chain risk their code has introduced?
Why should the vendor be allowed to remain aloof to the negative externalities that its flawed code and non-disclosure thereof may create?
The Stakes Haven’t Been Higher
Our economies and societies are little more than a tangle of computers running software produced by vendors with differing attitudes to cyber resilience and governance. I agree with one of the experts quoted in the QNX article that national security and cyber supply chain risks are deeply intertwined.
Taking stock of the situation, Gregory Conti and David Raymond’s observation especially comes to mind:
Technology's allure and potential efficiencies have drawn governments, businesses, military, and individuals en masse to adopt technical solutions that enable governance, commerce, and national security. You cannot live in modern times and avoid cyberspace. These digital systems are insecure, converging into risky monocultures, yet we depend on them.
But I’ll let NIST have the last word:
The United States depends on the reliable functioning of critical infrastructure. Cybersecurity threats exploit the increased complexity and connectivity of critical infrastructure systems, placing the Nation’s security, economy, and public safety and health at risk.
