I have been writing about the problem of medium and high impact NERC CIP systems being “illegal” in the cloud for close to ten years. At one point, I gave up on the idea that things would ever get better, since I thought the changes that would need to be made to the existing CIP standards would be too much for the power industry.
The problem was (and is) that prescriptive, device-based requirements like CIP-007 R2 and CIP-010 R1 can’t work in the cloud. These will all need to be rewritten as risk based. However, the industry is worried about how auditors would audit true risk-based requirements, since NERC’s Rules of Procedure were originally developed with only prescriptive requirements in mind. Since all the NERC Reliability Standards except for CIP are ultimately based on the laws of physics, prescriptive requirements are the only ones that make sense for those standards; but cybersecurity is based on risk, and all cyber requirements should be risk-based.
Thus, I was pleasantly surprised when in December 2023 a very well-written Standards Authorization Request (SAR) for fixing the cloud problem was approved by the NERC Standards Committee. Note that, by “cloud problem” I’m referring to the fact that medium and high impact BES Cyber Systems (BCS), Electronic Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) cannot be implemented or utilized in the cloud without violating over thirty NERC CIP Requirements and Requirement Parts. I break the cloud problem into three “sub-problems”: BCS in the cloud, EACMS in the cloud and PACS in the cloud.
Note the cloud problem is separate from the problem of BES Cyber System Information (BCSI) being stored or utilized in the cloud. The BCSI problem was solved when CIP-004-7 and CIP-011-3 came into effect on January 1, 2024, although hardly anybody in the NERC community seems to believe that the problem really was solved. As a result, a lot of NERC entities are needlessly refraining from using cloud-based services (SaaS) that sometimes uses BCSI, such as cloud-based MFA and configuration management.
The Risk Management for Third-Party Cloud Services Standards Drafting Team was constituted in the spring of 2024 (in response to the SAR’s approval) and started meeting in the summer; they have been meeting continually since then. However, the SDT has yet to publish a single draft standard or definition for comment, even though they are currently working on about twelve new standards and an undetermined number of new definitions.
If I’d been told a year and a half ago that the SDT would still be meeting today and that they wouldn’t yet have drafted any new standards, I would probably have said that’s not surprising, given how ambitious the project is; in fact, I predicted in late 2024 that it would be 2031 before new standards would be drafted, approved and in effect.
However, starting in early 2025, I began to see some red flags that made me worry the SDT might ultimately fail – i.e., disband without having solved the three cloud problems. Those red flags have only multiplied since then. Below are brief descriptions of about ten of those red flags. Once draft standards and definitions are posted, I’ll have a lot more to discuss.
1. The SDT decided in early 2025 that they would not only draft new standards for cloud-based systems, but they would develop new standards (called the “100-series”: CIP-102, 103, etc.) that would apply to both on-premises and cloud-based systems. At the time, I didn’t see how standards that apply to both types of systems could possibly work (since on-premises systems can be directly audited, but cloud-based systems can’t). But the SDT members assured me (since at that time I was attending at least two SDT meetings per month) that this would be no problem. I still don’t know if or how CIP auditing will work for cloud-based systems.
2. In order not to alienate NERC entities that are happy (or at least not terribly unhappy) with the current CIP standards and don’t want to go through a huge effort to revise all their documentation, procedures, etc., the SDT wants to let them stick with the current standards for on-premises systems, but utilize the 100 series standards for cloud-based systems. However, NERC entities that have both on-premises and cloud-based systems subject to CIP compliance will also be able to have their on-prem systems audited on compliance with the 100 series.
The SDT’s hope is that ultimately all systems subject to NERC CIP compliance will be audited based on the 100 series standards. This is a fine idea, but I know of no provision in the NERC Rules of Procedure that allows a NERC entity to choose not to comply with a group of standards, even though they’re technically required to comply with them. All NERC entities with on premises control systems and with assets (mostly Control Centers, Transmission substations and generating facilities) that meet one of the “bright line” criteria in Attachment 1 of CIP-002 must comply with the CIP standards.
The SDT might address this problem by changing Section 4 of each existing CIP standard to say that the standard isn’t applicable to entities that have chosen to follow the 100-series equivalent of that standard (e.g., CIP-105 for CIP-005). However, negotiating this wording with the NERC lawyers will be a bear. Instead, the SDT seems to be pursuing a strategy of hoping the lawyers won’t notice what they’re doing. Good luck with that.
3. The above is one of at least two – and perhaps more – aspects of the new standards that are likely to violate the Rules of Procedure. Of course, the RoP can be changed, although not by an SDT. Nobody has been able to tell me how the RoP can be changed, but it’s certainly going to require a long process and will almost certainly require both NERC and FERC approval. The SDT’s leaders have told me, probably with fingers crossed, that RoP changes won’t be needed (although one of them said something very different to me less than a year ago). We’ll see what happens, but this is another red flag.
4. The proposed 100 series standards will supposedly fix the cloud problem, which of course is the SDT’s mandate (see below for more on this topic). But the SDT decided early last year that they wanted to add a huge task that isn’t in their mandate at all: rewrite the current CIP standards to be entirely risk-based (or “objectives-based”, to use the current NERC term). Even though NERC entities will be allowed to stay on the current standards for their on-premises systems, the 100 series standards are intended to be the next version of CIP, so sooner or later all NERC entities will have to comply with them, no matter where their systems are located.
I’ve been saying for years that the current CIP standards need to be rewritten as risk-based. In fact, in 2018 I wrote more than half of a book explaining the problems I see with the current CIP standards and describing how they could be fixed. However, I abandoned it when I became too busy (I may be working with someone soon to finally finish the book. If you’re interested in joining this effort, let me know).
But I’m not the only person with ideas about how to improve the CIP standards; just about every NERC entity who must comply with CIP has something to say about the current standards, some of it printable and some not. If this SDT wants to rewrite the current standards for on-premises systems, I suggest they stop what they’re doing now and draft a SAR for doing that, since they have no mandate to do this now. In drafting that SAR, they need to hold listening sessions with NERC entities to get their ideas on how to fix CIP; if they try to impose their own ideas on a very passion-filled topic, they aren’t likely to get approved by the NERC ballot body.
If the SDT does this right, it will take them six months to a year to conduct “listening tours” (physical and virtual, of course), then draft the new SAR. This might seem to be an unnecessary use of the SDT’s time, but deciding for themselves what NERC entities need and then forcing them to swallow the team’s ideas whole isn’t going to work.
5. However, there’s one problem that currently makes all the others moot: Since the beginning of the year, the SDT has been sprinting (although running hard in place is a better description) to meet a seemingly arbitrarily imposed September “deadline” to submit the new standards and definitions for the first ballot for NERC entities to vote on. The SDT is no more likely to meet that deadline than I am to score a goal in the World Cup. Here’s why:
a) Given everything that needs to go on before the first ballot, the team needs to have at least an agreed upon set of about 12 draft standards ready in a few weeks – this will be the “posting for comment” for the NERC community. Yet, after 22 or 23 months of work, the SDT has yet to agree on a single draft standard; in fact, there is at least one standard that the team hasn’t yet decided whether it will even be part of the package they submit. Will they really be able to finalize all twelve standards in a few weeks? Is it possible that the reason why they’re having so much trouble drafting the 100 series standards is that they’re trying to do too much at once - like end global warming, square the circle, and invent a perpetual motion machine in one fell swoop?
b) When the team first started discussing new standards to apply to the cloud, they started using terms like “BES Cyber Systems or Services” and building the requirements on them. However, they never finalized any definitions and still haven’t done so; in fact, there isn’t even agreement on what terms are needed. This is just another task that needs to be accomplished in the next few weeks (this is also one reason why none of the standards are finalized. How can you finalize a requirement without being sure what the terms in it mean?). I note that the team that drafted CIP version 5 – the last major change to the CIP standards before this one – developed their fundamental definition, BES Cyber System, in 2008 or 2009. That was two years before they started drafting v5 and seven years before it came into effect, not three weeks before they first posted the standards for comment.
c) In recent years, the primary guidance for a new or revised NERC standard is its Technical Rationale (TR) – a document prepared by the drafting team that explains what they had in mind when they developed the standard. This SDT is already at work on a TR for each standard (to be more exact, a few individuals are at work on TRs. Given the huge volume of work remaining to be done and the pressure to finish up, it’s not clear they’ll have much time to coordinate with each other). I’ve seen some of the language in one of the TRs; it’s quite complex, which is a huge red flag in my book. If a requirement can’t be described in concise language, it shouldn’t be a requirement, since it will result in endless audit fights.
d) Before the SDT can post the standards for the first ballot, they need to take two steps: The first is posting the draft standards for comment, so that members of the NERC community can submit questions and comments. This comment period is normally at least 25 days; anything less than that will be a big problem, since a NERC compliance team at a major utility can’t just whip something up in a couple of weeks and submit it without any review; in fact, comment periods are normally 45 days.
e) Once the comments are received, the SDT needs to respond to them, including at least all the negative ones (although they can group comments that seem to be similar). However, after responding, the hard work begins: the team needs to decide which negative comments are valid and make changes to the standards or definitions to address those comments. Finally, they need to post the revised draft standards for comment, so NERC entities can verify that they have in fact taken their comments seriously. If the SDT tries to skip this step, they risk making a lot of NERC entities unhappy, and anxious to take their revenge on the SDT in the balloting.
f) The second step the SDT needs to take before the first ballot posting is the Quality Review, in which the draft standards are submitted to a group of NERC lawyers and auditors for their comments (actually, the SDT should have had at least one meeting with the auditors already. If they had done so – as I was repeatedly promised - they might have avoided running into a brick wall in the QR, with the lawyers and/or auditors telling them they have to restart the drafting process from the beginning.
g) I think this is a real possibility, although it’s still better than having the standards get approved by NERC (which is almost certain to take at least a year) and then go to FERC for their judgment. It might take more than one year for FERC to render judgment (I believe the CIP record was 17 months for version 1), given the importance of the cloud changes and given the fact that, unlike almost every other change in or addition to the CIP standards, FERC didn’t order the changes. Thus, if FERC has problems with what’s submitted to them, they might not do what they normally have done with CIP: approve the standard but require that changes be made in a new version. Instead, they might simply remand the standard entirely, so the SDT will have to restart the drafting process from the beginning. This would add at least two years to the amount of time the SDT has wasted. Of course, this would be a catastrophe for NERC, since so many NERC entities have been waiting for so long to – finally! – have full access to the cloud. If they suddenly find themselves in another long wait just when they thought their problem was finally solve…I have no idea what would happen, but it’s unlikely to be pretty.
h) It should be clear that the two comment periods (one for the general community and one for the NERC lawyers and auditors) will take at least two months each – which alone puts the SDT far past their September “deadline” for the first ballot posting. However, that assumes that none of the negative comments will require substantial changes to the standards (and anything more than a misspelling might require a substantial change). But it’s close to certain that many substantial changes will be required, to the point that the SDT may have to throw out everything they’ve drafted so far and start over (in fact, in the last SDT meeting, it was pointed out that one feature of the draft standards – even though they haven’t been officially drafted yet – has already drawn substantial negative comments from one group of NERC entities. There will likely be other such cases as well).
i) Given this, the earliest possible date for posting for a first ballot is probably January, but even that will depend on not needing to make any substantial changes after either the posting for public comment or the quality review. Since that’s not a realistic assumption, I’d say the SDT will be lucky if they can have a first ballot before next spring or even summer. On the other hand, it will be much worse if the initial draft standards make it to the first ballot posting substantially unchanged, since I don’t see any reasonable path to their getting passed by even a majority of the NERC ballot body (i.e., the NERC entities that say they want to vote on these changes), let alone the required supermajority. If the SDT is forced to go back to the drawing board soon (say, after the public posting for comment) rather than 1-3 years from now, it will be a very bad day at the office for the NERC community in general, but especially the SDT members.
Thus, I think it will realistically be at least 3-5 years (including allowance for an implementation period after FERC approves the new standards and definitions) before the standards now being worked on by the SDT come into effect (which brings me back to my original prediction of 2031, although I wasn’t aiming for that result). Given that the team has already met for two years with very little to show for that effort, I wonder how many members will be willing to stick around that long.
I want to point out that there are two scenarios in which I can at least imagine that the most important part of the CIP-in-the-cloud problem would be solved (i.e., an enforceable set of standards and definitions would be in place) in the next two years:
1. When I moved to Chicago decades ago, there was a common saying in politics: “The fix is in.” This meant there was no point in fighting some political move that had recently been made or was about to be made, since the people in charge (which was certainly not the voters at that time!) had already decided what they wanted; they would make it happen no matter what anyone else said. I certainly hope that can’t happen in this case, but given the obviously huge pressure on the drafting team to meet the September deadline for the first ballot, I’m not so sure it won’t.
After all, the NERC Board of Trustees has various emergency powers at their disposal. I can’t imagine what emergency would justify not going through the normal standards approval process in the case of CIP and the cloud. However, I do know that short-circuiting that process would be a huge and extremely costly mistake if it happened. NERC literally might not recover from that.
2. Last November, I realized that the three components of the Cloud CIP problem - BCS, EACMS and PACS in the cloud – could all be solved with eight small changes to the existing standards and definitions (seven of the changes are trivial. One, the definition of “system”, is less trivial but is certainly doable with a few SDT meetings). I also realized that by far the most important of these problems was (and continues to be) the “EACMS problem” (although the “PACS problem”, which is literally word for word identical with the EACMS problem if you just replace every instance of EACMS with PACS, is a close number two). In fact, the 2023 Standards Authorization Request (linked earlier), under which this SDT was constituted, mentioned – nay, pleaded – in a couple of places that the SDT should address the EACMS problem before the others. I don’t think the SDT ever seriously considered this request, mainly because they spent their first six months drafting their own SAR, which didn’t mention this issue at all.
When I realized early this year that this SDT was probably on the road to failure and needed some sort of quick fix, I realized that just the last four of the eight changes (now highlighted in red) in my November post linked earlier were all that are needed to fix both the EACMS and PACS problems (but not the BCS problem, which ironically is the least important today); all four of these are trivial changes that should be easy to draft and shouldn’t be controversial at all. I’m sure that, if the drafting team starts to draft these changes soon (they won’t require a new SAR), both EACMS and PACS in the cloud could be “legal” by the end of next year (Note to the SDT: The scheduling problem with CIP-002 that you discussed in your meeting on Thursday doesn’t apply to these changes, since no change to CIP-002 is needed).
Here’s a final kicker: I’m close to certain that whatever standards the SDT drafts for the posting for comment will not solve the problem of either EACMS or PACS in the cloud. In other words, even if by some miracle the SDT can get the currently envisioned standards and definitions approved by both NERC and FERC, they will still have to go back and make the four changes I listed in that post. Why not make these changes now, rather than wait for NERC entities - who have only on-premises systems, but want to utilize a cloud-based access control or monitoring service or PACS service - to realize they still can’t legally use the cloud when they start to get audited for the 100 series? Boy, will they be p___..…umm, unhappy.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for two months after they come out by becoming a free subscriber. You can also access all my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can donate more than that or become a founding subscriber for $100). Whichever option you choose, please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment in my chat or email me at [email protected].
