Note from Tom:
I have moved to Substack as my primary
blog platform. If you want to see all my new posts, as well as my 1200+ legacy
posts dating from 2013, please support me by becoming a paid subscriber to my
Substack blog. The cost is $30 a year. Thanks!
Last Thursday, FERC released new orders related to CIP-013 and CIP-003 respectively. I’ll
discuss the CIP-003 order in a future post. Before I discuss the CIP-013 order,
which is officially a Final Rule, here’s some important background information:
1.
FERC ordered NERC to develop a “supply chain
cyber security risk management standard” in July 2016. They gave NERC only one
year to develop and fully approve the new standard. Since just approval of a
new CIP standard usually requires a full year (including four ballots by the
NERC Ballot Body, plus a comment period of more than a month between each pair
of ballots), you can see this is lightning fast by NERC standards. FERC did
this because they could see that supply chain security attacks – of which there
had been very few at that time – would soon rapidly increase, both in numbers
and magnitude.
2.
FERC turned out to be right about the attacks
(think SolarWinds,
Kaseya,
XY
Utils, and more). However, to meet FERC’s unrealistic one-year goal, the
NERC Standards Drafting Team (SDT) had to make CIP-013-1 as
bland as possible, so they could obtain the necessary expedited approval by
the NERC Ballot Body.
3.
CIP-013-1 became enforceable on October 1, 2020.
FERC auditors, who reported
in 2023 on CIP-013 audits they had led, stated (on page 17), “While the
requirement language obligates entities to develop a supply chain risk
management plan with various characteristics, it does not mandate that the plan
apply to contracts that were in effect at the effective date of the Reliability
Standard.” Since the most important OT contracts are almost always multi-year,
this meant that some of the most important supply chain risks were originally deemed
by many NERC entities to be out of scope for CIP-013-1 compliance, even though there
was nothing in the wording of CIP-013-1 Requirement R1 suggesting that risks
from existing suppliers should (or even could) be ignored.
4.
FERC’s 2023 report continued, “Additionally, the
standard does not require the plan to incorporate responses to the risks
identified by the entity in the plan except in limited circumstances
(Requirement Part 1.4.2[i]).”
This was the most mystifying omission in CIP-013-1: the fact that it requires
the entity to “identify and assess” supply chain risks, but not to do anything
about the risks they’ve identified. It’s like you saw a runaway truck barreling
toward you in the street but you decided not to move out of the way, since the
law doesn’t require you to do that. I wrote about this issue in several posts
in 2019 and 2020, culminating in this
one.
FERC’s NOPR
In September 2024, FERC issued a Notice of Proposed
Rulemaking (NOPR) that laid out their concerns about CIP-013-1 and CIP-013-2 (version
2 added EACMS and PACS to the scope of CIP-013-1 but left the rest of the
standard unchanged). I wrote this
post about the NOPR. Since it’s a long post (surprise, surprise!), I recently
boldfaced three paragraphs that I consider especially important. However, the
whole post is still quite relevant, if you have time to read it.
In the NOPR, FERC identified two problems they were
considering ordering NERC to correct. The last sentence of paragraph 2 on page
3 describes these problems as, “(A) sufficiency of responsible entities’ SCRM[ii]
plans related to the (1) identification of, (2) assessment of, and (3) response
to supply chain risks, and (B) applicability of SCRM Reliability Standards to
PCAs[iii].”
Indeed, the Final Rule released last week requires NERC to act in both of those
areas.
What actions did FERC require NERC to take? To take item (B)
first, there weren’t any objections (in the filings received by FERC in
response to the NOPR) to including PCAs in the scope of CIP-013-2. This was probably
because
i.
Since a PCA is always installed on the same routable
protocol network as a component of a BES Cyber System (BCS), common sense seems
to dictate that it should receive the same level of protection as the BCS; and
ii.
Often, the same type of asset - such as an
electronic relay - might be a BCS component in one case, but not in another
case. The NERC entity is unlikely to use a different supplier for relays used in
the first case than relays used in the second case, so including PCAs to the
CIP-013 scope will not usually add much to an entity’s compliance workload.
Regarding item (A), FERC lists three NERC actions that they
considered ordering, although in fact they only ordered two of them in their
Final Rule last week:
1. To address the issue of NERC entities not
identifying risks that were due to suppliers whose contracts predated the
effective date of CIP-013-1 (October 1, 2020), NERC considered (and asked for
comments on) the idea of setting a maximum time between risk assessments for a
vendor – for example, a NERC entity would need to repeat a risk assessment for
a vendor every three years. Thus, if a vendor’s contract had started on for
example September 1, 2023, the vendor would need to conduct a new risk
assessment by September 1, 2026.
This idea drew criticism from some commenters, but FERC
decided to go ahead with it anyway. However, they changed it in one important way:
They will let the Standards Drafting Team leave it to the individual NERC
entity to decide what interval between risk assessments is appropriate. FERC
also said the SDT could allow the entity to identify more than one interval,
based on criteria they identify (for example, risks for software products are
likely to change more rapidly than risks for devices. This means the mandatory
assessment interval for a software product might be shorter than the interval
for a device).
2. In their NOPR, FERC suggested they might require
NERC entities to verify cybersecurity information that a supplier provides, for
example, in response to a questionnaire from the entity. Since this would be
almost impossible for a NERC entity to do without having to pay big bucks to
get a major auditing firm to audit the supplier, I wasn’t surprised that the
comments FERC received on this issue were mostly negative. I was also pleased
that FERC realized this was a bad idea and dropped it.
3. The third and final question on which FERC’s NOPR
solicited comments was “whether and how a uniform documentation process could
be developed to ensure entities can properly track identified risks and
mitigate those risks according to the entity’s specific risk assessment.[iv]
CIP-013-2 Requirement Part R1.1 states that the Responsible
Entity must “identify and assess cyber security risk(s) to the Bulk Electric
System from vendor products or services…” Notice that the word “mitigate” was
left out here, even though it should have been included (the Purpose of CIP-013,
listed in item 3 on the first page of the standard, is “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”).
I’ve heard that more than a few NERC entities, whether or
not they noticed that “mitigation” was missing from Part R1.1, acted as if it
was missing. That is, they diligently sent out security questionnaires to
suppliers, but then either a) paid little or no attention to the responses, or
b) evaluated the responses and noted which were unsatisfactory, yet never
contacted the supplier to find out when and how they would mitigate that risk.[v]
As you may have guessed, FERC’s Final Rule mandates that the
revised version of CIP-013 (which will be CIP-013-3, of course) require NERC entities
to identify, assess and mitigate vendor risks. However, FERC worded this
a little differently. They stated (in paragraph 53 on page 33), “…we adopt the
NOPR proposal and direct NERC to develop and submit for Commission approval new
or modified Reliability Standards that require responsible entities to
establish a process to document, track, and respond to all identified supply
chain risks.”
In other words, instead of mandating that CIP-013-3 require NERC
entities to “identify, assess and mitigate” supply chain risks to BCS, EACMS,
PACS and (soon) PCAs, FERC wants entities to “document, track and respond” to
those risks. In practice, these amount to the same thing. Nobody can document
and track a risk without also identifying and assessing it. Moreover, responding
to a risk is the same as mitigating it, since responding by doing nothing at
all about a risk will no longer be an option in CIP-013 compliance.
Risk identification
As I’ve already implied, I consider CIP-013-1 and CIP-013-2
to have been largely a failure, at least in relation to what they might have
been, if FERC had given NERC more time to develop and approve the standard. Fortunately,
FERC is giving NERC 18 months to develop and approve CIP-013-3; I consider that
an improvement, but 24 months would have been even better. This is because CIP-013
was the first what I call risk-based CIP standard (NERC calls these objectives-based
standards, which in my opinion amounts to almost the same thing). Since the
drafting team in 2016 didn’t have the time to consider what should be in a
risk-based standard, the new drafting team will need to do that.
CIP-013 was risk based because FERC’s Order 829
of July 2016 specifically called for a “supply chain risk management”
standard (my emphasis). FERC contrasted this with a “one size fits all”
standard - i.e., a prescriptive standard that doesn’t take account of risk at
all. Of course, in 2016 and even today, most of the CIP requirements are prescriptive,
not risk based. But I want to point out that there doesn’t seem to be any real
debate in NERC CIP circles anymore about which type of requirement is better.
Cybersecurity is a risk management discipline, so cybersecurity standards need
to be risk based. In fact, since CIP version 5 came into effect in 2016,
literally every new CIP standard and requirement has been risk based.
The biggest problem with the first two versions of CIP-013
is they require the NERC entity to “identify” supply chain cybersecurity risks,
but they provide no guidance on how to do that. This means that a NERC entity could
literally comply with CIP-013 R1.1 – which requires the NERC entity to create a
supply chain cybersecurity risk management plan – by writing “Supply Chain Cybersecurity
Risk Management Plan” at the top of a sheet of paper, then writing below that, “We
couldn’t identify any supply chain security risks at all; therefore, we have
not taken any further steps required by this standard.” It would be very hard
for the auditors to issue a “potential non-compliance” (PNC) finding for this.[vi]
The comments cited in FERC’s order last week make it clear
that NERC entities want guidance on how to “identify” supply chain security
risks. Since such guidance was missing in CIP-013-1 and CIP-013-2, I’m sure the
legal staff at utilities told the CIP compliance people not to identify any
risks beyond those behind the six mandatory controls listed in CIP-013
Requirement 1 Part 1.2. Of course, it’s a cardinal rule of regulatory legal
practice not to expose the company to compliance risk beyond what is necessary.
I’ve been talking with CIP compliance people since 2008,
when FERC approved CIP version 1, and I can attest that most of them prefer to
comply with challenging CIP requirements than with watered-down CIP requirements
or no CIP requirements at all. However, lawyers must protect the company (or
the cooperative or the municipal utilities department); that requires reducing
the compliance footprint as much as possible, which in turn precludes going beyond
the strict wording of the requirement. By the same token, NERC CIP auditors can’t
audit a requirement that just says the entity must “identify risks”, without
giving any guidance on how that can be done. In other words, CIP-013 R1 was foreordained
to fail.
The new drafting team can break this cycle by adding some “meat”
to the risk identification bones of the current CIP-013-2 R1.1. What the team shouldn’t
do is choose an existing risk management framework like NIST 800-161r1, “Cybersecurity
Supply Chain Risk Management Practices for Systems and Organizations” and require
NERC entities to “comply” with it. Risk management frameworks are meant to
cover the waterfront, as one glance at 800-161 will reveal. Only the largest
organizations could dedicate the resources required to address all the
provisions in that framework.
Instead, I think the new SDT should make it clear that the Responsible
Entity needs to identify (say) ten important supply chain cybersecurity risks
and just focus on those. In fact, they might suggest that the entity choose ten
important risks from the North American Transmission forum’s (NATF) Supply
Chain Security Criteria, which is my favorite “risk registry” for OT[vii]
supply chain risks to the electric power industry.
While I used to think differently, I now realize it’s
impossible to even itemize all the most important supply chain security risks,
let alone mitigate a good portion of them. If you don’t currently maintain and utilize
a supply chain security risk registry, it’s better to start somewhere
than to wait until your organization has the resources and knowledge to develop
a comprehensive risk management program, which may never happen.
Fortunately, since it will be a couple of years before taking
this approach is mandatory, you have some time to try this out. You also have
an incentive, since if you work for a NERC entity with a high or medium impact BES
environment, you’re supposed to review and update your CIP-013 supply chain
cybersecurity risk management plan every 15 months. Instead of keeping your
plan as is, why don’t you find 5-10 risks that you can identify, assess and mitigate?
At least, if you make a mistake, you won’t be facing a PNC (potential non-compliance)
finding.
I’ll be glad to discuss this with you. Please drop me an
email.
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 or comment on this blog’s Substack community chat. If you would like to join my CIP Cloud Risks Working Group described in the italicized paragraphs at the end of this post, please email me.
[i] There
is no Requirement Part 1.4.2 in CIP-013-1, but there is a Requirement Part
1.2.4. This might have been what FERC was referring to.
[ii]
Supply chain risk management.
[iii] PCA
stands for “Protected Cyber Asset”. These are Cyber Assets that don’t meet the
definition of BES Cyber Asset, but which are installed on the same routable network
as a BCA, or any component of a BES Cyber System. If compromised, they could be
used to launch an attack on the BCS components on the same network.
[iv] Quotation
from paragraph 49 on page 30 of FERC’s Final Rule.
[v]
There’s a third possibility here: A NERC entity accomplished a) and b), meaning
they got the supplier to confirm they had a security deficiency and promise to
fix it. However, they never c) contacted the supplier again – more than once if
necessary - to make sure they followed through on their promise. It’s important
that a NERC entity accomplish all these steps for every supplier risk that was
identified through a questionnaire, audit, news story, etc.
[vi] I’m
sure this scenario hasn’t happened and won’t happen. However, I hear there are
many NERC entities whose plan consists entirely of putting in place the six
controls listed inCIP-013 Requirement 1 Parts R1.2.1 to R1.2.6. Since those six
controls are mandatory, many NERC entities decided they were the only risks
that they needed to identify in their supply chain cyber risk management plans,
when in fact that wasn’t t why they were included in the standard. Those six
controls were called out at random places in FERC’s 2016 order; the drafting
team just gathered them into one Requirement Part. They were never meant to
constitute the entire set of supply chain cybersecurity risks that NERC
entities need to include in their plans.
[vii] For
CIP-013 compliance, it’s important to identify OT supply chain risks. What I call
“IT risks” (like those found in the NIST CSF and NIST 800-161) focus on
protecting confidentiality of data. While that’s very important for banking OT
systems, it’s not important for power industry OT systems, where availability
and integrity are much more important.
No comments:
Post a Comment