Tuesday, June 30, 2020

More on “product” risks



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.

Today I received a call from a friend I’ve known for a while, an engineer with a major supplier of electronic devices to the electric power industry. The call was about yesterday’s post, in which I explained why I didn’t think there was such a thing as a product risk – just supplier risks that can be realized in their products (although I didn’t use exactly those words).

He brought up to me two cases having to do with third-party software that this supplier either incorporates into its products or provides with them. In both cases the third-party products contained unpatched vulnerabilities; he was wondering if these might be examples of true product risks.

The first case was in a protocol stack that the supplier licenses from a third party. It seems there were a few unpatched vulnerabilities in the software. Because the supplier hadn’t implemented the parts of the stack that included those vulnerabilities, they felt they had no obligation to try to incorporate their own mitigations for those vulnerabilities; moreover, they weren’t obligated to inform their customers of them. Did this situation constitute a product risk?

The second case was of a particular piece of third-party software that the supplier provided to their customers to use for collaboration with the supplier (so it wasn’t incorporated into one of their products, as in the first case). There was a vulnerability in this software that might have allowed an insider to gain control and do bad things. Despite this vulnerability, the supplier felt this product was still worth using, and they made a point of telling their customers about the vulnerability and how to mitigate it. Was this a product risk?

As we discussed these two cases, I pointed out the difference between a vulnerability and a risk (in my way of thinking, of course). Software and firmware vulnerabilities occur all the time, but in my opinion they don’t constitute an actual risk unless the supplier a) doesn’t develop a patch in a timely manner, and b) doesn’t inform their customers and work with them to mitigate those vulnerabilities (until a patch is developed, which is of course the best mitigation for a vulnerability).  

In both of these cases, there is a risk, but it’s a supplier risk. In the first case, the risk is that a vulnerability in third party software – which is incorporated into a product that the supplier sells for use with BES Cyber Systems – won’t be patched by the supplier (although in most cases the third party would have to develop the patch, and the supplier would just need to apply it or distribute it, e.g. in a new version of a software library). But I pointed out that, since the supplier wasn’t using the portions of the third party code that contained the vulnerabilities, that code wasn’t part of their product at all – and therefore this risk doesn’t even apply in this case.

In the second case, the risk is that a supplier will distribute third-party software that has an unpatched vulnerability that they know about but can’t patch (in this case, it’s because this software wasn’t part of one of their products – so they have no access to the code to develop a patch. And the third-party supplier wasn’t providing their own patch, for some reason), yet they also don’t inform their customers of the vulnerability, or how to mitigate it. Had this supplier not informed their customers of this vulnerability, it would have posed a serious risk for their customers. But of course this supplier did tell their customers and did suggest mitigating steps they could take.

So was there a product risk in either case? In the first case there was no risk at all, since the vulnerabilities were in code that wasn’t incorporated in the supplier’s products. In the second case, there was a risk, but it was a supplier risk, not a product risk. And this supplier mitigated the risk as they should have done.

So I continue to believe there are no product risks, just supplier or vendor risks. But I could be wrong – I’d love to hear if you have any counterexamples.


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!



No comments:

Post a Comment