For our security's sake, don't regulate out the innovation in our supply chain

When the log4shell vulnerability was found in log4j in December 2021, Surevine immediately started systematically assessing the impact of it.

We’re relatively small, many orders of magnitude smaller than some of the defence prime contractors we partner with, but we’ve delivered hundreds of projects which serve tens of thousands of live users. We count amongst our clients some of the most security conscious organisations on the planet. We have delivered solutions for them which are critical to our national security, and that of our allies.

It was straightforward for us to identify those systems which we had developed which used log4j directly, but we also needed to understand which third-party components (whether open source or proprietary) we had integrated with used log4j. We needed to understand what our software was “made of”; our software supply chain, if you like. It is, incidentally, in helping determine the answer to that, that SBOMs (or Software Bills of Material) might help.

For those systems which were still under development or which we were under contract to support, we knew the environment they were being deployed into, had representative reference environments, so we were able to say clearly whether the vulnerability was exploitable or not, and what was required to either patch or mitigate. In other circumstances, we were no longer under contract: another vendor, or the client themselves, might have been responsible for ongoing maintenance and support. We no longer had up to date information on the environment into which it was deployed, or how the IP had developed since our engagement.  Where we could, we reached out to our clients and notified them of our findings and our recommendations.

At around the same time, a number of clients began asking us for information about how we were impacted by log4shell. This was almost entirely ad hoc, if not chaotic. From the way the question was phrased, to the way in which it was communicated (usually by direct e-mail). We were pro-active, and informed some clients who we were not under contract with, and somewhat more surprisingly, we were sent requests from former clients, who we were no longer under contract with.

I wonder if someone has tried to estimate the cost of the log4shell vulnerability which takes into consideration the time and energy consumed in reading, reviewing and responding to information requests. It was not insignificant for a small business like Surevine, and the costs were, for the most part, borne by us, and there is an important point to consider about liability and software warranty here: how do we price in the costs of patching as-yet-unknown vulnerabilities if software warranties become more onerous, and how do we ensure that this doesn’t price startups and scaleups out of the market?

Imagine now that you are the CISO of a large, extremely complex organisation and had to try and answer that same question: “How are you affected by log4shell?”

We were engaged by the CISO of a UK Central Government Department to help them to answer just this type of question. That Department has several distinct portfolios, has maybe 1000 people working in its IT department and has dozens of arms-length bodies, answerable to the Secretary of State. Some of those act as wholly separate businesses with their own CEO, their own IT infrastructure. So imagine how hard it is when they are asked (as they were) by Cabinet Office how they are affected by something like the log4shell vulnerability (or more recently, the Crowdstrike incident). Just one part of that organisation might have 1000s of IT systems.  And not only that, the software in those systems has been developed by a supply chain consisting of many more suppliers, including Surevine. In order to build a complete picture, key industry suppliers of critical systems will need to be consulted too (as we were for log4shell).

Hand on heart, most CISOs of even moderately complex organisations will still not have been able to fully (or possibly even adequately) answer the question about how they were affected by log4shell.

The problem is compounded but the fact that not only the organisation, but sub-entities might be directly asked to report on the same vulnerability by different authorities.

It’s important, of course, for an organisation to attempt to have as accurate an understanding of the assets they have, but for most, that goal is always a counsel of perfection, which is just out of reach. A complex organisation is undergoing frequent change: divesting business units, engaged in mergers and acquisitions or corporate restructures which can often take years to fully integrate. This is perhaps even more likely for a central government department that is as subject to changing political priorities as the private sector organisation is to market forces.

We were engaged by the CISO of that Government Department to help fill in the missing gap, to be able to manage the response to the “how are we affected by…” types of question, so that the organisation can rapidly focus its energies in those parts of the extended organisation most impacted by a vulnerability.

I wonder how the economics play out for our adversaries? Perhaps the longevity of their capabilities is less important if the pay-off for an exploit is sufficiently rewarding. Perhaps the need to track and patch vulnerabilities in systems used to conduct cyber crime is less critical. This gives them an advantage in time-to-market over those of us who are building systems which form part of our critical national infrastructure, support our economic wellbeing or are integral to our national security, which our adversaries are trying to exploit or disrupt.

As the US moves forward with the rollout of CMMC and the EU the NIS2 Directive, it is imperative that those who are responsible for developing policies, guidelines or regulations for software-intensive systems have the broadest understanding of the costs and benefits, so we don’t end up as victims of unintended consequences, to the detriment of our collective security.

Are you still going to be able to foster a market of small, agile, suppliers like Surevine, who are relied on for ability to innovate at a pace, if they simply don’t have the effort available to to incur the costs implied by cumbersome governance frameworks.

We should be imposing costs on our adversaries, and reducing those on our partners and allies. We need to ensure that the agility that our adversaries enjoy doesn’t become their exclusive domain, rather we deny them that benefit, and jealously defend it as the way we keep a step ahead.

This blog post summarises the text of a speech Stuart Murdoch made at the Cityforum Cyber Security Summit 2024 held in London on Thursday, 19th September 2024 joining a panel including Conrad Prince CB, Julie Johnson, Ollie Whitehouse, Sir David Omand GCB, David Mussington Ph.D. CISSP and Prof Alison Wakefield PhD CSyP FSyI