Since the beginning of 2019, I’ve been
working almost exclusively on helping clients prepare for compliance with NERC
CIP-013. I’ve had a number of “Aha!” moments, when I realized something
important that in retrospect should have been obvious from the beginning. For example,
I’ve known for a long time that three things are true:
- CIP-013 R1 is a
non-prescriptive requirement. It tells the entity to develop a supply
chain cyber security risk management plan (which I once christened
SCCSRMP, taking the idea from Kevin Perry. Since this is the only logical
acronym, I’ve been surprised not to hear anyone use it besides me. This
may be because the most logical pronunciation of it – “Scuzzy Rump” –
sounds vaguely obscene). However, other than saying that the six items in
R1.2 need to be included in the plan, it provides no other direct information,
other than that the plan must address the five areas of 1) procurement of
hardware and software components of BES Cyber Systems; 2) installation of
those components; 3) procurement of services for BCS; 4) use of those
services (I’ll admit this one is a little hard to discern in the wording,
but I promise you it’s there, and R1.2 confirms the SDT had this in mind);
and 5) transitions between vendors of BCS components.
- CIP-013 R2
requires the entity to implement the SCCSRMP. In fact, that is literally
all the requirements says.
- Many NERC entities
have had unfortunate audit experiences with other plan-based CIP
requirements, such as CIP-008 R1, CIP-009 R1, CIP-011 R1, CIP-007 R3 and
CIP-010 R4. These entities have found out the hard way that it’s important
to make sure you implement everything in your plan, regardless of whether
something in the plan is directly stated in the requirement or not. If something
is in the plan, you need to carry it out, or at least document why you
can’t carry it out in a particular instance.
If you had asked me three months ago whether
R2 was also a non-prescriptive requirement, I would probably have said yes,
since it seems logical to say that a requirement to implement a plan that isn’t
prescriptive is non-prescriptive in itself. However, in combining the above
three pieces of information, it dawned on me that this really makes R2 a prescriptive
requirement.
Of course, at first this seems strange (and
it would have seemed strange to me even three months ago). After all, when you
compare CIP-013 R2 to my poster child for a prescriptive requirement, CIP-007
R2 (with CIP-010 R1 a close number two for that coveted title), there’s a huge
difference. CIP-007 R2 tells the entity exactly what they need to do, exactly
when they need to do it, and exactly what systems they need to do it to, for a
set of perhaps ten different actions (some of which aren’t directly stated, but
are implicit when you start looking at the language closely). But CIP-013 R2
just tells you to implement the plan from R1, while R1 tells you nothing about
what actions should be required in that plan, and nothing about the timing of
those actions).
But as I thought about this, I realized there’s
no way R2 could be anything but prescriptive. Since it tells you to implement
the plan, this means the plan itself provides
the set of prescriptive requirements that you have to follow in R2. In other
words, rather than just follow the current wording of R2 (which rivals the
great haiku masters in conciseness),
NERC entities are well advised to effectively “replace” that sparse wording
with the “requirements” included in your SCCSRMP! Then you should comply with
that wording in the same way you comply with other plan-based CIP requirements,
like the five I cited above (BTW, a sixth plan-based requirement is CIP-003-7,
which comes into effect 1/1/20).
But note that I said you need to comply with
R2 as you would with other plan-based
CIP requirements. This was a term I used to use a lot, but now I mostly use the
term ‘risk-based’. At first I thought these referred to two different things,
but in the last couple years I came to realize they’re actually the same thing,
for the following reason:
A plan always has an objective (which is why I
also consider ‘objective-based’ to be synonymous with ‘plan-based’). Unless your
organization has unlimited resources to throw at BES security and NERC CIP, you’ll
always need to choose between measures you will take and measures you won’t
take - because you feel the results achieved by the latter won’t justify the
resources required to achieve them.
And how will you decide which measures you’ll
take and which you won’t? You will either explicitly or implicitly look at risk
– there’s no other way to do it. For each measure, you’ll determine (perhaps
without explicitly considering it) the degree of risk it mitigates. You’ll
choose to implement the measures that mitigate the most risk and not implement
those that implement the least risk (in fact, this pretty neatly describes the first
half of the CIP-013 compliance methodology that I’ve developed with my clients
this year). Because why would you want to spend your resources (money and time)
conducting activities that are less effective, when you could spend the same
amount of resources and mitigate much more risk? Unless you don’t care whether
or not you waste
money, of course.
Since risk-based, plan-based and
objective-based requirements are one and the same, where does the
prescriptive/non-prescriptive dichotomy fit in? I think a non-prescriptive
requirement is the same thing as a risk-based, plan-based or objective-based
one. I simply can’t think of a case where it might be otherwise (although if
anyone can, I’d like to hear about it). And it’s without a doubt true that a
prescriptive requirement could never also be one of these four categories.
What’s the difference between complying with
plan-based requirements like CIP-011 R1 and true prescriptive requirements like
CIP-007 R2? In case you didn’t know this, NERC has a very prescriptive auditing
regime. The reason CIP-007 R2 is so burdensome (it’s by far the
most-complained-about CIP requirement) is that the NERC entity needs to have
documentation of a) every step that was taken, b) for every piece of software
in the ESP(s), and c) every time it was taken, over the entire audit period. So
if an entity has 200 separate software packages in their ESP, and they have to
comply with CIP-007 R2 eleven times a year over the three-year audit period,
this means they need to have 6600 pieces of documentation.
And every NERC compliance professional can
state, while hanging upside down with their hands tied behind their back in their
sleep, the iron rule of NERC compliance: If you didn’t document it, you didn’t
do it. Woe betide the unfortunate person who misses one of those 6600 pieces of
documentation and then is asked to produce exactly that at audit! Yea verily,
all the furies of Hell couldn’t match the anger of that person’s boss, when
told the entity has received a PNC finding because of this![i]
And how do you comply with a plan-based
requirement, especially CIP-013 R2 (since that’s what this post is about)? In
general, you need to decide what are the important elements of your plan and
document that you have a program in place to comply with each element. While you
will certainly have to retain some
documentation of individual instances of compliance, you definitely don’t have
to document every instance in which you complied and every system you complied
for.
And if you’ll wake up our NERC compliance
professional, cut them down from the ceiling and untie their hands, they’ll
agree with you that there’s a big difference between complying with a
prescriptive requirement and a non-prescriptive one, even if they both require
you to take the same set of actions on the same set of systems. So this is one
big advantage of the way CIP-013 R1 and R2 are written.
The second advantage is even bigger: After all,
you are the one that writes your plan. If you think there’s something in your
plan that might be hard for you to comply with (for example, you stated that a
particular action needs to be done every month for every system, regardless of
the risk posed by that system), what you should do is very simple: Take it out. This is perfectly “legal”,
although if you do it after the compliance date, you will need to document why
you did that.
Just try that
with CIP-007 R2!
Any opinions expressed in this blog post are strictly mine
and are not necessarily shared by any of the clients of Tom Alrich LLC.
If you would like to comment on what you have read here, I
would love to hear from you. Please email me at tom@tomalrich.com. Please keep
in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP
issues or challenges like what is discussed in this post – especially on
compliance with CIP-013. My offer of a free webinar on CIP-013, specifically for
your organization, remains open to NERC entities and vendors of hardware or
software components for BES Cyber Systems. To discuss this, you can email me at
the same address.
[i]
In case you’re going to point out that the solution for having to produce so
much audit documentation is to sign on to the Risk-based CMEP program, you can
save your breath. I find it hard to believe this cure isn’t almost as damaging
– in terms of gallons of stomach acid produced while worrying about compliance (the key measure, IMHO) -
as the disease itself.
No comments:
Post a Comment