I have said
more than once that I might as well call this “Tom Alrich and Lew Folkerth’s
Blog”, given the number of times I have written posts about something Lew has
written or said. So, despite the fact that a recent post
was about two articles Lew wrote (and another post shortly before that quoted
him on a different topic), I now find myself writing about what was at the time
an offhand comment he made while addressing other topics. His comment struck me
as quite profound, as well as very serious in its implications regarding the
CIP standards – and also in its implications regarding how NERC entities should
be complying with those standards now.
Lew’s
comment was that he was expecting entities with High or Medium impact BCS to be
self-reporting violations of requirements CIP-007 R2 (patch management) as well
as CIP-010 R1 (configuration management). He specifically said “These two
requirements are so prescriptive that it will be nearly impossible for an
entity of any size to get them right for every system, every time.”
Think about
it. Lew is saying he expects to see most entities self-report violations of
these two requirements – and I would add to what he said the words “assuming
the entity has a good compliance program for these two requirements, which can
identify potential violations in the first place.” what little I know about the
rules of logic tells me that the converse of this statement must also be true,
which I will phrase like this: If an
entity is not self-reporting a number of violations of these two requirements,
this almost certainly isn’t because that entity is some sort of paragon of good
CIP compliance. Rather, it is probably because the entity’s compliance program
for these two requirements is so poor that it doesn’t even know when it is in
violation!
Let me
rephrase this another way (and Lew approves this statement in principle): If
you work for a NERC entity with High and/or Medium impact BES Cyber Systems and
you aren’t self-reporting any
violations of CIP-007 R2 and CIP-010 R1, you need to look closely at your
compliance programs[i]
for these two requirements. It is very likely there is something wrong with one
or both of them.[ii]
But let’s
turn the screw again: What does it mean if we in effect say there is almost no
way an entity could not be
self-reporting violations of these two requirements if it has a good program
for compliance with them? You’re right – it means there is something wrong with
the requirements![iii]
You might think it is that there are problems with the wording, and in one
sense you are right. But I don’t think that’s the root of the problem. I don’t
think there is any wording that would
ever change the situation I’ve just described.
What is at the root of the problem? Let’s
look at what Lew said: these two requirements are “so prescriptive” that it’s
almost impossible to conceive of an entity (with more than a small number of
BCS) being in complete compliance with them.[iv] You
might recall that I’ve been waving the flag lately about the prescriptive
nature of the CIP requirements (and I will continue to do so); I believe this
has resulted in the NERC CIP program becoming unsustainable – for many reasons.
And my poster child for an unsustainable, way-too-prescriptive requirement is
CIP-007 R2, although I may now have to include CIP-010 R1 as the poster child’s
identical twin.
Folks, if
the two most prescriptive CIP requirements (and not all of the CIP requirements
are prescriptive. There are now at least three or four non-prescriptive ones,
including CIP-007 R3 and CIP-010 R4) are literally impossible to completely
comply with, there are only two possible reasons for this. The first is that
the vast majority of CIP compliance people employed by NERC entities are idiots,
and simply can’t figure out how to comply with these requirements. The second
is that there is something really wrong with prescriptive requirements, at
least where cyber security is concerned. I’ll let you decide which of these is
the case, although for my personal answer I’m going to rule out the first
reason offhand, since I know for a fact it isn’t true. That leaves the second
reason, IMHO.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i]
And for a good description of what the CIP-007 R2 compliance process should be,
you should read the article by Lew that I referenced in this
post.
[ii]
I will make the exception for entities with very few Medium or High BCS. When
you don’t have many of these (as well as Protected Cyber Assets), then you
might very well be able to be 100% confident that you are properly complying
with both requirements – or at least the lack of self-reports shouldn’t be
considered prima facie evidence that
you are out of compliance. But if you have hundreds or thousands of BCS and
PCAs and you aren’t self-reporting any violations, you should look closely at
these two programs and make absolutely sure you’re doing everything right. If
you do this and you are still confident you’re in the good, congratulations.
But you should not make this assumption without being absolutely sure these two
programs are bullet-proof.
[iii]
Lew wanted to make it clear that he wasn’t criticizing the CIP v5 SDT for their
drafting of these two requirements. He pointed out that the SDT had originally included
the “Identify, Assess and Correct” language in 17 requirements (including the
two in question here), which would have mitigated most of the bad effects of
overly prescriptive requirements. FERC always had lots of questions
about this language, since they considered it likely to make the CIP v5
requirements un-auditable. So in their Order 791,
they ordered NERC to remove that language (in v6). NERC did this, of course,
but that then left NERC entities exposed to the full force of the cruel, cold
winds blowing from the most prescriptive CIP v5 requirements.
[iv]
I should point out that Lew made that statement during an email exchange
regarding the problem of prescriptive requirements, so it may not be surprising
that he pointed to that as the problem. On the other hand, Lew wouldn’t have
said this if he didn’t mean it.
No comments:
Post a Comment