January 31: I realized this post had missed the boat in several important ways, so I rewrote it here. I don't believe in removing posts, but there is no longer any reason to read this one.
Introduction
Introduction
I think anybody who
reads this blog will answer the question in the title in one of three ways:
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 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 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. Again, there will need to be a list: “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 the basic problems[ii] in CIP v5. Of course, this means it will
be easily 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 treat all of the above areas of ambiguity as implicit
requirements for the entity to resolve to its own satisfaction, and to document
how it resolved them.
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
I call requirements
explicit when there isn’t any fundamental ambiguity in them. For example,
CIP-007-6 R2 lays out a process the entity needs to follow for patch
management. I won’t say it’s crystal clear, and I know there has been a lot of
discussion at regional meetings about what it means. But I believe the
parameters are clear enough (35 days, etc) that entities have a good road map
on how to comply. I believe the majority of the requirements in CIP v5 are
quite clear, and don’t implicitly require any unstated “requirements”.
So for explicit
requirements, I believe the entity needs to have all of their procedures in
place and documented on April 1. If they don’t, they will need to submit a
self-report and try as quickly as possible to develop and document their
procedures. In other words, they need to do what they had to do with previous
CIP versions, as well as with other NERC standards.
If an entity hasn’t complied
with an explicit requirement of CIP v5, I believe a PV might be issued, just as
in previous CIP versions.
Addressing Implicit
Requirements
It’s a different story
for the implicit requirements. For all of these (and I realize I’m not
providing a list here, since as Lew says there can be no complete list. I have
discussed a lot of these in blog posts over the past three years, although I
haven’t usually referred to them as implicit requirements), it is up to the
entity to decide how to address each one. For example:
1. Sometimes the entity will have to develop their
own “definition” (like for “Programmable”, ERC, “custom software” in CIP-010-2
R1, etc), in order to comply with an implicit requirement.
2. In other cases, the entity will have to develop
a list, for example lists of PCAs, EACMS, EAPs and PACS. 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 still other cases, the entity will need to
document how they are interpreting a particular phrase, like “adverse impact on
the BES” in the BES Cyber Asset definition. Again, this doesn’t have to be a
dictionary-type interpretation, but could be a procedure for determining
whether or not there is adverse impact. You also need to document that you
applied this procedure consistently in identifying your BCAs.
4. 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 in the first place, 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 rogue blog posts like this one) and develop your own methodology. You also need to show that you
applied it consistently in identifying your BCS.
5. 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.
6. 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 with 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) than the burden for CIP
v3.
However, I don’t believe
PVs will ever be issued for violation of implicit requirements – unless that
leads to a violation of an explicit requirement. For example, if your entity
doesn’t develop a consistent definition of “programmable” but instead lets each
group determine for themselves what this word means, this could possibly be
interpreted as a violation of CIP-002-5.1 R1 because your entity would be
identifying BES Cyber Assets differently in different instances.
Of course, there is no
requirement to self-report a violation of an implicit requirement unless it
leads to a violation of an explicit requirement, as I’ve just discussed. For
example, this means the entity doesn’t have to self-report that it doesn’t have
its definition of “programmable” documented on April 1. However, the entity
still has to apply that definition consistently across all its High and Medium
assets, and document that it has done so.
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
implicit requirements in CIP v5, and the documentation needed to “comply” with
them.
To summarize what I’ve
said,
1.
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.
Implicit requirements
will not generally lead to PVs or self-reports, except in the case where
violation of an implicit requirement leads to violation of an explicit one.
However, they need to be complied with and documented before an audit, and the
entity needs to show that any definitions or methodologies shown were applied
consistently.
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 the SDT decided 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 important to try to get the
foundation as solid as possible, so the work that the SDT will do is important.
No comments:
Post a Comment