One of the two or three most serious problems caused by the current effective “prohibition” of cloud use in medium and high impact NERC CIP environments is that a Control Center for a renewable energy provider (usually an owner and/or operator of wind and solar farms) cannot be implemented in the cloud, any more than the Control Center for a medium-sized electric utility can – despite the indisputable fact that a compromise of the latter could have a far greater impact on the Bulk Electric System (BES) than a compromise of the former.
The reason why this is such a problem is simple: In case you haven’t noticed, renewables providers make up by far the fastest growing sector of the electric power industry. Some thriving renewables providers today didn’t even exist ten years ago, and all of them were much smaller then. Like almost any business that’s started in the last 15-20 years, it’s likely that most renewables producers were born in the cloud and have lived there ever since.
Of course, if a renewables producer has just a few wind or solar farms, their Control Center will be low impact and can be in the cloud now (some are). But once they have 1500 MW under control (and that could easily mean just 3-4 plants), the Control Center – and therefore the systems in it - becomes medium impact.
In theory, the formerly low impact Control Center then needs to move out of the cloud and onto the producer’s premises. Of course, that would involve a lot of expense and time. More importantly, it will both raise costs (at least operating costs) and greatly limit the producer’s software options, since on premises software is increasingly less functional, more expensive and less secure than cloud-based software (aka SaaS). In fact, someone who works for a major software provider to the power industry told me it’s now impossible for a large provider to make money with on-premises software.
Even though I hope no renewables producer will be forced to move their Control Center from the cloud to their premises (and I don’t know whether that has ever happened), this problem needs to be addressed the right way: by changing the standards. The current “Cloud CIP” standards drafting team (SDT) has always considered this to be an important goal of their project, and there’s no reason to doubt their sincerity.
However, it’s becoming increasingly unlikely that the new standards, called the “100 series”, will even reach the approval process (i.e., a first ballot by NERC entities), let alone survive it. But even if they do get final approval from NERC and FERC, there’s another problem: Due to something the SDT didn’t realize until recently, the earliest the new standards can come into effect[i] will be sometime in 2029. Given how long the NERC CIP community has already waited to have full use of the cloud, this may feel like the ultimate insult.
Fortunately, last December I realized that completely fixing the Cloud CIP problem – which roughly speaking means allowing NERC entities with high and medium impact BES environments to utilize cloud-based assets that meet the definitions of BES Cyber System (BCS), Electronic Access Control and Monitoring System (EACMS), or Physical Access Control System (PACS) - will require just about eight simple changes to the CIP standards and definitions (three will be simple changes to the standards and five will be changes to existing definitions or creating new ones).
These changes could be drafted and approved very quickly. If there’s an early implementation provision, at least some NERC entities could be utilizing cloud-based medium impact Control Centers sometime in 2027; the rest could do so in 2028. And this approach, since it doesn’t require modifying CIP-002, won’t suffer from the problem that will prevent the 100 series from being implemented until 2029. It can be implemented after FERC approval and at the end of whatever implementation period the drafting team (which might be the existing team but could also be a new one) decides on.
However, the Hugging Face attacks, in which a swarm of about 700 OpenAI bots escaped their enclosure and decided on their own to attack two companies, one of which was OpenAI itself (both attacks succeeded), convinced me that putting any power control systems in the cloud that could be commandeered by rogue bots to attack the BES shouldn’t be allowed - at least not for the time being. Since BES Cyber Systems (BCS) by definition impact the BES, this means medium and high impact BCS shouldn’t be allowed in the cloud at all for the time being.
But there’s a difference between systems in a medium impact renewables Control Center and systems in any other medium impact Control Center (e.g., a Transmission Control Center or a fossil Generation Control Center): The renewables systems don’t directly impact the BES. Instead, they impact the devices in a wind or solar farm, primarily wind turbines and solar panels.
The devices in the farm don’t themselves directly impact the grid, either. Instead, they supply DC power (which is constant) to an inverter, which converts that to AC (alternating current) power. Only the inverter is connected to the power grid, so only an attack on the inverter could directly affect the BES.
There’s an even more important reason why wind and solar farms don’t directly impact the grid: As most of us learned during our first year on this earth, the sun doesn’t always shine and the wind doesn’t always blow. No grid planner worth their salt would count on a wind or solar farm to provide power at any given moment, although they can do so on average over broader periods of time. This is what “baseload” power (nuclear or fossil fuel) is for. Therefore, if a cyberattack on a wind or solar farm, or on the Control Center that manages it, causes it to go offline, there will always be adequate power to keeps the lights on, unless the planners aren’t doing their jobs.
Given this, and given that leaving the cloud will cost a renewables provider a lot of money and probably leave them less secure and less efficient, why should a provider whose Control Center has become medium impact be forced to leave the cloud? And by the same token, why should a provider whose Control Center is already medium impact be prevented from moving to the cloud? Frankly, I can’t see any reason for doing either of these.
How can this change in policy be facilitated? As I’ve already said, I don’t like the idea of leaving the standards unchanged and implementing an unacknowledged workaround; there’s too much of that bug going around now in the NERC CIP community. One way to change the standards might be to insert the word “inevitably” in the BES Cyber Asset (BCA) definition (a BCS is defined as one or more BCAs), on the idea that if the impact isn’t inevitable, it doesn’t count as impact at all.[ii]
However, the problem with that is it could (and probably would) lead to assets in renewables Control Centers, and even the inverters fronting the wind and solar farms, not being considered BCS at all – meaning they might not have to comply with CIP at any impact level – low, medium or high. My guess is most renewables owners and operators don’t mind having medium impact BCS, since a) there are few renewables assets that meet the BCA definition (especially compared to assets in for example a medium impact Transmission Control Center), and b) having a medium impact Control Center – which must comply with the same CIP requirements as medium impact Transmission and fossil generation Control Centers - gives the renewables industry more legitimacy in the eyes of the electric utilities and private industry users like data centers that buy their power.
Another “solution” would be to make it possible for all operators of medium and high impact Control Centers to implement them (meaning the BCS in the Control Center) in the cloud, using either the very complex (and probably totally unworkable) process being proposed by the “Cloud CIP” SDT or the eight simple steps I suggested in the post linked earlier. However, I’ve now decided that, because of the dangers posed by bot swarms, high and medium impact BES Cyber Systems shouldn’t be allowed in the cloud for the time being, no matter which approach is pursued: the SDT’s or mine.
Thus, the only solution I can see – although I’m sure there could be others – is to create a new asset type called something like Renewables BES Cyber System (RBCS). RBCS could only be implemented in the cloud (which means that BCS in on-premises renewables Control Centers will continue to comply with the same CIP requirements that BCS in on-premises non-renewables Control Centers must follow).
In the cloud, the requirements that apply to RBCS wouldn’t necessarily be the same as those that apply to non-renewables BCS; since the risks are different for the two, the requirements should similarly be different. However, because the current SDT hasn’t considered cloud-based risks at all (as discussed in my most recent post), a new drafting team needs to consider new requirements applying separately to renewables and non-renewables BCS in the cloud, based on the cloud risks that apply to each.
As I said earlier, I think that for now, due to the threats posed by bot swarms, medium and high impact non-renewables BCS shouldn’t be implemented in the cloud (e.g., as SaaS) at all, although it’s safe to implement medium and high impact RBCS in the cloud. It would be a good idea to start drafting a Standards Authorization Request (SAR) for this now – although a Standards Initiation Request (SIR), the analog to the SAR found in the revised NERC Standards Process Manual (which will be phased in next year), might be more appropriate (the best thing about NERC is the simplicity and clarity of its processes 😊).
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 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). Of course, if you can’t pay $30 but really want to access all my posts, send me an email and I’ll give you a one year complimentary full subscription (this offer doesn’t apply to bots).
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].
[i] The problem is that the SDT feels that the new 100-series standards they’re drafting won’t work without a change to CIP-002. Therefore, if they ever reach the point where they can post the 100 series for the first NERC ballot, they will also post the revised CIP-002, which will be numbered CIP-002-9. The currently enforced version is CIP-002-5.1a (which has been in place for over nine years), but there are two versions that are awaiting enforcement (i.e., implementation): CIP-002-7 and CIP-002-8. These will both come into effect on July 1, 2028. Since a new version of a standard can’t “jump ahead” of an earlier version that is awaiting enforcement, the earliest CIP-002-9 (and the 100-series standards, which depend on it being in place) could come into effect is October 1, 2028. Since it’s not likely that NERC entities will appreciate having to implement three versions of one standard within even six months of each other, it’s likely that the 100 series will come into effect on or after April 1, 2029, if it is fully approved by NERC and FERC before then.
[ii] Seven years ago, I suggested this as a way to prevent transformers from being considered to be BCS. Fortunately, there’s never been a serious move to treat transformers as BCS, since a transformer in itself (as opposed to a load tap changer or dissolved gas analyzer attached to it) isn’t operated by a microprocessor (which can be hacked); instead, it operates strictly according to the laws of physics (which so far haven’t been hacked, although who knows what AI will be able to do? Perhaps annul Newton’s laws?).