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 [email protected] 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.