Two weeks ago, FERC issued an important Notice of ProposedRulemaking (NOPR) regarding NERC CIP-013, the CIP standard for supply chain cybersecurity risk management. There was a good discussion of the NOPR in the NERC Supply Chain Working Group meeting on Monday, and yesterday Mike Johnson (author of an excellent blog on NERC CIP that has been on hiatus for a couple of years) put up a post about this.
The NOPR states (in paragraph 2 on page 3), “…we
preliminarily find that gaps remain in the SCRM Reliability Standards related
to the: (A) sufficiency of responsible entities’ SCRM 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.”
To address (B) first, PCA stands for Protected Cyber Asset.
This is the only type of Cyber Asset subject to NERC CIP compliance that is not
already covered by CIP-013-2. It’s certainly not a controversial move to extend
CIP-013 to cover PCAs as well, and I agree with their concern.
However, I find (A) quite interesting. Why? Because it seems
to just repeat what’s been in CIP-013 from the beginning. FERC ordered NERC to develop
a SCRM standard in 2016.
CIP-013-1 came into effect on October 1, 2020. CIP-013-1 R1 states that the
NERC entity with high and/or medium impact BES Cyber Systems must develop a
plan
…to identify and assess cyber security risk(s) to the Bulk
Electric System from vendor products or services…
In my experience, most FERC NOPRs
that deal with an existing CIP standard start with an affirmation that the
standard has met its objective and continue to say that more is needed (of
course, adding Protected Cyber Assets to the three Cyber Asset types already
addressed in CIP-013, as item B suggests, is an example of that). However, this
NOPR seems to be saying, “NERC, we’re not happy with how CIP-013-1[i] has turned out. Not only
do we want you to add PCAs to the scope of the standard, but we want you to go
back and fix the language of the standard itself.”
The specifics of why FERC is
unhappy with the existing Supply Chain standards (which include CIP-013-2,
CIP-005- 7 and CIP-010-4) are found starting in paragraph 24 on page 21 of the
NOPR. These include:
“While providing a baseline of
protection, the Reliability Standards do not provide specific requirements as
to when and how an entity should identify and assess supply chain risks, nor do
the Standards require entities to respond to those risks identified through
their SCRM plans.” (paragraph 24)
“A responsible entity’s failure to
properly identify and assess supply chain risks could lead to an entity
installing vulnerable products and allowing compromise of its systems,
“effectively bypassing security controls established by CIP Reliability Standards.”
Further, incomplete or inaccurate risk identification may result in entity
assessments of the likelihood and potential impact of supply chain risks that
do not reflect the actual threat and risk posed to the responsible entity. In
the absence of clear criteria, procedures of entities with ad hoc approaches do
not include steps to validate the completeness and accuracy of the vendor
responses, assess the risks, consider the vendors’ mitigation activities, or
respond to any residual risks.” (paragraph 25)
“…a lack of consistency and
effectiveness in SCRM plans for evaluating vendors and their supplied equipment
and software. While a minority of audited entities had comprehensive vendor
risk evaluation processes in place and displayed a consistent application of
the risk identification process to each of their vendors, other entities
displayed inconsistent and ad hoc vendor risk identification processes. These
risk identification processes were typically completed by only using vendor
questionnaires. Further, using only vendor questionnaires resulted in
inconsistency of the information collected and was limited to only “yes/no”
responses regarding the vendors’ security posture.” (paragraph 27)
“…many SCRM plans did not establish
procedures to respond to risks once identified.”
The last comment relates to the
fact that CIP-013-2 R1.1 (quoted above) only requires NERC entities’ to develop
a plan to “identify and assess” supply chain cybersecurity risks to the Bulk Electric
System (BES)”. It says nothing directly about mitigating those risks. I pointed
out in my posts
during the runup to enforcement of CIP-013-1 that any NERC entity that developed
a CIP-013 R1 plan that didn’t address risk mitigation at all was inviting compliance
problems; I doubt any entity tried to do that, either.
In paragraph 30 on page 26, FERC
summarizes their concerns:
In light of these identified gaps, we
are concerned that the existing SCRM Reliability Standards lack a detailed and consistent
approach for entities to develop adequate SCRM plans related to the (1)
identification of, (2) assessment of, and (3) response to supply chain risk. Specifically, we are concerned that the SCRM
Reliability Standards lack clear requirements for when responsible entities should
perform risk assessments to identify risks and how those risk assessments
should be conducted to properly assess risk.
Further, we are concerned that the Reliability Standards lack any
requirement for an entity to respond to supply chain risks once identified and
assessed, regardless of severity.
In my opinion (which dovetails
with FERC’s), there were two big problems with most NERC entities’ R1.1 plans.
The first is that the plans didn’t try to identify any risks beyond the six
that are “required” by items R1.2.1 through R1.2.6. Those six items had been
mentioned in various random places in FERC’s Order 829
of July 2016, which ordered development of what became CIP-013. However, they
were never intended to constitute the total set of risks that needed to be
identified in the NERC entity’s plan. Yet, it seems that many, if not most,
NERC entities considered them to be exactly that.
The second problem is that, even though
NERC entities took the “assessment” requirement in R1.1 seriously, utilizing
supplier questionnaires to accomplish that purpose, the responses to the questions
weren’t considered to be measures of individual risks, requiring specific
follow-up from the entity. Instead, they were considered to be simply one datapoint
(among many) contributing to an answer to the question, “Is this supplier safe to
buy from in the first place?”
It's certainly important to ask that
whether your supplier is safe to buy from. But let’s face it: In the OT world, there’s
seldom a question who you will buy from. It’s the supplier you’ve been buying
from for the last 30-40 years. Is your utility really going to drop your current
relay vendor and move to another one, just because the incumbent gave one
unsatisfactory answer out of 50 on a security questionnaire? Certainly not. On the
other hand, the unsatisfactory answer needs to be looked at for what it is: an
indication that your current supplier poses a degree of risk in the area
addressed by that question.
Suppose your questionnaire asked
whether the supplier had implemented multifactor authentication for their own
remote access system, and that your incumbent relay supplier indicated this was
in their budget for FY2026. In my opinion, that’s an unsatisfactory answer. In 2018,
a DHS briefing indicated that nation-state attackers had penetrated
a large number of suppliers to electric utilities (and through them at least
some utilities), often through exploiting weak passwords in remote access systems.
Clearly, no supplier to the power industry should still have MFA on their to-do
list; it should already be in place.
A NERC entity that receives the
above response on a supplier questionnaire should immediately contact the
supplier and ask when they will implement MFA. The right answer is “By 5:00
today”, although “By noon tomorrow” might also be acceptable. Whatever deadline
the supplier sets, the entity should follow up with them on that day to find
out whether they kept their promise. If they did, great. If they didn’t, when will
they implement MFA and what price or other concessions are they ready to accept
if they don’t make the new date? After all, by not mitigating this risk, they’re
transferring the mitigation burden to your organization. Since you will have to
implement additional controls due to the supplier’s lax attitude, you need to
be compensated for that fact.
The point is that each question in
your questionnaire should address a specific risk that you think is important;
if you don’t think the risk is important, don’t ask the question – you’re just wasting
your and the supplier’s time. But since the risk is important, you need to
follow up and make sure it gets mitigated. Presumably, you’ll get the supplier’s
attention, and it will get mitigated. But if it isn’t, you will receive at
least partial compensation for the additional costs the supplier is imposing on
you, since you will probably have to spend money and/or time implementing mitigations.
Since this is a Notice of Proposed
Rulemaking, FERC concludes this section with a discussion (on pages 26-31) of what
changes they might require NERC to make in CIP-013-2 (of course, those changes
would be in a new standard CIP-013-3). All of their suggestions are good, although
I will provide a more comprehensive discussion of what I propose in a later
post. FERC is giving the NERC community until December 2, 2024 to submit
comments on this NOPR.
When FERC ordered the supply chain
standard in 2016, there had been few true supply chain cybersecurity attacks to
point to, although the potential for them was clear. That certainly isn’t true
today, when new attacks seem to be reported every day and some of them, such as
SolarWinds and the attacks based on log4j, have caused immense damage. FERC is
quite right to ring the alarm bell on this.
Are you either a NERC entity or
a supplier to NERC entities that is trying to figure out what this NOPR means
for your organization? Please drop me an email so we can set up a time to
discuss this!
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.
[i]
And presumably CIP-013-2 as well. That standard didn’t change CIP-013-1 much,
other than to add EACMS and PACS to the Cyber Asset types in scope for the
standard.
No comments:
Post a Comment