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