Supplier vs. Product Risks

Ever since I started working on supply chain security issues, I have been having a debate with myself and with other people about a fundamental question: Are there product risks that are distinct from supplier risks, or is every product risk at heart a supplier risk? Another way of wording that is “Does a product have risks that are independent of the supplier that designed and built (or coded) it?”

Before I continue, I want to point out that there’s another position on this issue: Some people argue that there are no supplier risks at all, just product risks. These people say – and this was my position early on – that, since the way the supplier “touches” you is through their product, all of the risks can be attributed to the product. If you only buy one product from the supplier and you never will buy any other (plus the design of this product never changes), I might agree with this position.

Someone yesterday took that position with me, and I quickly emailed them three risks that I’ve identified for CIP-013 compliance, which would require a huge stretch of logic to identify as pure product risks:

• The supplier won't patch a new vulnerability right away, and they also won't tell their customers about it.
• The supplier will be purchased by a hostile foreign power and their customers won't be told about it.
• The supplier will suddenly go out of business, leaving their customers with systems they can't immediately replace, but which won't have patches anymore.

My friend changed his position immediately after seeing these, so I’m going to ignore this possibility going forward.

After advocating the above position, I then switched to the opposite position: that all supply chain security risks – other than those that apply to the customer itself – apply to the supplier or vendor of the product (and the majority of risks apply to the supplier not the vendor, although there are a lot of risks that can apply both to suppliers and to vendors), not to the product.

My reasoning for saying this was fairly simple: The primary mitigation for a product risk is always the supplier (except in the case of open source software, where the online community usually supports the product, but the responsibility for making sure vulnerabilities are fixed rests with the user). If the supplier doesn’t do what they should or they move too slowly, then the user needs to take its own steps to mitigate the risk. But the primary mitigation for any product risk is always something the supplier has to do (usually a policy or procedure they need to put in place), not the user.

From a theoretical point of view, I think this argument is unassailable (although if someone disagrees, please let me know why!). However, it makes the risk management process cumbersome when the supplier makes multiple products, yet a risk applies to some but not all of those products. If for no other reason than paperwork reduction, it helps to think of risks like that as applying to the product, not the supplier.

Here's an example of what I have in mind: the risk that a product will allow users to install firmware updates without authentication. You may know that this risk played an important role in the first Ukraine attacks of 2015. Of course, the primary mitigation for this risk is making sure that all hardware products that are components of BES Cyber Systems are designed to require authentication before any firmware update can be installed.

But even if you were to convince the supplier to implement authentication tomorrow in all new products, it’s unlikely they’ll redesign their existing products to require authentication for firmware updates. This means that at least some of the products they’re currently selling won’t require authentication, until all of those products are discontinued. Since you will want to put in place some mitigation for this risk, such as restricting physical access to the product (which may already be in place, if you’re compliant with CIP-006), this means you have to track product risks in some way.

However, it’s important to distinguish between a product risk and a product feature. Let’s say you’re considering buying a hardware product that doesn’t support special characters in passwords – i.e. they support upper- and lower-case letters as well as numerals, but you can’t go beyond those in constructing complex passwords. Is this a risk?

No it isn’t. This is a feature that you should certainly ask about in a questionnaire to the supplier – just like you ask about other features like voltage required, size and weight, etc. Like all features, it’s something you’ll consider when you decide whether or not to purchase this product, but as I pointed out in a recent post, purchase decisions are seldom (if ever) made on the basis of a risk assessment alone, at least not for components of BES Cyber Systems.

Risk assessment comes into play once the purchase decision has been made. At this point, the fact that the product doesn’t support special characters might or might not indicate a risk. If you were purchasing the product for a low-security application, you might decide that the password complexity afforded by having lower- and upper-case letters, and also numerals, is sufficient for your needs.

On the other hand, you might decide you really do need more security than what comes in the box. Since the purchase decision has already been made (and the supplier hasn’t offered to redesign the product for you), the fact that required password complexity is limited might constitute a risk that needs to be mitigated in some other way – perhaps by limiting access to the system only to people who are onsite within your PSP. It’s only at this point that the feature (or more specifically, the lack of a feature) becomes a risk.

I will soon have a follow up to this post, addressing a related issue about the Executive Order.

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!