The Pursuit of Lucidity in the Labyrinth
By Ravi Nayyar
Last year, the Director of the Cybersecurity & Infrastructure Security Agency issued a warning:
Everything’s connected. Everything’s interdependent. Everything is vulnerable. We all ride on very similar technology backbones.
In referring to shared vulnerabilities borne from the extraordinary interconnectivity of modern computing (with some great assonance at that), Director Easterly’s words reflect the imperative to manage cyber risks that are transmitted through cyber supply chains.
But What Are Cyber Supply Chains?
Cyber supply chains are the ‘network[s] of people, processes, technology, information, and resources that deliver [technological goods and services]’. They include ‘a wide range of resources (hardware and software), storage (cloud or local), distribution mechanisms (web applications, online stores), and management software’.
Given how vital all things digital are ‘to the very fabric of our lives’ (to quote Director GCHQ), it is crucial that cyber supply chains are ‘resilient and secure’.
Especially when the need for digital connectivity rocketed during the pandemic, making economies and societies even juicier targets for malicious cyber actors.
The Challenge
Achieving the resilience and security of cyber supply chains remains, however, quite the challenge. Technical and commercial realities have made cyber supply chains rather labyrinthine.
Dr Ian levy, Technical Director for the National Cyber Security Centre, bemoaned how ‘they are genuinely unknowable… [and thus] impossible to risk-manage’. The Office of the National Cyber Director in the United States noted computers to be:
so complex that it can be difficult to fully appreciate the sum of their constituent parts — a sum which now extends beyond any given physical location. This problem compounds exponentially as computers have been networked together into the vast and increasingly complex digital systems that define our modern lives, economies, and societies.
If senior government officials are saying this, one especially gets the signal that there is a problem. A problem which will only grow with the amount of third-party software which folks deploy on their computer networks.
Further complicating matters for practitioners of cyber supply chain risk management (‘C-SCRM’) is that malicious actors have moved to exploit the aforementioned complexity of cyber supply chains with greater frequency.
To set the scene, the European Union Agency for Cybersecurity (‘ENISA’) provides a helpful definition of a cyber supply chain attack:
A [cyber] supply chain attack is a combination of at least two attacks. The first attack is on a supplier that is then used to attack the target to gain access to its assets. The target can be the final customer or another supplier. Therefore, for an attack to be classified as a supply chain one, both the supplier and the customer have to be targets.
The at least two stages of a cyber supply chain attack are captured by Figure 1. The attacker would seek to jump first into the blue box (supplier) and then, from it, to the red box (customer).
Hitting the Code
Per Figure 1, cyber supply chain attacks include attacks against software supply chains.
That is, attacks:
… when an attacker accesses and modifies software in the complex software development supply chain to compromise a target farther down on the chain by inserting their own malicious code.
Figure 2 is an example of how a software supply chain attack can occur.
As the definition and Figure 2 suggest, the software development lifecycle is a target-rich environment. Threat actors can pick any of the design, distribution, support and decommissioning phases of software development to go after.
And the fruits of their nasty labours comprise launchpads for them to conduct further nastiness, depending on the level and persistence of the access to vendors’ and/or end users’ systems which they gain therefrom as well as things like the market penetration of the software the supply chain of which they compromise.
Little wonder software supply chain attacks are on the rise.
State actors have had some fun targeting software supply chains in just the last few years. In 2020, Russian intelligence poisoned the update channel for the pervasively deployed network monitoring software, SolarWinds Orion (hello, exploitation of market penetration), to conduct espionage on United States government and critical infrastructure systems. In 2021, the Russians again exploited trusted channels between technology service providers and their customers, namely the providers’ administrative or privileged access to their customers’ systems, to target the latter. And who can forget the full-blown carnival enjoyed by Chinese Ministry of State Security-affiliated actors who exploited zero-day vulnerabilities in Microsoft Exchange on-premises software to pwn ‘tens of thousands’ of servers running it worldwide?
Note that attackers generally have shown this tactic a lot of love of late. Sixteen of 24 well-known cyber supply chain attacks that occurred from January 2020 to early July 2021, and were given the fine-toothed comb treatment by ENISA, featured attackers going after the relevant vendors’ code en route to their customers.
It should come as no surprise that software supply chains have been under stress. Indeed, per one estimate, attacks against them more than tripled in 2021 versus 2020.
Another oft-cited example is the exploitation of a critical vulnerability in the widely used open source logging library, Log4j, by state actors like China and Iran, as well as criminals to launch ransomware attacks. The (potential) consequences of that bug alone were so grave that Director Easterly said this in the first 30 seconds of an interview:
… first off, I should say that the Log4j vulnerability is the most serious vulnerability that I’ve seen in my decades-long career.
It can be safe to assume that the Christmases of many members of Infosec were messed up by Log4j. And, come to think of it, the less said about the state of utterly ubiquitous open source software supply chains, as well as the risk mitigation practices of the multitude of entities serviced by those supply chains, the better.
And that’s before we get to the sorry state of software supply chains for industrial control systems that keep our heavy industry and critical infrastructure sectors functional.
[Sighs.]
Policy Responses to the Challenge
But fear not, governments have recognised the need to promote the resilience and security of cyber (including software) supply chains.
On the World Stage
Take the noises and promises made on the world stage.
One of the cyber norms, that the United Nations General Assembly (‘UNGA’) endorsed in 2015, called for states to ‘take reasonable steps to ensure the integrity of the supply chain so that end users can have confidence in the security of ICT [Information and Communications Technology] products’. In July 2021, the United Nations Group of Governmental Experts on Advancing Responsible State Behaviour in Cyberspace in the Context of International Security (which just rolls off the tongue) stressed the ‘need to promote end user confidence and trust in an ICT environment that is open, secure, stable, accessible and peaceful’.
And went as far as advising (rightly, in my humble opinion) that:
Ensuring the integrity of the ICT supply chain and the security of ICT products, and preventing the proliferation of malicious ICT tools and techniques and the use of harmful hidden functions are increasingly critical in that regard, as well as to international security, and digital and broader economic development.
In May 2022, the European Union and United States, during a meeting of their Trade and Technology Council (‘TTC’), pledged ‘to promote secure, resilient, competitive, transparent and sustainable and diverse digital, telecoms, and ICT infrastructure supply chains’. As part of that pledge, both parties acknowledged the need for them to perform ‘a rigorous and risk-based evaluation of equipment, software, and services suppliers…’ (emphasis added). They will execute that risk assessment via ‘a comprehensive and holistic view of global ICTS supply chains and sensitive and critical areas of ICTS networks’. Considering that this meeting happened about five months after Log4j, it was necessary, and thus encouraging, that the word, ‘software’, got into the joint statement.
Not to be outdone, the Quad countries — Australia, India, Japan and the United States — announced (just a week after the TTC meeting) that two of the foci for the Quad Cybersecurity Partnership are supply chain risk management and software security. Per the Joint Principles adopted under this partnership, the Quad have pledged to ‘work together to improve the security of the technology products and services on which our critical infrastructure provider[s] rely’, which would include the software supply chains servicing said providers. The four countries acknowledged their ‘unique position to align and ensure the implementation of baseline software security standards domestically and internationally’. In this vein, they devoted three paragraphs of the Joint Principles to their promise to leverage their governments’ collective purchasing power and coordinate execution of said standards to, in partnership with industry, uplift the hygiene of ‘the broader software development ecosystem’. Signalling their awareness of the issue, the four countries name-checked some baseline standards they wanted vendors and developers to implement:
improving vulnerability management and applying the latest patches, providing a software bill of materials, using multi-factor authentication, regularly backing up data, encrypting data, and rigorously auditing the security management system, as well as mechanisms for skills and competency verification of auditors.
It is good to see the progress which the Quad has made in their cooperation on cyber supply chain resilience as a pillar of their partnership to ‘foster an open, accessible, and secure technology ecosystem’, first announced in September last year.
It is also heartening to see software getting specific attention on the world stage, a change from its being overlooked by national security policymakers more broadly in favour of hardware supply chains like those for telecommunications networks.
Now, it is a matter of such cyber diplomacy delivering tangible results, both internationally in terms of more resilient cyber supply chains and domestically in terms of better national law and policy for C-SCRM.
At Home
It is thus marvellous that governments have cottoned on to the need to uplift C-SCRM via decent domestic law and policy.
The United States has certainly done some recent work in this department.
In the final days of the Trump Administration, it enacted a national security-focused screening regime for the ‘acquisition, importation, transfer, installation, dealing in, or use of any information and communications technology or service’. The Biden Administration has proposed to extend the aforementioned screening regime to apps that include ‘as an integral functionality, the ability to collect, process, or transmit data via the internet’. Presumably, this can be used by the state to do successfully what was attempted by President Trump in relation to TikTok and WeChat as part of an intervention in national C-SCRM on counterespionage grounds (which I analysed for my old podcast).
Besides, in February this year, the National Institute of Standards and Technology released guidance on software supply chain security under the auspices of the current President’s cybersecurity executive order.
Said guidance dropped a month after the White House hosted a summit on ‘Software Security’, with a focus on cleaning up open source software. The summit was attended by folks from across stakeholder groups, be it government, major technology vendors and the open source software community, with the Apache Software Foundation, Linux Foundation and Open Source Security Foundation on the guest list.
Pleasingly, the summit was followed by an announcement from the Open Source Security Foundation of the ‘Alpha-Omega Project’, which will deploy software security expertise to ‘the most critical open source projects’ and use automated tooling to find major bugs ‘across at least 10,000 widely-deployed open source projects’. This initiative is backed by an initial investment of US$5 million from Microsoft and Google.
Australia has also gotten in on the action.
In 2021, as part of The Action Plan for Critical Technologies, Australia has defined ‘systems, algorithms and hardware’ that enable C-SCRM as ‘critical technologies’, that is, ‘current and emerging technologies that have been identified as having a significant impact on our [Australia’s] national interest (economic prosperity, national security and social cohesion)’. It has published Critical Technology Supply Chain Principles to, among other things, enable better mapping of cyber supply chains.
Under its International Cyber and Critical Technology Engagement Strategy, Australia is working to ‘promote cyber and critical technology capabilities that can strengthen supply chain resilience and sustainability’ as well as ‘encourage increased diversity in critical technology markets and supply chains’, all in partnership with industry.
As part of recent reforms to Australia’s critical infrastructure legislation, section 30ANA(2)(e) of the Security of Critical Infrastructure Act 2018 (Cth) (‘the Act’) empowers the Commonwealth Minister for Home Affairs to direct the operators of critical infrastructure assets to implement (part of) the Australian Signals Directorate’s guidance on C-SCRM as part of all-hazards risk management programs that are required by part 2A of the Act. (Said agency is Australia’s signals intelligence and offensive cyber operations agency, and home to the Australian Cyber Security Centre.) Australia also proposes to specifically require said operators to manage supply chain hazards.
Like Australia, Canada proposes to enact explicit C-SCRM obligations for operators of critical infrastructure assets. This is backed up by how one of the purposes of the proposed Canadian Critical Cyber Systems Protection Act is to ensure that ‘any cyber security risks… [faced by said operators] are identified and managed, including risks associated with supply chains and the use of third-party products and services’ (emphasis added).
The Need for Governments to Keep at it Collaboratively
Governments need to continue this trend of increased (regulatory) scrutiny of the labyrinth, which is constituted by cyber supply chains, in partnership with industry as well as allies and partners.
Partnering with industry is necessary by design because industry both largely populates our international cyber supply chains and is serviced by the latter in the process of providing the essential services that our societies depend on. Industry is the frontline stakeholder which will be responsible for implementing regulatory obligations and policies, as well as adapting their practices amid a complex threat environment which is in flux (as above).
Partnering with allies and partners is necessary by design because coordination of regulatory approaches and standards for C-SCRM will limit regulatory arbitrage by industry and reinforce incentives for vendors and manufacturers to implement security-by-design principles for their products, as suggested by the Quad above. This is combined with how, as Director Easterly warned, we all share cyber supply chains and are thus affected, regardless of our geographical location, by the:
- exploitation of vulnerabilities in widely used software (seen with the NotPetya attack and the Microsoft Exchange attack); and
- actual breaches of cyber resilience of major service providers (seen with the Kaseya attack and 2021 Akamai outage).
The OECD Council recognised the following in relation to critical infrastructure, but I reckon the observation is applicable to cyber risk management more generally:
… the multiplicity and complexity of digital dependencies across sectors and borders and along critical activities’ value chains create a shared digital security risk that no single actor can significantly reduce for all; that each actor is therefore dependent upon and responsible towards all others to manage digital security risk;
The sheer size of our collective attack surface borne from shared cyber supply chains demands a collective response, reflective of how ‘cybersecurity will forever be a shared responsibility’.
The criticality of which expands with that of cyberspace to the functioning of our economies and societies.
And with that of our pursuit of lucidity in the labyrinth.
