January 31: I recently
wrote a post
that made the case that compliance after April 1 with CIP v5 (and v6) will be
quite different from what compliance with CIP versions 1 through 3 was after
their compliance dates. The post went on to describe how I thought NERC
entities should approach compliance with v5. However, I decided that the second
part of that post (the compliance approach) needed to be rewritten, which I’ve
done here. I’ve also made some lesser changes to the first part. Thus, this
post entirely replaces the previous one.
Introduction
What happens on April 1? My guess is you will give one of three answers:
1. NERC CIP version 5 comes into effect;
2. It’s April Fool’s Day; or
3. Some combination of these two.
My personal preference would be the third answer. CIP v5 does come into
effect on April 1, but this time is very different from when previous CIP
versions (or other NERC standards) have come into effect. What will entities
need to do on (and after) April 1, that they didn’t need to do in previous CIP
versions?
The reason CIP v5 (and when I say CIP v5, I mean v5 and v6) is so
different is that there are many areas of uncertainty regarding what the
requirements mean, and many entities are far behind where they should be in
preparing for the compliance date – because they have been expecting/hoping for
some clear guidance, which hasn’t shown up. Of course, I’ve been saying this
since 2013, but here are three recent pieces of evidence:
First, I recently wrote a post discussing
a recent article written by Lew Folkerth of RF on the idea of “implicit
requirements” in CIP v5. Lew had stated last October at an RF meeting that he
was going to work on a list of these implicit requirements. However, in his
article he said, “My opinion is that we may never be able to achieve a complete
list of implied requirements; the more we mature in our understanding of CIP
Version 5, the more implied requirements we will find.”
Think about this. Lew has been saying for a while (and I picked up his
banner) that there are a lot of things an entity needs to do to comply with CIP
v5 that aren’t actually written in the standards. Now he’s saying that it will
probably never be possible to produce a complete list of these items. In other
words, there will probably never be a complete list of what an entity needs to
do to comply with CIP version 5!
Second, in a recent post I
republished a news article on the run-up to CIP v5. That article made a point
that both Lew and I have made repeatedly for more than a year: For areas of the
CIP v5 standards where there is ambiguity in the requirements or definitions,
the only choice the entity has is to determine for themselves the right
interpretation. But they need to document their interpretation and how they
arrived at it – and they need especially to show they’ve considered whatever
guidance NERC or their region has put out, even if they didn’t actually follow
that guidance.
Third, on January 19 I listened to a NERC webinar on “Future CIP
Standards Development”. NERC officially announced that a number of issues (more
than eight) in CIP v5 will be referred to the current CIP v5 Revisions
Standards Drafting Team for development of revised or new standards or
definitions. This in itself wasn’t a surprise, since NERC has been saying this
would happen for more than a month. What was surprising was that the drafting
team will be addressing what I think are probably the three most fundamental
areas of ambiguity in CIP v5:
1. The definition of Cyber Asset, especially the
meaning of “programmable”.[i] I
have written a number of posts on this issue, but the one I like best is still
the first
one.
2. The definition of BES Cyber Asset, and
especially the meaning of “adverse impact” in that definition. I have written
several posts on that topic, but the best is here.
3. The concept of External Routable Connectivity.
My last post on ERC was this one.
However, just like with “programmable”, I no longer think there can ever be a
dictionary-style definition of ERC that will address all of the current
questions. There will need to be a list describing different cases (presumably
with diagrams): “In case A, there is ERC; in case B, there isn’t ERC; in case
C….etc.” This is similar to the discussion of LERC in the Guidance and
Technical Basis section of CIP-003-6.
So I’m happy that the SDT is actually going to address some of the basic
problems[ii] in
CIP v5. Of course, this means it will easily be three to four years before the
new standards and definitions are drafted, approved by NERC and approved
(maybe) by FERC. Until then, NERC entities will have to resolve each of the
above areas of ambiguity to their own satisfaction and document how they
resolved them. In addition, each entity will need to document that they
considered all available NERC guidance in arriving at their own “definition”,
and that this was applied consistently across their assets (for example, both
Generation and T&D need to use the same “definition” of “programmable” in
deciding which devices are Cyber Assets and which aren’t).
Let’s get back to my question above: What do entities need to do
starting this April that is different from what they did to comply with
previous CIP versions? As I’ve just shown, there are explicit and implicit
requirements in v5. Let’s discuss these separately.
Addressing Explicit Requirements
Explicit requirements are ones that are stated in the CIP v5 (or v6)
standards. If the requirement has a number like R1, R2 etc. in front of it,
it’s an explicit requirement. However, there are two types of explicit
requirements: clear and ambiguous. While the line between these two types isn’t
a clear one, in general a clear requirement is one about which there is no
fundamental debate. For example, CIP-007-6 R2 Patch Management is fairly clear
in its concepts, although there is some disagreement around the edges. An entity
that decides to take 60 days to evaluate new security patches for
applicability, rather than the 35 days in the requirement, will most likely
receive a PV. It would be very hard for them to argue that the requirement
isn’t clear on this point.
An example of an ambiguous explicit requirement is CIP-002-5.1 R1. I
have expended billions of perfectly good electrons discussing the problems with
that requirement; a recent post is here.
Another example is any requirement, like CIP-007-6 R1, where External Routable
Connectivity is mentioned in the Applicability section. Since the definition of
ERC has been turned over to the Standards Drafting Team to rewrite (presumably
in CIP version 7), its ambiguity[iii] will
never be resolved until that effort is completed and approved, easily 3-4 years
from now.
For “clear” explicit requirements, you need to comply with them
in the same way you did for requirements in CIP versions 1-3: Develop and
document procedures for compliance, and make sure the procedures are applied to
all of your cyber assets that are covered by the requirement in question. If
you won’t be fully compliant with one of these requirements on April 1, you need
to self-report a violation and work as quickly as possible to come into full
compliance. A PV may be issued, whether you self-report a violation or it is
discovered during an audit.
For ambiguous explicit requirements, you first have to develop and
document how you have resolved the ambiguity. To use the example above, for
CIP-002-5.1 R1 you need to develop and document your own methodology for
identification and classification of BES assets and BES Cyber Systems. This
needs to take advantage of whatever guidance has been provided by NERC or your
region, but at the end of the day it is your entity that must make the decision
on what is the best methodology, since the wording of the requirement itself
(and Attachment 1) is ambiguous and contradictory. You also need to document
that this methodology has been applied on a consistent basis across all of your
assets.
If you have taken these steps by April 1, you don’t need to self-report
anything. However, if you simply have not finished this methodology by April 1,
and/or you haven’t finished applying it to all of your assets in scope, I
believe you do need to self-report that you are in violation and work as
quickly as possible to come into compliance. In other words, for requirements
that are explicit but ambiguous, you need to resolve the ambiguity in some way
and proceed with complying with the requirement. You won’t get a pass from your
auditor if you say you just couldn’t figure the requirement out, so you didn’t
do anything at all.
Addressing Implicit Requirements
It’s a different story for the implicit requirements. First, you need to
identify them. How do you do this? You think about how you comply with each
explicit requirement, and you look for steps you need to take that aren’t
specifically stated in the requirement. For example, you may have noticed that,
while the Applicability sections of many requirements list Protected Cyber
Assets, EACMS, and PACS as devices to which they may apply, you are never
required to identify these in the first place. So identifying them is an
implicit requirement.[iv]
It would certainly help if there were a definitive list of implicit
requirements. However, as I mentioned above, Lew Folkerth now says there can
never be such a list; I agree with him.[v] It is up
to each entity to identify implicit requirements and document how it dealt with
each one. You can find implicit requirements discussed in many documents, such
as the NERC Lessons Learned and in many of my posts. They aren’t usually
identified as implicit requirements, but here is a rough “field guide” to some
of the primary types:
1. If you have to develop your
own definition in order to comply with a requirement, doing so is an implicit
requirement. Examples of this are the word “Programmable” in the Cyber Asset
definition; “adverse impact on the BES” in the BES Cyber Asset definition;
“External Routable Connectivity” when the communications stream to a device
includes both routable and non-routable components; and “custom software” in
CIP-010-2 R1. For all of these, you have to develop and document your own
definition. In addition, you need to document that the definition was applied
consistently across your assets. Keep in mind that the “definition” will often
not be dictionary-style, but will probably be a procedure for identifying
something, as in the “programmable” procedure discussed in this
post.
2. In other cases, the entity
will have to develop a list, for example lists of PCAs, EACMS, and PACS. As I
discussed above, even though many requirements apply to these cyber asset
types, there is no requirement to actually identify and list them in the first
place. That requirement is implicit.
3. In a number of cases,
the entity needs to develop and document a methodology. For example, there is
no explicit requirement in CIP-002-5.1 to identify BES Cyber Systems, so the
requirement itself provides no guidance on how you can do that. It’s up to you
to read whatever you can about this (including the Guidance and Technical Basis
for CIP-002-5.1, rogue blog posts like this
one, and the Lesson
Learned just released by NERC, which primarily relates to identifying Cyber
Assets) and develop your own methodology. You also need to show that you applied
that methodology consistently in identifying your BCS.
4. Some implicit requirements
follow from actual requirements by simply applying common sense. One good
example (borrowed from an EnergySec webinar) is the fact that CIP-003-6 R1
requires an annual review of cyber security policies, but doesn’t require the
entity to change a policy if the review finds the need for a change. Of course,
common sense dictates you should make the change.
5. There is a whole class of
implicit requirements that deals with virtualization. Since virtualization
wasn’t considered at all in developing the CIP v5 standards, the entity has to
think about what makes the most sense if they have virtual machines or virtual
switching. This is one of the topics that the drafting team will take up, so
there will be no official word on this topic for years. However, NERC provided
some “implicit guidance” in a recent document that I discussed in this post.
If you have any virtualization within your ESPs, you need to address that in
some way in CIP v5, not simply pretend it’s not there.
So there is a lot of work that needs to be done to comply with the
implicit requirements in CIP v5, starting with the fact that there is not now,
and never will be, an official list of these requirements. I think there are at
least 150 different types of documentation required for CIP v5, and my guess is
half of these are due to implicit requirements. This is primarily why I say the
paperwork burden for CIP v5 is greater by some factor (at least three or four, in some cases a lot more than that)
than the burden for CIP v3, even when you allow for the fact that there are many more cyber assets in scope for v5 than for v3.
I don’t believe PVs will ever be issued directly for violation of
implicit requirements. However, since an implicit requirement is always part of
complying with an explicit requirement, you will almost always have to
self-report a violation of the latter. For example, if your entity doesn’t
develop a consistent methodology for identifying and classifying BES Cyber
Systems (an implicit requirement), but instead lets each group in your organization determine for
themselves how to do this, this would probably be interpreted as a violation of
CIP-002-5.1 R1 - since your entity would be identifying BES Cyber Assets
differently in different instances.
If you have complied with an implicit requirement but just have not yet documented
that fact, you don’t need to self-report anything. Going back to the example of
identifying PACS, EACMS and PCAs, you don’t have to self-report on April 1 if
you haven’t documented your methodology for identifying these devices, since
this is an implicit requirement. On the other hand, if you haven’t documented
your methodology because you don’t have one and you have just been identifying
these devices willy-nilly, you will need to self-report that, since you haven’t
identified these three items consistently and this will affect your compliance
with a number of explicit requirements.
Wrapping Up
The purpose of this post has been to show that the answer to the
question “What do I have to do regarding CIP v5 after April 1, 2016?” is much
more complex than it was with previous CIP versions. This is primarily because
of the large number of ambiguous and implicit requirements in CIP v5, and the
documentation needed to “comply” with them.
To summarize what I’ve said,
1. “Clear” explicit requirements need to be
treated as they always have been in previous CIP versions. Self-reports are
required for any areas in which you know (or suspect) you aren’t compliant, and
PVs may be issued.
2. To be compliant with an
ambiguous explicit requirement, you need to resolve the ambiguity to the best
of your ability (e.g. by developing your own methodology for identifying BES
Cyber Systems, since CIP-002-5.1 R1 doesn’t provide any guidance on that),
document how you resolved the ambiguity, and make sure you have applied this
consistently to all cyber assets. If you haven’t done this, you aren’t
compliant with that requirement, and need to self-report.
2. You need to document how you complied with an
implicit requirement, although you don’t have to make a self-report if the
documentation isn’t in place on April 1. However, if you haven’t fully complied
with an implicit requirement, it is very likely you have violated an explicit
one (as in the two examples above); you will need to self-report that.
Feb. 3: I felt I hadn't actually answered the question in the heading in this post, so I published a follow-on to this post here.
Feb. 3: I felt I hadn't actually answered the question in the heading in this post, so I published a follow-on to this post here.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i] I certainly hope the SDT doesn’t
limit themselves to just defining Programmable. I think they should consider
what would be the best definition of Cyber Asset, which might not even include
that word. I also think that it will ultimately be impossible to come up with a
“definition” of Cyber Asset in the dictionary sense of the word. The only
approach that will work, in my opinion, is some sort of list, for example
“Devices with one or more of the following characteristics are Cyber Assets.”
[ii]
When I say “basic problems” here, you may wonder how this relates to my
recent post where
I said it was time to start dealing with the “fundamental problem” with the CIP
standards – namely, that they are prescriptive, while cyber security is much
better addressed with risk-based standards. I regret to say that the SDT’s
efforts won’t address this fundamental problem; only a complete rewrite of CIP
(in a form something like CIP-014) would do that. My preference would be that
NERC (and I guess FERC) decide to do that complete rewrite now. However, other
than my kids and my barber, I don’t know anyone who is wholly in agreement with
this idea yet. It will take a while to build up a constituency for this change.
If the CIP v5 framework will be around for a number of years (not my
preference!), it is still important to try to get the foundation as solid as
possible, so the work that the SDT will do is important.
[iii]
When I say the ERC concept is ambiguous, I need to point out it is only
ambiguous in the case where the communications stream between a Cyber Asset
like a relay and the control center includes both routable and non-routable
(serial) components. If the stream is entirely routable or entirely serial,
there is no ambiguity. In the former case, there is ERC; in the latter, there
isn’t.
[iv]
For that matter, you are never required to identify BES Cyber Assets or BES
Cyber Systems, either. Where the word “identify” is used in CIP-002-5.1 R1.1 –
R1.3, it really means to classify them after they have been identified. In
developing your CIP-002-5.1 R1 compliance methodology (discussed under explicit
requirements), you will need to show how you will identify BCS in the first
place. I have written a lot about this problem, including in this
post.
[v]
I have developed a list of implicit requirements over the last five or six
months, and I am continually adding to it. We at Deloitte Advisory provide it
as part of the free CIP v5 workshops
we have done with a number of entities in the past few months – and are
continuing to do now. If you might be interested in doing this, please email me
at talrich@deloitte.com.
