My previous post
discussed various interesting things I’d learned at RF’s CIP v5 workshop in
Cleveland on October 1 and 2, 2015. In that post, I mentioned there had been a
good conversation at the meeting that I would discuss in my next post. Well,
now it’s the next post, and here’s the story of that conversation.
On the
second day of the meeting, Ron Ross and Frank Kapuscinski of RF gave a presentation
entitled “CIP-002-5.1 Audit Approach”. The presentation was very similar to
presentations on this topic by other NERC Regional Entities; I doubt any CIP
compliance person from any region would have thought there was anything wrong
with it. The bulk of the presentation was dedicated to displaying and
discussing a very large and interesting spreadsheet that constitutes Attachment C for the CIP-002-5.1 RSAW (this file is available on this page, in the CIP Document Library section). It allows the entity to
collect a wealth of detail on its assets and cyber assets – everything that’s
needed to comply with v5.[i]
After the
presentation, I asked Ray Sefchik, who leads RF’s CIP auditors (his title is
Manager, CIP Compliance Monitoring), whether RF would be putting out any document
to clarify the wording in CIP-002-5.1. Ray answered as I thought he would:
“No”. He implied (I can’t remember his exact wording) that it really wasn’t
RF’s job to try to clarify the wording in any NERC standard– and I totally
agree with this. The Regional Entity’s job is to audit compliance with the
wording of the requirement.
However, if
you have happened to read any of the 70-80 (perhaps more) posts I’ve written on
issues with the wording in CIP-002-5.1 over the past two and a half years, or
in particular the first two posts (Part
I and Part
II) in this series on Rewriting CIP-002, you will know I think there are a
huge number of ambiguities and contradictions in this standard (especially in
R1 and Attachment 1). So the question arises, is it actually possible to audit to the strict wording
of this requirement? And if so, what would “the strict wording of the
requirement” mean?
Fortunately,
I don’t need to spell out now what it would mean to audit to the strict wording
of R1; I did that in Part II of this series. There, I started by laying out the
fairly simple five-step process that is how almost all of the regional auditors,
and close to 100% of the compliance people at NERC entities, understand R1 to
work. It was certainly the methodology that lay behind the RF presentation. But
there’s just one problem with this methodology: It isn’t the actual
wording of the requirement.
Further on
in that post, I listed a very complicated 15-step process for compliance with
R1 that is as close to the actual wording as I can get. And I pointed out that
this was just the down payment; to be correct, there is no finite set of steps
that could be written down that would be compliant with the actual wording. You
could write 15 steps or 15,000, and still not have addressed all of the ambiguities
and lacunae in R1 (including its missing definitions, like “programmable”). But
if RF, or any entity, is going to audit to the "strict wording" of CIP-002-5.1
R1, they need to audit based on this complicated methodology, not the simple
five-step one. Of course, no NERC entity is going to follow the complicated
methodology as they comply with CIP v5, and certainly none of the regions are
going to audit based on it; if you don’t believe me, just read the post.
Since the
discussion so far has been fairly abstract, let me point out a few areas where
the presentation and the spreadsheet differ from the strict wording of
CIP-002-5.1 R1:
- First, Todd talked about “assets” being classified as
High, Medium and Low impact. Of course, this is how virtually all NERC
entities started their R1 compliance process, and it’s how all of the
Regions understand the process as well.[ii]
However, nowhere in R1 (or Attachment 1) is the entity told to do this.
What the entity is told to classify are BES Cyber Systems, not assets. R1
sends the user to Attachment 1 to determine the classification of each
BCS, depending on whether the BCS meets
the High, Medium or Low impact criteria. There is nothing about
classifying High or Medium impact assets themselves, only Lows (and even
that is indirect – see the next item). Of course, virtually all entities
and all regions but one (or maybe two) are assuming the first step in R1
compliance is to classify “assets” as High, Medium or Low impact; but this
implicit requirement isn’t found anywhere in the actual wording.
- R1 does tell the user to identify “assets containing Low
impact” BCS – of course, Todd’s presentation used the same wording. Looking
just at that wording, it seems quite clear there is only one way to do
this: a) inventory cyber assets at every
asset (High, Medium and Low impact) owned by the entity; b) identify Cyber
Assets among those; c) identify Cyber Assets that meet the BCA definition;
and d) finally aggregate these into BCS. At that point, the entity will be
able to determine whether an asset – that has not already been identified
as High or Medium impact – “contains” Low BCS. But there’s a problem with
this, since both R1 and Attachment 1 state that no list of BCS is required
for Low assets. So how is the entity going to identify assets containing
Low BCS without identifying BCS? Of course, virtually all entities and
regions are interpreting “assets containing Low BCS” to mean “BES assets
not already identified as High or Medium impact”; with this adjustment,
the meaning is perfectly understandable and doesn’t require a list of Low
BCS. This is fine – but it’s not what the requirement says, or Attachment
1 either.
- Just about all of the regions are telling their members
that they need to identify all of their assets that correspond to one of
the list of six asset types in R1, then “run these through” the Attachment
1 criteria to determine which are High, Medium and Low impact; Todd’s
methodology also started that way. Again, this is a fine idea. But what do
the actual criteria apply to? Let’s see…Criterion 2 applies to “reactive
resources”. I don’t see that on the list of six assets. Criterion 2.3 applies
to “Generation Facilities”. Since Facilities is a defined term, this must
be a single unit in a generating plant, not the plant itself; again, not
on the list. Criteria 2.4, 2.5, 2.7 and 2.8 apply to “Transmission
Facilities”; these are lines, buses, transformers, etc. – but not
substations, so the list of six doesn’t apply to these criteria either. I
could go on…The point is that very few of the criteria actually apply to
one of the six asset types – in fact, the only criteria that do actually
apply to one of those six asset types are those that deal with control
centers. Yet NERC entities are being told by their regions that the
criteria do apply to these six
asset types, directly contradicting what’s actually in black and white in
CIP-002-5.1. Once again, this isn’t a problem in the short term, since the
entities and the regions are in agreement on this point. Also once again, the
problem is this is not what the requirement says, and having this
disconnect will lead to longer-term problems (see below).
There are
lots of other ways in which the widely-accepted methodology for complying with
CIP-002-5.1 R1 directly contradicts the wording of R1 and Attachment 1; in
fact, of the five steps listed in the previous post in this series, all but the first are either
not stated in R1 or are directly contradicted by its wording (I’ll have more to
say on all of these issues as I put out more posts in this series on Rewriting
CIP-002). Again, I’m not criticizing RF or any of the other regions, or any
NERC entities, for using this simple interpretation of R1; indeed, I think it’s
the only way that one can make sense of that requirement. But it is important that everyone throw away
the idea that this interpretation is based on the requirement itself; it just
isn’t. It is literally true that the only practical methodology for complying with
CIP-002-5.1 R1 requires the entity to "rewrite" the wording of the requirement itself.
So what’s to
be done? Should RF and the other regions stop whatever they’re doing and bring
all the auditors together for a month or more, so they can try to figure out
what the wording of R1 actually means and come up with a common audit
methodology – one that conforms as closely as possible to the actual wording of
R1 and Attachment 1? Or should they continue following the fairly simple
methodology that all the entities and regions (and NERC itself) currently
understand to be the correct methodology for R1 – even though this doesn’t
conform to the wording of the requirement?
Obviously,
the latter is the only course to take – the former is completely unworkable.
However, at the same time, I believe someone needs to draft a SAR to rewrite
CIP-002, and the process of rewriting it must begin. But that process will take
probably three years. In the meantime, there needs to be a consensus among
NERC, the regions, and the entities that the simple methodology is the one to
follow (or something close to it – there would actually be a few more steps
required, but they’re all also being followed today).
This also
means that no region, including RF, can truly say it’s auditing to the strict wording
of CIP-002-5.1 R1. There is simply no way to audit R1, other than by coming up
with a workable “interpretation” of how to comply with the requirement. As I
said, the NERC community has actually done that without knowing it. They just
need to acknowledge that this is an interpretation,
not the strict wording of the requirement. And the community needs to start
working on the only real fix to this problem – rewriting CIP-002.
In the
meantime, I hope it’s clear why I’ve been saying for a while that CIP-002-5.1
R1 will never be enforceable until it
is rewritten (other than in the case of an entity that more or less blows it
off and doesn’t even try to comply - I'm sure they will still be issued PVs. I don’t know any like this, but I’m sure a few exist.).
How would any auditor write up an entity for not following a compliance
procedure that isn’t even in the requirement? The only question in my mind is
whether this non-enforceability of R1 (which is after all the fundamental
requirement in CIP v5 and v6) will spread to all of the other requirements.
For the
moment, I’m thinking it won’t – that is, that the other requirements can be
enforced, as long as the stipulation is made that whatever list of BCS the
entity came up with in CIP-002 R1 is valid. But I’m not sure even that will
work in the long run, especially once an entity challenges a large fine by
going to court. And this is the worst part: as long as CIP-002-5.1 R1
remains the current version of the standard, it is very possible that four or
five years from now, the entire v5/v6 edifice will be invalidated by some legal
ruling. And what does the industry do then? Go back to v3? Decide the NERC CIP
experiment has failed and turn cyber regulation over to DoE or DHS? Just give
up on CIP and hope Congress doesn’t notice? Lots of great choices!
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i]
Of course, there is the slight problem that this is probably a year too late to
help most entities. With about five months remaining before the compliance
date, it’s a little late for entities to be identifying cyber assets in scope
for the first time. When available, it will of course help in getting evidence
together for an audit.
[ii]
There are one or two regions that will most likely call the three asset types “assets
likely to contain a High BCS”, “assets likely to contain a Medium BCS” and
“assets likely to contain a Low BCS”. This fits a little better with the
wording of R1, but the fact remains that R1 (or Attachment 1) never tells the
entity to classify assets or “assets
that contain High or Medium BCS” (it does require identification of assets
containing Low BCS). The entity is told to “consider” six asset types, but
those are possible locations where BCS
can be found, not a list of assets to be classified H/M/L. It is the BCS that
are classified H/M/L, not the assets – according to the wording of R1 and Attachment
1. This is because the criteria apply to BCS, not assets. Of course, the fact
that it is impossible to classify BCS without basing that classification on the
asset it’s associated with was overlooked when R1 was drafted. This is the
primary problem in CIP-002 R1, although certainly not the only one.
No comments:
Post a Comment