Lew on CIP 13: Your
plan and how it will be audited – part I
Note: part II of this post (part 4 of the series) will be out later this month. Lew told me he's writing a new article on CIP-013, which will appear in this month's newsletter - I will wait for that before I do this post. If you want to receive that before I do my post, you can sign up on the first page of RF's web site.
This is the
third of four posts discussing what Lew Folkerth of the RF NERC Region has
written about CIP-013 in RF’s December and February newsletters. The first two
parts of this series (both written in January) are
here
and
here;
they deal with the December article, since that was the only one published at
the time. In this post and the next one, I will focus on the February article,
while still pointing out a couple items from December that I haven’t discussed
yet.
As I said
earlier, I believe Lew understands CIP-013 better than anyone else at NERC or
the Regions. In fact, I’ll go so far as to say that he understands it better
than anyone else on the planet, although I don’t want to extend that to the
Solar System or the Milky Way – that would be going a bit too far, since some
distant planet may well harbor someone who knows CIP-013 better than Lew!
I also want
to point out that this post, like the previous two in this series, doesn’t
confine itself to just repeating what Lew said in his articles. In some cases I
disagree with him, although these are regarding details, not his fundamental
approach to CIP 13. More often, I expand one or two sentences of his into one
or two pages, both because I’m much more verbose than he is, but also because
he’s constrained to a small amount of space in the newsletter – whereas I can
bloviate as much as I want.
You can
retrieve the December newsletter
here
and the February one
here.
You find Lew’s articles, as always, by going to the left side of the first page
of the newsletter and clicking on “The Lighthouse”. I also recommend you sign
up to receive the newsletter regularly (it comes out six times a year), by
going to RF’s
home page and signing up
about two thirds of the way down the page. Lew writes an article in every
newsletter, and they are always worth reading.
Lew’s
February article is entitled “A Structure for CIP Risk Management Plans”, and
it is clearly intended to apply to all NERC CIP standards or requirements that
mandate risk management plans. But as he points out, CIP-013 will be “the first
explicitly risk-based CIP Standard” – so it’s currently the
only standard that requires a risk
management plan
[i].
He points to some of the new requirements now being discussed by the CIP
Modifications drafting team as probably being future examples of risk-based CIP
standards or requirements, but of course they are a long way from becoming
standards.
[ii] So this
article could just as well have been called “A Structure for CIP-013 Risk
Management Plans”.
I like
CIP-013 a lot and I consider it the future of all CIP standards, but I’ll admit
it gives the NERC entity just about no information about what should be in
their supply chain cyber security risk management plan (or CIP-013 plan, which
is easier to say). And there has been no official guidance on this subject
published by NERC or any other organization (there is the Implementation
Guidance published by the drafting team, but it still exists only in
draft
form and I don’t believe it will ever be finalized, for reasons that are
too depressing to recount here). So I think it’s a huge help that Lew was
willing to lay out what he thinks should be in your plan (and since what he
thinks carries a
lot of weight with
CIP auditors in all of the NERC regions, it certainly behooves any NERC entity
to pay attention to this).
Lew says the
following sections should be in your plan. He breaks them into four areas,
based on NIST 800-30’s four phases of the risk assessment process: Frame,
Assess, Monitor and Respond.
I. FRAME
Scope
I’ll admit I
hadn’t thought of explicitly including a scope section in the plan, but it
makes sense. However, I’m not sure I agree with everything he says in this
section of his article. He says your plan should “include an inventory of Cyber
Assets that are covered by your plan, as well as a list of vendors that may be
affected by implementation of the plan”. While I think it’s a good idea to list
vendors (of course, it’s also good to keep in mind that that list will change
over time), I don’t think Cyber Assets is the right category of assets to list.
CIP-013 applies to Medium and High impact BES Cyber Systems. True, BCS are
usually implemented on Cyber Assets, but the software they run often isn’t
confined to one of the Cyber Assets – and sometimes, of course, the software
runs on virtualized hardware, which doesn’t meet the definition of Cyber Asset
at all.
Also, I
would qualify his use of the term “inventory”. What CIP-013 is definitely not about is the BCS that you already
have – it’s about the ones you will purchase once the standard is in place. I
think Lew might have meant to say that the inventory is of the types of BCS that you expect to purchase
in the future (again, with the caveat that these will change as well). So I
would reword what he says and write “Your plan should include an inventory of
types of Medium and High impact BES Cyber Systems that are covered by your
plan, as well as a list of vendors that may be affected by implementation of
the plan.”
Objectives
Lew’s
paragraph on Objectives reads “The objectives of the risk management plan
should be clearly identified. For example, your CIP-013-1 risk management plan
should include the four objectives from FERC Order 850 P2, as well as any
additional objectives that are appropriate for supply chain risk management at
your organization.”
Lew listed
FERC’s four objectives in his December article. They were originally stated in
Order
829, in which FERC ordered NERC to develop the standard in 2016, and in
Order
850, in which FERC approved CIP-013 (and the revised CIP-005 and CIP-010
that go with it) in October of last year.
In my first
post in this series, I pointed out that, while it’s obviously a good idea to
show how your plan meets FERC’s four objectives, the real objective of CIP-013
is found in the statement of purpose at the beginning of the standard: “To
mitigate cyber security risks to the reliable operation of the Bulk Electric
System (BES) by implementing security controls for supply chain risk management
of BES Cyber Systems.” What does this mean in practice? R1.1 answers that
question: The plan needs 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).”
Lew did state
that, besides showing that your plan meets FERC’s four objectives, you should
show it meets “any additional objectives that are appropriate for supply chain
risk management at your organization.” This does go beyond what’s in FERC’s
list of objectives, but I don’t think it goes far enough. I would rewrite Lew’s
paragraph on Objectives to say:
The objectives of the risk management
plan should be clearly identified. The objectives of your CIP-013-1 risk
management plan should include the four objectives from FERC Order 850 P2, as
well as the objectives stated in R1.1.”
Of course,
I’ll admit that the objectives of R1.1 don’t necessarily jump out of the page
in well-ordered ranks, so here’s what I think they are:
- Identify important supply chain cyber security risks to
the BES, resulting from:
- Procuring vendor equipment and software;
- Procuring vendor services;
- Installing vendor equipment and software;
- Using vendor services; and
- Transitions between vendors.
- Determine the degree of each risk[iii]
identified, by determining its likelihood and impact.
- Rank risks by their degree, and choose the highest risks
for mitigation.
- Rank the risks that underlie the six mitigations in R1.2
at the top of the list.[iv]
- Using appropriate policies, procedures and technologies,
mitigate[v]
those risks.
These are
all implicitly included in R1.1, even though that might not be obvious. I don’t
have time to explain my reasoning for this here, but if you disagree I’m
willing to fight you to see who’s right (you’d have to pay your travel to
Chicago, of course).
Risk assessment methodologies
Lew’s words
for this section are: “The methods you use to assess risk should be spelled out
in this section. Each methodology (you can use more than one) will lay out the
steps you will need to take to assess the risks you identify. These steps should take into account the
inputs to the process (e.g., threat sources, threat events, vulnerabilities,
predisposing conditions, etc.). Simpler
may be better here, but you will need to select the methodologies that you
determine are best suited to your organization. If you create a complex
methodology to assess your risks, then you will need to be able to explain that
methodology to an audit team.”
Of course,
Lew isn’t telling you here what your risk assessment methodology should be. In
his December article, he did give a broad suggestion of this: It should be
based on NIST 800-30, NIST’s “Guide for conducting risk assessments”. Lew said
regarding 800-30: “I expect developing a plan by implementing this document and
approach would work well for CIP-013-1.” I agree with him on that, and I’ll add
that 800-30 has played a big role in the methodology I’ve developed with my
clients. However, I would add that you shouldn’t think all of 800-30 will be
applicable to CIP-013 compliance. As with other NIST documents, it is aimed at
a very wide audience (basically, any organization in the US, although all NIST
800 series document are in theory aimed only at Federal government agencies),
and you always have to separate what applies in your case from what doesn’t.
Definitions
Lew says “Any
terms used in risk management that may be ambiguous and that are not defined in
the Standard should be defined here. Try to keep to generally accepted
definitions. Unusual definitions will probably be questioned.” Once again, this
is very good advice. You should define the terms you’re using in your risk
analysis – including risk, vulnerability, impact, likelihood, etc. And you
should make sure you’re following those definitions.
You
definitely shouldn’t assume that everyone knows what a risk or a threat is. It’s
true that everyone knows what they are – but everyone has a different idea! More
importantly, the auditors will almost inevitably have a different idea of what
these terms mean than you do, and I can absolutely guarantee that different
auditors will define them differently. This
of course creates a lot of problems in the NERC Operations and Planning
standards, as well as in the prescriptive requirements in CIP-003 through
CIP-011. However, it isn’t really a problem in CIP-013. As long as everyone –
NERC entity and auditor - knows what the terms in their methodology mean, it’s
fine if their definitions don’t agree.
I also want
to point out that you can “define” a term without coming up with a Webster’s-style definition. What’s much
more important is showing how each term fits into your methodology. For example,
NIST 800-30 uses “threat” as its fundamental term (as do I). The risk assessment
process starts with identifying threats, and builds from there. However, the
authors point out that you could just as legitimately start with
vulnerabilities as your fundamental term (in fact, the Recommendations section of
every security vulnerability assessment that I’ve ever seen – including NERC
CIP-010 R3 SVA’s – uses this approach). I think trying to base your CIP-013
risk assessment on vulnerabilities rather than threats would make the approach
more cumbersome (although I don’t have time or space to tell you why I think
this). But making vulnerabilities fundamental would certainly be doable, if you
saw some big advantage.
II. ASSESS
Identify possible risks
The first
step in the Assess phase of your plan should be risk identification, since R1.1
starts out with “identify and assess” risks. From the work I’m now doing with
clients on CIP-013, I believe risk identification (although I prefer “threat
identification”. See end note ii below) may well be the hardest part of the
CIP-013 compliance process – or at least it’s the one that requires the most
creativity.
Why do I say
creativity is needed? Because CIP-013 doesn’t provide a list of risks that you
should consider for mitigation in your plan. It would be great if NERC
developed such a list, but I know it won’t happen. Other organizations will
hopefully recommend risks to be considered, including one I’m part of, the
Supply
Chain Working Group of the NERC CIPC. The SCWG is currently developing six short
papers on supply chain risk management (and – in a momentary lapse of good
judgment – I have volunteered to lead one of those groups, which is tasked with
writing a paper on supply chain risk management lifecycle. Since the SCWG is
open to everybody, if you would like to participate in the web meetings for
drafting this paper, please drop me an email at the address at the end of this
post); these papers will certainly provide suggestions for risks you should
consider for mitigation in your CIP-013 plan.
But there
are lots of other sources of risk information as well. Lew lists four of them
in his article, but other good ones include:
1. The
2018 NRECA/APPA
white
paper on supply chain risks for small entities (although I don’t see
anything in there that doesn’t apply to large entities as well. I think it’s a
very good document for any electric utility, whether subject to CIP-013-1 or not);
2. The
2015 UTC
white
paper on cyber supply chain risk management for utilities (also very good);
3. The
2014 DoE/NERC CIPC (ESCSWG)
document
on cybersecurity procurement language (really excellent);
4. The
2018 North American Generator Forum
white
paper on supply chain security management;
5. The
2018 NERC/EPRI
report
on supply chain risk assessment;
6. The
2019 NERC draft
report
on cyber supply chain risks;
There is a
big difference between the sources Lew cites and the ones above. Lew’s are
sources primarily of technical vulnerability information (like DHS NCCIC or the
E-ISAC), while mine are sources of mitigations for supply chain risks. While
neither Lew’s sources nor mine can be used without restating what is provided,
I believe that in general particular technical vulnerabilities aren’t directly
related to supply chain risks; rather, they are related to more general cyber
risks that apply to the systems directly. In my opinion, supply chain risks
have much more to do with processes and procedures (executed at utilities or
vendors) that are used in procurement and installation of procured products,
than they do with particular technical vulnerabilities in those products. In
other words, I prefer the sources I’ve listed over Lew’s.
But even
using my sources, you have to “restate” the mitigation to identify the risk “behind”
it. For example, one of the mitigations listed in the APPA/NRECA document is “Limiting
the systems that can be accessed remotely”. What’s the risk that this
mitigates? You could state it as “The risk that systems that don’t need to be
accessed remotely will nevertheless be accessible.”
Of course,
even limiting your search for supply chain security risks to the sources I’ve
stated, there are a huge number of risks to consider! The next step will be
assessing each risk to determine its magnitude, which will probably be low,
medium or high. It would probably be a good idea at this point not to even
assess any risk which you are sure is low (i.e. you would only assess high or
medium risks, which means high or medium likelihood and/or high or medium impact).
If even that seems to be too many – and I’ll stipulate that anything above 50
is too many – then you might just select high risks for assessment).
Once you
have a list of risks that you have selected for assessment, you can go on to
the next steps of assessing and prioritizing risks. However – and I hate to
disappoint you – I’m going to save that discussion for Part II of this post,
coming soon to a blog near you! That part will not only finish the discussion
of Lew’s February article; it will also go on to discuss how CIP-013 will be
audited.
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. My offer to NERC
entities of a free webinar workshop on CIP-013, described in this post, is
still open! Let me know if you would like to discuss that, so we can arrange a
time to talk.
[i]
I know some would argue that CIP-014 is a risk management standard. CIP-014 R4
requires the owner of a Transmission substation or Control Center that is in
scope to perform a physical “threat and vulnerability assessment”, while R5
requires them to develop a physical security plan to address the threats and
vulnerabilities identified in the assessment. Of course, the physical security
plan is risk-based, but it isn’t a risk
management
plan – since it doesn’t allow the entity to identify and assess other risks,
and mitigate those. I’m not dogmatic about this, but I just don’t think it’s
the same thing as CIP-013 R1.
[ii]
I also consider the existing “plan-based” CIP requirements to be implicitly
risk-based – this includes CIP-003-7 R2, CIP-007-6 R3, CIP-010-2 R4 and
CIP-011-2 R1. These all require the entity to have a plan or program (although
even that is just implicit in CIP-007-6 R3) to achieve a certain objective, but
IMHO there is no way to do that without considering risk. The objective you are
achieving is always risk mitigation, e.g. risk from malware in CIP-007-6 R2 or
from use of TCAs or RM in CIP-010 R4.
[iii]
You may have noticed that it’s awkward to talk about the “degree of risk” of a
risk. I would prefer that my step 1 required the entity to identify
threats to the BES, not “risks to the
BES”; then step 2 would require the entity to determine the degree of risk
posed by each threat. This is the terminology used by NIST 800-30, and it also
makes sense to me. I think of risk as a magnitude, whereas a threat is simply a
statement of something that poses danger, such as “A software vendor won’t have
good internal security, and a malicious third party will plant malware in one
of their products while in development.” However, CIP-013 uses the term risk in
both cases – and this follows FERC Order 829, which does the same thing. I
don’t want to confuse my readers too much by introducing a different
terminology at this point, although I’m strongly suggesting my clients should
follow 800-30’s example in this regard.
[iv]
R1.2 lists six mitigations that are mandatory – and they’re mandatory because
FERC said (in Order 829) that they need to be included in the risk management
plans. Like any mitigations, these six mitigations are all based on
particular
risks. However, unlike all of the other risks you identify and assess for
your CIP-013 plan, you essentially need to rank these six risks as the highest
and place them at the top of your list; this way, they’ll definitely “make the
cut” to be mitigated. But these six risks are in no way intended to be the only
ones you mitigate in your plan, although I know some people – including at
least one or two CIP-013 drafting team members – who believe that CIP-013 is
pretty much just R1.2, while R1.1 is simply some flight of fancy that can be
ignored. I certainly can’t say that auditors will consider doing this a
violation, but I can say that this strategy will strip away most of the
benefits that would come from correctly complying with CIP-013.
Think about it. I don’t think there should be much
doubt that supply chain is the most important area of cyber threats in the
world today (if not the most
important), for just about any industry and any organization. So why wouldn’t
you want to identify all important risks and mitigate the most important of
these (which includes the six R1.2 risks, of course), since you’re allowed to
choose the risks you want to mitigate in CIP-013? In CIP-002 through CIP-011,
you aren’t given the chance to look for important threats and mitigate them,
using dollars allocated to you because of management’s fear of NERC/FERC noncompliance
– so if you decide that phishing or ransomware should get a lot more attention
than patch management in CIP-007 R2, you have to do that using another budget,
not your NERC CIP budget. You have to implement the mitigations described in
the CIP 2-11 requirements, and you don’t have any power to make substitutions.
In CIP-013, these choices are all up to you.
[v]
You may notice that the word “mitigate” isn’t in R1.1. Even though the drafting
team included that in the purpose statement, they left it out of the main
requirement! Of course, there’s no question at all that your CIP-013 plan
should include mitigation of risks, not just identification and assessment.