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:
- 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]
- 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.
- 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:
- 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.
- 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.
- 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.
- 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!
- 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.
- Transient electronic devices and removable media used at
Low impact assets;
- Data communicated between Control Centers;
- Communications devices located between Control Centers;
- “Data at rest” in Control Centers; and
- 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.
It's fantastic that you are getting ideas from this piece of writing as well
ReplyDeleteas from our argument made here.