Introduction
Shortly
after FERC issued their NOPR saying they would approve CIP v5 in April 2013, I
set out to do a series of posts that would create a road map for what an entity
should do to comply with v5. Since the beginning is a good place to start, my
first post was on CIP-002. But a funny thing happened on the way to the road
map: I realized there was a fundamental “You can’t get there from here” flaw in
the logic of CIP-002-5 R1. If an entity were going to try to follow the logic
of the requirement in order to identify and classify their High and Medium impact
BES Cyber Systems, as well as their “assets containing Low impact BCS”, they
would simply run into a wall and never get where they wanted to go. Since then,
I—and others—have identified many more problems with CIP-002 R1 and Attachment
1, as well as certain definitions, like “Cyber Asset”, that are necessary to
comply with this requirement but that are missing or ambiguous.
However, I
was surprised to see that this has not stopped NERC, the regions and the NERC
entities from coming up with a generally-accepted “interpretation” of how to
comply with CIP-002 R1 by first classifying “assets” as High, Medium or Low
using Attachment 1, and then identifying BES Cyber Systems using a criterion
something like the one used in CIP v1-3 to identify Critical Cyber Assets:
those Cyber Assets that are “essential to the operation of” a Critical Asset
(of course, that criterion is really used to identify BES Cyber Assets; then
these are aggregated to BCS).
I’m quite
happy with this development, since I didn’t want to see CIP v5 implementation
stop dead in its tracks because of the problems I was writing about. But there
remains one big problem: The methodology that NERC entities are using to comply
with CIP-002-5.1 R1, and that the regions (and even NERC) are for the most part
advocating as proper, is almost completely incompatible with the requirement
(and Attachment 1) as written. In other words, assuming nobody makes the
entities radically shift how they comply with R1, not a single entity will be
in compliance with the literal wording of CIP-002 R1! This obviously isn’t
something that is good for CIP, or for NERC for that matter. It means
CIP-002-5.1 will never be enforceable, and perhaps this contagion will spread
to the other CIP standards as well – since they all depend on the entity correctly
complying with CIP-002-5.1 R1.
Of course,
there are two ways to change this situation. One would be to beat into
everybody’s head – the entities, the regions and NERC itself – what the real R1 compliance methodology is (or to
state it better, the methodology that comes closest to following the words of
R1 and Attachment 1). I don’t think this is a good idea, because I believe the
methodology that people are adopting is far superior to the one that is found in
the words of CIP-002. Plus enforcing this would be impossible in any case.
The second
way to make the practice and the words compatible is to change the words – i.e.,
rewrite CIP-002. I have been saying for a while that this is the only possible
way to make v5 enforceable, even though it will take several years (or more)
for a new version to be approved and enforceable. Despite that fact, simply
leaving CIP-002 in place as it is should not be acceptable. In my opinion, it’s
likely to lead sooner or later to all of
v5 (and v6, and perhaps future versions as well) being unenforceable. If the
foundation is rotten, sooner or later the house will fall. CIP-002 is the
foundation of CIP v5 and v6, and it can’t be allowed to exist forever in its
current state.
This is why I say CIP-002 should be rewritten. In the next three or
four posts, I will lay out the problems I see with the current CIP-002. I will
conclude with a discussion of what might be done during the three or more years
it will take to draft, ballot and have FERC approve the new version – given
that CIP v5 and v6 will be effective in
some way or other starting next April, whatever the status of CIP-002-5.1
on that date.
I divide the
problems in CIP-002 into four types, each of which will have its own section in
these posts (but not necessarily its own post). The sections are:
- “Spot” Problems
- Problems Caused by Excessive Brevity
- The Fundamental Problem with CIP-002
- Problems Dependent on Resolution of the Fundamental
Problem
- What to do while CIP-002 is being Rewritten
I.
“Spot”
Problems
There are a number of problems that are confined to particular sentences
or phrases, as well as a missing definition or two; I’m calling these “spot
problems”. Unlike the remaining problems
discussed in this document, these problems can be dealt with through relatively
small wording changes.
Before I begin, I want to point out that there is a large class of spot
problems that I won’t be discussing here: These are problems with the
Attachment 1 criteria. I’m referring
here to technical issues that have come up with application of the criteria in
practice[i]
– and that can be foreseen to continue to come up as the criteria are further
applied to real-world situations. I see
the potential technical issues as almost unlimited in number.
To be honest, I don’t think these technical issues can be addressed
through rewriting the criteria; I think the criteria are pretty good already –
or at least as good as they could ever be.
The problem is with the whole idea of bright-line criteria being applied
to an industry as incredibly diverse as this one in the first place; I don’t
think God Himself could write a set of short criteria that wouldn’t lead to an
almost infinite number of questions (and I don’t believe God was on the SDT in
any case). I first wrote about this problem on a different blog in 2012, but I
recreated that post here
in 2013.
I think the best solution to the issue of the bright-line criteria is a
kind of “Supreme Court of BLC” – a panel of experts from the industry that will
consider disputes regarding the criteria and provide guidance. I also know that the worst solution is to
handle all of these disputes through the enforcement process. This will be very expensive for NERC
entities, the regions, and for NERC and FERC.
And to be clear, there will never
be an end to BLC issues. It’s like
whack-a-mole: as soon as one issue is dealt with, a couple more pop up. In my opinion, my court idea would have to be
dealt with outside of the standard – based on some consensus among NERC, FERC,
the regions and the entities, but not relying on a rewrite of NERC’s Rules of
Procedure, which would take forever.
So here are the spot problems that I see in CIP-002-5.1, other than
technical ones involving the BLC:
a)
Section 4.2: “Facilities” – The title of Section 4.2, which is about
the scope of CIP v5, is incomplete. Some of the “big iron” in scope for CIP v5
is indeed Facilities – i.e., lines, buses, transformers, etc. - per the NERC
definition. But some of it is “assets”. This is an undefined term that is
“defined” for purposes of CIP-002 by the list of six asset types in R1. I think “Facilities” in the title of 4.2 should
be replaced with “Facilities and assets”; the reasons for this will be made clearer
in c) below. In addition, Section 4.2
refers several times to “Facilities, systems and equipment”; the same phrase
appears in the BES Cyber Asset definition.
For the life of me, I can’t figure out why this phrase is here, or what
it means[ii]. Is the entity supposed to start out with a
list of each Facility, system, or piece of equipment it owns, to see what’s in
scope for v5? Do “systems” include
desktop PCs used in Accounting? Does
“equipment” include monkey wrenches? And
since, per the Glossary definition, an asset like a control center or
substation can’t be a Facility (and assets obviously aren’t systems or
equipment either), are control centers and substations therefore not subject to
CIP v5 at all? I think it would be much
better to simply replace “Facilities, systems and equipment” with “assets or
Facilities”[iii]
everywhere it is found.
b)
Section 4.2: “owned” – This section also says that the
requirements only apply to FSE that are owned
by a Responsible Entity. What if an
entity does a sale/leaseback deal to raise cash and transfers ownership of the
systems in a control center to a finance company? Do the requirements no longer apply to these
systems? Obviously, that shouldn’t be
the case. But I don’t see how it’s
prohibited by the current wording.[iv]
c)
Section 4.2.2: “All BES Facilities” – This section – which is of course found in
each CIP v5 and v6 standard – states what is in scope for all Responsible Entities
except DP’s. According to the Glossary definition, no substation or control
center is a Facility. And since in the
Generation environment a Facility will usually be a single unit, most
generating plants won’t be Facilities either.
So a literal application of this wording could possibly eliminate close
to 95% or more of the assets in North America from CIP v5 compliance. The solution to this problem is simple: use a
lower case “f” so that the general meaning of “facilities” will apply.
d)
Section 4.2.3.2: “discrete Electronic
Security Perimeters” – The
problem with this wording was discussed quite eloquently in the Memorandum on
“Network and Externally Accessible Devices” published in April (and rescinded
in July). It seems the SDT forgot that there can now be BES Cyber Systems that
are only serially connected and therefore don’t have an ESP; but they will
still have external communications. NERC
recently put out a Lesson Learned that does a good job of addressing this
issue; it can form the basis for a rewrite of this section.
e)
Definition of “Programmable electronic
device” – There has, of
course, been a lot of controversy on this, as well as failed attempts to
address the issue. Clearly, there will
be no agreement until a definition is drafted and balloted. Perhaps there
shouldn’t be a definition of PED, but the Cyber Asset definition should be
rewritten to eliminate the undefined term. Either way, this needs to be
addressed.[v]
f)
Attachment 1, Criterion 2.6 – This criterion reads “Generation….and
Transmission Facilities..” Taken literally, the fact that this doesn’t say
“Generation Facilities…” means that an entire plant is Medium impact, even if
only one of its units is designated as critical to IROLs; although with a
substation, only particular lines, transformers or other Facilities are in
scope. However, in the Guidance the SDT did refer to Generation Facilities; plus
NERC took it to mean this in their Memorandum in April. So I think it’s safe to
say that this should really read “Generation Facilities and Transmission
Facilities”.
For Part II of this series, go here.
For Part II of this series, go here.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i]
There is one issue of wording with the Attachment 1 criteria that I will
address in this document. But all the
other issues I know of are technical ones relating to industry structure,
engineering considerations, etc. As you will see, I’m saying they really need
to be dealt with in a court-like setting.
[ii]
Since I originally wrote this sentence – while writing Part III of these posts
– I discovered where this phrase came from – a Concept Paper the SDT wrote in
2009 that provided much of the intellectual foundation of CIP v5. On the other
hand, I still don’t understand why it is used in CIP v5, since the standards
clearly don’t apply to “Facilities, systems and equipment”.
[iii]
The other place where “Facilities, systems and equipment” is found is in the
BES Cyber Asset definition. As will be
seen in the remaining Parts of this series of posts, I am recommending
rewriting that definition in a way that will eliminate FSE, although that isn’t
the purpose of the rewriting. But even if the definition weren’t rewritten for
other reasons, I would still recommend that FSE be removed, since I think it’s
just as useless and misleading as it is in Section 4.2.
[iv]
I’m told there are some smaller Control Centers where the operator of the
Control Center literally does not own the equipment. So this isn’t a completely
academic question.
[v]
On September 9, 2015, NERC released a Lesson
Learned that discusses this issue (and others related to CIP-002). In that,
they frankly admitted that entities need to figure out for themselves what
“Programmable” means, and there are all sorts of possible ways of doing this. Of
course, this discussion of “Programmable” doesn’t constitute a definition at all, although I believe this
document is as good as could be done; it is now up to each entity to develop
their own definition or methodology for identifying Cyber Assets. While this is
clearly the only thing that can be done in the short term, since “Programmable”
is quite literally the foundation for the entire scoping process of CIP v5 and
v6 (and probably for several versions after v6 as well), this situation can’t
be allowed to stand in the long run. There needs to be some kind of definition
of “Programmable” – or perhaps the definition of Cyber Asset needs to be
revised to clarify exactly how an entity identifies “Programmable electronic
devices”.
No comments:
Post a Comment