I have
mentioned in at least a few posts the idea of “implicit requirements” in CIP v5
– that is, things an entity needs to do to comply with the written
requirements, that aren’t actually stated as requirements. I believe I have
also acknowledged (at least I hope I have) that this idea wasn’t mine but that
of Lew Folkerth, Principal Reliability Consultant with RF.
Even though
I may not always have identified them as such, my posts on CIP v5 have been
loaded with implicit requirements – to identify Cyber Assets, BES Cyber Assets
and BES Cyber Systems in CIP-005-5.1 R1; to develop and document a methodology
for determining whether there is External Routable Connectivity for substation
relays that are connected to a device like an RTU which is then connected
through IP to a control center; etc. I have even put together a document
listing all of the implicit requirements I have so far identified in v5 (it is
growing all the time, of course).[i]
At RF’s CIP
v5 workshop
in Cleveland on October 1, 2015, Lew – in response to a question – said he
would “look into” preparing a list of implicit requirements in v5. He published
an article in the most recent RF newsletter
(pages 8 and 9) in which he discusses what he found when he did look into this.
As with everything else Lew writes on CIP, I strongly recommend you read this
article, whether or not you’re in RF (there is nothing in it that just pertains
to RF. In fact, I don’t recall anything he’s written on v5 that doesn’t apply
to all NERC entities, no matter which Regional Entity they’re part of. I
believe you can find the archived newsletters on the RF site; Lew’s articles
are always under the heading “The Lighthouse”).
Lew admits
up front that he doesn’t have a list of implicit requirements to provide.
Moreover, he admits he will not be providing one in the future, either. This is
because “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.”
You may
wonder why Lew can’t provide at least an incomplete list – after all, wouldn’t
it be better to have a partial list of implied requirements than no list at
all? I believe the answer to this question (although I haven’t discussed it
with Lew) is that, if someone in NERC (and of course, the Regional Entities are
all part of NERC, or the “ERO Enterprise”) provides a partial list of implied
requirements, entities will complain if they are later cited for missing an
implied requirement that isn’t on that list. There is really no way he can
provide this list, given his current job responsibilities.
I find the
above statement of Lew’s to be very significant for another reason: I think it raises serious doubts about whether NERC CIP version 5 can
ever be “enforceable” in the strict sense of being upheld in the US court
system. I will have more to say on this point (a lot more, in fact) in one of
my next posts. However, I also do have a few comments on Lew’s article, which
I’ll discuss now.
Lew states
close to the beginning of his article that “Implied requirements are a
consequence of writing CIP Version 5 as results-based Standards.” This is an
interesting idea, but I believe it’s contradicted in the section titled
“Sources of Implied Requirements”. In that section, he lists four cases in
which implied requirements can arise. I agree with everything he says in this
section, but note that the second of these four cases is “Results-Based
Specification”. If this is only one of four ways in which implied requirements
arise, how can Lew’s initial statement that implied requirements arise from
“results-based standards” be true, since it clearly is meant to apply to all
implicit requirements? My personal opinion is that the only general statement
that can be made about all implicit requirements in CIP v5 is what I said in
the first sentence of this post - they are things an entity must do to comply
with one or more v5 requirements, which are not themselves stated in a
requirement.[ii]
As I said, I
do completely agree with the section entitled “Sources of Implied
Requirements”. Lew wrote this section to give entities a way to identify
implied requirements on their own. Since he can’t provide them with his own
list, this is obviously the next best thing that he can do. I think all of the
four “sources of implied requirements” he lists can definitely lead to implicit requirements, although
I would think there are some implicit requirements that don’t spring from one
of these sources.[iii]
However, I
don’t agree with the next section of the article, “Failure to Comply with an
Implied Requirement”. It states in part “If an implied requirement is violated,
an audit team will return a finding for the Requirement that is supported by
the implied requirement. Since an implied requirement may support multiple
Requirements, a violation of the implied requirement may result in multiple
audit findings. An example of this would be the failure to identify and protect
an EACMS associated with a high impact BES Cyber System. Failure to identify
and protect each EACMS could potentially result in an audit finding in 64 Parts
of 18 different Requirements.”
I agree that
there are some implied requirements – like the implied requirement to identify
all EACMS associated with high BCS – which are quite evident. If you’re not
required to identify your EACMS, how could you possibly comply with all the
requirements that apply to EACMS? If you don’t identify your EACMS out of pure
stubbornness, I can see a PV is justified. But there are other implicit
requirements that are not clearly implied at all.
For example,
I think every Regional Entity will require that an entity being audited present
a list of “Medium impact” substations, or more correctly “substations that
contain at least one Medium impact BES Cyber System”. This is an implied
requirement, but it is also not one that can be easily identified from the
wording of CIP-002-5.1 R1 or Attachment 1 (in fact, I believe it can’t be identified from that wording[iv]).
In a case
like this, I think it would be very hard for an auditor to actually issue a PV
for violating that implicit requirement. My guess is, if the entity doesn’t
have the list of Medium substations, the auditor will simply ask them to draw
one up.
And going
back to Lew’s example of an entity that failed to identify one or more EACMS
and thus didn’t comply with 64 parts of 18 requirements, I find it very hard to
believe they would receive any PVs at all because of this – unless they had
simply pretended that they didn’t have to identify any EACMS and therefore none
of the requirements that apply to EACMS applied to them. Except in that extreme
case, I think most failures to identify EACMS will be caused by confusion over
what exactly the definition applies to (or perhaps whether or not ERC is
present); and as I’ve said in several posts including this
recent one, I don’t think any PVs will be issued for these cases until there is
general agreement in the NERC community on the many areas of ambiguity in v5 –
which will probably be at least a year after April 1, 2016.[v]
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i] Deloitte Advisory provides this document to entities that decide to take advantage of the free
CIP v5 Quick Check, described in this
post.
[ii]
I also disagree with the example Lew uses to illustrate a “results-based
specification”. It is CIP-002-5.1 R1. I disagree that this requirement is
“results-based”. As I discussed in this
post from 2014 (in the section labelled “Issue 4”), because of the ambiguities
and missing definitions in R1, there can never be a definitive statement of
what results are required by R1, other than to get into a curious argument: a)
R1 requires the entity to properly identify and classify its BES Cyber Systems.
How does the auditor determine whether or not the entity has done this
properly?; b) The auditor needs to determine whether they have properly
followed the procedure described in the requirement; c) But Lew has just said
that much of what is required by R1 is implicit – how can the auditor possibly
say they have followed the correct procedure or not, other than to use his or
her own personal judgment?
I followed up the 2014 post with this
post, which made the point that calling CIP-002-5.1 R1 a “results-based”
requirement leads to a completely circular argument, where a correct “result”
of the requirement can only be determined by whether or not the requirement has
been “properly” followed – and the only way to determine whether it has been
properly followed is to know what the result should be!
[iii]
My guess is some implicit requirements are implicit simply because the
Standards Drafting Team didn’t think to include them; there is simply no
further reason. Someday I would like to go through my list to see which
implicit requirements are due to one of Lew’s “sources of implied requirements”, and which ones are
simply there because of SDT error.
[iv]
The reason this is the case is that the criteria that apply to substations –
2.4 through 2.8 – all use the word Facilities as their subject. A Facility is a
line, transformer, etc. – but not the substation itself. Literally every entity
or auditor that I have talked to either a) thinks “Facility” means the
substation or b) knows that it doesn’t, but is choosing to treat it that way
because of the complications of trying to classify BCS in a substation
according to the Facility they’re associated with, not the substation itself.
Effectively, these criteria do apply to substations, and a list of Medium
substations is implicitly required. On the other hand, this isn’t what the
wording says.
[v]
There is another consideration here: I believe there has been some sort of
unofficial doctrine in place among the CIP auditors since CIP v3, to the effect
that a failure to identify a particular cyber asset in scope (e.g. a Critical
Cyber Asset under v3 or a BCS under v5) will at most lead to a PV for violating
the original identification requirement (CIP-002-3 R3 or CIP-002-5.1 R1), but
not to PV’s for missing other requirements due to not having identified that
cyber asset as in scope. If that is the case, then at worst the entity would
receive a single PV for not having identified an EACMS – and frankly, even that
is hard to support since there is no requirement that even implies EACMS need
to be identified. If a PV is issued for not identifying an EACMS, what
requirement would it apply to?
No comments:
Post a Comment