Should CIP v5 and v6 be Rewritten?

I recently wrote a post discussing what is in NERC’s recent Standards Authorization Request (SAR) for the next CIP version (which I certainly hope will be called v7; no more talk of “revisions” to v5 or v6). I said I would soon write a post on what isn’t in the SAR, but perhaps should be. That is, I’ll list changes that could be made to CIP v5 and v6, even though these aren’t called out in the SAR. I hope to have that post out right after this one – and hopefully in advance of NERC’s CIP Technical Conference in Atlanta on April 19, which I am looking forward to attending.

However, I recently realized that, before I do that post, I need to address the question whether the team drafting the new version should go back to fundamental principles and “rewrite” CIP v5 or not. This might seem like an odd question, but it was something I was advocating until five or six months ago, and I have heard that at least one large NERC entity is currently pushing this very course of action.

Why would CIP v5 need to be rewritten? That’s an easy question for me to answer. It’s because there are two types of problems with CIP v5[i]:

1. Problems that can be addressed without rethinking any of the fundamental concepts in v5. For example, the term “custom software” in CIP-010-2 R1 isn’t defined, and has caused a lot of confusion for NERC entities. This problem can be fixed by coming up with a definition.
2. Problems that can’t be addressed other than by opening up the fundamental concepts in v5. For example, the fact that CIP-002-5.1 R1 and Attachment 1 were written simultaneously from two different points of view[ii] – and that these were never reconciled - leads to confusion in a number of areas. One example of this was the big controversy over the far-end relay issue, which was mostly due to the widespread (and mistaken) belief that CIP-002 Attachment 1 classifies assets (i.e. “big iron” – control centers, substations, etc) as High, Medium or Low impact.[iii]

From everything I have seen so far, including the SAR, the Standards Drafting Team is only being tasked with addressing problems of the first type, not the second type. And I can certainly understand this; going back to debate fundamental concepts like the asset identification and classification process could easily add six to twelve months to the SDT’s work. Since I’m currently estimating that – even without this fundamental debate – it will be at a minimum three years, and more likely four or even five years, before CIP v7 comes into effect, this is no small consideration.

But what is lost by not addressing the fundamental problems? For one, these problems are creating confusion, just like the non-fundamental ones are; getting them resolved will make it much easier for entities to comply with CIP v7 (which will otherwise include the same contradictory wording found in CIP-002-5.1) and for auditors to audit them.  This was evident to me at the RF CIP workshop last week in Columbus, Ohio, where there were discussions about some fundamental questions that should have been settled three years ago. They shouldn’t still be causes of confusion now - less than three months before the compliance date.[iv]

But there is a bigger issue here: I have said previously that CIP v5 (and v6) will never be enforceable in the strict sense, unless it is rewritten to address these fundamental issues.  And what do I mean by enforceability in the “strict sense”? I mean that, should a violation of CIP v5 be challenged in the civil courts, I simply don’t see how the violation (and its associated fine) could be upheld. At that point, CIP v5 and v6 (and v7, if the SDT doesn’t fundamentally rewrite CIP-002) would turn into nice guidelines to follow, not enforceable standards. What would happen at that point is anybody’s guess.[v]

Up until five or six months ago, I was advocating that CIP-002 be rewritten from scratch. However, some of you may have noticed that I have changed my tune now: I now think that the fundamental problem with NERC CIP is that it is a set of prescriptive standards, and prescriptive standards don’t work for cyber security – risk-based standards work. For that reason, the fact that rewriting CIP v5 might make it enforceable no longer excites me, since it will remain a set of prescriptive standards.

However, I recently heard that one or more large NERC entities are advocating for a complete rewrite of CIP v5, presumably to address both the clarity and enforceability problems. I certainly don’t want to discourage them. CIP v5 and v6 will clearly be around for a while, and if there is a will on the part of NERC entities – and the SDT – to try to make these standards both clear and enforceable, I will certainly support that effort.

I also realize that perhaps I have been exaggerating the amount of work that will be required to rewrite CIP-002. The biggest problem with that standard is the fact that CIP-002-5.1 R1 and Attachment 1 are written from two different points of view, and haven’t figured out what they want to be when they grow up. However, as I stated in this post, the NERC entities and regions have come to a remarkably consistent consensus on how to “comply” with this wording; they are just about universally following one of these two points of view, which happens to be pretty much the approach used in CIP versions 1-4.

In this approach, the entity starts with the “big iron” – control centers, substations, etc. - then classifies these High, Medium and Low impact. Once they have done that, they identify BES Cyber Systems at the High and Medium assets; the BCS take the classification of the asset. They come out with the three things that are required by R1: lists of High and Medium impact BCS and a list of Low impact assets (aka “assets containing Low impact BCS”, in the rather strange circumlocution adopted to try to bridge the unbridgeable gap between the two points of view in R1 and Attachment 1).

So the problem isn’t that entities and auditors don’t understand how to comply with CIP-002-5.1 R1; the problem is that the way they are complying with it doesn’t fit with the words of R1 and Attachment 1 (more specifically, it doesn’t fit with some of those words. It does fit with others). In one sense, the solution is simple: simply rewrite CIP-002 so that the words fit what everyone is actually doing anyway. This would be one giant step toward making CIP v5 and v6 enforceable in the strict sense. And I don’t think this would take much time.

But I need to throw a caution in here: It is very possible that CIP v5 and v6 will be unenforceable in the strict sense, no matter how much time the SDT spends resolving the fundamental problems in CIP-002-5.1. My reasoning for saying that can be found in these posts: here and here. If the SDT does decide to address these fundamental problems – as I believe they should – they shouldn’t do so with the idea that this will make CIP v5 enforceable in the strict sense; I believe that ship has already sailed.

Note April 18, 2016: It just occurred to me that rewriting CIP would make all the sense in the world if it could be rewritten as a risk-based standard. I have just been assuming that the consensus needed to do that is still years away. However, it is definitely the most logical thing to do: Simply leave v5 and v6 in place as they are, warts and all, and start work on a completely new v7. But I'd say that's the stuff of dreams at this point.

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

---

[i] Note that, when I mention “rewriting” v5, I’m implicitly saying the same thing about v6. Since the fundamental problems are mainly found in CIP-002-5.1 (which is part of v5, of course), that is the only standard that would have to be substantially rewritten. However, there would be further changes required in all of the standards, both the v5 and v6 ones.

[ii] One point of view is that Cyber Assets become BES Cyber Assets if they have an inherent impact on the BES. The other point of view is that they become BCAs only if they impact a critical asset or Facility, which then has an impact on the grid. The latter is more or less how asset identification worked in CIP v1-v4. The former was an idea that came up when the team that drafted v2-v5 was starting work in 2009, embodied in this Concept Paper. Different parts of CIP-002-5.1 R1 and Attachment 1 ended up embodying both these points of view, and they were never reconciled. I discussed this in at least two previous posts: this one (the section titled “Have an Apple, Adam?”) and this one. I’ll admit I’ve never explained myself fully on this issue; that may need to be part of a book, not just a blog post.

[iii] As I said in this post, the problem with CIP-002 R1 and Attachment 1 isn’t that entities and auditors don’t agree on how to classify BES Cyber Systems as H/M/L, but that the asset classification model they all agree on doesn’t correspond to most of the wording in CIP-002. The best way to fix this problem is to rewrite R1 and Attachment 1 so that their wording follows the model that people are actually using (which IMO is quite good, and has the added benefit of being very similar to the model in CIP versions 1-4).

Note 4/21: Kevin Perry, Director of Critical Infrastructure Protection for SPP, takes exception to my reference to "auditors" above. He points out that SPP's message since CIP v5 was approved has always been that the Attachment 1 criteria are for classifying BCS, not assets. I didn't mean to say this wasn't their official position, nor that it wasn't the position of other regions, but that the procedure they advocate that entities follow - first identifying "assets likely to contain High or Medium BCS", then running these through the criteria - amounts to pretty much the same "big iron / little iron" approach as v1-3, and is understood by most entities to be basically the same approach. What I'm advocating is that the wording of R1 and Attachment 1 be changed so that it does actually reflect the v1-3 approach, since I think that one was pretty good and since just about every entity (if not every one) is actually following it anyway.

[iv] This was also evident by the fact that, when attendees were asked to raise their hands if they were ready for the v5 compliance date, only a small percentage did so. This was two weeks after April 1, which of course was supposed to be the compliance date, until less than two months ago. It seems very likely that a large number of NERC entities wouldn’t have been ready on April 1; it remains to be seen how many will truly be “ready” on July 1.

[v] Here are a couple of my guesses: 1) All the work that NERC and entities have done on v5 and v6 gets thrown out, and the industry goes back to v3, the last enforceable set of standards; or 2) Congress is so alarmed by the fact that there are no longer any enforceable cyber standards for the industry that they take responsibility for cyber regulation away from FERC and NERC and give it to some other agency, like DHS or even the military. I would say the second of these is more likely.