Further supply chain security lessons from SolarWinds

I’ve come to realize that there are a lot of supply chain cybersecurity lessons to be learned from the SolarWinds attack, beyond what I discussed in my post yesterday. Here are a few more. Note that two of these are risks from the list I’ve compiled with my clients for CIP-013 compliance purposes, but they’re very relevant in this context. Of course, you don’t need to be subject to CIP-013 compliance to use them!

First, you should contact your suppliers and find out if they run SolarWinds – and demand they disconnect it if they do.

Second, you should ask your supplier whether they have a configuration management system installed in their development environment. There’s no way to know for sure, but that might have caught the attack by the Russians in the first place.

Third, ask the supplier whether they have a process in place to investigate whether computer viruses or malware are present in any software or patches before providing such software or patches (note: this is one of the questions in the NATF questionnaire). Since the SUNBURST malware used by the Russians is based on a zero-day vulnerability, it wouldn’t have been picked up in SolarWinds’ case. On the other hand, if a supplier isn’t taking this step, their patches might have non-zero-day malware as well.    

Second, in an article titled “Hey, only as many as 18,000 customers installed backdoored software linked to US govt hacks”, The Register points out that there’s evidence that SolarWinds’ Office365 account “was hacked and its emails accessed, possibly leading to the dodgy downloads”. Of course, this isn’t proven, but it points to something that I’ve wondered about for a while: A software supplier’s development network(s) should be treated like an electric utility treats its Electronic Security Perimeter. It should be isolated from the IT networks, with no direct communication between systems on the two networks. Of course, separate authentication should be required for the two networks.

It sounds like that might not have been the case with SolarWinds, since otherwise a compromise of email and other office productivity systems would be dismissed out of hand as a possible cause of penetration of the development environment. My guess is a lot of other software suppliers may be in the same position. You definitely need to ask your suppliers questions about this (examples are in yesterday’s post).

You might wonder how much good it does to ask your supplier a question. I have two answers for that:

1.      It doesn’t do any good if you don’t follow up with the supplier whenever an answer indicates the likelihood of the risk being present is more than low. And you not only need to follow up with them, but you also need to try to get them to implement mitigation(s) for this risk.

2.      Remember that just the fact that you asked about a particular risk sends a message. For example, in item 2 above, that question sends the message: “Configuration management is very important. We are concerned that if you don’t manage configurations in your development environment, you might be penetrated by the Russians or some other malicious actors – just like SolarWinds was.”

3.      Even if the supplier doesn’t have config management but lies and says they do, right after they send you their answers to the questionnaire, the person filling it out might pick up the phone and say “Hey Joe. You remember that proposal for configuration management we’ve had on our desk for months? Let’s get it approved.” This will be a win for you, even though you will probably never know it happened. 

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.