The new administration gets it: Software is where the risks are!

Christian Vasquez of E&E News published on Monday a very good article that reviewed Anne Neuberger’s keynote address for the SANS (virtual) ICS Summit last Friday. In it, she said, according to the article, that “Biden is planning to unveil an executive action that aims at ‘building standards for software, particularly software that's used in critical areas.’”

I was quite happy when I read that (I hadn’t attended her keynote for the Summit on Friday). It’s been clear to me for quite a while that the real supply chain security risks – for any industry – are in software (in fact, Robert M. Lee said exactly this in his keynote to the Summit on Thursday). In fact, I know of no true hardware supply chain attack ever (and I’m not talking about an attack on firmware, as in the Mirai botnet. Firmware is just software installed on a different medium, and mitigating firmware risk is a lot like mitigating “regular” software risk) – that is, one in which the attackers altered the microcode in a processor.

I’m certainly not saying that there could never be a hardware supply chain attack, but we need to look at the record. On the software side, you have SolarWinds, Equifax, Delta Airlines and other very successful software supply chain attacks. And on the hardware side you have…rumors that the NSA might be altering microcode in network devices being sent to some foreign countries. On which side should you allocate your scarce time and money resources?

Ms. Neuberger mentioned two different concerns that the new order will address. The first is “in response to the massive Russian-linked espionage campaign that has affected nine agencies and around 100 organizations by exploiting a commonly used software product from Austin-based SolarWinds.” Unfortunately, that’s all the information she gave on this topic.

Here's what I’m hoping the EO will do regarding software supply chain security: Scrutinize the controls the supplier has on their software development environment. The appalling thing about SolarWinds is that the Russians penetrated the SolarWinds development network (they were presumably already in the IT network) in September 2019. As documented in a great article by Crowdstrike, they had free rein in that network, and were able to first plant “proof of concept” code (i.e. a non-malicious version of Sunburst) in two or three updates for the flagship Orion product.

Having demonstrated that they could do that undetected, they went on to build Sunspot, perhaps the most sophisticated malware since Stuxnet - or even more sophisticated that the latter - and installed it in the build network to guide the rest of the effort. In March 2020, Sunspot started planting Sunburst in Orion builds. This continued until June, by which time Sunburst was in about seven Orion updates that had been provided to customers. In June, the Russians decided the fun was over, covered their traces and pulled out.

But they didn’t do this because they’d been detected or feared being detected – they did it because they already had been so successful that they knew they weren’t ever going to be able to exploit more than a fraction of the 18,000 organizations that had downloaded a version of Orion containing Sunburst (it seems they actually used Sunburst to attack about 100 organizations). And indeed, SolarWinds never detected them. The world might never have known about Sunburst if some observant person at FireEye hadn’t noticed that an unauthorized device had been added to an account.

Clearly, SolarWinds dropped the ball on this, and there’s no reason to believe they won’t continue to drop the ball from now on. They – and a number of their peers, including the cloud providers – need to be regulated just like any other critical infrastructure. Because that’s what they are.

The other concern Ms. Neuberger mentioned was the need for monitoring of OT networks. Here, the example was the Florida water system that was compromised. The compromise wasn’t discovered by any sort of monitoring system, but only because an operator noticed his cursor was moving on the screen, even though his mouse wasn’t. This is another problem, but it’s probably much easier to solve than the first one.

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.