Note from Tom: I have moved from Blogspot to Substack as the main platform for my blog. Starting August 11, I will charge $30 per year on Blogspot for a subscription to all my new and legacy posts (the 1200 legacy posts go back to 2013, when I started the Blogspot blog. Almost half of those posts deal with NERC CIP).
Because of my long relationship with Energy Central, I will continue to publish my new posts that have to do with the electric power industry (including my posts on NERC CIP) on EC for free. However, if you want to see my other new posts (including posts about AI, the cloud, and developments with vulnerability management and vulnerability databases), you need to become a paid subscriber. I hope you’ll do that!
I’ve said multiple times that the “Cloud CIP” standards, that will make full use of the cloud “legal” for NERC entities with high and medium impact CIP environments, are unlikely to be fully drafted, approved and implemented before 2031; frankly, I think even that date is optimistic, absent some extraordinary action by the NERC Board of Trustees.
However, I think timing is only the second biggest concern about the Cloud CIP standards. The biggest concern is whether the drafting of the standards will be hurried so much that they won’t do much good once they’re implemented. I have attended (and participated in) the meetings of multiple CIP Standards Drafting Teams (SDTs) previously, so I’ve had a chance to observe how they work. The biggest disappointment I’ve had was with CIP-013-1, although as you will see, I don’t blame the team that drafted it for its problems.
I participated in a lot of the meetings of the team that drafted CIP-013, one of the first non-military supply chain security standards ever drafted. That team had to break a lot of new ground. If they had been able to spend more time on drafting the new standards, they would have been able to make them much better. However, in their order in July 2016, FERC gave them just one year to develop the standard, get it approved by the NERC Ballot Body (as has been the case with other new or revised CIP standards, final approval required four ballots) and the NERC Board of Trustees, and put it on FERC’s desk for their approval.
The team started drafting CIP-013-1 in the summer of 2016, soon after FERC issued their order. The first ballot for CIP-013, which I believe was in January 2017, failed miserably. When the team met again in February, their primary concern was what changes they could make to at least improve their position in the second ballot – even though they realized it was unlikely they could pass CIP-013 on the second ballot.
Here’s a quiz question for you. When they met in February 2017, do you think the CIP-013 drafting team:
a)Â Â Â Â Â Racked their brains to figure out a way to make CIP-013 a shining example of how to draft a tough but fair supply chain cybersecurity standard, no matter how many ballots it might take to do that? Or,
b)    Terrified at the prospect of missing FERC’s deadline, focused all their changes to the draft standard on the single goal of getting the most votes possible on the next ballot?
You’re right! The correct answer is b). I’m sure all NERC SDTs are constantly evaluating their prospects in the next ballot and adjusting their changes accordingly, but the fact that this SDT was laboring under a very unrealistic one-year deadline set by FERC meant they had little room for error; they had to implement – and quickly – whatever changes were needed to put the standards on course to meet that deadline. However, the team did meet the deadline; they had CIP-013-1 approved by NERC and on FERC’s desk by one year after FERC’s original order was published in the Federal Register.
What did option B “cost”? Here are four changes that the SDT made to the standard in response to negative comments received with the first or second ballots:
1. The SDT had originally developed a definition of the term “vendor”, which is of a course a key term for a supply chain security standard. Since new terms must be balloted as well, this was included in the first ballot. Like the draft standard itself, the draft vendor definition also failed in the January 2017 ballot. However, instead of redrafting the definition, the SDT decided there wasn’t time to redraft both the definition and the standard multiple times; therefore, they dropped the definition altogether. As a result, the NERC Glossary still lacks a definition of vendor.
While there aren’t many disputes over the meaning of vendor, one common issue that arises in the power industry is when one utility does a non-cash barter deal with another utility for say substation equipment. Is each utility a vendor to the other one, meaning they both must follow the requirements of CIP-013? This issue has never been addressed in the only way it can “legally” be addressed: put together a team to draft a new definition, submit the definition to multiple NERC ballots, get NERC Board approval, and finally submit the definition to FERC to approve.[i]
2. In the first draft of CIP-013-1, Requirement R3 mandated that, every 15 months, the NERC entity repeat a lot of what they are required to do in Requirement R1: “identify and assess” risks to the supply chain of BES Cyber Systems and services. However, that requirement received a lot of pushback in the comments made with the first ballot; it seems a lot of NERC entities thought having to identify and assess their supply chain security risks every 15 months is too much to ask. That attitude might have been justified in 2017, when there still hadn’t been many serious supply chain security attacks. However, it’s impossible to justify today, when massive supply chain attacks like SolarWinds and Kaseya have unfortunately become much more common.
To ease passage of the standard in the next ballot, the SDT reduced R3 to what it contains today:
Each Responsible Entity shall review and obtain CIP Senior Manager or delegate approval of its supply chain cyber security risk management plan(s) specified in Requirement R1 at least once every 15 calendar months.
Note that:
A.    The Responsible Entity must “review” their plan, but the Requirement doesn’t state what they need to look for in their review. Is it enough to make sure that the first letter of every sentence is capitalized? I don’t see what prevents the entity from making that interpretation.
B.    The RE must obtain CIP Senior Manager approval, but for what? Presumably, the CSM could simply rubber-stamp “Approved” on the plan every year; the entity wouldn’t be in violation of the Requirement. In fact, it’s hard to see how any entity could not be found in compliance with R3. They would certainly have to try very hard for that to happen.
3. CIP-013-2 Requirement R1 Part 1.1 says the Responsible Entity must “…identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services…” Fair enough, but where does the standard indicate that the entity must mitigate those risks? The answer is simple: Not only was the word “mitigate” completely left out of the standard, but Requirement R2, which would have been the logical place to require mitigation of risks, reads “Each Responsible Entity shall implement its supply chain cyber security risk management plan(s) specified in Requirement R1.” In other words, R2 is just a redundant requirement emphasizing that the entity should really do what they’re already required to do by R1.
4. Meanwhile, there’s no requirement for the entity to do anything about the risks they’ve identified and assessed in R1 and R2. For example, suppose the entity has determined - perhaps through an answer to a questionnaire question - that a vendor poses a huge risk because they don’t require strong passwords to access their systems.
In theory, a NEC entity – or frankly, a customer of any type – would immediately call the supplier upon hearing this. They would be outraged and demand to know when strong passwords would become mandatory: “5 minutes from now? 10 minutes? OK, we’ll give you until 2PM today.” No matter what time the supplier quoted them, the entity would call back at that time and demand to see evidence that strong passwords were now mandatory.
Last September, FERC put out a Notice of Proposed Rulemaking (NOPR) for CIP-013-2. In that document, they expressed dissatisfaction with how CIP-013 has been implemented; they asked for comments on problems that are present in the standard, as well as possible fixes to those problems. In addition, they listed a few problems they had identified on their own.
One of those problems – and IMHO the biggest one – is that “…many SCRM plans did not establish procedures to respond to risks once identified..”[ii]; of course, this is the fourth problem above. In other words, since CIP-013-2 doesn’t require a NERC entity to mitigate any risks they identify, many are simply not doing mitigation. That is, when they learn (perhaps from a questionnaire response) that a supplier is missing an important security control or is otherwise falling down on cybersecurity in an important way, they don’t immediately get in touch with the supplier to find out why they have this problem – and to get them to agree to address the problem by X date. And even if the entity does that, they may not follow up with the supplier on X date, to make sure they did what they said they would do.
To make an already-long story short, the four changes (or omissions) listed above were made by the CIP-013 Standards Drafting Team in 2017 to increase the chances that the new standard would be approved by NERC by the date required by FERC when they issued their order in July 2016. While the team achieved their goal of meeting FERC’s deadline, they didn’t, in my opinion, achieve their goal of delivering to FERC a high-quality supply chain cybersecurity risk management standard.
Here’s a second quiz question. Did FERC, upon receiving CIP-013-1, immediately drop whatever they were doing and start reviewing the standard – especially after they’d forced NERC to jump through hoops and cheapen the standard to meet their arbitrary deadline? Of course not. In fact, by the time FERC received the new standard in 2017, they no longer had a quorum; this was because a few Commissioners resigned after the new administration came in on January 20, 2017. The remaining Commissioners (I believe there were just two left) couldn’t take any official actions at all. Thus, after giving NERC only a year to develop CIP-013, it took FERC 15-16 months to approve CIP-013-1 in October 2018.
Because of the compromises the team made to meet their deadline, CIP-013, although it has done a lot of good, has so far not lived up to its potential for mitigating supply chain cybersecurity risk for the Bulk Electric System. This is why FERC is now considering ordering NERC to re-draft CIP-013. I hope they do that.
I also hope the NERC Project 2023-09 Risk Management for Third-Party Cloud Services drafting team won’t make the same mistake and sacrifice the quality of the standard(s) on the altar of getting the new and/or revised standards drafted and approved quickly. I’m saying this because I believe there may be pressure on that SDT to speed up drafting of the standard(s) already, even though there are a number of fundamental decisions they haven’t made yet.
I’ll have more on that topic soon.Â
If you would like to comment on what you have read here, I would love to hear from you. Please comment on this blog’s Substack community chat or email me at [email protected].
[i] Please don’t point out that FERC tried to clarify the vendor definition in their October 2018 Order approving CIP-013-1; I know they did. However, FERC has no authority to change, or even “clarify”, a NERC standard or definition on their own. Of course, they can order NERC to draft a revised standard or definition, get it approved by the NERC Ballot Body and the Board, then submit it to them to approve – easily a 1-2 year process. But FERC didn’t do that in 2018, so what they wrote has no official bearing on CIP-013-1 compliance.Â
We all know that, if FERC says up is down in one of their orders, the auditors are likely to follow their lead and audit using this revised definition of “up”; therefore, wise NERC entities will do the same. Thus, FERC’s informal definition of vendor is likely to be “implemented” in this back-door manner. The big problem with the CIP standards is that there are so many of these back doors. They’re in place because the “front-door” methods for drafting, interpreting or revising standards and definitions usually take at least 1-3 years to complete – at which point the question is often moot or the threat has already been realized.
This is why there are still no CIP standards that directly address ransomware or phishing. Those two standards could each easily take 4-5 years to develop, from initial discussions and development of a Standards Authorization Request (SAR) to compliance being auditable. Nobody at NERC is inclined to devote years of their life to developing a new standard, unless the need for it is overwhelming (which is the case with the “Cloud CIP” standards).
[ii] This finding is from a 2023 NERC Lessons Learned report. The reference is from paragraph 28 of the NOPR.