Â
Two weeks ago, FERC issued an important Notice of Proposed Rulemaking (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.