Another day, another supply chain attack?

This morning, the Wall Street Journal published an article – which fortunately seems to be freely available here – saying that UK government agencies are investigating whether a trading disruption at the London Stock Exchange in August may have been caused by a cyberattack. The disruption was indisputably caused by a problem in the configuration of the exchange’s software, perhaps after an upgrade had been applied. The problem delayed the opening of the exchange for 1 ½ hours, and was the worst outage the exchange has suffered in eight years.

Of course, many people might wonder why this is being called a cyberattack, since it was related to a software upgrade. Upgrades go bad all the time, and nobody considers them to be a cyberattack (indeed, the exchange’s initial report on the incident made no mention of an attack). There is evidently some evidence that leads to the idea that the code may have been tampered with while it was being developed – and the article says specifically that the U.K.’s Government Communications Headquarters (which monitors critical national infrastructure) is examining time stamps in the code, presumably because there’s some anomaly with them.

The WSJ isn’t saying this is a cyberattack, and I’m certainly not saying so, either. But this is another good indicator that the risk that a bad actor will penetrate a software developer and plant malware in the code, as happened with Delta Airlines in 2018 and Juniper Networks in 2015 (an attack that was enabled by a flawed encryption algorithm, perhaps implemented due to pressure from the NSA, just to thicken the plot a little more), isn't negligible.

As you develop your supply chain cyber security risk management plan for CIP-013 compliance (or if you develop it just because it’s a good idea, if you don’t have to comply with CIP-013), keep in mind that this is a risk you should consider for mitigation. Of course, it would be vast overkill to require a code review of all software you acquire, as a way of mitigating this risk. But it’s certainly not out of the question to include one or two questions about the security of a supplier’s software (or firmware) development lifecycle, when you assess them using a questionnaire or other means. If you find out their development lifecycle leaves something to be desired as far as cybersecurity goes, you can make the decision whether to stop buying from them, or you can try to persuade them - through means such as contract language or meetings with their management - to improve in this regard.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.