NERC’s Supply Chain Webinar: Good, but I still have Questions

I eagerly awaited NERC’s Supply Chain webinar yesterday. I found it was a good webinar on supply chain security, although the CIP-013 discussion raised more questions in my mind than it answered.

To start with the good news, I thought two of the presentations, by my friends Corey Sellers of Southern Companies and Joe Doetzl of ABB, were excellent – and I’m looking forward to seeing the slides for their presentations, as well as those of the other speakers, including Tobias Whitney of NERC. Corey, who is head of the team that drafted CIP-013 and guided it – with help from others, of course - through the shoals of four NERC ballots to deliver it to FERC in time to meet their one-year deadline, spoke mainly about the CIP-013 guidance document that the North American Transmission Forum (NATF) is putting together. This sounds like an excellent document, although Corey pointed out that it’s mainly focused on best practices for supply chain security, not CIP-013 compliance per se.

Joe Doetzl, who was with KCPL for many years and was an important part of the CSO706 drafting team as they drafted CIP versions 2, 3, 4 and the beginning of v5, gave a really excellent presentation on what you (i.e. a NERC entity) should expect from your software vendors (his slides had much more information than he could get through in his presentation, so I’m especially looking forward to seeing those).

Now to the not-so-good news (although I’ll say upfront that this isn’t bad news): I still have a few fundamental questions about how entities should comply with CIP-013, and these weren’t answered. Or if they were answered, the answers seem at odds with what is written in the requirements. Here’s what I mean:

1. My biggest question is what should be in the supply chain cyber security risk management plan, which is of course required by CIP-013 R1. In the presentations by Tobias and Corey, they focused exclusively (as far as I could see) on the six items that are required by R1.2. The implication is that these are the only things that must be in the plan. 
2. As I have pointed out in several posts (at least), CIP-013 R1.1 requires the entity to “identify and assess[i] cyber security risks to the Bulk Electric System” resulting from a) procuring vendor equipment and software, b) installing vendor equipment and software, and c) transitions from one vendor to another. The six items in R1.2 all have to do with a), not with b) or c). And even for a), there are clearly many more risks to be addressed than the risks underlying the six items in R1.2. For example, how about the risk that a vendor won’t follow good security practices for their own network, and will experience a breach where information on your software and how it is configured is stolen? This has happened with at least one SCADA vendor in North America in the past four or five years.
3. So is the entity required to identify and assess other risks than the risks behind the items in R1.2? I’m sure Tobias and Corey would answer this question in the affirmative, but then the question becomes “Given that there are a huge number of supply chain security risks – some with extremely small impact or probability – that could be identified, how many does the entity have to identify? Is it a certain number like 10 or 20? Or is it something like “all risks with high impact and probability”? And if that’s the case, who will determine which risks meet that description? The auditor? The entity? Someone else?
4. CIP-013 R1 is one of a category of what I call “plan-based requirements” which seem to have found favor with the CIP drafting teams in the last few years, as the only type of CIP requirement they should consider drafting. I am all for that, since I think – as do a lot of others – that the alternative - prescriptive requirements like CIP-007 R2 - just doesn’t work for cyber security, period. But, as I pointed out in this post (and a few subsequent ones), the only way I can see a plan-based requirement being successfully audited under NERC’s auditing procedures is to have criteria for what should be in the plan in the requirement itself. My best example of this is CIP-010 R4, where Attachment 1 (which is called out in R4, and is thus part of the requirement) provides a very detailed list of items that should be addressed in the plan for Transient Cyber Assets and Removable Media – e.g. software vulnerability mitigation, malicious code mitigation, etc. When reviewing an entity’s CIP-010 R4 plan, the auditor can fairly easily go through this list and determine whether the entity has addressed (and meaningfully addressed) each item on the list. Unfortunately, no such list is to be found in CIP-013-1 R1.
5. My second question is about the meaning of “mitigation” of risks (as I pointed out in the first end note below, this word was left out of R1, but clearly is meant to be in there). As far as I could see, both Tobias and Corey were only considering vendor contract language as a mitigation means for the six risks implied in R1.2. Yet, as I’ve pointed out in two recent posts (this one and this one), contract language is only one means of risk mitigation, and IMHO it isn’t anywhere near the best one.
6. But suppose you follow Tobias and Corey (and I’ll readily admit that both Order 829 and the NERC Implementation Guidance for CIP-013 take the same position as these two gentlemen) and first try to get your vendors to accept contract language for the six items in R1.2. And suppose a few of them absolutely refuse to insert the language you ask them to include. Furthermore, suppose these few vendors are absolutely critical to your organization, and it would be very disruptive and costly to try to replace their product with a competitor’s. What do you do then? Do you not have to do anything more to mitigate[ii] the risk?
7. To answer this question, look at the title of CIP-013: “Cyber Security – Supply Chain Risk Management” (my emphasis). You are supposed to manage each risk, not simply try one particular mitigation strategy and then give up if that fails. In this post, an auditor described an alternative strategy – and of course it’s one of many alternatives – that an entity could use if the vendor refuses to provide prompt notice of employees who either leave the company or no longer need access. In my opinion (and the auditor agrees with me), you need to be prepared to try multiple approaches to mitigating each risk that you identify.

However, I’m not waving a red flag yet. CIP-013 hasn’t even been approved by FERC, so there is still some time to address these questions[iii]. But – again, in my opinion – these two questions need to be addressed as soon as possible, since the entities will need to know the answers to both of them before they start developing their plans.

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. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] As I pointed out in this post, it seems an important word was left out here: mitigate. Your plan must describe how you will identify and assess risks, but the plan doesn’t have to say a word about what you will do about those risks! And since R2 just requires implementation of the plan, mitigation doesn’t automatically come in there, either. Of course, all of the other documents related to CIP-013, including FERC’s Order 829 and the NERC Implementation Guidance, make it abundantly clear that mitigation of these risks is the purpose of the standard – so I don’t recommend that you decide to stonewall it and only include identification and assessment of risks in your plan! But this does need to be fixed at some point. Assuming FERC orders some changes to CIP-013-1, as their NOPR strongly hinted they would, this should be included in the SAR for CIP-013-2.

[ii] Tobias seemed to strongly indicate this was the case, when he talked about what to do if a vendor won’t provide a means to authenticate identity and integrity of vendor-supplied software and patches. He didn’t talk about anything else you could do to mitigate the risk of a bad actor inserting malware into a patch, when there are clearly other things you could do (ask to download the patch from a secure FTP site, ask the vendor to burn the patch on a CD and overnight it to you, etc). BTW, I wasn’t able to ask a question about this because it was announced at the beginning of the webinar that there wouldn’t be time for questions from the online webinar audience.

[iii] Although the fact that FERC wants to shorten the implementation time for CIP-013 from 18 to 12 months, and that I believe they’ll approve the standard in Q2, means there isn’t much time remaining.