CIP Version 7

In case you haven’t noticed, a new version of NERC CIP has just entered the gestation process. While it is certainly too early to head to the maternity ward, it isn’t too early to start thinking about a color for the baby’s room. Two new documents led to this happy event: NERC’s January webinar on “CIP Version 5 Revisions” and FERC’s Order 822. Each of these identified a number of items to be addressed by the Standards Drafting Team in v7. From the looks of it, they will have a lot to do! I will discuss both of these documents and what they have contributed to the SDT’s “inbox”.

First a few general points:

1. Rather than constitute a new drafting team, NERC plans to utilize the existing “CIP v5 Revisions” SDT[i]. These were the folks that developed CIP v6. I am fine with that, since this is a very competent team. However, I certainly hope that, with CIP v7, NERC won’t make the same mistake as with v6 and pretend this isn’t a new version. That has led to a lot of confusion, since entities now have to comply with three v5 and seven v6 standards, rather than ten v6 ones. If NERC does the same thing with v7, entities may conceivably be complying with three different versions at once. My advice: “rev” all of the CIP standards to v7, whether or not they need to be changed for any other reason.[ii]
2. I have to admit it isn’t 100% certain that there will only be one new CIP version, not two. The changes that NERC requested will not need a new Standards Authorization Request (SAR), since they fit into the current SDT’s “mandate” to address issues that come up in the CIP v5 implementation process. However, I believe the changes that FERC required in Order 822 will require a new SAR, since they obviously were a new mandate. I certainly hope these two efforts can be combined.
3. In Order 822, FERC didn’t mandate a new supply chain security standard, since they were waiting for the recent Technical Conference on that subject - and even though the conference happened a few weeks ago, I doubt an Order for that new standard will appear anytime soon. When and if FERC does order a supply chain standard, I would think its drafting would get added to the existing SDT’s plate, rather than handed to a new SDT. If this is a new standard (probably CIP-012), it will likely be considered part of v7, but it might not become enforceable with the rest of v7, since the SDT would have started work on it after the other v7 standards.

NERC’s Webinar

In the webinar, NERC listed a number of issues that need to be addressed by the SDT, including:

1. The definition of Cyber Asset (slide 8), and especially the word “programmable”. Note that this effort might be more than just a definition of the word “programmable”. The SDT may decide they like a different definition – without the “p”-word – altogether.

2. The definition of BES Cyber Asset. NERC listed (slide 8) three items that need clarification:

• “Focusing the definition so that it does not subsume all other cyber asset types” I honestly don’t know what they mean by this, so I won’t speculate.

• “Considering if there is a lower bound to the term ‘adverse’ in ‘adverse impact’” I assume this means they’re concerned that – as the definition now stands – anything that has the slightest impact on the BES could be considered a BCA. Correcting this is quite laudable, but how will it be done in practice? Will there be some sort of electrical criteria? And how will these be determined, if not by putting together a treatise that would be hundreds of pages long and comprehensible only to someone with an EE degree or two? I agree this is a problem, but I really don’t think it’s soluble. It may just be something the SDT needs to decide to live with; it certainly won’t be the only issue for which they’ll probably have to make that decision.

• “Clarify the double impact criteria (cyber asset affects a facility and that facility affects the reliable operation of the BES) such that ‘N-1 contingency’ is not a valid methodology that can eliminate an entire site and all of its Cyber Assets from scope” Of course, N-1 was a big problem with the RBAM in CIP v3, since invoking that contingency was a pretty sure-fire way to remove an asset from consideration as a Critical Asset. I hadn’t heard that entities were doing the same thing in the case of the BCA definition in v5, but if so this is a good example of the disconnect between how CIP-002-5.1 R1 reads and how it is actually being followed by most if not all entities.[iii] While there would be a way to address this issue, I think it would require a more fundamental rewriting of R1 than NERC is currently contemplating.

• Unfortunately, even if acceptable wording is found for all three of these items, it still won’t fix the BCA definition. The main problem with that definition is that, in my opinion, its wording doesn’t correspond at all with how NERC entities understand the BCA identification process to work; this means there is literally no way to properly identify BCA, except to literally disregard the current definition.   While I believe the SDT could still decide to open up the whole BCA definition and start from scratch, I doubt they will have the appetite or time to do that.

3. There are a number of issues (slides 9 and 10) regarding ESPs, ERC and Interactive Remote Access (IRA). The most important of these, in my opinion, are:

• The question of “demarcation”, when an entity owns one or more cyber assets located between two assets and at least one of those assets doesn’t have an ESP. This issue was addressed quite well in this Lesson Learned.

• “Review of the applicability of ERC including the concept of the term ‘directly’ used in the phrase ‘cannot be directly accessed through External Routable Connectivity’ within the Applicability section.” While I understand NERC’s concern about fixing the ERC definition, I suggest they’re trying to square the circle. I have written about ten posts on ERC, and I finally came to the conclusion that the concept is a black hole – there is no way to develop a dictionary-style definition of ERC that will apply to all the different situations found in substations. The only possible course is to develop a number of use cases (as was done in the Guidance section of CIP-003-6), indicating whether each has or doesn’t have ERC; I suggest the SDT just concentrate on doing that, and forget trying to find the perfect definition.

•  “Clarify the IRA definition to address the placement of the phrase ‘using a routable protocol’ in the definition” I agree with NERC here that the phrase in question is confusing, and should be clarified.

4. On slide 11, there are two items related to TO Control Centers that “perform the functional obligations of a TOP”. This is a big issue for a number of NERC entities, but I won’t rehash it here; the people it affects understand it much better than I do!

5. Slide 12 says “CIP V5 standards do not specifically address virtualization”. This is perhaps the most important of NERC’s “mandates” to the SDT. The basic problem isn’t that nobody knows how to address virtualized systems within CIP v5; people do know that. The problem is that the current wording doesn’t allow for virtualization. For example, it seems obvious that a virtual machine is a Cyber Asset and should be considered a possible BES Cyber Asset. Yet the definition of Cyber Asset is “Programmable electronic device…” (emphasis mine). A VM isn’t a device; it’s software. This means the definition of Cyber Asset needs to be revised (or perhaps there needs to be a new type of asset called “Virtual Cyber Asset”). There will need to be other changes like this as well.

FERC’s Mandates to the SDT

FERC’s Order 822, issued January 21, mandated that NERC address the following items in the next CIP version. Since I have dealt with each of these in some detail in this post, I won’t discuss them further here.

1. Transient electronic devices and removable media used at Low impact assets;

2. Data communicated between Control Centers;

3. Communications devices located between Control Centers;

4. “Data at rest” in Control Centers; and

5. The definition of Low impact External Routable Connectivity (LERC).

Conclusion (with Despairing Remarks)

As you can see from the above, the SDT will have a lot on its table for CIP v7. I don’t believe they’re forbidden to address other issues as well, but given their current workload I doubt they’ll be searching diligently for more requirements and definitions to rewrite.

And this is the problem. The fundamental issue with CIP v5 (and this applies to v6 as well) is that the asset identification process in CIP-002-5.1 R1 (and Attachment 1) is so fundamentally flawed that an entity can never be certain it has properly identified and classified its BES Cyber Systems. Unless the SDT has an appetite for a lot of philosophical arguments, and perhaps an additional year available to draft v7, I sincerely doubt they will want to take this problem on, especially because there is no clamor for it.

I don’t see this problem becoming huge for a while, because – as I discussed in this post – both the entities and the regions have a good idea of what needs to be done to comply with R1 (see this post for a discussion of how they’re doing that). However, the problem is that this idea doesn’t correspond with the actual wording of CIP-002, meaning that literally the only way to comply with the requirement is to ignore big parts of its wording.

However, at some point in the future, an entity will get a fine for CIP v5 or v6 violations that they think is unfair; they will then appeal it to the civil courts, since NERC standards are regulatory law and can be challenged in court. When that happens, I don’t think a judge will need to take ten minutes to read CIP-002, before he or she exclaims “What is this (stuff)?” and throws CIP-002 out the window. And at that point, I believe CIP-003 through CIP-011 will also suffer defenestration, as all those requirements depend on being able to properly identify BCS. This means there will literally be nothing left of CIP v5 and v6 (and probably of v7 as well), and the time and money spent on developing and complying with those standards will literally be for naught. What do we do then? Go back to CIP v3?...Drop CIP altogether and hope Congress doesn’t notice?... Move to rewarding careers in fast food?...The possibilities are endless.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

---

[i] It seems there are now some openings on the SDT. If you are part of a NERC asset owner and would like to become a voting member of the SDT, contact NERC. Of course, literally anybody can observe and make comments at the drafting meetings – both face-to-face and phone meetings. You only have to be a user of electricity – and if you’re reading this post, my guess is you pass that test.

[ii] When FERC approved CIP v2 in the fall of 2009, they also asked for one change – a requirement for escorted physical access – in CIP-006. Even though that was the only standard that changed, the SDT changed all of the other standards so they were also v3. This is why the industry complied with eight v3 standards, rather than seven v2 and one v3. If it was the right thing to do then, it’s certainly the right thing to do now!

[iii] Since explaining why I think this would require a longer discussion than I have time or space for now, I will just point the interested reader to this post, which outlines a procedure that I believe properly describes how most entities think about the meaning of “adverse impact”. I believe this is the right approach, but it doesn’t correspond with the wording of R1 or the BCA definition.