NATF’s CIP-013 guidance

Recently, the North American Transmission Forum released their “CIP-013-1 Implementation Guidance”, which they have submitted for possible NERC approval as official guidance (although of course NERC won’t approve the content of any guidance document, only say that it was properly drafted, or something like that). While I think this is an interesting (and useful) document, it isn’t in any way a complete guide to how to comply with CIP-013, which it seems to aspire to being.

The document first describes how a NERC entity can a) ask vendors to get an “independent assessment…from a certified auditor” to evaluate the vendor’s controls to meet the criteria found in CIP-013 R1.2 (what I call the “six things”. These were originally mandated by FERC in their Order 829); b) assess the results; and c) document any mitigating actions that need to be performed by the vendor.

Fair enough. I agree that this would be a good thing to do, and would help with compliance with R1.2 and R2. But the document goes on to say “A Responsible Entity could choose to include this process as the only R1 process in its overall R1 plan or it could be one of several processes that meet the R1 requirements in its overall R1 plan.” So it is saying that implementing this process alone will constitute compliance with R1 in its entirety. Is that really the case?

Let’s look at what R1 requires, sticking just to what the words say. First, R1 itself says “Each Responsible Entity shall develop one or more documented supply chain cyber security risk management plan(s) for high and medium impact BES Cyber Systems. The plan(s) shall include:” (this is followed by R1.1 and R1.2). Let’s stop there and see what this says about what we should do. It says we should develop a plan that needs to include R1.1 and R1.2. Fair enough, what should this plan contain?

R1.1 reads “One or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).” In other words, your plan should a) identify and assess[i] cyber security risks to the BES from procuring vendor equipment and software; b) identify and assess cyber security risks to the BES from installing vendor equipment and software; and c) identify and assess cyber security risks to the BES from transitions between vendors.

NATF is saying the entity can choose to designate the third-party vendor assessment process as the only R1 process in its plan – meaning that the plan could consist entirely of this process. Since that’s the case, then this process should also be enough to comply with R1.1. How well does it do this, for each of the three plan elements just identified from the R1.1 wording?

Let’s start with element a) above. Will implementing the vendor assessment process help the entity identify and assess risks from procuring vendor equipment and software? How could it possibly do that? A process to get vendors to have third-party assessments isn’t a process to identify and assess risks from procurement. This might be part of the mitigation plan for some of the risks identified, but that’s it. In itself, this process neither identifies nor assesses any procurement risks. The same thing can be said for element b); that is, the process neither identifies nor assesses any installation risks (and I can’t think of how it would even be part of the mitigation plan for installation risks). And as for c)…well, the vendor assessment process has nothing to do with identifying, assessing or mitigating risks of transition between vendors. So we can safely say that including the third-party vendor assessment process in your plan won’t in any significant way help with compliance with R1.1.

R1.2 reads “One or more process(es) used in procuring BES Cyber Systems that address the following..” Of course, we should preface this with “The plan(s) shall include…” from R1. Let’s ask the same question here. Does the third-party vendor assessment process help the entity comply with R1.2?

It does that partially, but not entirely. To understand what I mean, you need to understand why the six items in R1.2 are there: It’s because FERC explicitly ordered that these six things be mandated by the new supply chain security standard. But these six things aren’t included in CIP-013 as prescriptive requirements; rather, they’re supposed to be included in the overall plan mandated by R1 (of course, this is a good thing, since having six prescriptive requirements in a standard that is supposed to be entirely based on having a plan would create a very uncomfortable mix, both for entities that need to comply and for auditors).

And since the overall plan is a plan for risk management, the six items need to all be considered as mitigations of particular risks. Therefore, what R1.2 is really saying is “The risks of which these six items are mitigations must be included in your plan”. Of course, most of the risks in the plan will be those that the entity itself identifies in R1.1; but the six risks behind the six R1.2 items have to be included in the plan as well – and therefore have to be mitigated.

For example, R1.2.3 reads “Notification by vendors when remote or onsite access should no longer be granted to vendor representatives”. This is a mitigation of a risk[ii] which could be (fairly roughly) said to be “the risk that a terminated vendor employee will take out his unhappiness on your BES Cyber Systems”. So we will list this as the risk “behind” R1.2.3; and we’ll do the same for each of the other five items in R1.2.

Let’s say we’ve listed the risks behind each of the items in R1.2. Of course, the plan needs to include mitigation of each risk. Can the third-party vendor assessment discussed by NATF serve as the mitigation for these six risks? It can certainly provide part of the mitigation, but it isn’t the entire mitigation process by any means.

To go back to our example, if the assessor determines that the vendor does in fact endeavor to provide notice within 24 hours – and sooner if possible – whenever an employee who had access to a customer’s systems leaves, this would certainly be a big step toward mitigating the “risk that a terminated vendor employee will take out his unhappiness on your BES Cyber Systems”. But is this all that’s required? What happens if there’s a big management change at the vendor soon after the assessment, and the new management doesn’t care at all about the notification policy? If this happens, what if anything does the entity need to do to make sure this risk is mitigated?

There are a lot of things the entity can then do: When they first realize the policy has changed, they can call up the vendor and threaten to terminate their business – and then make good on that threat if the vendor doesn’t change their policy. And if it isn’t possible to terminate this vendor (which it often isn’t), the entity can at least terminate all remote access for this vendor and require that representatives who want physical access be accompanied at all times by an employee of the entity. These aren’t easy steps to take, but the point is that the entity has to have a plan to mitigate each risk, and simply getting a good assessment won’t always be enough to mitigate a risk.

At this point, someone might point out that “vendor performance and adherence to a contract” is explicitly stated to be out of scope in CIP-013 R2 (and implicitly in R1 as well). So if the entity had not only had the vendor get the third-party assessment, but they had also had them agree in their contract to implement whatever mitigations were indicated in the assessment, the entity wouldn’t be found in violation if the vendor didn’t perform.

This is very true. But this is very different from saying that, if the vendor doesn’t perform an obligation in their contract, the entity doesn’t need to take any more steps to mitigate the risk in question. The goal of CIP-013 is risk management, not vendor assessment and not contract language. Those are both useful tools for mitigating risk, but the risk must be mitigated regardless of what the vendor does or doesn’t do.

So is NATF’s statement that “A Responsible Entity could choose to include this process (i.e. the third-party vendor assessment) as the only R1 process in its overall R1 plan” accurate? No. This process can contribute very little to R1.1 compliance; for R1.2, it can contribute maybe half of the mitigation required. This process is far from being the “only R1 process” in an entity’s CIP-013 R1 plan. However, the clause that follows this says “or it could be one of several processes that meet the R1 requirements in its overall R1 plan.” I certainly agree with that, although I think there will usually be a good number of processes in an entity’s CIP-013 R1 plan – not just “several”. I think there will need to be a process to mitigate each of the risks the entity identifies in R1.1; and I would think that any entity that wanted to put together a credible plan would need to mitigate more than “several” risks.

Now let’s move on to R2. This requirement reads in its entirety “Each Responsible Entity shall implement its supply chain cyber security risk management plan(s) specified in Requirement R1.” And since NATF has stated that the third-party vendor assessment process by itself meets an entity’s compliance obligations under R1, it’s not hugely surprising that they say that implementing that process is all that’s needed to comply with R2, specifically “The documentation maintained by the entity would demonstrate that the entity used its supply chain cyber security risk management plan required in R1 and, therefore, met its requirements under R2.”

So is NATF’s statement true? Oddly, I’d say it is. There are two cases here. First, suppose that the entity’s auditor has already decided that just describing the third-party vendor assessment process constitutes compliance with R1. If the R1 plan has been found compliant, then the R2 implementation of that plan will also be found compliant (assuming the plan was actually implemented). Second, suppose the entity’s R1 plan hasn’t been found compliant. Even then, the R2 implementation might still be found compliant, since R2 doesn’t require that the entity rethink its R1 plan, but simply implement it.

So the important question is whether the R1 plan will be found to be compliant, if the entity has simply followed NATF’s advice and based their whole plan on a third-party vendor assessment. That is a real question, but in my opinion there’s an even more important question that needs to be asked. Since this post is already pretty long, I will save it for the next[iii] post. 

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. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. To discuss any of this, you can email me at the same address.

---

[i] As I first noticed when I wrote a post that analyzed R1.1 in excruciating detail, the drafting team seems to have left out the word “mitigate” here. There’s certainly no point in developing a plan to just identify and assess risks, without doing anything to mitigate them! I don’t particularly blame the SDT for this error, since they were under a really tight deadline from FERC to develop and approve this standard in one year; and CIP-013 is probably the first non-military mandatory supply chain cyber security standard in the world. Unfortunately, this also seems to have happened with CIP-014, which faced a three-month deadline. The result is that both standards are in some way un-auditable. I’ll elaborate this more in a post soon on CIP-014, as well as in my next post on CIP-013.

[ii] I have a problem with R1, in that it uses the word “risk” where I would use “threat”. Forgetting about CIP for the moment and just thinking of the process a CISO goes through in deciding how to allocate her budget for the year, she must first identify a threat like malware, then assess the degree of risk it poses. Once she has identified all of the major threats and decided their degree of risk, then she can allocate her resources to particular threats based on their individual risks. If you substitute the word risk for threat in the above two sentences, you’ll see that “risk” will be used with two entirely different meanings – which of course is very unhelpful. But CIP-013 uses the word risk, and that’s because FERC used that word in Order 829. I’m not going to fight that here, but it will become important when an entity actually sets out to comply with CIP-013; then they will have to have these terms straight.

[iii] Even though I believe this will be the topic of my next post, there have been a number of other times when I’ve been sure I knew what my next post would be, only to have some other event intervene that I thought was more important to address. So if my next post is on a completely different topic, you can’t sue me.