I regret to say that the NERC Risk Management for Third-Party Cloud Services Standards Drafting Team (SDT), which in the 2 ½ years they’ve been meeting has yet to finalize a single draft CIP standard of the approximately twelve they committed to deliver, is now under tremendous pressure to come up with some set of standards in the next 7-8 weeks (including the holidays), since NERC is telling them that it’s essential to finish the first drafts of all the new standards by the end of the year. Frankly, there doesn’t seem to be much concern about coming up with quality standards, just getting something that can be put in front of the NERC ballot body in early 2027. Unless a big change happens in the next few weeks, this will not end well.
Here’s some background:
1. The team was constituted based on a good Standards Authorization Request (SAR) that was developed by two NERC entities and approved by the Standards Committee in December 2023.
2. When they first met in - I believe - July 2024, the team decided they wanted to re-draft their SAR. They spent the next six months doing that; it was approved a year after the first one. I didn’t think the second SAR was hugely different from the first one, but I was willing to concede that it had been worthwhile to take so much time to draft it.
3. The second SAR (on page 3) listed two “deliverables” for the project. The first reads, “The (S)DT will strive to minimize impacts to existing requirements for on-premises systems and assets under the existing CIP-002 through CIP-015 suite of standards.” Have they achieved this goal? No, just the opposite: They’re developing a completely new set of CIP standards and definitions called the “100 series” (CIP-102, CIP-103, etc.).
Any NERC entity that wants to make any use of the cloud in a medium or high impact BES environment will need to adopt these standards and definitions wholesale. Moreover, they need to adopt them for both cloud-based and on premises systems. This means those entities must toss their existing CIP programs altogether and start over literally from scratch. I don’t think this meets the definition of “minimizing impact”, do you?
4. Of course, if the SDT is willing to force NERC entities to adopt the new standards for both on premises and cloud-based systems, at least those standards need to be superior to the current ones. Are they? Here’s the problem: The SDT has yet to finalize the first draft of a single standard (and I suppose the same applies to the definitions), let alone all twelve new standards. So, there’s currently no way to be sure what the new standards will look like.
In July, the SDT released “straw man” versions of five standards and nine definitions, which are quite convoluted and raise more questions than they answer (plus, releasing just five of a planned 12 standards is close to useless, since CIP standards tend to depend heavily on each other; that’s certainly true in the case of the 100 series).
Since the July release, inadequate as it was, is the best we have so far, here is the definition of “Cyber Security Zone”, the concept that will replace “Electronic Security Perimeter” for both on premises and cloud based systems: “A defined logical trust boundary that groups applicable systems based on common security requirements, impact levels, or operational security objectives and enforces controls for access, communication, and monitoring. The boundary of a Cyber Security Zone is established through logical security controls, including security policies, identity and access management controls, authenticated communication pathways, and monitoring capabilities, and is independent of physical location or underlying network topology.”
Got it? You’d better get it, since if this definition isn’t improved and the 100 series standards are approved by the NERC ballot body and FERC, you will have to apply it to every on premises medium or high impact BES Cyber System. Moreover, you will have to apply it equally to systems in the cloud, if they meet the definition of “BES Cyber Systems or Services” (BCSS).
5. And what, pray tell, is a BCSS? That definition (the one provided in July, of course) in essence consists of the current BES Cyber Asset definition, with the words “A Cyber Asset” replaced with “One or more cyber services or systems…” This would be OK if there were NERC glossary definitions of both “service” and “system”; but there aren’t any. Of course, NERC entities all have long experience identifying on premises BES Cyber Systems, so it’s safe to assume that if they continue to identify those in the same way, they won’t be found in violation when BCSS replaces BCS.
However, how will you identify your BCSS in the cloud? With on-premises BCS, you have an easy rule to follow: You need to identify every Cyber Asset (i.e., “programmable electronic device”), then decide which of those meet the definition of BES Cyber Asset, including a sub-15-minute impact on the BES if compromised, lost, etc. Then you need to include each BCA in one or more BES Cyber Systems. But I know of no such simple rule for the cloud. Of course, this will lead to problems.
For example, let’s say a NERC entity takes a narrow view of what constitutes a BCSS in the cloud, so they end up identifying very few BCSS. However, an auditor strongly disagrees with them and says they should have identified many more. How can either the entity or the auditor win this argument, absent rigorous definitions of system and service? One way to settle the argument would be if the SDT prepared Implementation Guidance for each standard, as is often (but unfortunately not always) done by SDTs dealing with CIP, and if the document provided guidance on identifying BCSS in the cloud.
However, this SDT has decided they don’t have “enough time” to develop Implementation Guidance, even though they’ve been meeting for 2 ½ years. This means it will be up to each NERC entity to develop their own definitions. In theory, if they apply those definitions consistently in asset identification, the auditors can’t complain, since the problem is that there’s no definition available.
I remember when NERC entities were preparing for implementation of CIP version 5 (the last time the CIP standards and definitions were totally rewritten, although the 100 series will entail much more thoroughgoing changes). Then, multiple auditors weighed in to endorse the idea of NERC entities “rolling their own” definitions. However, since the auditors haven’t been part of discussions of the 100 series so far (probably because they’re under greater restrictions on providing compliance advice than they were more than ten years ago), I doubt that will happen now. The NERC entities will have to decide for themselves how they will comply with ambiguous wording in requirements and missing definitions, and hope their auditor likes what they did when audit time rolls around.
6. Getting back to the SDT’s 2024 Standards Authorization Request, the second deliverable (of two) reads, “The Drafting Team will consider risks related to cloud services for CIP applicable systems, including but not limited to:…” This is followed by twelve risks like “Reliance on indirect services”, “Data sovereignty”, “Key management”, and “Multi-tenancy”. I was pleased to see this deliverable, since I initially thought (and still think) the SDT should focus on “cloud” risks like these. But I was disappointed to hear a few months ago that the SDT has decided these “cloud-only” risks aren’t in their scope, so they’re not addressing them at all in the new standards.
Instead, all the requirements the SDT is now developing are based on the existing CIP requirements for patch management, background checks, configuration management, vulnerability assessments, etc. While all of these are good things, is there really reason to fear that any major cloud provider isn’t regularly applying patches or conducting background checks on their employees? More importantly, since everything in the current CIP standards is required by certifications like ISO27001 and authorizations like FedRAMP, and since the major cloud providers have all of these, why is it necessary to ask them again whether they do these things, since they will be glad to show you their audit reports that demonstrate they’re completely compliant with those standards? Wouldn’t it be better to ask about their key management options or what they can do about the multi-tenancy problem in SaaS? When you’re talking about the cloud, those are the real risks.
Therefore, the SDT is ignoring both of the deliverables they committed to in their SAR. Instead, they’ve decided to rewrite the current CIP standards, even though that goal was nowhere mentioned in the SAR. While I’ve been pointing out inadequacies in the current CIP standards for more than a decade, I believe the only way to rewrite them - and get acceptance from the CIP community for the new standards - is for NERC entities to draft a new SAR requesting this, and for the drafting team to solicit copious comments and ideas from the community before putting (digital) pen to (digital) paper. I say this because I doubt there’s anyone who’s worked with the CIP standards for a while that doesn’t have strong opinions (some unprintable, to be sure) about them.
What should never have happened – but which has happened – is for a drafting team that was formed to address a very different task to decide that it would be more interesting to rewrite the existing CIP standards, then develop new standards that reflect their own idiosyncratic ideas about what the standards should look like – all without soliciting any feedback from the CIP community until the standards are balloted. At that point, the NERC entity’s only choice will be to reject the standards altogether or to swallow their objections and approve them.
7. Probably the worst part of all this is that the SDT, again because they’re in such a hurry, is clearly not planning to post the standards and definitions they’re drafting for the NERC entities before the first ballot. What it seems they’re planning to do is share them with certain selected NERC entities that ask to see them. Given that there are over a thousand NERC entities that will be affected by this, that seems a little odd, don’t you agree? I don’t know of any time that’s been done before. It’s certainly against the spirit of NERC standards development, if not the Rules of Procedure themselves. Every NERC entity that will have to comply with the new standards should have the opportunity to comment on them before the SDT finalizes them.
Folks, I remember the big confusion – and sometimes fierce arguments, although I don’t believe anybody was killed – that accompanied the CIP v5 rollout, due to the ambiguities in those standards and their definitions. Even though there were only a small number of significant ambiguities in CIP v5, including the meanings of “affect the BES”, “programmable” and “routable” – those alone were enough to create a lot of trouble.
If what this SDT released in July is any indication (and it’s unfortunately the only indication that most NERC entities are likely to have before the first ballot in early 2027), there will be far more significant ambiguities in the 100 series, with even more arguments, etc. And as I’ve already said, there will be no guidance documents to settle arguments between auditors and entities.
Why should the NERC CIP community have to suffer through this? In my opinion, two things need to be done:
1. When the SDT finishes their first draft of the 100 series standards and definitions – even if it’s at 11:59 PM on December 31 – they need to post them for comment by all NERC entities. There should be at least a three-week comment period, hopefully followed by a webinar so entities can get their questions answered and perhaps make further suggestions. The SDT should then make their best effort to incorporate each suggested change into the 100 series standards (when the change has merit, of course). At that point, they should submit the standards to the quality review process and make any changes required by the QR team. Once they’ve done that, they can be posted for the first ballot.
2. The SDT needs to develop implementation guidance for each of the 100 series standards. Of course, that will take a significant amount of time and will delay approval, since the guidance itself will need to be approved by the ballot body. However, that’s the whole point: NERC entities should not be forced to throw out their current CIP compliance program and adopt a brand new one, if there are going to be significant questions about what “compliance” means and no reliable way to resolve them.
I’ve already made suggestions like this to one SDT member, who immediately pointed out that they must finish drafting the standards by the end of the year. I asked why that’s the case, although I already knew the answer: the Modernization of Standards Processes and Procedures (MSPP) changes come into effect on January 1. These are a set of badly needed changes to the NERC standards development process.
I’ve skimmed through the document I just linked, and I think these changes are quite good. My favorite is that NERC entities will only need to vote once on each new or changed standard, as opposed to having to vote usually four times, with the standards revised to reflect comments received with the ballots. In the new procedure, there will be multiple comment periods, in which the entities will submit comments and the SDT will make changes based on those comments; but there will only need to be one vote, after the NERC entities have gone through multiple comment rounds, and the standards are to their liking. This should greatly expedite the approval process and make it much less stressful.
I asked the SDT member why the MSPP was something to be feared. He didn’t have an answer, but I already knew it: The MSPP replaces the Standards Authorization Request process – which has always been quite cumbersome – with a more streamlined Standards Initiation Request (SIR) process. Of course, that’s good, but that means the SAR that the drafting team spent six months developing will need to be thrown away and they’ll need to start over with a SIR.
However, I consider that to be a feature, not a bug, since the SDT hasn’t followed their SAR anyway. They need to rethink what they’re doing and only require deliverables that they can actually…you know, deliver. And if they insist that they need to rewrite the current CIP standards, they need to explain why that’s necessary, so the replacement for the Standards Committee (which goes away on January 1) can decide whether this is in fact needed. Even more importantly, they need to provide the one “deliverable” that was urgently requested in both SARs: They should focus first on solving the problem of NERC entities not being able to utilize SIEM services that move to the cloud.
In my last post, I described (in the second-to-last paragraph) the three small changes that I think are needed to make it possible to use cloud-based SIEM services; I honestly think those changes could be drafted in a matter of weeks, not 2 ½ years and counting. Let’s get this done first and then think about whatever else is needed. But whatever we do, let’s not saddle NERC entities with a Rube Goldberg machine that seems designed to provide maximum confusion with minimum benefits.
P.S. It’s ironic that the SDT is in such a hurry to finish this year, since it will be more than two years before the 100 series can be implemented, even if the standards are quickly approved by the NERC ballot body and by FERC. This is because the SDT wants to make some changes to CIP-002 (i.e., the current version for on-premises systems, not CIP-102, the 100 series version). Those changes will go into a new version CIP-002-9.
However, there are now two previous versions of CIP-002 that are scheduled to become enforceable on July 1, 2028: CIP-002-7 and CIP-002-8. Since one version of a NERC standard, no matter how important, isn’t allowed to “jump ahead” of an earlier version, this means the 100 series can’t be enforced before October 1, 2028, but most likely will need to wait until sometime in 2029.
By the way, the simple proposal to fix the SIEM-in-the-cloud problem that I discussed earlier shouldn’t require any change to CIP-002 or any of the other current CIP standards. Thus, it can be implemented as soon as it is approved by FERC, although how soon will depend on the implementation plan.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for three months after they come out by becoming a free subscriber. You can also access all of 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 become a founding subscriber for $100). Whether free or paid, 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].