EEI’s second try at procurement language

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.

Last fall, I wrote a post that pointed out something I’d recently realized: In contrast to the other CIP standards, the risk-based approach of CIP-013 provides the NERC entity complete freedom to do something they would have a hard time doing while complying with the other CIP standards – waste money.

I said this because the requirements in the other CIP standards are almost all prescriptive – they tell you what to do; you have to do it, period. There’s officially no consideration of what you have to spend to comply with the requirement. You need to spend whatever time and money is required for your organization to comply.

On the other hand, CIP-013 doesn’t tell you what specific actions you need to perform. It simply says you need to a) develop a plan to “identify” cyber risks to the BES arising from your supply chain; b) “assess” those risks to identify the most important ones; and c) mitigate those risks (although the word mitigate was left out of the requirement, there’s no question the standard should be read as requiring mitigation. Just look at the Purpose statement at the beginning of CIP-013-1). You do need to address the six risks listed in R1.2.1 through R1.2.6, but you have a lot of freedom in how you do even that.

This means that the scope of the work you need to do for compliance with CIP-013 is very much under your control. In the post, I listed three ways in which it would be possible for you to waste a lot of money on CIP-013 compliance. The last was the most important, and I’ll rephrase it now to say: You can waste money by inadvertently requiring your organization to mitigate risks that you never identified in the first place.

I went on in that post, and the follow-up post, to point out that the biggest problem with the then-current version of the EEI language was that it threw in so much other language that doesn’t address the six risks in R1.2.1 through R1.2.6 (and there are really eight risks, since R1.2.5 and R1.2.6 address two risks each). So it’s essentially adding a bunch of risks to the ones you’ve decided to mitigate in your CIP-013-1 plan.

As I stated above, the first step in CIP-013 compliance is to identify BES supply chain cyber security risks and identify the most important ones for mitigation. The eight risks in R1.2 have kind of a special status: They need to be mitigated, regardless of whether or not you think they’re important (of course, they are all important risks, so this shouldn’t be a big issue for anybody). But the others you identify are up to you, although R1.1 lists (or implies) five types of risk that should all be addressed in the plan: risks from hardware or software procurement, hardware or software installation, procurement of services, use of services, and transitions between vendors.

But it’s very important to keep your list of risks under control; what you don’t want to do is inadvertently add to that list, because for every risk on the list, you will need to show that you a) took steps to assess the likelihood that the risk is present in the vendor’s environment, and b) took steps to mitigate the risk (which might include contract language, although that’s never sufficient in itself). I see most of the compliance risk in CIP-013-1 occurring as entities comply with R2: Whatever plan you drew up in R1 (and you have a lot of freedom to do that), you need to implement it exactly in R2. If you have said you’ll mitigate a particular risk, you have to both assess your vendors for that risk and take steps to get them to mitigate it if the assessment indicates they haven’t already done so.

So how could you “inadvertently” add a risk to your list of risks? One way to do that is to ask your vendors a questionnaire question that goes beyond the list of risks that you’ve identified. As I recently pointed out in one of my posts on the NATF questionnaire, asking questions that don’t correspond to risks you identified in your list means you are inadvertently adding those risks to your list. If a vendor’s answer indicates they haven’t mitigated one of those risks, you need to follow up with the vendor to get them to mitigate it. And if you don’t do that, you may be found non-compliant with R2.

The same thing applies to contract language. In fact, I think you need to have a one-to-one relationship between each risk and one contract term, just as you should have a one-to-one relationship between each risk and one questionnaire question. You shouldn’t require contract terms that don’t address risks on your list, just like you shouldn’t ask questions that don’t address risks on your list.

The EEI language is supposed to address the risks in R1.2.1 through R1.2.6. In my posts on the original EEI document last year, I pointed to a number of examples where they included language that goes beyond the eight risks in R1.2. I reminded my readers (as an attorney for an IOU had reminded me) that each “extra” term a) requires a lot of additional legal effort, since the vendor is almost always guaranteed to want to negotiate any contract term that you require of them; b) requires you to take steps to verify the vendor is in fact complying with the term; and c) puts you at compliance risk if you don’t follow up to get the vendor to comply with any term that they haven’t complied with so far.

I was hoping that EEI’s new version 2.0 would fix these problems, but I regret to say they’re still there. Let’s just go through what just one paragraph requires. Paragraph (a) under R1.2.5 on page 10 requires the vendor to address the following risks that have nothing to do with R1.2.5:

a)      chain of custody practices,

b)     inventory management program,

c)      information protection practices (and since it doesn’t specify what information, the vendor needs to document their entire program for protecting all of their information),

d)     integrity management program for components provided by sub-suppliers, and

e)     “instructions on how to request replacement parts, and commitments to ensure that for [negotiated time period] spare parts shall be made available by Contractor”.

The point is that, by including just this one paragraph in your required contract language, you’re committing your organization to consider each of these five items to be a risk that must be mitigated, just like the risks you explicitly identified in R1.1. Of course, maybe you think these all are important risks and you understand what you’re committing yourself to – fine, that’s great. But be sure to add them to your overall list of R1.1 risks, so you can track their mitigation, and so that you can get “credit”, come audit time for all of the risks you’ve mitigated.

And the same thing goes for any of the other EEI terms that go beyond what’s required by R1.2.1-R1.2.6: If you include these in contracts, you need to be prepared to address them the same way you address all of your other identified risks (including the eight R1.2 risks themselves). I haven’t even tried to identify them all, but I would think it’s in the hundreds, especially in cases where the language requires a vendor to “follow” particular sections of for example NIST 800-53 – just one of those probably includes 10-20 separate risks that need to be mitigated.

Of course, if you have lots of time and lots of money available for CIP-013 compliance (and you all do, I’m sure…), you’ll at least know what you’re committing to. But if you don’t, you may want to rethink the idea of implementing the whole of EEI’s latest contract language document. In general, I think their language that just applies to the R1.2 requirements is good. But you need to be very careful in using the other language in the document.

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!