On Tuesday, I listened to the webinar presented by the NERC Risk Management for Third-Party Cloud Services Standards Drafting Team (SDT), the group that is charged with revising the NERC CIP standards to make it possible for larger electric utilities and independent power producers to implement systems that monitor and operate the North American Bulk Electric System (BES) in the cloud; currently, those entities cannot do this without running the risk of being found non-compliant with many CIP requirements.
While I have at least four or five blog posts’ worth of observations to make, I’ll give you the Cliff Notes™ summary: Although I wouldn’t have said this six months ago, I now believe the drafting team, after 18 months, is on the wrong course and headed for a dead end. If they succeed in drafting the standards they say they will draft (they haven’t drafted a single requirement yet), the standards will never be approved by NERC’s legal department, the NERC entities, or FERC. Of course, if just one of those groups disapproves, all the SDT’s work will be for naught; NERC will have to go back to the drawing board, presumably with a new SDT.
However, even if the standards they’re proposing to draft are approved, they will quickly be seen to be compliance theater, not regulations intended to mitigate real risks. They will mitigate little cloud risk, and they will leave the question whether use of the BES is safe for the cloud unanswered,
Therefore, I’m recommending that the SDT abandon what it’s doing now and take a very different approach – one that is likely to achieve the goal articulated in their Standards Authorization Request (SAR). If they don’t abandon this approach now, they will surely abandon it within a year or two - since there is no way their current approach can succeed, no matter how long they work at it.
Should the SDT just give up and go home? No. The reason why they’re in this situation is they made the problem out to be much harder than it is. There is another approach that will address the problem they need to solve, and – ironically – do so much quicker.
Here’s the problem…
The problem the SDT needs to solve is that the current CIP requirements, and the definitions that go with them, were mostly drafted in 2011-2012, as part of CIP version 5. At that time, the cloud was still widely viewed as an experimental technology; nobody (including me) thought it would ever be considered suitable to house systems that operate the BES.
As a result, the CIP standards never mention the cloud, nor do they distinguish between on premises and cloud-based systems. Thus, any cloud-based system that meets the definition of  BES Cyber System (BCS), Electronic Access Control or Monitoring System (EACMS), or Physical Access Control Systems (PACS) has to comply with every Requirement and Requirement Part that applies to that system (there are about 120 that apply to BCS, 75 that apply to EACMS, and 50 that apply to PACS. I’ll label them collectively as “requirements”. I’ll also refer to BCS, EACMS and PACS as “BES systems”).
If a NERC entity utilizes one of those systems that is located in the cloud (either as SaaS or PaaS. SaaS stands for software-as-a-service, meaning the customer has no responsibility for installing or maintaining the software. PaaS stands for platform-as-a-service, meaning the customer is provided a platform with O/S and database, on which they can install and manage their own software), they will of course need to provide evidence of compliance with each applicable requirement during audits.
If a SaaS product in the cloud meets the definition of BCS, EACMS or PACS, the Saas provider will need to furnish the greater part of that evidence, although they need to provide it to the NERC entity, not the NERC Region conducting the audit. If a software product (e.g., a SCADA system) is implemented on PaaS, the “platform CSP” – e.g., AWS or Azure – will need to furnish that evidence. From now on, I will refer to both SaaS and PaaS providers as CSPs (cloud service providers).
But guess what? Neither type of provider is likely to furnish compliance evidence for a single CIP requirement, let alone 50-120 applicable requirements. The most they will provide is for example an ISO 27001 audit report, but that is not acceptable as NERC CIP compliance evidence. It is even less likely that a SaaS provider or platform CSP is likely to agree to special contract terms of any type, let alone terms obligating them to provide evidence.
For example, probably the most important manifestation of the CIP/cloud problem is systems that perform electronic access monitoring of a BCS or an ESP (electronic security perimeter). If one of those systems - e.g., a SIEM system - is deployed onsite, it meets the definition of EACMS. That means it will have to comply with about 70 CIP requirements. Of course, the NERC entity will need to have evidence of compliance with all 70 requirements. Gathering that evidence will require a lot of work, but there is no reason why the entity should not be able to gather it, barring a CIP Exceptional Circumstance.
However, suppose a NERC entity’s longtime SIEM vendor announces that a) they are moving to a cloud-only delivery model, or b) they will retain their on premises version, but from now on all functionality upgrades will only be available for the cloud version, or c) the on premises version will still receive all upgrades, but will from now on cost ten times as much as the cloud version (which was reported to me by one large NERC entity). All three of these scenarios are being realized with increasing frequency. In fact, one large software provider to the electric power industry told me recently that it’s now impossible to make money with software that runs only on premises.
The entity decides they have no choice but to move to the cloud, unless they want to drop that vendor altogether and go with what they think is an inferior on-premises product. Of course, just because the SIEM moves to the cloud doesn’t mean it ceases to be an EACMS. The EACMS definition, which was originally drafted in 2011, doesn’t say anything about applying only to on-premises systems.
Six months after they start using the cloud version of the SIEM software, the entity receives their 90-day CIP audit notification. They send the provider a list of all the CIP requirements that apply to the CSP and ask when they can anticipate receiving compliance evidence for each of those requirements. They are shocked when the reply is, “We can’t provide any of that evidence.” The entity huffs and puffs and threatens to leave for another cloud-based competitor (since by this time the entity has realized how superior the cloud-based delivery model is), but every competitor they contact tells them the same thing: They can’t provide the required evidence. The entity swallows their pride and finds an on-premises SIEM that is most likely inferior to, and more expensive than, the cloud-based SIEM they just left.
Why does this entity have this problem? It’s not because the current standards and definitions don’t apply to the cloud, it’s because they do apply to the cloud, since they don’t exclude it. For example, the EACMS definition was written only with on-premises systems in mind, but the fact that it doesn’t mention “on premises” or “cloud-based” systems means it applies to systems in the cloud as well.
A possible solution
While this may sound like bad news, in fact it’s good news: The “CIP/cloud” problem is exclusively a problem of wording of a small number of definitions and requirements. Therefore, the solution to the problem should just require a small number of changes to definitions and requirements.
In December, I put up this post that listed eight small wording changes that I believe will completely solve the CIP compliance problem for BCS, EACMS and PACS; in other words, if these changes are made, I believe that NERC entities subject to CIP compliance will be able to utilize cloud-based services (SaaS or PaaS) that meet the current definitions of BCS[i], EACMS and PACS. How would my simple changes solve the problem articulated in the example problem above?
Since the example above relates to the EACMS problem, how will the changes listed in my post solve that problem? Only three of the changes are required:
1. The term “System” needs to be defined to include both on-premises and cloud-based systems. Note: This will not be an easy task. Even though the term was first used in CIP v5, it was not defined when v5 took effect in 2016 and it remains undefined today. It isn’t an easy term to define, unless you refer to a physical asset (which doesn’t work in the cloud, of course). However, I’m sure it can be defined for CIP purposes.
5. A new term, “Cloud Electronic Access Control or Monitoring System” (“Cloud EACMS”), needs to be defined. The definition might read (with changes highlighted), “A System that performs electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems. This includes Intermediate Devices.”
7. The definition of Electronic Access Control or Monitoring System needs to be revised to something like, "Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems. This includes Intermediate Devices. It does not include Cyber Assets installed in a cloud data center.”[ii]
Just these three changes would probably fix the EACMS problem. The original SAR for the current SDT strongly hinted that it would be great if the SDT prioritized addressing the EACMS problem, then turned to the remaining Cloud/CIP problems; unfortunately, the SDT didn’t take that hint.
Since I believe the EACMS problem is the worst part of the Cloud/CIP problem (although the “PACS problem” – i.e., the fact that NERC entities can’t utilize cloud-based physical access control services – is a strong Number Two), it is a shame the hint wasn’t taken. The three changes required to fix the problem could probably have been drafted, approved and implemented by this year. This would have allowed NERC entities to freely use cloud-based services like SecureWorks (the PACS problem could also probably have been solved by this year, allowing NERC entities to utilize cloud-based PACS services, which, like cloud-based EACMS, they have been forbidden to do since CIP version 5 came into effect in 2016).
Meanwhile, back at the ranch…
What is the SDT’s current approach? They’re proposing a three-track compliance program:
1.     NERC entities that don’t use the cloud for BES systems now, and don’t intend to do so in the near future, can continue to comply with the current CIP standards, which will remain essentially unchanged.
2.     A new set of standards, numbered CIP-102 through CIP-115, will be developed; the SDT is referring to these as the “100 series”. These standards will aim to accomplish roughly the same purposes as the analogous existing CIP standards do, but they will apply to both on-premises and cloud-based systems. For example, the requirements in CIP-107 will have the same overall goals as the requirements in CIP-007, but the requirements will apply both to cloud-based and on-premises systems (for on-premises systems, a NERC entity will be able to choose, on a system-by-system basis, whether they will follow the current standards or the 100 series).
3.     A single standard, CIP-116, will address risks that only arise when a NERC entity uses cloud-based BES systems, which means they’re not addressed in the current CIP standards. I don’t believe the SDT has had any serious discussions so far about what requirements will be in CIP-016, but I believe it will only address cloud risks that can affect a single NERC entity – for example, the risk that the entity’s communications to their cloud provider will be cut off.
Note that the latter risks do not include risks originating in the cloud that affect the BES, which I called “cloud BES risks” in my previous post; these are by far the most important risks that arise due to use of the cloud for power industry OT systems. During this week’s webinar, one of the speakers described those risks as “out of scope”, meaning they won’t be addressed by this SDT. I was surprised to hear that, since the SDT made a point of identifying twelve of these risks as in scope, in the revised SAR they drafted in 2024.
However, I have also concluded recently that these risks need to be out of scope. In fact, I now realize that cloud BES risks can’t be addressed in any reasonable amount of time (unless you call three decades “reasonable”) by this or any other NERC CIP standards drafting team – since these risks can’t be mitigated by mandatory standards that apply to NERC entities. They need to be addressed in voluntary guidelines that apply to CSPs, that are developed by a working group of power industry and CSP experts (whether or not those experts currently work for a CSP). This will be a hugely important effort. See my previous post for a full discussion of this.
I don’t have a problem with the first and third items, but I do with the second. It is clearly based on the assumption that the current CIP standards and definitions don’t apply to cloud-based systems. However, just the opposite is true. As the above example shows, the essence of the Cloud/CIP problem is that, as written, the current CIP standards already apply to cloud-based systems, because the current CIP definitions don’t differentiate between on-premises and cloud-based systems. The problem is there is no way for a NERC entity to get the evidence it needs to prove CIP compliance for cloud-based systems.
Let’s use another example. Since the SDT clearly intends to draft a new requirement in the “100 series” CIP standards, corresponding to almost every CIP requirement in the current standards, there will presumably be a requirement CIP-107 R3 that is based on CIP-007 R3, Malicious Code Prevention. CIP-107 R3 will apply to both cloud-based and on premises BES Cyber Systems.
Will the CSP be able to provide a NERC entity with compliance evidence for CIP-007 R3? The answer is almost certainly no for most – if not all – CSPs. This is because almost none of them will be willing or able to provide evidence for any CIP requirement. Is there a way the NERC entity could force the CSP to provide this evidence by inserting terms into their contract? Again, the answer is almost certainly no, since few if any CSPs will be willing to negotiate any terms in a customer contract.
What is a CSP likely to say if a NERC entity customer requests that they provide compliance evidence for CIP-007 R3 or any other CIP requirement? If anything, they’ll say, “We have spent many millions of dollars passing ISO 27001 and Soc 2 Type 2 audits and becoming authorized for federal government use under FedRAMP.”
“Literally all the risks addressed by the current CIP requirements are addressed in these (and other) frameworks, since they are much more comprehensive than CIP. We will be pleased to provide you with audit reports to show we have already mitigated these risks, probably to a much greater degree than you have. Will that be sufficient for you?” (translation: “We have already mitigated all the risks addressed in today’s NERC CIP standards, as well a huge number that aren’t addressed at all. We’re not going to spend time documenting for you controls we have already documented for other audits)
At that point, the NERC entity may say (in their most humble voice), “We will certainly be happy to see the audit reports. However, we can’t use those as compliance evidence, since the wording of the controls listed in the report does not comport with the wording of the CIP requirements. And even if it did, we wouldn’t be able to utilize the reports as evidence, since NERC doesn’t recognize “the work of others” (“others” means any auditors not part of the NERC ERO).
The CSP will probably end the conversation by stating (in as nice a voice as possible), “These are your problems, not ours. If you really want us to provide all this evidence for you, we will be happy to do so after you have signed a new contract at twice the price of the old one. If you’re not willing to do that but you still require the evidence, don’t let the door hit you on the way out.”
This is the bottom line: The electric power industry is a small user of cloud computing services. Even if every system subject to CIP compliance were to move to a single cloud provider tomorrow, that would probably barely register on the salesperson’s monthly quota. Power industry customers (outside of a few huge IOUs, perhaps) are not going to be treated any differently than any other customers
In other words, the SDT is telling us that, after 18 months of work with no final product other than a white paper, they are now ready to spend at least 3-5 years more developing and getting approval for a new set of CIP standards (the 100 series) that suffers from two big problems.
The first is that the new standards, if ever developed, are likely to be rejected by NERC legal, the NERC ballot body, or FERC (all three must approve them, of course) for multiple reasons. I will address those reasons in future posts, but I’ve just described possibly the biggest reason: that CSPs will not provide the compliance evidence that NERC entities will need to prove compliance with the new requirements. Of course, no NERC entity will be assessed a violation for that reason, but why should they have to go through the whole charade (“compliance theater”), developing, balloting, and “complying” with standards for which NERC will never be able to assess compliance? Do NERC entities and CIP auditors have no better use for their time than this?
This would be funny, were it not that in 18 months the SDT has not made any progress in addressing the problem they were engaged to solve: the fact that small changes in the wording of a handful of requirements and definitions are needed to allow NERC entities with high and medium impact BES environments to utilize BES systems located in the cloud (whether as SaaS or self-deployed on PaaS).
I recommend that the SDT, as soon as possible, meet to decide how to accomplish their primary goal in something less than five or more years. I’ll be able to provide some help to them if requested. Every day that passes before they do this is a day wasted before NERC entities can make full use of the cloud.Â
Tom Alrich’s Blog, too is a reader-supported publication. By becoming a free subscriber, you can view new posts for two months after they come out. However, 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!). Please subscribe.Â
If you would like to comment on what you have read here, I would love to hear from you. Please comment below or email me at [email protected].
[i] A BES Cyber System is currently defined as simply a grouping of BES Cyber Assets (BCA), meaning BCA is the foundation of BCS.. Since the BCA definition applies to Cyber Assets, which are devices, and since devices can’t be tracked in the cloud, the definition of “cloud-based BCS” (or whatever the term ends up being) can easily be created by substituting the word “System” for “Cyber Asset”. However, “System” needs to be defined (it was never defined when the term BES Cyber System came into place in 2016 with CIP Version 5).
[ii] There may need to be a definition of “cloud” as well.