How deep do you need to go for CIP-013?

 If you're looking for my pandemic posts, go here.

Last Thursday, Fortress Information Security sponsored an excellent two-hour webinar titled “Exploring Opportunities to Secure the Grid's Supply Chain” . You can download the slides here, but I really recommend you listen to the recording, since there was a lot of great discussion that went far beyond what was in the slides. You can access the recording here.

The webinar featured a very well-chosen group of speakers who I wouldn’t normally expect to present in the same webinar – yet it worked very well. They included speakers from Fortress (Tobias Whitney, formerly of NERC of course), Lew Folkerth of RF (sporting an enhanced beard, which looked great. It seems that sheltering in place has served Lew well), Jeff Sweet of AEP, Val Agnew from NATF, and three speakers from Israel. Two of these were Yosi Scheck of Israel Electric Corporation (which serves the entire country) and Aviram Atzaba of the Israel National Cyber Directorate.

All of the presentations were good, although the presentation by Aviram Atzaba really stood out for me because it addressed supply chain cyber risks explicitly, and discussed (at a high level) four supply chain cyber attacks that Israel Electric has experienced (and it sounds like there have been others as well). I would like to do a post soon on some of the interesting things I learned in the webinar, but first I need to listen to the recording, since I couldn’t write things down fast enough.

However, I do want to discuss a question that both Tobias and Lew addressed, although Lew deliberately went beyond the question to address a larger issue. Since this question is quite relevant to CIP-013, and since somebody recently told me that the compliance date for CIP-013 is coming up 😊 (is it November 3? No, that’s another important date), I want to discuss it now.

The question (and I didn’t write the words down, so this is just a recap of what I believe was the thought behind it) was “When a large supplier uses a dealer channel, they will usually not answer a questionnaire, although the dealer will. Does this mean we just need to assess the dealer, not the supplier itself?”

Tobias read the question and answered it by saying something to the effect of “You need to assess the risks that can have an impact on the Bulk Electric System, whether they originate with the supplier or the dealer.” Tobias’ answer was exactly correct, IMHO. However, since he didn’t have time to elaborate on that statement, I will do that for him here:

Let’s say we’re talking about Cisco™. They don’t sell directly to any NERC entity that I know of; they almost always use an intermediary, who at most just inventories Cisco products and reships those to end users, then invoices the end user (sometimes they don’t even touch the box – they have it drop shipped directly from Cisco to the end user). I call the dealer a vendor, as discussed in this post.

What risks apply to the supplier vs. the vendor? Of course, when the supplier and the vendor are the same organization (which of course is the case with all but the largest suppliers, like Cisco and Microsoft™), all of the risks apply to that organization. But when they are different as in this case, there are very few risks that apply to just the vendor – in fact, I have only identified two that I consider significant, one being that a vendor will ship you a counterfeit product, as has happened in at least two cases with Cisco products (including one very recently).

However, while the counterfeit product would be annoying, it wouldn’t in itself pose a risk to the BES (as opposed to a financial and operational risk to the utility that bought it, which is definitely the case). What would pose a BES risk would be if the counterfeit contained malware (which has not been the case with the Cisco knock-offs so far). So the risk is that a vendor will ship you a counterfeit product that contains malware, which could damage the BES if installed.

On the other hand, there are a huge number of risks that apply to the product supplier. For example, there are the risks included in CIP-013-1 R1.2.1, R1.2.2, R1.2.4, and R1.2.5, as well as a host of other risks, such as the risks behind almost all of the 60 NATF criteria (the few risks having to do with secure product shipment are the only criteria that could possibly apply to a pure product vendor – i.e. one that doesn’t also provide services for BES Cyber Systems. If the product vendor also provides services, they would be both a service vendor and a product vendor in my way of seeing things. This means the risks that apply to service vendors, as well as those that apply to product vendors, would apply to the same organization.

In other words, if you just send a questionnaire to the product vendor, you will only be assessing a small portion of the total risks that apply to the supplier and vendor. But if the supplier won’t answer your questionnaire, how do you assess them?

I’m glad you asked. There are a number ways, including looking at various publicly available sources of information (Fortress offers a service that does this, which was mentioned by Jeff Sweet in his presentation) and reading documents on their web site (in particular, Cisco has at least a couple documents discussing their secure development and vulnerability management processes). It’s true that neither of these methods will yield you the same information that a questionnaire would, but the point is they’re better than not doing anything to assess the supplier.

After Tobias gave his answer (which was a little shorter than the one I just gave), he turned the question over to Lew. Lew said he wanted to table the question until the end of the webcast. When he came back to answer it in the end, he expanded it to be part of the more general question that’s been asked by many people about CIP-013: We all know that CIP-013 applies to your organization’s immediate suppliers, but what out those suppliers’ suppliers? And even the suppliers’ suppliers’ suppliers? Where do you cut it off?

And like Tobias, Lew’s answer was very simple (although I’m just paraphrasing it): Your CIP-013 R1 supply chain cybersecurity risk management plan needs to describe how your organization will mitigate supply chain cybersecurity risks to the BES. Let me elaborate on what Lew said, since after all this is my blog and I can say what I want:

I think it’s perfectly acceptable to say that your R1 plan must describe how you will mitigate only important supply chain cybersecurity risks. This means that you don’t need to mitigate all risks down to say the 99^th level. In practice, the likelihood that a risk applies to a supplier that’s four levels down from your immediate supplier makes it fairly unlikely there will be an impact on the BES if the risk is realized.

Let’s say that fourth-level supplier didn’t have strong access controls on its remote access system, leaving it open to compromise by the Russians – and DHS said in 2018 that the Russians penetrated over 200 vendors to the power industry, primarily through their remote access systems. While it might be possible that the Russians penetrated the supplier’s software development network and implanted a backdoor in a software module that was incorporated into a product that was itself incorporated into another supplier’s product that was itself incorporated into the software product you bought, it’s quite unlikely that the Russians will now use that backdoor to penetrate your BES Cyber System and attack the BES. Given this low likelihood, you would certainly be justified in ignoring this risk.

But what if your software supplier included a component from a second-level supplier that included the IP library from Treck that is subject to the Ripple 20 vulnerability? That might be something that could affect your BCS and therefore the BES. So you probably need to think about risks due to second-level suppliers, although first you have to know who they are, which is why getting a software bill of materials is a good first step.

However, your first line of defense against risks in the second, third, fourth, fifth, etc. levels of software suppliers is your supplier itself – i.e. the organization that wrote the software you’re using. What you need to be concerned about is their supply chain cybersecurity risk management plan. For example, does your supplier require their component suppliers to notify them of unpatched vulnerabilities in their software, and hopefully quickly develop patches for them? And if the component supplier can’t immediately patch a vulnerability in their product, will they tell your supplier about measures your supplier can apply to mitigate this vulnerability?

So my answer to the question Lew posed (and answered) is that a) you need to address risks that you believe have something more than a low likelihood of being realized, whether they pertain to your supplier or one of the supplier’s supplier’s supplier’s…suppliers…Yea verily, unto the hundredth generation. And b) your best defense against risks in those further generations is your supplier’s own policies regarding their suppliers.

 

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 wondering if you’ve forgotten something for the 10/1 deadline for CIP-013 compliance? This post describes three important tasks you need to make sure you address. I’ll be glad to discuss this with you as well – just email me and we’ll set up a time to talk.