This EO is essentially Round Two, since in many ways it’s similar to the first Trump administration’s May 1, 2020 EO about the power grid. Like the previous EO, EO 14420 prohibits acquisition of “foreign-made” electronic devices, but it goes much further. It prohibits any “transaction (that) involves bulk-power system electric equipment — or any critical component, software, firmware, digital service, maintenance service, or remote-access capability associated with such equipment — designed, developed, manufactured, or supplied by persons owned by, controlled by, or subject to the jurisdiction or direction of a Covered Foreign Entity”.

Note that instead of applying only to “bulk-power system electric equipment” as the first EO did, EO 14420 also applies to software, firmware, and services (including maintenance). Moreover, it applies not just to devices and software that are directly purchased for use on the grid, but it also applies to all the components of those devices and software products. The average software product has hundreds or even thousands of software components, 90% of which are open source – meaning they are developed collaboratively by developers around the world, and the source code is available to anyone that wants to inspect it.

Usually, open source collaborators only need to reveal their email address. This can easily be a Gmail address, which is only traceable if you want to subpoena Google. And even if you do that, you will just learn the name the person gave when they opened the Gmail account; this might be Roadrunner, Atilla the Hun, Thomas Jefferson, etc. However, it’s well known that a large percentage of people who participate in open source projects are Chinese and Iranian. What are we going to do: ban all software that contains a single open source component, if somebody (presumably in the White House) suspects that even one of the 100 developers of that component was Chinese? After all, the very existence of the power grid is at stake!

Moreover, even proprietary software and software components are developed by worldwide teams. For example, Siemens operates 21 R&D hubs in China, most of which develop software; they employ over 5,000 Chinese nationals in China. Should be ban use of Siemens hardware and software on the US grid? Siemens is hardly alone in seeking out software development talent wherever it’s found in Asian countries; I would be surprised if any major software company doesn’t emulate Siemens in this regard.

I think you get the idea: few if any software or hardware products can safely be considered free of all foreign influence. So, should electric utilities and independent power producers suspend all procurement of software or hardware products for the grid until the government publishes a list of proscribed products? By my reckoning, that list is due near the end of May 2027 (270 days from publication of the EO). That’s a long time for there to be no investment at all in upgrading the US grid, especially with all the new data centers being built. Of course, data center construction will continue, but when finished they will sit dark until there’s power for them. Maybe someone can convert some of them into roller skating rinks or indoor go-cart tracks.

Actually, the EO doesn’t effectively prohibit all new software and hardware. It only seeks to prohibit software and hardware that:

A) poses an undue risk of sabotage, subversion, unauthorized access, malicious remote action, or supply disruption affecting the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of the bulk-power system in the United States;

(B) poses an undue risk of catastrophic effects on the security or resilience of United States critical infrastructure or the economy of the United States; or

(C) otherwise poses an unacceptable risk to the national security of the United States or the security and safety of United States persons.

The good news is that, if you’re suresuresure the equipment or software you’re about to procure doesn’t fall in one of these three categories, you’re free to go ahead and procure it. However, the bad news is that you’d better be darn sure that nobody in the White House (or the wide circle of industry types and campaign contributors that seem to have broad access to the people that work there) is ever going to raise an objection.

For example, suppose you go ahead and purchase a large quantity of Device X for the power grid, but the number one competitor of Product X is Product Y, whose manufacturer has a close relationship with some high-level people in the White House. A year from now, company Y convinces the WH that Product X poses “an unacceptable risk to the national security of the United States”; X suddenly appears on the “forbidden” list. You will have to pull out all those X devices and replace them with Y devices, selling the former at a bargain price to a utility in Canada. That utility will be pleased to have them, since their power industry won’t have been on hold for nine months as it was in the US. While the US is in its self-imposed grid investment funk, there will be lots of generation and transmission investment in Canada, since there will be huge demand for their power here. Doesn’t all this sound like a lot of fun? 😊

I think you’ll agree with me that this scenario is such a huge own goal that even this administration will back down from trying to enforce this EO, just as they did with the 2020 EO (although they will be reluctant to do that, since campaign donations are sure to flow into the WH due to it). If this were really an emergency – that is, if there had already been successful attacks on the grid conducted through pre-compromised commercial products – and if the volume of attempted attacks were increasing, this EO might even be a good idea. However, the situation is just the opposite: There has never been a successful attack on the North American power grid, which was conducted through pre-compromised products used on the grid. Moreover, I don’t know of a single such attack that was ever seriously attempted^[i].

In fact, I only know of one successful cyber attack that was conducted through a device used in any environment, and in any region worldwide. This was the Israeli pager attack in Lebanon in 2024. But keep in mind that this was very much a physical attack, which was aided by some embedded malware. It would be very hard to arrange an attack like this – with a bunch of things blowing up simultaneously, or even one thing blowing up – on the grid, other than by conducting an on premises physical attack like Metcalf.

Of course, the pager attack caused a lot of damage and deaths. But it’s the only verified successful malware implantation attack that I can find on the internet. This isn’t surprising, since planning and executing it required a massive effort that would be very hard to replicate by any actor other than a nation-state. This is a high impact but extremely low frequency event. Since risk is likelihood times impact, this has to be considered a low risk, just slightly larger than the risk that a high official will be killed by a meteorite while walking his or her dog.

Of course, when it comes to the power grid, even a very low likelihood event needs to be treated as at least a medium risk, due to the huge impact that any grid event can have. That’s why the penalties for non-compliance with the NERC CIP standards are so high, even though the likelihood that a cyberattack – of any kind – on the Bulk Power System will succeed is very small.

However, it certainly can’t be truthfully said that an attack on the grid that has never been seriously attempted, let alone succeeded, poses (to quote the EO at the end of Section 1) an “unusual and extraordinary threat, which has its source in whole or substantial part outside the United States, to the national security, foreign policy, and economy of the United States.” Of course, if you work for an electric utility or IPP and disagree with me, you’re welcome to recommend that you employer cease all purchasing of equipment or software for the grid, since there’s no way to know today which products might be on the proscribed list (called “Covered Foreign Entities” in the EO) when it’s released next May.

I just hope not many of you do that.

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.

Subscribe now

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 tom@tomalrich.com.

^[i] You may have heard of a large transformer that was built in China for the Western Area Power Authority (part of DoE), but was discovered after arrival in 2019 to have a “hardware back door” – although nobody has ever explained what would constitute a hardware back door – a flaw in the sheet metal? This is a 100% lie, propagated by someone who was at one time a respected OT security researcher. If you go to my blog and search on WAPA, you’ll find about ten posts that discuss this lie, which refuses to die. Here’s one of those posts: https://tomalrich.substack.com/p/the-chinese-transformer-didnt-have

By the way, a transformer doesn’t operate under the control of a microprocessor, but only according to the laws of physics. A transformer can no more be hacked than can a rock.

You might notice this was just a little broad 😊, since it blocked all acquisitions of equipment for the BPS if

1. “any foreign country or foreign national has any interest” in that equipment, and

2. “the transaction poses an unacceptable risk to national security or the security and safety of American citizens.”

Since it would probably be impossible to find any equipment purchased for the BPS that a foreign national doesn’t have some interest in, and since “unacceptable risk” was completely undefined, this order had the immediate effect of causing almost all acquisition of equipment for the BPS (which is more or less the same as the Bulk Electric System – BES) to grind to a halt, pending clarification of what this meant. Unfortunately, the order was never clarified and the power industry lay under a cloud of uncertainty for at least the rest of that year. A lot of projects to build out the grid were slowed, and some were stopped altogether, due to this uncertainty.

In the coming days and months, there was a huge amount of back-and-forth and strategic retreating by both the White House and DoE (although DoE was clearly dragged into this fiasco against their will). The end result was that the EO shrank to a shadow of its original self by the end of 2020. It was mercifully put to death after the new administration took over in 2021. Nobody was dragged to jail or paid a fine because of this EO, but the power industry and DoE wasted a tremendous amount of time and energy for no discernable good purpose, other than perhaps to make the industry do a better job of tracking where the equipment they buy comes from.

Now it seems we’re once again in that situation, except that the Executive Order issued yesterday is at least ten times broader than the 2020 order. For example, yesterday’s order covers software as well as hardware. It would be quite hard to find a single software product that doesn’t include over one hundred open source software components. Those components are developed collaboratively by anybody worldwide that wants to participate (Iranian and Chinese nationals are often active participants in open source projects).

To be safe, I believe the power industry needs to:

1. Stop procuring any new hardware or software that monitors or operates the BPS (the good news is that it’s still OK to acquire equipment or software for such important purposes as running the March Madness office pool or displaying menus for the company cafeteria).

2. Rip out any hardware or software they have installed, since the order states that various White House officials, at any time in the future, “may impose conditions on the continued use, operation, maintenance, servicing, or updating of foreign manufactured or operated bulk-power system electric equipment acquired or installed before the date of this order, including requirements to identify, isolate, monitor, secure, disconnect, replace, or remove such equipment.”

In other words, until further notice (perhaps coming in the afternoon of January 20, 1929?), no existing or newly purchased hardware or software can be trusted to still be “legal” tomorrow. Most electric utilities won’t take the chance of being found out of compliance with the EO, so as of today (well, maybe tomorrow, since it’s late in the day today), I suggest that all power market participants stop producing, transmitting or distributing electric power and begin dismantling all equipment and software currently being used for operations.

Of course, this means the US economy will come to a screeching halt. But hey, you can’t be too careful. After all, we’re surrounded by evil enemies who would just love to shut us down. We need to show them we can do a great job of shutting ourselves down; we don’t need outside help for that!

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.

Subscribe now

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 tom@tomalrich.com.

I want you to read the article for yourself, so I won’t try to summarize it. However, here are my most significant takeaways from the article:

1. Early in the article, the reporters point out that “Electrical engineers had long assumed that the patchwork nature of the grid would protect it from failure.” Fortunately, the grid was protected from failure in this attack, since there was never any outage. The grid’s built-in redundancy, along with human grid controllers who rehearse continually for contingencies like this, worked as intended. That’s good, because no group ever claimed responsibility for the attack and the perpetrators were never identified.

2. However, the article goes on to describe why the lack of an outage in this case is cold comfort: a coordinated attack like Metcalf on a small number of transmission substations in each of the three US Interconnects – Eastern, Western, and ERCOT (most of Texas)– could lead to literally a total US blackout of the continental US. This was revealed to us in 2014, when Rebecca Smith of the Wall Street Journal wrote a widely-quoted article about a FERC memo that probably shouldn’t have been written. I didn’t know Rebecca at the time, but we became good friends when she published an even-more-explosive story about Russian penetration of the US grid (which still has never been officially investigated, even though other government sources have implied this happened). She passed away far too soon in 2023 and I miss her terribly.

3. Fortunately, the response to the Metcalf attack has gone a long way to mitigate the risk. NERC developed and rapidly enforced CIP-014, which is so far the only NERC physical security standard.^[i] Not only did NERC entities (mainly electric utilities and independent power producers) move as quickly as possible to comply with the standard, but in many cases they over-complied (even though compliance for just one substation was very expensive).

4. That is, a lot of substations that weren’t in scope for the standard were treated as if they were.^[ii] While it was up to each NERC entity to make the final decision on how to mitigate the risk of such an attack, most entities who complied put up ballistic barriers around the entire substation, as well as greatly increased monitoring capabilities (one problem at Metcalf was that most of the security cameras faced inwards to catch copper thieves – which were until 2013 considered to be the biggest threat to a substation. Besides squirrels, of course).

5. However, it’s too early for “Mission Accomplished” signs. Near the end of the article, the reporter describes his own on-site investigation, including his finding that there are multiple low hills close to the Metcalf substation where it is still possible to get an unobstructed sight line – from about 150 yards away - to the transformers that were the targets of the snipers. You might wonder why substations are always built in the open. This is because the transformers generate a lot of heat that needs to be dissipated, which is unfortunate since the advent of cheap and destructive drones means almost nothing exposed to the open air is completely safe. We must live with the fact that the only way we can limit sniper and drone threats to substations is to move all transmission substations underground, where they will be cooled with sulfur hexafluoride. Of course, the cost of doing that would be tremendous, and it’s usually only done in very crowded cities.

The second part of the article discusses the even bigger problem that was made clear by the Metcalf attack. It starts with this passage: “It was hard to replace transformers quickly back then; it’s nearly impossible now. Since 2021, the average wait time for a large power transformer — the kind you’d find at a major substation, capable of handling tens or hundreds of thousands of volts — has climbed from less than a year to 128 weeks, with some lead times growing as long as five years.” The article goes on to describe how serious the consequences would be from a widespread and prolonged outage (and three days is “prolonged”), especially if it includes a major city.

For a highly readable book that describes in vivid detail how unprepared the US is for such an outage, I recommend you pick up Ted Koppel’s book, “Lights Out”. It’s dated, but still very relevant. But don’t be fooled by the blurb that says the book is about what a cyberattack could do the US grid – it’s about what would happen if there were a widespread and prolonged outage due to any cause. Of course, such an outage could be caused by a physical attack like Metcalf, although I think unleashing swarms of drones to simultaneously attack key substations would be more likely to succeed today. There’s also the very remote (but nonzero) possibility of an EMP attack, which could literally destroy the entire grid by frying transformers and other equipment that would take years to replace. But probably the most likely cause of a widespread and prolonged outage would be a superstorm like Sandy, only bigger.

Ironically, the one type of grid threat we don’t have to worry about – besides a zombie apocalypse – is a cyberattack that brings down all three Interconnects in the US, or even just the smallest of the three, ERCOT. This simply.can’t.happen.

While I think the Times reporter did an excellent job, I want to point out that he fell for a lie that’s been told repeatedly since 2020. It’s in this paragraph:

Disabling nine substations simultaneously might be beyond the reach of a domestic terror group, but it is well within the capabilities of a state actor. For years, intelligence analysts have warned that the grid represents an inviting “attack surface” for adversaries including China, North Korea, Russia and Iran. Already, China has been caught installing a software backdoor in a large power transformer being shipped to a federal utility in Colorado. The Pentagon has warned that the Chinese could target critical infrastructure specifically to “undermine the will of the U.S. public.”

The sentence in red is a complete fabrication that keeps resurfacing in the media; it was dreamed up by a very well-known ICS security expert in 2020, who unfortunately has come to believe that the best way to promote his business is to scare the public with lies and get them repeated again and again by the media. The fact is that transformers operate entirely according to the laws of physics. They don’t have a microprocessor at all, so hacking a transformer would be as difficult as hacking a tree or rock in the forest (transformers can have add-on devices, usually from different manufacturers, that do have microprocessors - including load tap changers and dissolved gas analyzers. But those devices don’t control the transformer itself).

I’ve been playing whack-a-mole with this lie for years, including here and here, but it refuses to die. In fact, last year I received two or three emails from college students who had a writing assignment on a topic that sounded something like “In light of the recent successful cyberattack on a large transformer, what can be done to protect transformers from cyberattacks?”

To summarize, if you insist on worrying about a widespread grid disaster, you should worry about a widespread physical attack on substations - Metcalf on steroids – or a huge superstorm. What’s not likely at all is a successful cyberattack on transformers or the zombie apocalypse. You don’t have to lose sleep over either of those.

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.

Subscribe now

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 tom@tomalrich.com.

^[i] CIP-006 deals with physical security of control systems but isn’t intended to protect the assets where the systems are located: Control Centers, transmission substations and generating facilities.

^[ii] The article doesn’t mention this, but I know it to be a fact.

However, there’s another problem, which I realized when I read the “unofficial comment form” that the SDT wants commenters to fill out. The form contains 20 questions that all follow a similar format. Here is the first question:

Each question asks for a Yes/No answer but also asks for alternative ideas. As you can see, the SDT is clearly saying they want to hear any and all ideas about alternatives to what they’re proposing.

Of course, it’s great that the SDT is soliciting alternatives, but I have one question for them: “Why are you just doing this now? After all, you started meeting in the summer of 2024. You spent the rest of that year rewriting the Standards Authorization Request (SAR) under which your SDT was constituted. You were allowed to do that, of course, but why didn’t you settle fundamental questions like these then?

Instead, you’ve waited until, by your own admission, you’re facing intense pressure to finalize all the new standards for the first ballot by the end of the year (although up until about six weeks ago, you were insisting that the first ballot would be in September. I always assumed you said that just to show you have a sense of humor). You have only developed five of the twelve or so new standards that you’re proposing, along with a number of definitions of new terms.

There are serious problems with all the standards and definitions you’re proposing, and you have yet to hear about those problems from anybody but me. I don’t recall any fundamental questions after the SDT’s webinar two weeks ago, probably because few NERC entities had invested much time in studying what was posted just a week or two previously. In fact, this is probably still true today. That’s what happens when you wait ‘til the second half of the summer to engage in a serious public discussion about anything other than sports, wildfires, or summer camp.

In the next couple of months, the NERC entities, the CIP auditors and the NERC lawyers are almost certain to bring up a lot of problems with the posted standards that I haven’t thought of. They always do. Yet, you seem to believe that by December you will fix all of those problems (plus any new ones you might create while fixing them), and in your spare time, draft the remaining six or seven new standards, put those up for comment, address the problems that come out of that comment period, fix those problems, put the fixes up for comment…rinse and repeat at least a couple more times.

While you’re at it, do you think you could also solve the problem of global hunger and invent a perpetual motion machine by the end of the year? Perhaps that’s too much to ask…

SDT, you’re not going to have your standards ready for ballot by the end of the year, and if you just throw something together that clearly has problems, you won’t even be allowed to put it up for ballot. The balloting process is for standards that have already been thoroughly vetted and in which no serious known problems remain – since, God knows, the NERC Ballot Body is sure to come up with lots of objections when they’re asked to vote on mandatory standards that carry significant penalties for non-compliance.

The CIP v5 SDT received two thousand pages of comments on just one of their four ballot postings over the twelve months of 2012. Four ballots were needed to get the required supermajorities in each of the NERC voting segments; I think you’ll be lucky if what you’re proposing now only takes four ballots (each ballot will take about three months, including the comment period, responding to the comments and making changes to the draft standards to address those comments). Of course, you will need to respond to every comment you receive during the balloting period and either make changes to the draft standards or explain why you didn’t. After all, this ain’t beanbag.

I suggest you stop trying to draft any new standards and instead ask yourselves the question: “How can we most efficiently fulfill the two deliverables that we included in our SAR?” I listed those two deliverables in my last post. BTW, those deliverables don’t include rewriting the current CIP standards or developing requirements that address both on premises and cloud-based systems, although you seem to think you’re obligated to do both of these things.

Last December, I identified eight small changes (almost all to definitions) that I think will fix the three main problems you need to fix (which I identified near the beginning of my last post). I doubt it will take more than two weeks to draft these changes; I also doubt there will be any strong objections to them, so approval should be quick. The changes could easily be effective next year. I suggest you at least take a close look at what I proposed (which you have never done); as it is, you’re wasting both your time and that of the NERC entities who are taking the time to pay attention to what you’re doing.

Of course, I may be wrong; you should certainly solicit other ideas as well. Above all, you need to remember the First Law of Holes: When in one, stop digging.

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.

Subscribe now

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 tom@tomalrich.com.

This post describes the admission made by the SDT member at that meeting: Despite the SDT’s repeated assurances that a NERC entity that doesn’t want to use cloud-based systems in its high or medium impact BES environment will not need to comply with the 100 series standards, they haven’t mentioned the fine print (perhaps because they didn’t realize it themselves until recently).

If you read that (and the only place I’ve seen the fine print is in my post just linked), you’ll learn that entities that want to use cloud-based software that meets the definition of EACMS (Electronic Access Control or Monitoring System) or PACS (Physical Access Control System) will have no choice other than to comply with the 100 series standards – which, if you take a look at the draft standards and definitions that were posted last month, won’t be a piece of cake, to say the least.

As background, there are three problems that constitute the “Cloud CIP” problem; they were laid out (not in exactly these words) in the original Standards Authorization Request (SAR) that led to the SDT being constituted in 2024. These are:

1. NERC entities with a high or medium impact BES environment can’t utilize BES Cyber Systems (BCS) that are installed in the cloud while maintaining compliance with all (or even most) NERC CIP requirements.

2. NERC entities with a high or medium impact BES environment can’t utilize EACMS that are installed or made available in the cloud while maintaining compliance with all (or even most) NERC CIP requirements.

3. NERC entities with a high or medium impact BES environment can’t utilize PACS that are installed or made available in the cloud while maintaining compliance with all (or even most) NERC CIP requirements.

The original SAR made it clear that by far the two most important of these problems are the second and third ones; the SAR requested – nay, begged – that the SDT focus on those two problems first. Unfortunately, that didn’t happen. Thus, a NEC entity that wants to utilize a cloud-based SIEM or MFA service, or PACS service, to protect their on premises medium or high impact systems will be exactly where they are today: SOL (which doesn’t stand for “system operating limit”, BTW).

During the Q&A at the end of the meeting, a person who introduced himself as new to the NERC CIP world asked a simple question (which I am paraphrasing, since I’ve forgotten the original wording): “It seems like you’re not sure about a lot of this.” Unfortunately, this person hit the nail on the head. This was confirmed in another meeting I attended this week, in which a drafting team member was discussing some of the fundamental questions they’re running into now, as they are starting to draft more of the 100 series standards, beyond the five they’ve drafted so far. Why didn’t they nail these issues down two years ago when they started meeting, or at least when they decided to rewrite the existing CIP standards – which activity was never mentioned in either of their SARs?

Comments on the initial posting are due next week. The comment form asks some very specific questions about the standards, most of which require a yes or no answer (with the option of adding freeform comments at the end). These questions all assume the framework of what the SDT is proposing is basically sound and it just needs some fine tuning. That’s far from being the truth. Here are some fundamental questions for the SDT (most of which I’ve asked in one form or another already):

1. After starting work in the summer of 2024, why did it take you until only two or three months ago to finalize definitions for fundamental terms like “BES Cyber System or Service”? That should have been the first thing you did. How can you even discuss requirements when the terms addressed in those requirements haven’t been at least preliminarily decided on – as evidenced by the fact that the white paper you published last December doesn’t have any definition at all? The team that drafted CIP version 5 starting in 2011 (CIP v5 was the only complete rewrite of the CIP standards before now, but the 100 series is far more ambitious than v5 was) had already defined the fundamental term in v5 – BES Cyber System – in a “concept paper” in 2009.

2. You have – ahem! – pushed the boundaries of CIP (or even NERC) compliance with concepts like System Security Plan and the idea that a NERC entity can choose, for each on-premises system that meets the BCS definition, whether to have it comply with the existing CIP standards or the 100 series. Have you ever formally run these ideas by the auditors, as well as the NERC lawyers, to determine whether changes to the Rules of Procedure will be needed to make them feasible? After all, the CIP v5 SDT spent at least a full day with NERC auditors within about 2-3 months of commencing work in January 2011. As you’ll see below, even that didn’t protect them against later pushback from FERC.

3. I know the answer to the above question: No, we haven’t formally run our ideas by the auditors (despite promising me to do that at least a few times). Then, why did you ask NERC entities to comment on five draft standards and a number of draft definitions as they’re doing now, when you weren’t even sure they will pass auditor muster? Surely you know, since you collectively have decades of SDT experience, that the draft standards will never even make it to the first ballot if the auditors haven’t signed off on them. You are probably literally wasting NERC entities’ time, since once you’re revised the standards to address the concerns the auditors will likely raise, you will have to re-post them for comment. The last thing you should want to do is submit standards for balloting when there are still problems that can be fixed, since it’s inevitable that the Ballot Body (i.e., the NERC entities who want to vote on this) will find all sorts of problems in what you submit for balloting, even if the auditors, lawyers, Alexander Hamilton and Thomas Jefferson have all signed off on them beforehand.

4. Perhaps you’ve heard that the CIP v5 SDT included, in all its drafts of the CIP v5 standards, the words “identify, assess, and correct” in just about every requirement. These were there to address what was considered the number one problem with CIP versions 1-3 (v4 was approved but never implemented): “zero-tolerance” auditors who insisted that even small deviations from a requirement were violations. The idea of IAC was that an entity wouldn’t be assessed only on whether they had complied with the strict wording of the requirement; instead, they would need to a) identify any potential violations, b) assess what problem caused the PV, and c) correct each problem found. If they did all that, there was no harm, no foul. I and lots of others thought this was a great idea, but FERC didn’t. When they approved v5 in 2013, they ordered that wording be taken out. They did that on the grounds that “No standard can dictate how it will be audited.”

5. I think what you’re advocating now, especially the System Security Plan, is quite similar to “identify, assess and correct”, since it attempts to dictate how the standards will be audited. While you certainly have no channel by which you can get feedback on this issue – or anything else, other than perhaps the time of day – from the FERC Commissioners, this is certainly something you need to discuss with the NERC lawyers. The last thing you want to happen is to have FERC, 2-4 years from now, completely remand the 100 series (since they never ordered it in the first place, unlike almost every other change in the NERC CIP standards) due to this problem. This will mean you will have completely wasted 4-5 years of your time, as well as the industry’s time. Won’t that be a bummer?

6. Did you ever figure out what the fundamental “cloud CIP problem” is – specifically, the issue at the root of the three problems I listed earlier? Why do you think that the wording of the current CIP requirements is at fault, since none of them even mentions the cloud, let alone forbids its use? The problem is with the definitions of the terms BCS, EACMS and PACS, since they don’t take into account any system based in the cloud. In this post last December, I outlined eight simple changes (almost all to definitions, plus one new definition: “system”). All eight of the changes could easily be drafted within 1-2 weeks, not two years and counting. They would most likely sail through approval, since NERC entities wouldn’t have to change any CIP practices or documentation. If you started to draft those changes today, they could probably be in effect early next year.^[i]

7. After having needlessly decided to develop new versions of all the existing CIP standards, you compounded that error by deciding that the new versions you were developing need to apply both to on premises and cloud-based systems; moreover, they will replace the current CIP standards in the future. Who asked you to rewrite the CIP standards? I and others have been advocating for rewriting the standards since it became clear there were still fundamental problems with CIP after the v5 standards were implemented in 2016.

The main problem with the current standards is that cybersecurity is fundamentally risk management, so the standards need to be made risk-based. But that can’t succeed until there are changes to NERC’s Rules of Procedure, since it isn’t possible to “audit” risk-based requirements in the traditional sense of auditing. Instead, the former auditors need to be more like consultants that advise NERC entities regarding the risks they face and how they can mitigate them. They do that now, but this consultation needs to replace the audit, although the auditor should still be able to cite the NERC entity if they believe the entity is simply not taking a requirement seriously. What I’ve just described isn’t possible under the currend Rules of Procedure.

8. Unfortunately, the 100 series requirements seem to assume that a risk-based compliance enforcement regime is already in place. For example, the new vulnerability management requirement in the 100 series, CIP-105 Requirement R6 Part 6.3, mandates “A plan to mitigate prioritized cyber security vulnerabilities.” What’s a good plan? The requirement doesn’t give any hint, meaning the NERC entity and the auditor will need to decide this question through friendly (?) conversation.

But that might be hard. For example, suppose an auditor thinks that the only way to mitigate software vulnerabilities is to implement a strict Zero Trust environment. When a NERC entity presents a Part 6.3 plan that includes conventional vulnerability mitigation practices - prioritizing vulnerabilities and mitigating the most serious ones, through patching where possible and other means if no patch is available - this auditor may tell the entity they must base their plan on Zero Trust and then patch when a patch is available.

How is the entity going to counter this, especially since the SDT has decided that they don’t have time to develop implementation guidance for the 100 series – and since no other documents are likely to provide it? As was often the case when CIP version 5 was being implemented (and will almost certainly be much more the case after the 100 series is implemented, if what we’ve seen so far isn’t changed), there will probably be lots of heated compliance discussions that will never be resolved, except through a fragile truce that could fall apart at any time?

10. Why are so many 100-series requirements written to apply to cloud-based systems (most of which will be under the complete control of the cloud service provider) as well as on-premises systems, even though the CSPs have made it clear from the beginning they will never provide any compliance evidence other than audit reports - which they already give to any customer that asks for them? And even though they’ve also made it clear they won’t negotiate contract terms with any customer not named Uncle Sam?

11. Continuing this thought, since the only possible evidence for most 100 series requirements will be audit reports, why not just require the entity to look at those? If they were about to sign a contract with Clem’s Cloud Services and Screen Door Repair, which probably isn’t FedRAMP authorized or SOC 2 Type 2 certified, this step will hopefully dissuade them from doing that. But if the entity long ago signed a contract with one of the Big Two CSPs (and my guess is 80-90% of NERC entities did this long ago for systems on the IT side of the house), reviewing the latest audit reports will just confirm to them that there’s no reason even to question the original decision. Thus, there will never be any doubt that the entity won’t be found in violation of any requirement, unless they haven’t even tried to comply with it. It’s like the Lake Woebegone effect: All the children are above average.

12. I’ve heard you’re now starting to rewrite the BCSI (BES Cyber System Information) requirements: CIP-004-7 R6 and CIP-011-3 R1 and R2. Please stop. A drafting team started working on those requirements in 2019, to achieve their objective of making use or storage of BCSI in the cloud “legal” under CIP. Their changes were approved by FERC in 2022 and implemented on January 1, 2024. Those changes have been almost completely ignored since then, mostly because neither NERC nor any of the Regional Entities has taken it upon themselves to explain them to the CIP community.

Fortunately, that SDT left a brief but workable guidance in their Technical Rationale, included in their filing to FERC in 2021 (see page 11, the second full paragraph). I hate to see you throw that away, when what’s needed is just to hear NERC tell them to follow what the Technical Rationale says? What that SDT developed is fine. SDT members, I suggest you devote your time to fixing the problems in the 100 series. You have your work cut out for you.

Finally, here is the entire “Deliverables” section of the revised SAR that you drafted in 2024, which was approved by the NERC Standards Committee at the end of that year. This is, of course, the SAR you’re supposed to be following:

“The following describes the proposed deliverables for this project:

1. The 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.

2. The Drafting Team will consider risks related to cloud services for CIP applicable systems, including but not limited to:

· Procurement / supply chain controls

· Reliability / operational risk / resilience

· Compliance / enforcement risk

· Data sovereignty

· Life cycle

· Key management

· Cloud ramping / communications

· Concentrated Span of control

· Reliance on indirect services

· Multi-tenancy

· Regional considerations

· Blackstart scenarios”

Note: I numbered the two deliverables.

As you can see, there are only two deliverables in the SAR. Has the drafting team delivered the first deliverable? Only if you ignore the “fine print” that I mentioned at the beginning of this post. In other words, the existing CIP requirements haven’t been changed at all (except for a technical change in CIP-002). But another thing hasn’t changed: NERC entities with high or medium impact BES environments will still be completely shut out of the cloud once the 100 series becomes enforceable, as they are today. If one of these entities wants to use the cloud, they need to make the big leap to complying with the 100 series. My guess is most entities with only on-premises systems, who would love to utilize a cloud-based EACMS (e.g. a SIEM or MFA system) or PACS will simply not do that, given the huge investment of time required to understand and document compliance under the 100 series standards, for their on-premises as well as cloud- based systems.

How about the second deliverable? The 12 bulleted items are almost all purely “cloud risks” – i.e., risks that arise when BES systems are deployed freely in the cloud. I was expecting these risks would be the focus of the SDT’s work, but I was very disappointed when I realized they weren’t going to address them at all in the first version of the 100 series.

Instead, as you can see, the SDT is focusing entirely on rewriting the existing CIP standards,. Those standards only address risks that are already addressed in FedRAMP and ISO27001, which the major CSPs have all been audited on and passed. In other words, those risks have already been mitigated to the satisfaction of FedRAMP and ISO27001 auditors. So, rather than focus on mitigating real risks that will arise when BCS, EACMS and PACS are utilized in the cloud, the SDT is asking NERC entities to spend a large amount of time documenting that their CSP has mitigated risks that have already been mitigated. ^[ii] This isn’t compliance; it’s compliance theater.

There’s one more problem that I just realized when I read the SDT’s comment form. Since this post is already very long, I’ll save that for a new post, hopefully tomorrow. I’ll also include my ideas for what the SDT should do, which could shorten the time before the cloud will be fully usable by high and medium impact systems from the current minimum of three years (from today) to less than a year. Whaddya think? Is it worth a try?

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.

Subscribe now

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 tom@tomalrich.com.

^[i] Also, implementation of what I’m proposing will come into effect at least two years before what the SDT is proposing, even if the implementation period is the same. This is because the SDT’s complicated compliance model requires a change in CIP-002. There are already two new approved versions of CIP-002, versions 7 and 8, scheduled to take effect on July 1, 2028. Since nobody wants three new versions to take effect the same day, this means the earliest that the 100 series standards can take effect is January 1, 2029. But even that isn’t likely, since it will require a NERC entity to make two major revisions to its CIP-002 compliance program in one year. To say the least, that’s not going to be a popular suggestion. Meanwhile, the eight simple definitional changes I’m proposing don’t require any change to CIP-002.

^[ii] This is unfortunately like the old joke regarding a man who comes home at night and sees his neighbor on his hand and knees, looking for something under the streetlight. He goes over and asks what he’s looking for. The neighbor answers, “My house keys”. The man asks where the neighbor last saw his keys; the neighbor gestures toward the dark lawn. The man asks why he’s looking under the streetlamp if the keys are probably on the lawn. The neighbor explains, “Because the light’s better here.”

In fact, a scientific finding needs to meet two criteria: It can’t clearly violate a scientific principle like the conservation of energy, but it also needs to be “falsifiable”. That means there needs to be some way by which the finding can be proven wrong. For example, if I state that the moon is made of green cheese, I can be proven wrong in many ways. But if I state that people in North Carolina are friendlier than people in Wyoming, how could I ever be proven right or wrong? It doesn’t matter how many surveys you take or how many times you visit those states; you can never prove my statement is either right or wrong. It’s a waste of time even to try to verify that statement.

Which brings me to the draft NERC CIP 100 series standards for cloud use. Four or five of these standards (there will ultimately be about 12 or 13, and the Standards Drafting Team (SDT) is just starting to work on the others) were released in July, along with some definitions and some other documents. I’ve already pointed out several serious problems with what’s been released (e.g., here and here), but I now realize that one of the biggest problems – found throughout the standards and definitions that have been released so far – is that there’s usually no way that a NERC entity could be found non-compliant with a requirement. Here are some examples:

1. In this post, I pointed out that the fundamental term in the 100 series – the term “BES Cyber System or Service” (BCSS) – depends on two undefined terms: “system” and “service”. The first sentence of CIP-102 Requirement R1 requires the NERC entity to identify “services and systems, that affect or support the reliability of the BES...” Suppose an entity decides they don’t have any BCSS because they don’t have any services or systems that meet that criterion, yet their auditor doesn’t agree with them; he or she believes the entity has at least one service that meets the criterion.

Since there’s no definition for service or system, how could the auditor possibly prove their point? They will just have to state there’s no finding with regard to this requirement (by the way, there are many other undefined terms in the 100 series; this will lead to a lot of problems. This happened the last time the CIP standards were completely rewritten as CIP version 5. But in that case, there were only a few important undefined terms. I’ve just identified two of them and I suspect there are a lot more).

2. One of the most common causes of findings in the current standards (at least, it was when those standards were first enforced as CIP version 5 in 2016) is that a NERC entity didn’t include all its BES Cyber Systems within its Electronic Security Perimeter (ESP). This is required by CIP-005 Requirement R1 Part 1.1, “All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP.” Any violation of R1.1 was (and is) easy to prove, since it can easily be verified using network diagramming software. Conversely, if an auditor thinks an entity has violated R1.1 and the entity disagrees, it won’t take a long discussion for them to figure out which one of them is right.

However, in the 100 series, the term ESP has been replaced with “Electronic Security Zone” (ESZ). Its definition is “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.”

I think you’ll agree that this definition allows an ESZ to be defined in many ways. If the auditor and the entity disagree about whether a particular system is included in an ESZ, the auditor will need to show that, no matter how the entity defines this ESZ, that system is still outside of it. I can see that easily turning into a week-long exercise. This means that in practice NERC entities will seldom if ever be found non-compliant with CIP-105 Requirement R1.1.

3. My third example is really many examples, since it is likely to describe many of the requirements in the 100 series, including the standards that haven’t been drafted yet. It stems from the problem that, more than any other, led to the 100 series being drafted: PACS and SIEM tools that used to be available entirely on premises are increasingly moving into the cloud. This is due to the huge cost decreases, as well as increases in flexibility and reach of services, that are available in the cloud. Even if the vendor continues to offer an on-premises version, it will often be more expensive and not updated as regularly, if at all.

Yet, if a NERC entity with a high or medium impact BES environment wants to continue using one of these services after it has moved to the cloud, they will face the problem that, since the cloud based system meets the PACS or EACMS definition, all of the CIP requirements that apply to a PACS or EACMS will still apply to that system. This means the vendor will need to provide evidence that they complied with each part of requirements like CIP-010 R1 Configuration Management, even though that means providing evidence about individual physical and virtual devices in cloud data centers – something that no CSP can do.

Since this problem just has to do with definitions, it would probably be well on the way to being solved by now if the SDT had been willing to even consider making the eight small changes (almost all to existing definitions) that I suggested last year. Instead, they have rewritten four or five of the existing CIP requirements to remove any need for evidence about individual devices. They intend to draft and submit the other 100 series standards, as well as get feedback – and make changes that will inevitably be required - from NERC entities, NERC auditors and NERC lawyers by the end of the year, so that all the standards will be ready to start the likely one year process of balloting and re-balloting them in January (while this is less unrealistic than their deadline up until a month ago, late September, it’s still quite unlikely they will make it. I assume they’re doing this to show they have a sense of humor).

Here’s the problem: Even when all of the existing CIP standards are rewritten to apply to both the cloud and on premises systems, the cloud service providers – which I define as platform CSPs and SaaS providers - still won’t provide evidence of compliance with any of the CIP requirements. This is because their whole business model is based on not doing special favors for individual customers, unless they happen to be the federal government, the military, the intelligence agencies or the major AI companies.

For example, CIP-105 Requirement R4 Part 4.2 reads, “Default accounts are identified and the associated credentials are changed, disabled, or protected from unauthorized use.” One of the Measures shown for this requirement part is, “Listing of accounts by account types showing the enabled default or generic account types in use.” Do you think that AWS or Azure is going to provide this level of evidence for you? Not to keep you in suspense, the answer is No. I’ve verified this with knowledgeable people at both organizations. The best they will do, in response to specific security requests, is give you the link to their latest ISO 27001 or SOC 2 Type 2 audit report and tell you the evidence that they properly address risks from default or generic account types is in there – which is almost certainly true for all the requirements in the 100 series.

If CIP-105 is approved and implemented and you face an audit, what are you going to do when you’re asked to provide evidence for compliance with CIP-105 R4.2? You’ll tell the auditors that the CSP wouldn’t provide the required evidence, but you will also show them the section of the CSP’s SOC 2 Type 2 audit report that shows they have the proper controls in place. The auditor will almost certainly agree that this constitutes evidence of compliance (since they have heard the same story from every NERC entity they’ve audited on the 100 series), even though the wording of the CIP requirement will never exactly match the “equivalent” control in the audit report.

The above scenario will be repeated for most of the requirements and requirement parts in the 100 series. In fact, unless you have intentionally violated one of the requirements, it’s quite hard to think of how you wouldn’t receive a perfect audit score for every audit.

Of course, it’s nice that you won’t be failing audits and you will be home in time for dinner most weeknights, but what is all this accomplishing? If all the evidence is in the CSP’s audit report and if no NERC entity is likely to use any CSP other than the Big Two when BES systems are involved, why even bother to audit the 100 series? Even better, given that the only risks addressed by the 100 series are those that are also addressed by the existing standards – but in a device-oriented, sometimes prescriptive manner – why even go through the process of approving and implementing the 100 series?

That process will almost certainly take 3-4 years starting today. Even worse, at the end of that process, the real risks from the cloud (such as the 12 or so cloud risks that were listed in the SDT’s revised SAR) will remain unaddressed (the SDT worked a little on a standard to address cloud risks, which was I believe called CIP-116, but decided a couple months ago to put it aside because they didn’t have time to get it done. It’s all a matter of priorities…).

Folks, this isn’t compliance, it’s compliance theater. However, the difference between this and legitimate theater is that the price of admission – meaning the huge effort that will be required to understand and document compliance with the 100 series standards, even though the evidence requirements will be minimal – will be much higher. But the worst part is that the actors – the NERC entities and the NERC enforcement staff – won’t have the satisfaction that what they’re doing is meaningful and important, because it won’t be. And if you think job satisfaction isn’t important both to you and the people you work with, think again.

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.

Subscribe now

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 tom@tomalrich.com.

In their announcement, the EPA engaged in some twisted logic. First, they neglected to note that only Congress can change the applicability of a law that Congress passed. Second, the EPA somehow believes that this measure will encourage data center developers to “bring their own plant” – i.e., build generation needed to power a new data center. The EPA says this, even though the AI companies and developers already promised exactly that in their Ratepayer Protection Pledge announced with the President in March. Of course, just signing the pledge doesn’t mean a developer or AI company won’t do whatever makes the most economic sense for them, Pledge or no Pledge. After all, who’s going to throw them in jail for breaking a promise?

How exactly will the fact that the data center power plants will be exempt from some (or even all) environmental regulations encourage more data centers to bring their own plant? It’s quite simple: If a power plant doesn’t have to comply with pollution regulations, it can be built much more cheaply. But when we look at the total cost of a power plant, we can’t just look at the costs directly paid by the developer and operator of the plant. We need to look at the total cost imposed by the plant on other people, especially people who live near it.

Of course, pollution is the biggest of those costs, even though nobody (today) sends the plant operator a bill for all the effects that the plant has had on their health, including effects like cancer that won’t be apparent for years or even decades. And no tree sends a bill for stunted growth due to the acid rain caused by the plant.

Nevertheless, the costs are there. My former economics professor Milton Friedman regularly pointed out that if a truck operated by the power plant hits my car, I can determine the exact damages and sue for that – plus my legal fees – in court; no regulation is needed. However, I can’t normally do that with pollution, even if I develop lung disease ten years later due to breathing the polluted air. Since pollution affects large numbers of people, the best way to deal with it is through regulation and taxation.

Exempting the power plants from environmental regulations is no different from imposing a tax on all inhabitants of the areas around the plants (and even wider areas, in the case of acid rain. I’m leaving out climate change for now). That tax is paid through poorer health and a less livable environment. In other words, all of us (and especially the people that live close to the data centers, who – ahem! – don’t tend to be the same people as the ones that decide to build the plant without pollution controls. The latter tend to live in nice areas that would be literally up in arms if a polluting plant were built in their area).

We pay for pollution with our health and through environmental degradation. Some people would say those costs can’t be calculated, so the only course of action is to prevent power plants that cause pollution from being built in the first place. However, the fact is that we make tradeoffs involving health all the time. After all, how many of us continue to drink alcohol – hopefully in moderation! – despite knowing there’s no perfectly safe level of alcohol consumption?

We need to consider all the negative effects of large data centers together; this includes high and increasing utility bills, but also other effects like the really scary risk related to grid stability. That risk is fortunately being actively addressed by the power industry today, but naturally a lot of the cost of mitigating the problem will be borne by – who else? – the ratepayers. All these costs – which are truly incalculable but are definitely very large – should be looked at as a tax on citizens to pay for the AI buildout. Should citizens really be the ones ultimately paying that tax?

Of course, the answer to that is no. We shouldn’t be required to pay costs incurred by any private entity (unless as a deliberate government subsidy granted through an open government process), whether it be OpenAI, Google, or the corner sandwich shop.

Here’s an idea: Why not tell (not ask) the AI and other tech companies that are directly benefiting from these data centers to pay that tax themselves? Of course, there’s no way to determine an appropriate tax for each data center. However, we can do what we often do when there’s an activity that imposes costs on the general public, such as smoking or alcohol consumption: impose an excise tax - which is a sales tax on a particular product or service. In this case, the tax might be imposed on the lease rates that the tech companies pay for the data centers (and if the same company built and operates the data center, they would still owe the tax). The proceeds should go to things that benefit everybody – affordable health care, quality schools, Universal Basic Income, etc.

And make no mistake: the tax needs to be a hefty one. And don’t worry about it’s being too high. You’ll know it’s too high when Jeff Bezos, Sam Altman, Mark Zuckerberg, and their like are on the street panhandling for quarters.

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.

Subscribe now

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 tom@tomalrich.com.

This SDT was constituted to make it possible for NERC entities with high and/or medium impact assets to implement or utilize systems in the cloud, while maintaining complete compliance with the CIP standards. Since the CIP version 5 standards were implemented in 2016, this has been impossible to do for medium or high impact BES Cyber Systems (BCS), Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS).

This is not because any CIP requirement forbids cloud use; in fact, even today, none of the CIP requirements or definitions even mentions the cloud. Rather, it is because the NERC entity that utilizes one of these systems in the cloud – for example, a cloud-based service that monitors access to on-premises systems within a medium impact ESP – would need to provide evidence that the cloud service provider (CSP) that hosts the service is in strict compliance with the wording of the fifty or so CIP Requirements and Requirement Parts that apply to EACMS. This includes requirements for ports and services management (CIP-005 R1), patch management (CIP-007 R2), configuration management (CIP-010 R1), etc. Of course, the evidence will need to cover every electronic device on which any part of the system resided during the three-year audit period. Of course, no NERC entity can possibly provide this evidence.

Of the three “branches” of the Cloud/CIP problem, by far the most serious is EACMS in the Cloud and its nearly identical twin, PACS in the Cloud. This is because there are many cloud-based physical and electronic security monitoring services that NERC entities have been unable to use since 2016; that number is growing all the time, as more and more security service providers either move to an exclusively cloud-based model or make their on-premises option much more expensive. Many NERC entities (and even NERC ERO staff members) have said their level of security is lower because they have fewer service options available to them than similar-sized organizations that don’t have to comply with NERC CIP.

The Standards Authorization Request (SAR) that led to the creation of this SDT made clear, in multiple places, that the authors thought the most important cloud problem was the EACMS problem; they hinted strongly that the SDT should focus on that problem first. Unfortunately, even though the SDT’s revised SAR repeated that sentiment, the SDT doesn’t seem to have taken the hint.

Instead, in early 2025 the SDT decided that the only way to achieve their goal was to rewrite all the existing CIP standards so that they apply both to on-premises and cloud based systems, even though neither of their SARs mentions that as a goal. To make the “transition” easier, they assured themselves (and NERC entities, in the single webinar they did last December) that a NERC entity with on-premises systems could continue to comply with “Classic CIP” - CIP-002 through CIP-015 - without changing anything they’re doing today (of course, cloud-based systems will all need to comply with the 100 series standards).

I don’t think most NERC entities would have a problem with that two-track arrangement if they could be assured that they would finally be able to utilize cloud-based security monitoring services. After all, there have been complaints about this problem since 2016; this SDT was supposedly “hired” to fix the problem. It never even occurred to me that that wouldn’t be the outcome.

However, a few weeks ago I started to suspect – and I confirmed it with an SDT member this week – that NERC entities that want to make use of a cloud-based service that meets the definition of EACMS or PACS must move their on premises systems (or at least, on-prem systems that are protected by the cloud-based service) to the 100 series standards. I honestly don’t understand why they say that’s the case (it presumably has something to do with the changes they made to sections 4.2 and 4.3 of CIP-002-9), but I’m not going to argue that point.

What this means, to be clear, is that even if you don’t have or use any BCS, EACMS or PACS deployed in the cloud today and have no intention of doing so in the future, you will still be unable to use cloud-based electronic or physical security monitoring services deployed in the cloud if the proposed 100 series standards come into effect in something like their current form - unless you’re willing to invest the substantial amount of time and effort that will be required to understand and comply with the 100 series (and if you don’t think that time and effort will be substantial, I suggest you take a look at the documents that were released and think about how you will put together a compliance program for those standards (let alone the eight or so 100 series standards that haven’t even been drafted yet).

That time and effort will be even larger because of something else I heard this week: Due to the “lack of time”, the SDT will not prepare an implementation guidance document. That means the only documents that will count at audit are the 100 series standards and the definitions that will presumably be approved with them (the SDT has produced some voluminous Technical Rationale documents, but that’s all they are: rationale, not guidance. If the SDT were willing to submit these to the balloting process with the standards and definitions, they would probably be binding on the auditors; but the SDT decided not to do that). In preparing your compliance documentation for the 100 series, you won’t be able to rely on any other document – not even my blog posts! 😊

Keep this in mind when you write your comments on the posted standards, especially if you attend Tuesday’s SDT information meeting on the standards (the only webinar they have scheduled). Of course, I recommend you attend it.

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.

Subscribe now

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 tom@tomalrich.com.

The post described a phenomenon that had already occurred twice in northern Virginia, which has become the Saudi Arabia of data centers: a routine disturbance on the grid causes a lot of data centers to go to backup power at literally the same time, causing a sudden drop in power demand. This is a problem that has only recently been recognized, since it only happens when there are a number of “large loads” (which are usually data centers, but can include other facilities like electric arc furnaces) on the same section of the grid, all with backup power sources that they can switch to whenever their protective relays decide the grid is too dangerous at the moment.

The reason this sudden drop in load is so serious is that, unlike a sudden loss of generation (which of course happens regularly), it doesn’t seem to naturally self-correct – in fact, it naturally self-reinforces. If too much generation is lost, there will be a blackout, which of course means a lot of load will drop as well. With the help of various protective measures, the grid will quickly move to equilibrium at lower levels of supply and load.

However, if too much load drops at one time, that doesn’t naturally cause generation to drop – which is what would be needed. In fact, it might well cause the opposite to happen: The imbalance between supply and demand will increase as more and more large loads go to backup power. Where does this end? I’m no electrical engineer, but I don’t believe there’s necessarily a natural path by which stability will be restored, as there is in the case of too little supply.

When I wrote the post in March, there had been two such events in northern Virginia in the last couple of years (that area is part of the PJM grid); in both of them, less than 2,000 megawatts of load was suddenly lost. That’s a lot, but it was survivable. However, the article I quoted continued: “It didn’t cause an emergency, but I would say it caused concern,” said Mike Bryson, PJM’s senior vice president of operations. “What we’re worried about is, what if that happens for 3,000 megawatts or 5,000 megawatts?”

This week, we found out the answer to that question. To quote from Energy Central’s daily newsletter:

on Wednesday, a transmission line fault in Northern VA’s “Data Center Alley” triggered over 3 GW of load to suddenly disconnect from the grid. This massive drop occurred as data centers automatically shifted to backup power.

It could’ve been worse: It took around 10 minutes for Dominion to stabilize the grid, far longer than the typical millisecond-scale response time. But residents reported only minor problems. This means automatic systems (plus grid operator responses) likely kept things in check.

“The system, as far as we know, and as far as we’ve seen, responded incredibly well,” Kyle Thomas, VP of engineering and compliance services at Elevate Energy, told Energy Central. “That’s the really good side of this.”

Yes, but: The industry lacks good models and data to grasp when and where these events could occur next, Thomas said. These could inform more tools and practices to mitigate them.

To get ahead of future data center disconnections, NERC is developing a large-loads action plan and new reliability standards. Plus, CAISO and ERCOT are getting proactive with ride-through rules that require data centers to stay online in outages.

The takeaway? New rules aren’t enough—data center operators must collaborate with grid pros to adapt (or upgrade) their equipment to “meet the requirements of the grid,” Thomas told us.

When this problem was discovered to be so serious this spring, NERC (encouraged by FERC) took extraordinary steps – including developing a new fast-track development process for standards needed to address serious new threats. It was probably too early for NERC’s measures to have an effect on this week’s event, since it sounds like Dominion (which operates the Virginia portion of the PJM grid) did all the right things needed to keep the grid from falling off a cliff. On the other hand, the fact that fixing the problem took ten minutes, not the milliseconds it would normally take, shows that a lot more help is needed. Fortunately, help seems to be on the way.

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.

Subscribe now

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 tom@tomalrich.com.

Don’t be put off by the fact that the invitation makes this event sound like it’s “All AI, All the Time”. There will be lots of different speakers and they will be focusing on many topics, all having to do with how the CVE program can be improved. I’m sure AI will be a subject of some of those discussions, but hardly all of them. The point of the program is to address any and all current shortcomings of the CVE program, and discuss how they can be improved, whether or not they have anything to do with AI.

If you would like to read a short “CVE 101” to prepare for the various terms that are likely to get thrown around during the event, see this post.

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.

Subscribe now

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 tom@tomalrich.com.

Before two weeks ago, the last time a new set of CIP standards was introduced was in 2011, when the NERC team that drafted the CIP version 5 standards (after having previously drafted CIP versions 2, 3 and 4) introduced the new standards CIP-002-5.1 through CIP-011-1. The NERC approval process (including four ballots and intervening comment periods over one year) for CIP v5 started in early 2012 and lasted one year, followed by FERC approval on November 22, 2013 (50 years almost to the minute after John F Kennedy’s assassination – although nobody has ever alleged there’s any connection between the two events. Me? I’m still not sure…😊).

There were many discussions (and debates) over the standards in the NERC community during the drafting and balloting periods. The version that was finally approved had been significantly changed in response to comments received after each of the first three ballots (in just one of the comment periods, the SDT received over 1,000 pages of comments. They had to respond to every comment, although they were able to group similar comments and answer them together).

Despite all the discussions and revisions to the standards before they were approved by NERC and FERC, more problems were discovered after FERC’s approval, as NERC entities prepared for compliance. One of the biggest problems was that the SDT hadn’t defined two words that were part of the “foundation” of CIP v5: “programmable” (used in the defined term Cyber Asset, the foundation of asset identification) and “routable” (used in the defined term External Routable Connectivity). While the SDT defined literally all the important terms in CIP today (Cyber Asset, BCA, BCS, EACMS, PACS, ESP, Interactive Remote Access, etc.), they wanted to limit their number as much as possible, since creating a definition that’s used in more than one NERC standard requires submitting it to the same balloting process as the standards themselves.

If a NERC CIP standard uses a word that has a generally accepted definition in the computing and networking community, it’s OK if it isn’t officially defined. Since I attended many of the SDT meetings in 2010 and 2011 (which were mostly in person, of course), I can attest there were several discussions of those two words. However, the team convinced itself that both words have a generally accepted meaning (although I don’t recall one ever being called out); therefore, there was no reason to create a definition for either of them.

This turned out to be a mistake, since once NERC entities started to put together their v5 compliance programs in early 2014, they had a lot of questions about the meanings of those two words. I wrote about twenty posts on the various interpretations that NERC entities made of each word, as well as NERC’s ultimately fruitless efforts to “define” them without invoking the only process allowed by the NERC Rules of Procedure: developing a definition and having it balloted by NERC entities, approved by the NERC Board of Trustees and finally approved by FERC (a process that is almost identical to the process of developing a new standard, and is certain to take 2-3 years). There was even a meeting (including just NERC staff members and staff of the four trade associations) at NERC’s offices in DC in I believe 2015; it was mostly focused on the meaning of “programmable”. From what I heard, the discussion grew so heated that it was a miracle that a fistfight didn’t break out.

How were these controversies officially resolved? Neither one was resolved – since nobody had the time or inclination to devote a couple of years to resolving them the correct way. Instead, NERC entities and their auditors worked out a general understanding of both terms. But none of that was ever written down, and there was nothing to prevent an auditor from changing his or her mind and issuing a PNC (potential non-compliance) notification for a procedure they had said was probably compliant a month previously. I wish I could say this were the only case in which something like this happened, but that would be far from the truth.

Those who do not learn from history are doomed to repeat it

Two weeks ago, what I call the Cloud CIP SDT introduced four of the approximately twelve standards that they are proposing to ultimately replace the current CIP standards (except for CIP-014 and – perhaps – CIP-006, the two physical security standards). They are called the “hundred series”, since they are numbered CIP-102, -103, etc. The primary term in the standards (i.e. the equivalent of “BES Cyber System” in today’s CIP standards) is “BES Cyber Services and Systems” (BCSS). Its definition consists of almost exactly the wording of the current BES Cyber Asset definition, with the term “Cyber Asset” replaced by “One or more cyber services or systems”.

In today’s CIP standards (which are fundamentally unchanged since CIP v5 was introduced), the basic defined term is Cyber Asset (even though the definition of that term, “programmable electronic device”, is ambiguous due to the lack of a definition for “programmable”). The fact that Cyber Asset is part of the definition of BES Cyber Asset means that today, asset identification must start with devices; anything not in the universe of intelligent devices isn’t in scope for CIP compliance today (only software on devices that are in scope is itself in scope).

Of course, since the 100 series standards are intended to apply both to on-premises and cloud-based systems and since individual devices (or combinations of devices) can’t be tracked by cloud users, Cyber Asset is no longer a useful term. Moreover, since BES Cyber System is defined as “One or more BES Cyber Assets…”, it clearly can’t be used in the cloud, either.

This is why the Cloud CIP SDT developed the term BCSS. It was a good decision to build the definition on the BCA definition, since the concept of “sub-15 minute impact on the BES” is a valid one, whether the asset being considered is an on-premises device or entirely in the cloud. However, the devil’s bargain that the SDT made to do this was basing the BCSS definition on two undefined terms: “cyber service” and “(cyber) system”. If this isn’t fixed, the 100 series standards are unlikely to be approved by NERC or FERC; even if they’re approved, these problems will persist long after the 100 series standards have been implemented (which is unlikely to be before 2030, if then).

You might point out that the term “system” is a fundamental part of “BES Cyber System”, even though it’s not defined – just like programmable and routable aren’t. The CIP v5 drafting team discussed defining “system” as well, but they ultimately decided that defining BCS as “One or more BES Cyber Assets” meant they had implicitly defined “system” as “a grouping of Cyber Assets”. While I never thought that was a great move, it at least stopped the bleeding; unlike with “programmable” and “routable”, there were never big arguments about “system” that I know of.^[i]

However, I think not defining “cyber system” and “cyber service” will be a huge mistake for this SDT, if they don’t correct it before they go to the balloting phase. Fortunately, the SDT has now admitted that balloting won’t start until early2027, and perhaps not even then. Until two or three weeks ago, they were insisting (without providing a good reas) that balloting had to start in September, which would have – by my calculation - required stopping the earth’s motion around the sun for at least a month or two as they finished the many things they were required to do before the balloting can begin. I always suspected that insisting on the September date was the SDT’s way of demonstrating that they have a sense of humor.

If the SDT doesn’t draft definitions of those two terms^[ii], here’s what could happen: any NERC entity would be free to develop their own definition of BCSS, as long as they could justify it to the auditor; at the same time, auditors and Regions would be free (nay, required to develop their own definitions). What could possibly go wrong with that?

Well, for example:

· Suppose an entity decides that only systems that run Windows are properly called BCSS, whether they’re in the cloud or on-prem. They say this because Windows software has more vulnerabilities than Linux software. This blog doesn’t discuss religious issues, so I won’t weigh in on whether that’s a valid argument. However, I can certainly see it coming up.

· An auditor might decide that, since the average software product today contains hundreds of dependencies - which are often called “microservices” when part of SaaS - and each dependency is a software product in its own right, they should all be identified as BCSS.

· A user might argue that only dependencies that load into memory when the user accesses the software should be identified as BCSS.

· A user or auditor might argue that only dependencies that load from the cloud should be identified as BCSS, whether the software is used as SaaS or on premises. They would argue that dependencies that are part of the base software should normally be patched by the software supplier.

· Another auditor might point out that the user needs to verify that the supplier patches component vulnerabilities; otherwise, the components need to be treated as separate BCSS.

· A user might note that since only a very small fraction of vulnerabilities found in software components are exploitable in the software itself, treating any components as BCSS will make compliance with the 100 series requirements needlessly burdensome for any NERC entity.

· An auditor might announce they’ve decided to retire and take a job as a Walmart greeter.

Wouldn’t all these discussions be great fun and quite interesting, especially at audit time? If you don’t think they would be, you might suggest to the SDT, during the 45-day comment period that started last weekend, that they define “system” and “service”, or even better drop the latter from the BCSS definition altogether.

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.

Subscribe now

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 tom@tomalrich.com.

^[i] However, if the SDT had been willing to take the time to define “system”, we probably would not be having such a big problem with the cloud today, since the problem is almost entirely because of out-of-date definitions.

^[ii] I don’t understand why both “service” and “system” need to be included in the BCSS definition. “Systems” are found both on premises and in the cloud. On the other hand, “service” only applies to the cloud; if access to software is provided in the cloud, it’s called “software as a service” or SaaS. But it’s both a system and a service.

However, SaaS only meets the BCS definition if it has a real-time impact on the BES, which implies a direct connection to a sensor or actuator. Any other SaaS that is used to operate or monitor the power grid might use BCSI, in which case it falls under CIP-004-7 R6 and CIP-011-3 R1 and R2. A separate SDT recently spent 2-3 years developing or modifying those three standards to accommodate use of BCSI in the cloud; they did an excellent job. There’s no reason to reopen that issue.

In my bio for the podcast, I described my relatively new consulting relationship with Foxguard Solutions. Foxguard is an entirely OT-focused cybersecurity service provider, which provides services in some very important areas. One is OT patch management, where their widely used Patchintel service provides patch discovery, evaluation, and verification for OT-focused organizations, especially those that must comply with NERC CIP-007 Requirement R2. The other is OT vulnerability management, where Foxguard’s Cyberwatch product provides OT asset discovery, as well as asset-based vulnerability management.

The primary focus of the podcast was the last phrase of the title: “post-NVD era”. This doesn’t mean we think the National Vulnerability Database is dead or even on the way out, but it does mean that the NVD, which is run by NIST and has for years been the primary resource for software vulnerability information for a significant percentage of public and private organizations worldwide, has retreated from performing such an important role.

The questions we answered in the podcast can be summarized as, “Given that the NVD is no longer able to be our one-stop shop for vulnerability identification and prioritization, how else can we perform the tasks we previously relied on the NVD for? In fact, once we’re no longer dependent on the NVD, are there better ways to do vulnerability management?” (If you would like to see an overview of how the CVE program works, including its relationship to the NVD, see this post)

There are three main components to this problem:

The decline (but not yet fall) of CVSS

Because the CVSS Base Score used to be published in almost every CVE record, it became widely used for vulnerability prioritization, even though many vulnerability management professionals pointed out that it didn’t provide much value as a measure of risk, especially OT risk. For example, suppose that CVE-2026-12345 has a 10.0 CVSS Base Score (the highest severity). It affects two systems in your organization: a system that monitors safety in your factory and a system that displays menus for the company lunchroom. At the same time, a system that schedules production in the factory is affected by a vulnerability with a 9.0 score, which is severe but not the highest severity. If you use only CVSS Base Score to prioritize application of patches, this means you should patch the lunchroom menu system before the factory scheduling system. Of course, that makes no sense.

In fairness to CVSS, the Base Score by itself was never intended to be a measure of true risk; that is only achieved if the CVSS Temporal metrics^[i] and Environmental metrics are utilized with it – i.e., if the user pays attention to a composite score created by combining the Base metrics with the other two types of metrics. This is not usually done, because neither the Temporal nor the Environmental metrics are published.

The Environmental metrics are completely under the user organization’s control; they are meant to distinguish different systems based on their importance to the organization, i.e., the criticality of the process controlled by the system. For example, an organization might assign each of their control systems a criticality level of low, medium or high, or else use a binary low/high criticality score. When the organization incorporates these metrics into the CVSS Base Score, they will get a “Base and Environmental” score that is specific to each asset or type of asset. Of course, that will be much closer to a true measure of risk than the Base Score alone.

The Temporal metrics change over time. Two Temporal metrics are the maturity of exploit code and the remediation level of the vulnerability (i.e., the degree to which the CVE has been patched). But the problem with the Temporal metrics is that no data is regularly available for them, so the user organization will normally only be able to compute Temporal scores for a small percentage of the CVEs that they deal with. Of course, this doesn’t mean that Temporal scores are useless, since they can help compare risk posed by one CVE with risk posed by another, when both have a Temporal score.

However, the biggest problem with CVSS today is that a large and growing percentage of CVE records contain no CVSS Base Score. In February 2024, due to funding problems, the NVD greatly decreased the rate at which it added a score to each new vulnerability record (NVD calls this process “enrichment”). Moreover, in January of this year, NIST announced that from then on, CVSS scores will only be added to the records for CVEs deemed to pose the highest risk (e.g., those in CISA’s KEV Catalog). Of course, it’s good that the NVD will focus on enriching the highest risk vulnerabilities, but it’s not good that they aren’t enriching other vulnerabilities at all.

However, the fact that fewer and fewer CVE records contain a CVSS score doesn’t mean organizations should stop using CVSS for vulnerability prioritization, especially if they are able to utilize Environmental and (if possible) Temporal metrics to create a true CVSS risk score. But CISA recently changed their guidance on vulnerability prioritization.

SSVC

Last month, CISA’s BOD-26-04 deprecated CVSS as an appropriate measure of risk for vulnerability and patch prioritization purposes, in favor of SSVC^[ii]. SSVC is a decision tree process that CISA developed in 2022. It operates simply and incorporates user provided data on Technical Impact of the vulnerability, based on the system (or class of systems) that is affected by the vulnerability; SSVC also takes account of whether the CVE appears in CISA’s KEV Catalog. Thus, it can be considered a much better representation of risk than CVSS Base Score.

The final output of the SSVC process (called the “decision” for the CVE) is the prioritization of the vulnerability into one of six classes. CISA is currently providing three of the four SSVC metrics (only the “Publicly Exposed” metric, which has a yes/no answer, is the only metric CISA doesn’t provide. The user organization needs to provide that, whether or not they are a federal organization) for some, although not yet all, CVE records.

CPE and PURL

The third component of the “NVD problem” is that the NVD, along with reducing the number of CVSS Base Scores that it adds to CVE records, has also greatly reduced the number of CPE names that it adds to CVE records. Since CPE is currently the only machine-readable software identifier that ties a CVE to an affected software product (or intelligent device), this means an ever-increasing percentage of CVEs are invisible to an NVD search using a product name. This is probably the most serious of the three problems, since simply learning about a vulnerability doesn’t help if there’s no way to know what product(s) is affected by the vulnerability.

Last fall, the CVE Program added support for the PURL software identifier (which stands for Product URL) to the CVE Record Format. PURL has the big advantage that nobody needs to “create” a PURL for most open source products; all users of a product can create their own PURL, using its simple specification. A PURL can always be constructed using information the user already has, or could easily obtain. This includes, for most open source software products, the package manager from which the product was downloaded and the name of the product in that package manager.

PURL could ultimately be the solution to the lack of a machine-readable software identifier in many CVE records. However, PURL’s biggest problem today is that currently it can’t be used to identify commercial software products. This is not a technical problem but an operational one, since solving it will require a significant number of commercial developers to agree on procedures for naming commercial software products. OWASP has formed the PURL Expansion Working Group to address this problem. Anyone interested in participating in that group should contact me at tom@tomalrich.com.

Vulnerability databases

Toward the end of the podcast, I was asked what other vulnerability databases are available besides the NVD. My answer was there are many other options, but they are very diverse, so it’s impossible to point to a single database that would replace the NVD. You may need to get used to using 2-4 vulnerability databases, although it would be nice if in the future that wasn’t necessary.

1. GitHub Security Advisories (GHSA): This huge database contains open source software vulnerabilities (mostly found in GitHub projects). GHSA has its own vulnerability numbering scheme called GHSA. There’s no way to map a GHSA identifier to a CVE number, unless the GHSA record refers to a CVE number. Often, GitHub creates a new CVE record at the same time as it creates a new GHSA record (GitHub is one of the most prolific CVE Numbering Authorities – CNAs). Vulnerable projects in GHSA are identified using PURL or OSV (OSV is the main software identifier used in Google’s OSV.dev vulnerability database. That database includes GHSAs, as well as advisories from a large number of ecosystem-specific databases, like those for Maven, Python, and many flavors of Linux).

2. Sonatype Guide (formerly OSS Index). This is another huge open source vulnerability database, although all the vulnerabilities are identified using CVE identifiers. The vulnerable products are identified with PURL. Since so many organizations are used to working with CVE records, it is easy to use this database to look up open source vulnerabilities, since the coverage of those vulnerabilities is much more comprehensive than it is in the NVD. However, the fact that PURL is currently limited to open source software distributed in package managers means this database cannot currently handle commercial software vulnerabilities – although, as discussed above, an OWASP project will hopefully start soon to extend PURL to commercial software. Currently, the only vulnerability databases that identify vulnerabilities in commercial software products are the NVD and its offshoots.

3. VulnDB, VulDB, VulnCheck, Vulners, JP-CERT/CC, as well as others. These databases were all built on the NVD. All of them include everything that the NVD does (they’re updated in close to real time, since it only takes about ten minutes to download the entire NVD). This means they support CVE as a vulnerability identifier and CPE as a software identifier. Each of these databases adds their “secret sauce” to what the NVD has, but you need to go through their websites to compare them. They all (except JP-CERT/CC) charge for at least some use. However, people swear by all of them.

4. The EU Vulnerability Database is run by ENISA; it started operating last year. It identifies vulnerabilities using EUVD identifiers, although in many cases they are mapped to CVE numbers and/or GHSA advisories. However, no machine-readable software identifiers are included in the records (i.e., neither CPE nor PURL). This makes automated searches difficult.

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.

Subscribe now

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 tom@tomalrich.com.

^[i] These are called “Threat metrics” in CVSS 4.0.

^[ii] CISA’s BOD-26-04 doesn’t specifically refer to SSVC, but the process it describes is clearly SSVC. SSVC documents are referenced in the Implementation Guidance for the BOD.

While this had nothing to do with my leaving Blogspot, ten years ago I first noticed that my Blogspot blog was getting occasional huge spikes in hits. Normally, that would be good news, except for one thing: The increased hits (called pageviews in Blogspot) weren’t for new posts but for old ones going back years. And instead of being concentrated on a few all-time favorite posts, these increased hits seemed to be spread across all my old posts, regardless of whether I considered them important or not. Obviously, someone or something was going through my posts one-by-one and reading each one. And that person or thing told a lot of their friends about the blog, so they all followed suit.

I didn’t know what to make of this phenomenon. I asked by readers if they knew, but I got no response, so I just filed it away as a curiosity. However, these unexplained hits continued to grow. More importantly, they spread to other countries, such as Singapore and Hong Kong - to the point where four or five years ago I had more hits in one year from Singapore than I did from the US. This wouldn’t itself be strange, were it not that until about 2020, my posts were mostly about the NERC CIP cybersecurity standards for the North American electric power industry (that’s still my number one topic, although vulnerability management is a close number two nowadays). I never realized there’s a huge body of NERC CIP affandicios hiding out in Singapore. Who would have known? 😊

Two or three years ago, the reason for these hits became clear: My blog is being heavily used for AI training, not because I’m a brilliant individual but because I’m almost the only independent source of information on NERC CIP, other than the “official” channels of NERC and the NERC Regional Entities. I’ve confirmed this myself, since sometimes responses to questions about CIP that I raise in ChatGPT or Google AI reference one of my posts (always in Blogspot, of course).

Since then, my total pageviews on Blogspot have continued to rise, even though last August I set up my new blog on Substack and stopped putting up new posts on Blogspot (I also put up all my new posts in Energy Central and put up a link to them on LinkedIn. I’ve been doing that for more than a decade).

Meanwhile, my Blogspot pageviews have grown at a literally exponential rate, even though the last new post I put up there was in November. Last year, I think I averaged about 15-25,000 pageviews per month (which I thought then was a lot). But this year they really took off. In May 2026 I had 274,000 pageviews, and in June (i.e., this past month) I had over 670,000 pageviews – in Blogspot alone. If this trajectory had continued, I would probably have received a million pageviews per month by the end of the summer. Yet I have never received a single email or comment on one of my Blogspot posts since I stopped putting up new posts there. It doesn’t seem that the bots reading my posts have any questions about them. I wonder why.

I wasn’t happy about this, and why should I be? It’s clear that my Blogspot blog has become nothing but a free resource for AI training. So I took down that blog just now, after posting a warning that I would do this about a month ago (not a single bot complained, or even sent me a going away card).

Anyone who wants to access any of my old posts (i.e., all posts over three months old, whether they were originally in Blogspot or Substack), is welcome to read them to their heart’s content in Substack. AI training bots are also welcome to read them – although I freely admit that I consider bots to be inferior to humans (after all, Thomas Jefferson said “All men - and we now add ‘women’, of course - are created equal.” As far as I know, he never mentioned AI bots, or any bots for that matter).

Of course, anyone who just wants to see my posts that are less than 90 days old is welcome to sign up for a free subscription. But anyone who wants to read my old posts – human or otherwise – has to pay a subscription fee of $30 per year. However, if someone wants access to my old posts yet can’t afford $30, I’ll be glad to give them a complementary one year subscription if they just email me. But people with OpenAI or Anthropic email addresses need not apply. I figure they can afford $30.

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 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 donate more than that or become a founding subscriber for $100). Whether free or paid, please subscribe.

Subscribe now

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 tom@tomalrich.com.

Until this week, I had been told by SDT members that they were expecting to start the NERC balloting process in September (the balloting process alone will probably take at least a year. See below). Given that the SDT just finished drafting their first four standards and the definitions that go with them (two years after they started work), and that none of their standards have been previously reviewed by either NERC entities, the CIP auditors, or the NERC legal staff - I regarded their September target date as just a way of showing they have a sense of humor.

Fortunately, an SDT member told the ERCOT CIPWG last Friday that the team is now aiming for early 2027 to post the standards (all of them) for the first ballot. Given the big changes that I can already see are required, I believe even that date is optimistic - unless the SDT decides to just make the seven small, and one medium-sized, changes that I suggested would accomplish their goals, in this post last fall.

But the SDT isn’t planning on doing that. Ironically, I now realize that my eight changes will almost certainly still be needed anyway, even if the SDT is able to get something like their current standards and definitions approved. This is because the three “Cloud CIP” problems that need to be solved – in order of importance, the inability to use EACMS based in the cloud, PACS in the cloud and BCS in the cloud – all have to do with the current definitions of EACMS, PACS and BCS, none of which the SDT proposes to change.

In other words, while it’s true that entities who fully adopt the new 100 series standards will have full use of BCS, EACMS and PACS based in the cloud, NERC entities who wish to stay on the existing CIP standards for their on-premises systems still won’t be able to utilize EACMS and PACS based in the cloud. For example, if their SIEM vendor decides to move to a completely cloud-based model after the 100 series standards come into effect, a NERC entity that wants to continue to use the existing CIP standards for their on-premises systems will most likely not be able to use the SIEM vendor. This is because the existing CIP requirements (like CIP-010 R1 Configuration Management) apply to EACMS, not Associated BES Cyber Services and Systems (ABSS), the term that replaces EACMS in the 100 series. This problem could be avoided if a small change were made to the existing EACMS definition (it’s number 7 of the eight changes I listed in the post from last fall, which is linked above).

It won’t take long to add my eight changes to the existing CIP definitions (and one existing standard) when and if the SDT realizes this needs to be done. If this had been done last fall, or even today, at least the BCS, EACMS and PACS problems would probably have been fixed a couple of years earlier than they will be without making those changes now.

To be blunt, the draft standards released yesterday are loaded with problems. Since I probably can’t discuss all of them in twenty posts (which I certainly don’t have time for anyway, even in the next 20 weeks), I will focus for now just on what I call the showstopper problems: the problems that are so serious that they need to be fixed before the draft standards are put up for ballot. In other words, waiting for the balloting to start and then trying to make all the needed changes is a terrible idea; it might lead to a total breakdown of the balloting process for the 100 series (after all, nobody benefits if the balloting process goes on for 2-3 years).

Instead, this SDT should do what all the other NERC CIP SDTs that I have followed have done: try their hardest to fix all the problems that have been identified before they submit the standards for balloting.

For example, the CIP version 5 balloting process (which was the last – and so far the only – time that the CIP standards were completely rewritten) required four ballots over a year, with a comment period after each ballot except the fourth one. In at least one of those periods, NERC entities submitted over 1,000 pages of comments, all of which needed to be responded to – and acted on, if needed – by the SDT^[iii]. Given how much more ambitious the 100 series standards are and how many fundamental new questions they raise (far beyond those raised by CIP v5), I think even one year may be too little to allocate for the balloting process.

Here’s the first of the showstopper problems that needs to be fixed before the SDT can seriously hope to have draft versions of the CIP 100 Series that won’t be completely rejected when balloting starts. The problem is with the Technical Rationale (TR) documents. The content of those documents is incredibly dense. As an example, I recommend you read through the TR for CIP 100 Series Definitions – all 16 pages of it. As you do this, keep in mind that you’re reading not just a book review but a guidance document which may well determine whether you are in compliance with probably over one hundred CIP requirements and requirement parts.

The six TRs that were released yesterday contained a total of 54 pages – an average of nine pages per TR. Since there are still at least six standards to be developed and released, it’s safe to say there are at least six more TRs coming, so the total pages of TRs will be over 100. Keep in mind that at least one person in every NERC entity subject to CIP compliance (or at least each entity with a medium or high impact BES environment) will need to understand each word of these documents, as well as each of the standards themselves; of course, large entities will probably require 20-100 people to understand these documents very well. Does your organization have those people available?

However, there’s another point about the TRs: As far as I know, the SDT has decided not to submit these for balloting, meaning they won’t be approved NERC guidance. This means that, if you believe a certain requirement means one thing but an auditor believes something completely opposite, you can’t win the argument by pointing to the TR. As is often the case today, you will essentially need to “negotiate” a mutually acceptable interpretation of the requirement in question. Thus, the TRs will just fall into the “nice to know” bucket, nothing more – which is the case with most of what’s called compliance guidance (or guidelines) today.

Most importantly, the fact that the TRs are so voluminous, yet still will only have unofficial status, raises a big red flag about the 100 series standards themselves. Why do the standards need so much explanation? And why isn’t the SDT willing to go through the trouble of getting the TRs approved as official guidance? In other words, if the SDT thinks so much verbiage is required to make the 100 series standards comprehensible, why isn’t it willing to defend that verbiage during the balloting process?

Note 7/12/2026: I put up this post yesterday, but I just realized I missed an important fact about the Technical Rationale documents: The problem with them isn’t that they provide complex and confusing guidance, but that they don’t provide guidance at all. They just explain why the 100 series standards were developed, not how a NERC entity might comply with them. NERC entities have to figure out how to comply with the 100 series standards on their own.

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.

Subscribe now

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 tom@tomalrich.com.

^[i] As you may know, there are already two new versions of CIP-002: CIP-002-7 and CIP-002-8. These will both be implemented on the same day, July 1, 2028. The new version, CIP-002-9, will presumably be implemented at least a year after that date (the Implementation Plan is silent on this topic). Since CIP-002-9 will need to be in place when the 100 series requirements are implemented, this means the 100 series probably can’t be implemented until July 1, 2029, at the earliest.

^[ii] It is quite odd that the SDT is even publishing a Technical Rationale for a set of definitions, let alone a 16-page Technical Rationale. The whole idea of a definition, in my opinion, is that it’s supposed to be the final word on some issue; it’s not supposed to need another document to clarify it. What if someone doesn’t understand a single word in the TR, even if it happens to have a dictionary definition? Will there need to be another TR for each ambiguous word in the first TR? And on and on?

^[iii] Although the SDT can group similar comments and answer them together.

Recently, I wanted to see a post I had written in 2015. (Some background: I started the Blogspot blog in January 2013. I transferred all my Blogspot posts - over 1200 then - to Substack last August and stopped posting any new posts on Blogspot last fall.

When I entered “2015” in the Substack search bar, I wasn’t terribly surprised that, while I immediately was shown every post where “2015” appeared in the text, the search doesn’t look at the date of the post itself, and therefore couldn’t show me which posts I wrote in 2015 (or any other date range). I asked the chatbot if it was possible to search on a date range. It cheerfully pointed out to me (it’s always cheerful, of course) that the feature I want isn’t supported in the search bar, but it would be happy to submit a new feature request for me. Even though I knew this would be useless, I let it do that anyway. Then it closed the ticket.

After that, I received the usual email asking me to clarify what I wanted, so I did that – again, not expecting anything more to come of it. However, this time a human emailed me to point out that there’s a completely different way – not involving the search bar – that I can see all of my posts within any date range. It works fine, so now I can find posts from 2015 or any other time period.

The important point about this is that I don’t think the person who solved my problem is some sort of brilliant individual that Substack is lucky to employ. They just did what a human who’s trying to be helpful does naturally (or should, anyway): go back to the problem I was trying to solve and figure out how it could be solved in the context of the Substack platform. The chatbot had categorized my problem as narrowly related to the search bar (even though it was formulated more generally), but my problem was really that I wanted to see posts from a range of dates – and I didn’t know the platform well enough to realize that the search bar isn’t the only possible way to do that. My guess is the human figured out the answer to my problem within a few seconds, even though the chatbot would probably never have done so without being given additional prompts that a human wouldn’t need.

The moral of this story is that generative AI, which is simply an elaborate statistical algorithm for predicting the next word in a sentence, will never reach the point where it can satisfactorily answer a question, if the questioner didn’t ask their question in a way that the answer will be straightforward – specifically, if the questioner didn’t ask the question in the context of the correct response. I asked my question in the context of the search bar, so that was all the chatbot focused on in its answer. But the human understood the question in the right context: “Given that I’m a Substack user, is there a way for me to find all of my posts within a particular date range?”

Of course, since this was Substack’s chatbot, it could have been trained always to consider every question that appears to be about a particular function within Substack to be instead a question about the platform as a whole. That might have allowed it to solve my problem without requiring human intervention, but what if I’d really been asking whether blogging platforms in general allow searches by posting date? That would have required an even bigger context, which the chatbot probably wouldn’t have been trained for.

Human beings don’t know all the answers, but they should at least be able to reformulate the question in its proper context. Generative AI can’t even do that and probably never will.

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 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 donate more than that or become a founding subscriber for $100). Whether free or paid, please subscribe.

Subscribe now

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 tom@tomalrich.com.

Not more than a few years ago, I was like most people who utilize CVE information all the time: I had no more idea of where CVEs came from than if the Vulnerability Fairy created CVE records. There’s no “CVE for Dummies™” book that puts everything you need to know in a few pages, so I’ve pieced together what I know about CVE over the past few years from a variety of sources.

Since I write about vulnerabilities regularly in my blog but I always feel bad when I use terms that I’m sure people don’t understand well (e.g., CVE, CNA, CPE, PURL, NVD), I’m writing this post to serve as an “anchor” for future posts. Because the world of CVE is always changing, I will try to keep this post up to date with new developments.

Where do vulnerabilities come from, Daddy?

You probably know that a CVE number (e.g., CVE-2026-12345) designates a vulnerability, which is why it is called a “vulnerability identifier” (CVE stands for “Common Vulnerabilities and Exposures”). There are many vulnerability identifiers, such as GitHub Security Advisories (GHSA), but CVE is by far the most widely used vulnerability identifier worldwide. Where do CVE’s come from?

Here’s a short quiz: Who do you think reports the overwhelming majority of software vulnerabilities in commercial software: A) independent researchers (good guys), B) evil hackers (bad guys), or C) the developer of the software? If you said “C”, you’re correct! As far as commercial software is concerned, vulnerabilities are usually identified and reported by the developer of the software; moreover, a small number of the largest developers report the great majority of new vulnerabilities.[i]

Far from hiding vulnerabilities, developers are taking the lead in rooting them out and exposing them to the light of day. Of course, this isn’t to say there aren’t developers who try to hide vulnerabilities. But I suspect that any developer who does that today is setting themselves up for failure, not success. I say this because, if the developer’s software is hacked and they get sued by a bunch of unhappy customers - and if the plaintiffs learn that the developer almost never (or literally never) reports vulnerabilities they find in their software - the developer might not be happy with the outcome of their court case. That is, if they’re even still in business afterwards.

Before I go further, you may wonder whether developers are stupid, since they’re usually still identifying new vulnerabilities in their products long after they develop them. Wouldn’t the world be a better place if the developers just followed secure software development practices to begin with? That way, their software will be vulnerability-free from the start, right? Is it hard to do that?

In fact, developing vulnerability-free software is not only hard, but it’s literally impossible. That’s because even though most developers do their best to identify and fix vulnerabilities they identify in their code before they ship their product (if for no other reason than because they know that a lot of their customers will scan the product for vulnerabilities before starting to use it), a determined individual - usually a member of either Group A or Group B - could fairly easily find multiple vulnerabilities that were unknown when the code was originally written. Thus, no software is ever truly “vulnerability free”. Anyone who tells you otherwise is wrong.

New vulnerabilities are discovered all the time, and they’re discovered in code that was previously thought to be completely benign. In other words, lots of pairs of experienced eyes previously looked at a piece of code and saw nothing wrong with it. But one day, some intrepid soul realized these seemingly innocuous lines of code were in fact a vulnerability that needed to be reported to the world; without any change to the code, the software went from being “vulnerability-free” to “vulnerable”.

The CVE Program

The CVE Program creates and manages the CVE Records that identify software vulnerabilities – so that two people discussing a vulnerability can be sure they are discussing the same thing. The program used to be called simply “MITRE”, since from its inception CVE has been a project contracted to the MITRE Corporation (in fact, MITRE first described their idea for CVE in 1999). Today, an independent board of government and private industry representatives governs the CVE Program, although MITRE staffs and runs the program.

Here are the steps by which a new CVE record is created in the CVE Program:

1. New CVEs are reported by public and private organizations that are called CVE Numbering Authorities or CNAs; today, there are over 525 CNAs. Each CNA has a scope, which can be a country, an industry, etc. When a person or organization that is not a CNA wishes to report a vulnerability, they can approach a CNA that has the organization within its scope. For example, any project on GitHub can report a vulnerability to GitHub, which is a CNA; GitHub will assign a CVE number to the vulnerability and submit the report for approval by the CVE program. If an organization can’t find a CNA that way, they can go to one of the “CNAs of Last Resort”. Currently, these are CISA (for industrial control systems) and MITRE (for everything else).

2. The CNA creates a CVE ID (aka “CVE number”) for the vulnerability and submits the report to CVE.org, where it becomes a CVE record and is included in the CVE.org database (although it needs to be approved first. Many proposed CVEs are rejected, for various reasons). At this point, the CVE record always includes a textual description of the product(s) in which the vulnerability is found. However, it does not usually contain a “CPE name” (CPE stands for “common platform enumeration”, although that phrase means little today); see below for further discussion of CPE.

3. Now the CVE record goes to the National Vulnerability Database (NVD), which is operated by the National Institute of Standards and Technology (NIST), an agency of the US Department of Commerce. It also goes to any other vulnerability database that supports both CVE and CPE (there are at least six or seven of these databases. They all include everything currently in the NVD, plus additional features and data offerings).

4. Until 2024, after a new CVE record reached the NVD, an NVD contractor almost always “enriched” the CVE record by a) creating and adding a CVSS Base Score, b) identifying one or more CWEs (common weakness enumeration) that apply to the vulnerability, and c) creating a CPE name[ii] for any product described as vulnerable in the text of the CVE record.

5. However, starting in February 2024, that process broke down, with the result that currently a large percentage of CVE records do not contain a CPE name; that percentage is growing quickly, following an announcement by NIST in January 2026 that they were going to significantly restrict the number of CVEs they enrich going forward (see this post for more information on this subject). This is a big problem, because a CVE record that does not contain either a CPE name or a PURL identifier is usually invisible to a command line- or API-based search in the NVD. This means that, when a user searches the NVD for a particular product and version number, they will not be notified that CVE-2026-12345 has been reported in that product, even if the product/version was mentioned as vulnerable in the text of the report for CVE-2026-12345. This may potentially leave the user with a false sense of security.

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 donate more than that or become a founding subscriber for $100). Whether free or paid, please subscribe.

Subscribe now

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 tom@tomalrich.com.

[i] These results are different for open source software (OSS), since currently most OSS vulnerabilities are reported by third parties including Patchstack, VulDB, the Linux kernel, MITRE and GitHub. Of course, commercial software is compiled code. Seeing the source code (or what’s asserted to be the source code) requires decompiling the software, which is hard to do and is often a violation of the user’s contract. This puts the responsibility to identify vulnerabilities in a software product squarely on the shoulders of the developer of that product.

[ii] Because names for individual software products vary widely based on the context in which the software is being referred to, the only reliable way to identify a software product in a vulnerability database like the NVD is to have a single machine-readable identifier. CPE is the oldest machine-readable software identifier.

Until October 2025, CPE was the only software identifier supported by the NVD. At that time, support for the PURL identifier was added to the CVE Record Format, so that CNAs now have the option of using PURL to identify the vulnerable software in a CVE record. However, PURL can currently only be used to identify open source software found in package managers. Work is now proceeding (in the PURL working group) to extend PURL to identify open source software not found in package managers, including programs written in C and C++.

However, by far the biggest “hole” in PURL coverage is commercial software, which is almost never distributed through package managers. Extending PURL to identify commercial software products isn’t a technical problem at all, but requires a) developing, with commercial developers, protocols which the developers will follow to make naming information about their products available to the public, then b) conducting education and training to get commercial developers to follow those protocols. The required protocols will almost certainly be easy to follow.

Note that, unlike CPE names, PURLs for commercial software, like PURLs for open source software projects in package managers, will not need to be created by a central authority, nor to have a central database. This is the primary reason why PURL has become by far the most widely used identifier for open source software.

An OWASP group, called the PURL Expansion Working Group, has been approved to address expansion of PURL to commercial software; the group is led by Tom Alrich and Steve Springett, OWASP Global Chairman. If you would like to learn more about this group, please email Tom at the address below.

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.

Subscribe now

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 tom@tomalrich.com.

I was reminded of that behavior last week, when press organization after press organization dutifully reported the latest deliberate misrepresentations about the power grid from a few cynical players that understand clearly where their narrow interests lie. But even I was appalled to see that the Federal Energy Regulatory Commission (FERC) seems to have crossed over to the Dark Side and is now happily spreading those misrepresentations. Et tu, FERC?

Let me explain:

Last week, a number of press organizations (such as the LA Times) repeated more or less the same story, implying that PJM Interconnection, the grid operator based in Valley Forge, PA (about five miles from where I grew up, although at that time the area was mostly populated by Black Angus cattle who seemed to care very little about the power grid), was obstinately throwing sand in the gears of US prosperity. PJM’s sin was (and is) that they aren’t doing everything they can to please those wonderful folks that would have us believe that the Chinese will eat our lunch if we don’t build as many data centers as possible, as quickly as possible. Of course, those people want us to push aside all concerns about air quality, climate change, affordability and other woke frou-frou. After all, the insatiable AI Gods must be satisfied, whatever the cost!

A month ago, I wrote about one important player in this cabal, American Electric Power, which has recently thrown caution to the winds. It seems they promised a bunch of data center developers that they will be able to supply them about 63 gigawatts of new generation capacity to power new data centers that the developers promise – Scout’s honor! – they will build (assuming their customers come through, of course…) by 2030.

For some perspective, 63 GW is one-seventh of current US power consumption. It’s also equal to nine times the power generated annually by Grand Coulee Dam in Washington State, the largest power source in North America, or the power generated by 685 average-sized natural gas plants (92 MW). Most importantly, it’s equal to about 75% of the total utility-scale generation under construction in the US – which was already a huge number.

So AEP wants PJM to allow 63 MW of additional new generation (on top of the record amount of generation now under construction) to be built just in PJM’s grid, and just for AEP’s customers. This ignores the fact that just about every other electric utility in the US (AEP is one of the largest utility holding companies in the US, but not the largest) is also clamoring for more generation. Most of that is for data centers, too, but new generation is also needed for manufacturing, mineral extraction, hospitals, schools, and a lot of other things – although we all know that these are all much less important than AI data centers! 😊

Despite this, when they made those promises to data center developers, AEP was sure that PJM would have no problem lining up that much new generation. However, it seems AEP was shocked…SHOCKED!...that PJM didn’t immediately rush out and approve 63 GW of new generation. Instead, PJM brought up such obviously made-up problems as the huge pollution those plants are likely to generate or the severe supply chain bottlenecks that are occurring because everyone else is trying to build more power plants. For example, new orders for gas-fired turbines are likely to take 5-7 years for delivery.

There’s another headwind working against more generation: A lot of generation projects, mostly renewables projects, have been cancelled for various reasons, including active opposition to renewable energy by the current federal government. As I wrote last December:

A report[i] by Cleanview (which was reposted by Andy Bochmann last week on LinkedIn) states that “..1,891 power projects with a combined 266 GW of generation capacity have been canceled in 2025—equivalent to roughly one-quarter of America’s entire current electricity generation capacity. To put this in perspective, this is more capacity than the total electricity generation of Texas, the nation’s largest power producer.” Moreover, 93% of these cancellations were for clean energy projects.

Of course, that trend has continued this year. In fact, the federal government has recently taken a giant step forward and started paying renewables producers to abandon projects they’ve already started. You heard it right: the feds are now paying power producers not to build plants. This reminds me of the time when some farmers were paid not to plant crops like wheat or corn. The farmers would joke that they were “in the business of not growing corn.” Nice work if you can get it.

Now it seems AEP is threatening to take their business to another grid operator, as if the other six operators in the US are in any different situation than PJM is; I presume they just said this to show they have a sense of humor. Meanwhile (according to the LA Times), “FERC’s head warned last month that PJM may need to be split into smaller, more manageable pieces if reform seems unlikely to work. A senior White House official, speaking on condition of anonymity, also said a breakup should be considered if necessary. The organization’s inability to move faster, said FERC Chairman Laura Swett, places America’s artificial intelligence leadership at risk.”

I want to respectfully point out to Chairman Swett that maintaining “America’s artificial intelligence leadership” isn’t supposed to be one of FERC’s goals. The website says FERC’s purpose is “to ensure that energy services are safe, reliable, secure, and economically efficient for consumers at a reasonable cost.” Bullying grid operators into permitting a madcap generation buildout that pays no attention to considerations like pollution or cost, doesn’t seem to be a strategy that’s going to achieve that purpose.

However, I do have an idea. Just this past week, the White House did its part to increase power supply by announcing a plan to increase coal generation capacity, in part by building two new plants. The interesting thing about these plants (which are now quite expensive to build. That’s why the most recent new coal plant came online in 2013) is that they will be largely financed by US taxpayers as a whole, not by the ratepayers in the areas where they will be built, Alaska and West Virginia.

I’m wondering if, just maybe, concerned citizens in other areas might take advantage of this free money from the feds and ask for coal plants to be built where they live. After all, it’s a good way for them to do their fair share to help retain America’s artificial intelligence leadership. I don’t know where Chairman Swett lives (I’m guessing it may be in the PJM footprint, not that it matters), but I suggest that she start working with her neighbors now to get a nice new “clean coal” plant built in their area, courtesy of Uncle Sam – along with a few big data centers to take advantage of that new power and Make America Safe for AI. If she takes me up on my suggestion, I’ll be sure to let you know. 😊

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 tom@tomalrich.com.

Read more

Read more