I eagerly
awaited NERC’s Supply Chain webinar yesterday. I found it was a good webinar on
supply chain security, although the CIP-013 discussion raised more questions in
my mind than it answered.
To start
with the good news, I thought two of the presentations, by my friends Corey
Sellers of Southern Companies and Joe Doetzl of ABB, were excellent – and I’m
looking forward to seeing the slides for their presentations, as well as those
of the other speakers, including Tobias Whitney of NERC. Corey, who is head of
the team that drafted CIP-013 and guided it – with help from others, of course
- through the shoals of four NERC ballots to deliver it to FERC in time to meet
their one-year deadline, spoke mainly about the CIP-013 guidance document that
the North American Transmission Forum (NATF) is putting together. This sounds
like an excellent document, although Corey pointed out that it’s mainly focused
on best practices for supply chain security, not CIP-013 compliance per se.
Joe Doetzl,
who was with KCPL for many years and was an important part of the CSO706
drafting team as they drafted CIP versions 2, 3, 4 and the beginning of v5,
gave a really excellent presentation on what you (i.e. a NERC entity) should
expect from your software vendors (his slides had much more information than he
could get through in his presentation, so I’m especially looking forward to
seeing those).
Now to the
not-so-good news (although I’ll say upfront that this isn’t bad news): I still
have a few fundamental questions about how entities should comply with CIP-013,
and these weren’t answered. Or if they were answered, the answers seem at odds
with what is written in the requirements. Here’s what I mean:
- My biggest question is what should be in the supply chain
cyber security risk management plan, which is of course required by
CIP-013 R1. In the presentations by Tobias and Corey, they focused
exclusively (as far as I could see) on the six items that are required by
R1.2. The implication is that these are the only things that must be in
the plan.
- As I have pointed out in several posts (at least), CIP-013
R1.1 requires the entity to “identify and assess[i]
cyber security risks to the Bulk Electric System” resulting from a) procuring
vendor equipment and software, b) installing vendor equipment and
software, and c) transitions from one vendor to another. The six items in
R1.2 all have to do with a), not with b) or c). And even for a), there are
clearly many more risks to be addressed than the risks underlying the six
items in R1.2. For example, how about the risk that a vendor won’t follow
good security practices for their own network, and will experience a
breach where information on your software and how it is configured is stolen?
This has happened with at least one SCADA vendor in North America in the
past four or five years.
- So is the entity required to identify and assess other
risks than the risks behind the items in R1.2? I’m sure Tobias and Corey
would answer this question in the affirmative, but then the question
becomes “Given that there are a huge number of supply chain security risks
– some with extremely small impact or probability – that could be
identified, how many does the entity have to identify? Is it a certain
number like 10 or 20? Or is it something like “all risks with high impact
and probability”? And if that’s the case, who will determine which risks
meet that description? The auditor? The entity? Someone else?
- CIP-013 R1 is one of a category of what I call “plan-based
requirements” which seem to have found favor with the CIP drafting teams
in the last few years, as the only type of CIP requirement they should
consider drafting. I am all for that, since I think – as do a lot of
others – that the alternative - prescriptive requirements like CIP-007 R2
- just doesn’t work for cyber security, period. But, as I pointed out in this
post (and a few subsequent ones), the only way I can see a plan-based
requirement being successfully audited under NERC’s auditing procedures is
to have criteria for what should be in the plan in the requirement itself. My best example of this is CIP-010
R4, where Attachment 1 (which is called out in R4, and is thus part of the
requirement) provides a very detailed list of items that should be
addressed in the plan for Transient Cyber Assets and Removable Media –
e.g. software vulnerability mitigation, malicious code mitigation, etc.
When reviewing an entity’s CIP-010 R4 plan, the auditor can fairly easily
go through this list and determine whether the entity has addressed (and meaningfully addressed) each item
on the list. Unfortunately, no such list is to be found in CIP-013-1 R1.
- My second question is about the meaning of “mitigation” of
risks (as I pointed out in the first end note below, this word was left
out of R1, but clearly is meant to be in there). As far as I could see,
both Tobias and Corey were only considering vendor contract language as a
mitigation means for the six risks implied in R1.2. Yet, as I’ve pointed
out in two recent posts (this
one and this
one), contract language is only one means of risk mitigation, and IMHO it
isn’t anywhere near the best one.
- But suppose you follow Tobias and Corey (and I’ll readily
admit that both Order 829 and the NERC Implementation Guidance for CIP-013
take the same position as these two gentlemen) and first try to get your
vendors to accept contract language for the six items in R1.2. And suppose
a few of them absolutely refuse to insert the language you ask them to
include. Furthermore, suppose these few vendors are absolutely critical to
your organization, and it would be very disruptive and costly to try to
replace their product with a competitor’s. What do you do then? Do you not
have to do anything more to mitigate[ii]
the risk?
- To answer this question, look at the title of CIP-013:
“Cyber Security – Supply Chain Risk
Management” (my emphasis). You are supposed to manage each risk, not
simply try one particular mitigation strategy and then give up if that
fails. In this
post, an auditor described an alternative strategy – and of course it’s
one of many alternatives – that an entity could use if the vendor refuses
to provide prompt notice of employees who either leave the company or no
longer need access. In my opinion (and the auditor agrees with me), you
need to be prepared to try multiple approaches to mitigating each risk
that you identify.
However, I’m
not waving a red flag yet. CIP-013 hasn’t even been approved by FERC, so there
is still some time to address these questions[iii]. But –
again, in my opinion – these two questions need to be addressed as soon as
possible, since the entities will need to know the answers to both of them
before they start developing their plans.
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. To discuss this, you can email me at the same address
or call me at 312-515-8996.
[i]
As I pointed out in this
post, it seems an important word was left out here: mitigate. Your plan must
describe how you will identify and assess risks, but the plan doesn’t have to
say a word about what you will do about those risks! And since R2 just requires
implementation of the plan, mitigation doesn’t automatically come in there,
either. Of course, all of the other documents related to CIP-013, including
FERC’s Order 829 and the NERC Implementation Guidance, make it abundantly clear
that mitigation of these risks is the purpose of the standard – so I don’t
recommend that you decide to stonewall it and only include identification and
assessment of risks in your plan! But this does need to be fixed at some point.
Assuming FERC orders some changes to CIP-013-1, as their NOPR
strongly hinted they would, this should be included in the SAR for CIP-013-2.
[ii]
Tobias seemed to strongly indicate this was the case, when he talked about what
to do if a vendor won’t provide a means to authenticate identity and integrity
of vendor-supplied software and patches. He didn’t talk about anything else you
could do to mitigate the risk of a bad actor inserting malware into a patch,
when there are clearly other things you could do (ask to download the patch
from a secure FTP site, ask the vendor to burn the patch on a CD and overnight
it to you, etc). BTW, I wasn’t able to ask a question about this because it was
announced at the beginning of the webinar that there wouldn’t be time for
questions from the online webinar audience.
[iii]
Although the fact that FERC wants to shorten the implementation time for
CIP-013 from 18 to 12 months, and that I believe they’ll approve the standard
in Q2, means there isn’t much time remaining.
No comments:
Post a Comment