Sunday, April 17, 2016

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]:

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.

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.

Thanks, Anonymous. As long as they "rev" all of the standards so they all end with -7 or -3, I'm fine with whatever they want to call them. I will refer to it as v7 and I think the industry will, too. But this business of having some v5 and some v6 standards to comply with has proven very confusing for a lot of people. And completely needlessly.