This is the
second in a series of posts on NERC CIP-013, the upcoming supply chain security
management standard. In the first
post, I tried to empty my head of everything I already knew (or had
opinions on) about CIP-013, and tried to focus on just what was written in the
standard itself. I started with the statement of the standard’s purpose, and
tried to tease out of that some good pointers on what will be required to
comply with the standard. Just analyzing this single sentence showed that
complying with CIP-013 will be very different from complying with any previous
CIP standard.
In this
post, I will look at the requirements of CIP-013 (and they’re all pretty
short!). Again, I’ll try to forget anything I know about the requirements or
what has been said about them, since in the end all that matters is what is
written in the requirements themselves.
Let’s start with
R1, which reads:
R1.
Each Responsible Entity shall develop one or more documented supply chain
cyber security risk management plan(s) for high and medium impact BES Cyber
Systems. The plan(s) shall include:
Of course,
this is very different from almost all of the other CIP requirements, which require
the entity to put in place specific security controls – configuration
management, patch management, personnel risk assessments, etc. R1 requires the
entity to develop a plan, period. Sure, the plan will need to include certain
items to be listed later, but those items aren’t themselves the point of the
requirement; the plan is. This isn’t new; there are two currently-enforced CIP
requirements that are written in exactly the same way: CIP-003-6 R2 and
CIP-010-2 R4. These are also plan-based requirements.[i]
And what is
the purpose of the plan required in CIP 13 R1? It is “supply chain cyber
security risk management”. In the first post in this series, I already
emphasized the fact that the purpose of CIP 13 is risk management, not
implementation of particular controls – so the fact that R1.2 lists six
particular controls that need to be in place shouldn’t be taken to mean that
your plan just needs to address these controls. Your plan needs to address the
mitigation of supply chain cyber security risk in general, which is a much
broader topic than these six controls.
Let’s
continue with the two parts of R1. R1.1 reads:
1.1. One
or more process(es) used in planning for the procurement of BES Cyber Systems
to identify and assess cyber security risk(s) to the Bulk Electric System from
vendor products or services resulting from: (i) procuring and installing vendor
equipment and software; and (ii) transitions from one vendor(s) to another
vendor(s).
Note that
this is pretty curious wording. R1 left off with the words “The plans shall
include:” This means that 1.1 should lay out something that must be included in
the plan. Instead, 1.1 requires “one or more processes used in planning for the
procurement of BES Cyber Systems to…” What does this mean? Concatenating these
words with the end of R1 leads to:
“The plan shall include one or more
processes used in planning for the procurement…”
Why should a
plan include “processes used in planning”? This means that the plan should be
for developing further plans. A plan should be for taking particular steps to
achieve a particular goal, not for simply developing more plans. Wouldn’t it be
simpler just to say the plan should include identification and assessment of
cyber security risks to the BES from the two areas of risk listed? Why does
there need to be this intermediate step of having “One or more process(es) used
in planning…”?
To be
honest, I’m not sure at the moment why these words are there; maybe a drafting
team member (or someone else) can enlighten me on this.[ii] I
recommend you ignore those words. In other words, I suggest you interpret this
requirement part as if it were written:
1.1. Identification
and assessment of cyber security risk(s) to the Bulk Electric System from
vendor products or services resulting from: (i) procuring and installing vendor
equipment and software; and (ii) transitions from one vendor(s) to another
vendor(s).
If R1.1 were
worded this way, what would an entity need to include in its plan in order to
be compliant with this requirement? The plan would need to include steps to a)
identify and b) assess risks to the BES from vendor products or services
resulting from risk areas (i) and (ii).
What does
this mean? First of all, I want to point out that item (i) really includes two
risk areas, not one. Risks from procuring vendor equipment and software are
very different from risks from installing vendor equipment and software. This
means I would rewrite the part of the sentence after the colon as “(i)
procuring vendor equipment and software; (ii) installing vendor equipment and
software; and (iii) transitions from one vendor(s) to another vendor(s).”
Once we’ve
made that change, I interpret R1.1 – if written as it is directly above – to
require the following steps:
- For each of the three risk areas, identify particular
risks included in each one. For example, in the area of “procuring vendor
equipment and software”, an entity might identify risks such as “the risk
that a piece of third-party software included with the product will be
infected with malware”; “the risk that the software will include known
vulnerabilities that haven’t been mitigated”; etc. This is, of course,
potentially a long list. However, IMHO the entity doesn’t have any choice
but to list all of the risks[iii]
that might be part of procuring vendor equipment and software. As we’ll
see in one of the upcoming parts of this series of posts, just the fact
that an entity needs to develop a complete list of risks doesn’t mean they
will have to spend a lot of time and money mitigating each one; in fact,
the entity might determine (and document) that some of those risks are so
small that no mitigation at all is required. This is permitted, of course,
due to the fact that CIP 13 is the first NERC risk-based requirement.
- “Assess” each of these risks. What does this mean?
Obviously, there are many aspects of each threat that we might assess. For
example, we might assess each threat based on whether it targets our
particular department or not; those that don’t affect our department can
be ignored.[iv]
However, what I think needs to be assessed here is the level of risk in
each case.[v]
I think that the entity needs to classify each of these risks according to
some scheme: high/medium/low; high/low; 1 to 5; etc.
Once the
entity has included in the plan each of the above steps (and of course each of
these has quite a few implied sub-steps), I think they have properly addressed
R1.1 as written. But wait! Haven’t we forgotten something here? We’re going to
include in our plan steps to a) identify risks and b) assess those risks. Why
are we doing this? Are we going to be satisfied if we simply produce a nice
list of risks, each one ranked as – for example - high, medium or low? What
else could be needed?
Here’s
something else: How about mitigating
those risks? After all, isn’t that the whole idea of CIP 13? To actually lower
the overall risk to the BES by mitigating supply chain security risks? Yet R1.1
doesn’t require the entity to include anything about mitigation in their plan.[vi]
To be honest,
I think it is simply a mistake that mitigation isn’t mentioned in R1.1. It
doesn’t make any sense just to identify each risk, assess it, then call it a
day and go home. You need to interpret R1.1 as if it included mitigation. In
other words, there needs to be a third step in the list above, reading
something like:
- For each identified risk, mitigate the risk according to
the risk level assigned to it in step 2.
Of course, there
is a lot more that could be said about this step, and I’ll hope to do that in
some future post.
I must admit
that, when I started to write this post a few hours ago, I thought I was just
going to go over the words of R1 and R1.1 and tease out all of their meaning.
Instead, I’ve found that R1.1 doesn’t make much sense unless two changes are
made to it (the change incorporated in my revised R1.1 above, as well as adding
mitigation to R1.1, as just discussed). So, with greatest respect, I suggest
that NERC entities interpret R1.1 to read this way:
1.1. Identification,
assessment, and mitigation of cyber security risk(s) to the Bulk Electric
System from vendor products or services resulting from: (i) procuring vendor
equipment and software; (ii) installing vendor equipment and software; and (iii)
transitions from one vendor(s) to another vendor(s).
I’m having a
déjà vu moment here. A little less
than five years ago, in late April 2013, I set out to write the first of what
was going to be a series of posts on how to comply with the CIP version 5
standards; I did this because FERC had about two weeks previously issued a NOPR
saying they intended to approve v5 (just as FERC
did with CIP-013 less than two weeks ago). Since CIP-002-5.1 was the first
standard in order, I started with that.
In that
post, as in this one, I tried to work through the steps that would be required
to comply with CIP-002-5.1 R1 (including Attachment 1), and I came to a “you
can’t get there from here” point – where the logic in the requirement
completely broke down. That is a serious flaw in CIP 2 R1 that has never been
fixed. At the time, I thought the only solution was to rewrite the requirement
(and Attachment 1); I wrote perhaps ten to fifteen posts on this particular topic
over the next couple of years (plus many more on other problems in CIP 2 R1),
of course without success.
However, it
turns out that this flaw didn’t prove to be very harmful as CIP v5 was
implemented and then enforced. This is because NERC entities and auditors all came
to a common interpretation of CIP 2 R1. The interpretation wasn’t based on the
actual wording of the requirement and Attachment 1, but since there was
unanimity among entities and auditors, everyone came to believe that this
interpretation was actually the correct one.[vii]
Now I
believe I’ve found a serious problem with CIP 13 R1.1 (namely the lack of
mention of mitigation. The first problem I discussed is more of an annoyance
than anything else), but this time I’m not even going to suggest that R1.1 be
rewritten. It would easily set back implementation of CIP 13 by more than a
year, and I think the solution will be the same as it was with the problem I
found in CIP-002-5.1: There will just need to be a common interpretation[viii] of
R1.1 that includes mitigation. In fact, I humbly[ix] suggest
that my version shown above could be used as that common interpretation – I’ll
even make it available royalty-free!
The views and opinions expressed here are my own, and do
not reflect those of any organization I work with or for. 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.
[i]
There is another current requirement that is, in my opinion, functionally
plan-based. CIP-011-2 R1 requires an information protection program, not a
plan. However, the rest of the requirement closely matches CIP-003-6 and
CIP-010-2 in form. This is interesting because CIP-011 R1 was developed as part
of the “CIP version 5” effort, while the other two requirements were developed several
years later, as part of “CIP version 6”.
You may wonder about two other requirements that were
originally part of “CIP version 5” that specifically require “plans”. CIP-008-5
R1 requires the entity to develop a cyber security incident response plan,
while CIP-009-6 R1 requires recovery plans. However, I distinguish between these
two requirements and the three requirements cited above: The plans referred to
in CIP-008-5 R1 and CIP-009-6 R1 are actually controls that need to be implemented to protect against threats that
might be realized in the future. In CIP 8 R1, the threat is that of a cyber
security incident (or more precisely, the threat is that the entity will not
respond in an intelligent fashion to a cyber incident and will end up making
things much worse). In CIP 9 R1, the threat is that there will be outages of
systems that could impact BES reliability unless quickly restored.
The only way you can deal with these two threats is to
put a plan in place to address them when they are realized. So CIP 8 R1 actually
requires a control – the CSIRP – to address the threat of improper response to
cyber incidents, while CIP 9 R1 requires a control – the recovery plan(s) – to
address the threat of inability to restore one or more systems when lost. To
compare this with a requirement that doesn’t require a plan, CIP 7 R2 requires
a control – a patch management program – that mitigates the threat of malicious
code. All three of these are prescriptive requirements requiring one or more
controls to be implemented; it’s just that in the first two requirements, the
control happens to be a plan. That doesn’t make these plan-based requirements
using my definition of the term: a requirement to develop a plan for addressing
a particular threat or set of threats.
[ii]
And I’m not in any way saying the drafting team did anything wrong here; after
all, I attended at least two of their face-to-face meetings and some of the
call-in meetings, and I never raised this issue at the time. In fact, I didn’t
notice this issue, or other issues noted in this post, at all until I started
to write the post.
[iii]
I would much prefer if R1.1 referred to threats, not risks. I will hopefully
address this issue in an upcoming post (and if not, it will definitely be
addressed in the book that I and two co-authors are working on, regarding how
the CIP standards could/should be rewritten). Briefly, I think the steps should
actually be: 1) identify threats; 2) using estimated impact of each threat and
the fact that risk = threat X impact, classify each threat by the relative degree
of risk it poses; and 3) develop a mitigation strategy for each risk, based on
its classification. This would be much clearer if CIP-013 distinguished between
threats and risks.
[iv]
Obviously, I’m being facetious here.
[v]
And as I said in end note ii above, I think this requirement part would be much
clearer if it distinguished between threats and risks.
[vi]
And, while it might be tempting to think that R1.2 is the part where mitigation
is required, that would be a mistake. As I will discuss in the next post in
this series, R1.2 lists a set of six specific risks that FERC required NERC to
address in this standard when they ordered its development in Order
829; it was never meant to be any sort of comprehensive list of the risks
to be mitigated. R1.2 does require
mitigation of these six risks, but not of any other risks.
And don’t think that R2 might save the day here. R2
just requires implementation of whatever is in the plan, nothing more. If the
plan only includes identification and assessment of risks, then that’s all that
has to be implemented.
[vii]
Briefly, the issue is that the wording of CIP 2 R1 and Attachment 1 is
contradictory. Some of the wording – especially in Attachment 1 Section 3 –
leads one to believe that assets
should be classified as high, medium or low impact, while most of the wording
says that only BES Cyber Systems are
classified, not the assets themselves. However, I’d say there is close to 100%
unanimity in the NERC community that it is assets, not BCS, that are being
classified in Attachment 1. And since this is working, why mess with it? I
think I last raised this issue in late 2015 in this
post. I don’t intend to raise it again. There are enough real problems with the
current CIP standards to be discussed, without dragging out what has turned out
to be a fairly harmless wording problem.
[viii]
Of course, since it doesn’t make any sense just to identify and assess risks
and not mitigate them, it’s very hard to see how R1.1 could be interpreted any
other way.
[ix]
OK, not so humbly.
No comments:
Post a Comment