If you’ve
read the first two posts in this series (here
and here),
you realize that for these posts I’ve tried to forget everything I know or have
written about CIP-013, and just work through the words of the requirements (and
the Purpose statement at the beginning of the standard). My goal has been to
mine what is actually written in the requirements and get it all out on the
table. The reason I’m doing this is because nothing is binding on the auditors
(and therefore on the NERC entity) except what is in the requirements. So it’s
important to put in a lot of effort to pull apart the requirements to find
everything that’s possible to find in them – before we start going beyond what
the wording says and start to think about the best way to actually comply with
the requirements.
In our last
episode, we wallowed in R1 and found – to my genuine surprise – that there is
something important missing from R1.1: While this requirement mandates that the
NERC entity “identify and assess” cyber security risks in the supply chain, it
doesn’t require them to do anything about them! Of course, this is clearly just
a mistake, and I highly recommended that everyone assume the word “mitigate” is
also in there, whether or not this problem ever gets fixed in a formal manner.
Now we’re
ready to go on to R2, which on the surface seems quite simple:
R2.
Each Responsible Entity shall implement its supply chain cyber security
risk management plan(s) specified in Requirement R1.
Is this
really that simple? Yes and no. It isn’t simple because of what I just pointed
out about R1.1: Your supply chain cyber security plan must include mitigation
of the risks you’ve identified and assessed, even though that step isn’t included
in the requirement part; so you need to mitigate risks when you implement the
plan as well. But it is simple because it doesn’t mandate anything about how
the plan needs to be implemented.
It seems you’re
on your own in this requirement. You have to implement the plan, but you might
take one year or 50 years. You might complete one part before starting on the
next one, or you might address all parts simultaneously and try to complete
them all at the same time. You might prototype your plan in one part of the
company before moving it to others, etc. It seems the details are all up to
you.
Indeed, this
idea is reinforced in spades by the Implementation Guidance document put out by
the CIP-013 drafting team last year. The document says literally nothing about
what must be done to implement the plan, beyond repeating the substance of the
note that appears below R2, emphasizing that the entity isn’t required to
renegotiate or abrogate existing vendor contracts. It seems the drafting team
couldn’t think of anything important to say about implementation.
However, let’s
be realistic: The details of implementing a NERC CIP standard are never up to
you. Last fall, I looked at the industry’s early experience with audits of
CIP-014; like CIP-013, this standard requires the entity to develop a plan (in
this case, a physical security plan for key substations) and then implement it.
In two posts (here
and here),
I told several stories that point to the same conclusion: Even though R2 lacks
any details about what constitutes a good vs. a bad implementation, the auditors
are going to have their own ideas, and they won’t hesitate to make these known
to the entity if they think they haven’t done a good job of implementation[i]. They
hopefully won’t actually issue a Potential Non-Compliance (PNC) finding, as
they did to one of the entities discussed in the second post. But they will very
likely identify an Area of Concern and require the entity to fix the problem
identified.
So what are the
auditors going to look to when they decide whether or not an entity has
properly implemented their supply chain cyber security risk management plan
from CIP-013 R1? Darned if I know, but there is one thing of which I’m sure: I’m
sure that auditors will look at the actual timeline for completing the
implementation, and how that compares with what is in the plan.
Say your
plan lays out a two-year implementation schedule, and your next audit is
scheduled for about 1 ½ years after you start the implementation. If the
auditors show up on that date and decide there’s no way your implementation can
be completed by the two-year mark, they will very likely issue an Area of
Concern, meaning you will need to develop a new plan with a realistic implementation
date. And you’d better make that new date, or you’ll be in trouble three years
later at your next audit.
So what does
this mean for your plan? Should you always sandbag the finish date in the plan,
making it at least a year or two after the date you think you’ll really finish?
I don’t really think this is a great idea. I think you should include in your
plan what you honestly believe is the date you will finish your implementation.
However, I also think you should keep very close tabs on the implementation.
Whenever it begins to look like you will not be able to meet your original
finish date, you should immediately revise the plan to reflect the new date (of
course, you should have change control to document that you made this change. You
certainly don’t want to be in the position of needing to convince the auditor that
the revised plan was actually the original one!).
Of course,
if the auditor doesn’t agree with your excuse for why the implementation date
had to be moved back (e.g. “My dog ate our supply chain cyber security risk
management plan and we didn’t have any backup. This forced a six-month
implementation delay as we re-drafted the plan from scratch.”), they may
disagree with you. But IMHO there is no way they can issue you a PNC because of
this, since R2 is completely silent on what characterizes a good vs. a bad
implementation.[ii]
What’s the
moral of this story? Even though R2 looks like it’s wide open to whatever
interpretation you might want to give it, this doesn’t mean you should simply
do whatever you want when you implement your supply chain cyber security risk
management plan. The auditors will
always have their idea of how a plan should be implemented. It is almost
certain that they will make their ideas clear to you in your audit, even if –
hopefully – they don’t resort to a PNC to do that.
But what if
it didn’t need to be this way? What if there were a way you could get your auditors
(or at least your Regional Entity) to weigh in on whether and how your plan
should be changed, before you started
to implement it? That is the question I discussed in this
recent post. There needs to be some way a NERC entity can get their CIP-013 R1
plan reviewed by their Region before they embark on implementing it. Moreover,
there needs to be some way the Region can check in on the implementation of
that plan as it is in progress, to make sure the entity hasn’t made some big
mistake that might force it to re-do some or all of what it has already done.
The post
described, with the assistance of an auditor, the Entity Development teams that
are already implemented in one NERC Region and being implemented in another.
The members of these teams aren’t auditors, but they help entities comply with the
NERC CIP standards (and possibly other NERC standards). It seems to me that
these teams would be the ideal organization to review an entity’s CIP-013 R1
plan as well as its implementation, before the entity has invested a sizable
sum in implementation of what could turn out to be a flawed plan
I believe
that some mechanism like this needs to be in place, in order for CIP-013 (as
well as other plan-based standards like CIP-014 and the upcoming CIP-012, along
with plan-based requirements like CIP-003 R2 and CIP-010 R4) to be successful.
I hope you agree with me on this (and if not, that you’ll let me know). I hope
NERC does, too!
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
Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed
in this post. You can email me at the same address or call me at 312-515-8996.
[i]
To be honest, the auditor issues in the second of the two posts cited (i.e.
Part 3 of the series on lessons from CIP-014) had to do mostly with the plan
itself, not with its implementation. But that is just because of timing: The
two audits discussed in that post both occurred before the entity had even been
able to start to implement their plan. Of course, this was very beneficial, since
– had they implemented the plan, which was later determined to be insufficient,
they might have been forced to re-do some or all of their implementation, using
a new plan that was deemed sufficient.
[ii]
They might conceivably issue you a PNC for violating CIP-011 R1.2, since the
plan presumably included BES Cyber System Information and you obviously didn’t
have a very good plan for protecting BCSI from your dog.
No comments:
Post a Comment