There’s a third type of risk!

Note from Tom: If you’re only looking for today’s pandemic post, please go to my Pandemic Blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

A longtime friend wrote to me today to point out something he thought might be a product risk, not a supplier/vendor risk, based on my Monday and Tuesday posts. I was able to convince him it wasn’t a product risk, but I also had to admit it wasn’t a supplier/vendor risk either. There’s a third type of risk that I was leaving out of this discussion, but which is very much relevant to it – as I now realize.

My friend’s idea was that there are some products that users are prone to misconfigure, which can leave a system subject to cyber attacks. As an example, he brought up the attack that was reported on an OE-417 form last March, which was the first reported successful cyberattack on the US Bulk Electric System. There were two problems that led to that attack:

The first problem is that the attackers exploited a vulnerability in Cisco’s IOS that had been patched by Cisco – however, the organization that was attacked hadn’t applied the patch yet. As I pointed out in Monday’s post, if a vulnerability appears in a product and the supplier doesn’t either issue a patch for it or – if for some reason they can’t patch it immediately – let their customers know about it and provide help in mitigating it, this is a supplier risk (in fact, it’s the risk addressed by CIP-013-1 R1.2.4). But Cisco did issue a patch, so it was mitigated by them – yet a patch never does you any good unless you apply it! So apply it (and you can quote me on that one).

The second problem was that the router’s web interface was connected to the public internet (no doubt to make somebody’s job a little easier…), which as we know should never be done. In fact, my friend believes the attack probably wouldn’t have been successful if this hadn’t been done.

Of course, this isn’t Cisco’s risk. This is just good security practice for control systems in general – they should never be directly connected to the internet. This isn’t a product risk, but of course it also isn’t a supplier risk. In Monday’s post I didn’t mention any other type of supply chain cybersecurity risk, but there is one: risks posed by the end user organization itself.

The biggest category of organization risks is insecure installation: The product has all the needed security capabilities, but the organization doesn’t make sure it is installed securely and it ends up being exploited. The mitigation for this risk is of course training for people doing installations, although one of my clients suggested “peer reviews” that their people do for each other, to confirm their work. I’m sure there are other mitigations as well. Of course, installation risks are covered by CIP-013 since they’re mentioned explicitly in R1.1.

So I continue to believe there are no true product risks, but I was wrong in saying that there is only one alternative: supplier/vendor risks. There are also risks due to the organization purchasing the product. These have to be mitigated just as much as supplier/vendor risks do – and of course they’re a lot easier to mitigate, since I have yet to identify one that required more than implementing a policy, procedure or training to mitigate. Of the 100 or so important supply chain cybersecurity risks that I and my clients have identified, around 15 or 20 of them are risks due to the NERC entity itself.

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. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!