Friday, September 19, 2025

What could possibly go wrong?

 

Note from Tom:

I have moved to Substack as my primary blog platform. If you want to see all my new posts, as well as my 1200+ legacy posts starting in 2013, please support me by becoming a paid subscriber to my Substack blog. The cost is $30 a year. Thanks!

The “Links” section of Dale Peterson’s weekly newsletter today contained this bullet point: “MITRE’s Project Homeland is trying to map US critical infrastructure.” Even though mapping critical infrastructure is a worthwhile goal that could bring lots of benefits, I must admit that, when I saw this, a bunch of red flags immediately appeared in my field of vision. After all, wouldn’t a map of US critical infrastructure be an early Christmas present for Valdimir Putin, Xi Jinping, and Kim Jong-Un?

I started to read the article, expecting to be quickly reassured that the leaders of this project, MITRE Corporation (whom I praised in my post just yesterday – for something completely different, of course) have security considerations firmly in mind and are going out of their way to protect this treasure trove of critical infrastructure data. I was reassured when I read the second and third paragraphs:

“As MITRE’s senior principal scientist, Philp has spent four years working to understand how America’s critical infrastructure systems are interconnected and where they’re most vulnerable.

“We’re more at risk today than we were in 2001,” said Philp, who has spent much of his career working on infrastructure vulnerability assessments. “The question is, with less money, how do we reduce the greatest amount of risk?””

However, I was soon disappointed. Here are some further quotes, in the order in which they appear in the article (my comments are in italics).

What emerged was something unprecedented: a spatial knowledge graph that could power dynamic visualizations showing exactly where critical infrastructure exists, how it’s all connected, and where those connections create the greatest vulnerabilities. (my emphasis)

             *  *  *

“The sheer number of infrastructure points and the intricate web of connections among them were staggering…The graph revealed not only the complexity but also enabled staff to see each entity, such as a hospital, in isolation related to its dependency on water and power.”

When you’re talking about power connections, you need to be quite clear about what you mean. You could say that, within each Interconnect in North America (the four are the Eastern Interconnect, Western Interconnect, ERCOT – which covers a large part of Texas - and Quebec) every power source, no matter how mighty, is “connected” to every residence, no matter how humble.

Of course, if you include each of those connections in your map, or even just the major ones, the map will be close to black with power connections. However, if you ask the really important question, “How many hospitals will lose power – or at least have to go on backup generation – if there’s a total outage at Grand Coulee Dam (the largest power source in North America)?”, the answer should usually be “None”.

This is because each Interconnect has lots of redundancy built into it. It’s the job of the ISOs/RTOs and the Reliability Coordinators to make sure that, at literally every second of the day and night, there are backup power sources (and preferably backups of backups) ready to cover for every possible contingency – such as a power plant unexpectedly going down at that moment. Utilities are closely monitored for how good a job they do of keeping the lights on.

On the other hand, there’s certainly some combination of power sources, the loss of which would bring down a substantial number of – say - hospitals in one of the Interconnects. If you’re trying to cause such an event, MITRE’s map would probably be very helpful.

               *  *  *

The map and graph together shed light on not just infrastructure networks but also human networks such as the highly skilled workers who maintain the infrastructure. The graph can reveal who works with whom, while the map shows where they work and can even track their location in real time.

  *  *  *

The team gathered detailed data about critical infrastructure and then used graph data science tools in ArcGIS Knowledge to analyze dependencies, revealing the web of vulnerabilities from the national scale down to individual city blocks. In Fort Lauderdale, for example, the system could show how a flood affecting one neighborhood’s electrical substation might upset water treatment systems, hospitals, and emergency services across the region.

Of course, the effects of a flood in a substation would be similar to those of a cyber or physical attack on the substation. The most chilling example of the latter is the Metcalf attack.

My guess is that, if someone writing the article had asked MITRE what risks the map itself might pose, they would have been assured that the risks were very low, since each of these assets is very well protected against both cyber and physical attacks. Moreover, the map doesn’t reveal IP addresses, firewall types, or any other information that could be used to launch an attack on one or more assets.

That is most likely true, but it completely misses the main point: The map itself, if it fell into the wrong hands, might be a great tool for plotting a massive physical or cyber attack on the grid. For example, you might use the data from the map to answer the question, “Which generating facilities and substations would we need to take out, to bring down most of the hospitals in City X?”[i] I’m sure there’s not enough data to get an exact answer to this question, but at least the map will put you on the road to having that answer.

Were there any statements in the article that warned of the dangers of gathering so much critical infrastructure information in one huge map? Not even one. The closest to a warning statement that I found was this one: “MITRE needs cutting-edge technology from trusted partners—like Esri—that are committed to protecting sensitive customer data.” This isn’t a warning about the map at all, but just a pledge to protect sensitive data of the users of ESRI’s software.

I’m not saying that MITRE should abandon this project, since the map will be incredibly useful in the case of physical disasters like hurricanes. But they obviously need to start thinking about how they’ll protect access to the map itself, not just “sensitive customer data”. This isn’t a map of risks; rather, the map itself is the risk.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com or comment on this blog’s Substack community chat.


[i] Why would someone want to execute such an attack? Certainly, a terrorist might want to. But what’s often overlooked is the opportunity to make money in financial markets by short selling for example healthcare stocks or municipal bonds, before launching an attack like that.

Thursday, September 18, 2025

Thanks, but no thanks, CISA

Note from Tom:

I have moved to Substack as my primary blog platform. If you want to see all my new posts, as well as my 1200+ legacy posts starting in 2013, please support me by becoming a paid subscriber to my Substack blog. The cost is $30 a year. Thanks!

Last week, my friend Patrick Garrity of VulnCheck – the most respected vulnerability researcher cum skateboarder in the world – posted on LinkedIn about a paper that CISA put out last week titled “CISA Strategic Focus: CVE Quality for a Cyber Secure Future”. The paper describes what CISA would like to do to improve the CVE Program. For a short 101-level overview of that program, go here.

Since the CVE Program isn’t run by CISA, you may wonder why CISA is concerned about improving the program. The answer is that CISA fully funds the CVE Program, although it is operated by the MITRE Corporation, a (nonprofit) Federally-Funded Research and Development Center, under the direction of the Board of the nonprofit CVE.org. CISA fully funds MITRE’s contract, which costs, as I’ve heard from different sources, somewhere between $44 and $57 million per year.

On April 15, the international vulnerability management community was shaken by a letter sent by MITRE to the members of the CVE.org board; the letter indicated their contract wasn’t going to be renewed by CISA and the program would have to shut down the next day. The letter caused a veritable firestorm of concern and criticism, which immediately bore fruit. By the next day, MITRE announced that everything was hunky-dory again, since the contract had been extended after all.

But everything really wasn’t hunky-dory. The fact that the contract had almost been cancelled and that CISA was (and still is) planning to cut a lot more people, led me and many others to conclude that it was close to certain the contract won’t be renewed next March (don’t ask me why the renewal was in April this year but will be in March next year. Such questions are above my pay grade).

Fortunately, literally at that moment a white knight appeared on the horizon, in the form of a new international non-profit organization called the CVE Foundation. The Foundation’s Board is comprised entirely of longtime members of the CVE.org Board, including Lisa Olsen of Microsoft (an important contributor to the CVE Program, who is also now Executive Director of the Foundation), my friend Pete Allor of Red Hat, and Dave Waltermire of NIST. I was quite impressed when their lineup was finally announced a few weeks after April 16, the day the Foundation was officially launched.

The Foundation’s board members have all been in the thick of discussions about what’s needed in the CVE Program during the 25 years that CVE records have been reported and disseminated. In fact, one of those board members has been involved with CVE since 1999 (that was the year CVE records started to be disseminated. That year, around 350 CVEs were identified. This year, probably around 45,000 new CVEs will be identified – and those are still just the tip of the iceberg). While the board members haven’t put out a plan for the changes they want to make, I know they’re already working hard on them.

However, there’s something else that the Foundation’s board members have been working on: fundraising. They have been approaching private organizations and government agencies worldwide and are getting a great response. They already have a lot of funds committed; they’re sure they will have more than enough funds available when it comes time to buy out MITRE’s contract next March.

Which brings me back to CISA. They are now making a big effort to make amends for their mistake in April and are campaigning hard to keep the CVE Program under their belt. Their document describes a lot of nice things they pledge to maintain or put in place. Here are three of them.

1. Good governance

Without naming the CVE Foundation, CISA’s document attacks the Foundation’s proposal to take over funding and running the CVE Program – in partnership with MITRE. They call this “privatization” and imply that governance would suffer because the Foundation won’t be able to ensure “conflict-free and vendor neutral stewardship, broad multi-sector engagement, transparent processes, and accountable leadership.” Given the chaotic history of CISA since the new administration came in, including the many threats to close the agency entirely, the complete elimination of entire programs (and their staffs) without any attempt to demonstrate why this was necessary, and most importantly the outright hostility exhibited to longtime employees before they were terminated (as if they were doing something wrong just by being employed by CISA), this assertion seems a little out of place.

2. “Public good”

The second section of CISA’s document includes these two sentences: “Privatizing the CVE Program would dilute its value as a public good. The incentive structure in the software industry creates tension for private industry, who often face a difficult choice: promote transparency to downstream users through vulnerability disclosure or minimize the disclosure of vulnerabilities to avoid potential economic or reputational harm.”

Essentially, this is saying that accepting money from software companies – along with government agencies from all over the world, nonprofit foundations, and many other types of organizations – will inevitably corrupt the CVE Foundation, since software companies face the “difficult choice” of whether to disclose vulnerabilities.

I don’t deny that software companies face that choice, but I can attest that at least the larger software companies (who produce a huge percentage of all commercially available software products) have almost all made the choice for the side of Virtue, since they’re the biggest advocates for (and funders of) software security. In fact, I’m sure that over 95% of CVE records are generated by either

1.      A CNA that works for the software company (or open source community like the Linux Foundation or GitHub) that developed or supports the software (e.g., Microsoft, Oracle, HPE, Red Hat, Cisco, Siemens, Schneider Electric, etc.), or

2.      A CNA that the developer approached to create the record (usually because the developer is in the CNA’s “scope”).

In fact, on the second page, CISA writes, “Many in the community have requested that CISA consider alternative funding sources. As CISA evaluates potential mechanisms for diversified funding, we will update the community.” Of course, given the extreme pressure on the entire federal government to cut costs as much as possible, it’s quite understandable that CISA would want to look for alternative funding sources. Setting aside the question of whether they would be allowed to accept funding from outside the government (see below), it’s worth noting that one of the most likely prospects to help CISA out is…you guessed it: large software companies.

3. Dump MITRE?

Patrick Garrity pointed out in his LinkedIn post that CISA’s document never mentions MITRE. Patrick speculates this means CISA is considering not renewing MITRE’s contract next March, even though they clearly want to keep the CVE program going. Unfortunately, CISA is deluded if they think they can keep the program going by themselves, let alone improve it. MITRE staffs the whole CVE Program now (along with many volunteers, most notably the 470+ CVE Numbering Authorities). They have been running the program since 1999, when two MITRE researchers came up with the CVE idea and described it at a conference.

The MITRE team reports to the Board of Trustees of the nonprofit CVE.org; that board includes representatives from government (including CISA and the National Vulnerability Database - NVD), as well as private industry (as mentioned earlier, the entire board of the CVE Foundation consists of current members of the CVE.org board). While there are certainly things MITRE has not done well in their many years running the CVE Program, it would be hard to find anyone knowledgeable about the situation who says MITRE’s work hasn’t overall been good, if not excellent.

Of course, I’m sure CISA management thinks they can do better than MITRE at running the program. If they drop the MITRE contract, they will presumably have a lot of money available to lavish on their own people. One of those people was Edward Coristine. He was listed as a Senior Advisor to CISA in February, having been installed by the “Department of Governmental Efficiency” or DOGE (Coristine had a famous nickname that I can’t repeat here, since this is a family blog).

Mr. Coristine had success in the cybersecurity field while still in high school (which wasn’t long ago, since he was 19 when he was at CISA. He’s either 19 or 20 today). He must be quite good at whatever he does, since his company, DiamondCDN, was complimented by a customer called EGoodly. They posted on Telegram, “"We extend our gratitude to our valued partners DiamondCDN for generously providing us with their amazing DDoS protection and caching systems, which allow us to securely host and safeguard our website…”

What kind of company, pray tell, is (or was) Egoodly? They were described by Reuters (in the article linked above) as “a ring of cybercriminals”. Perhaps I’m old-fashioned, but it doesn’t seem to me that someone who has done work for cybercriminals should be installed as a senior advisor to CISA (with access to their most sensitive systems, of course). At the very least, one would expect that CISA’s (and DHS’s) management team would have requested a background check first – and if it was refused, they would have refused to give Mr. Coristine access to any system, except perhaps the cafeteria menu system. But it seems there was no background check.

Of course, I’m sure that CISA management last February and March was under tremendous pressure to do whatever DOGE told them to do. Even if DOGE demanded system access for Vladimir Putin, it would probably have been granted. I guess we can at least be happy that didn’t happen.

Nevertheless, I think this incident alone should disqualify CISA from taking over operation of the CVE Program from MITRE next year. The CVE Foundation is much more qualified, experienced, and connected than whoever happens to be in charge of CISA this month. They will be able to raise much more money than CISA could raise on their own – even if CISA were allowed to raise money from private sector organizations (of course, they’re not. That’s known as bribery). And of course, whatever money CISA has today may very well be gone tomorrow. That’s how things happen in Washington nowadays.

Most importantly, the CVE Foundation will build on MITRE’s vast experience, starting with their “invention” of CVE. I know for a fact they won’t let MITRE just continue to do the same old same old, but I also know for a fact that the MITRE staff members I know are quite motivated to make improvements (and they’re continually making them now); they also don’t want the same old same old. Next year, working with the CVE Foundation, they’ll continue to make improvements, and even pick up the pace. The CVE Foundation is making big plans.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com or comment on this blog’s Substack community chat. 

Tuesday, September 16, 2025

A further look at the FCC's cybersecurity requirements for IoT devices.

 

Note from Tom:

I have moved to Substack as my primary blog platform. I will continue to put up all my posts about the power industry and NERC CIP on Energy Central. However, if you want to see all my new posts, as well as my 1200+ legacy posts starting in 2013, please support me by becoming a paid subscriber to my Substack blog. The cost is $30 a year. Thanks! 

Last week, I put up a post that discussed the Federal Communications Commissions Cyber Trust Mark” program, known more generally as a device labeling” program. I opined that a carrot-based” approach to cybersecurity regulation like this one is much better than a stick-based” approach like..well, most other cyber regulations.

I also lamented that it looks like the program might be dead. I said this because, while there was a White House announcement on January 7 of the launch” of the program, there have been no further official announcements about the program since then. It seemed logical to assume that the whole idea was dead, probably for at least the duration of the current administration.

However, my speculation was wrong. On Monday, I got an email from my friend Grace Burkard, Director of Operations for the ioXt Alliance, an organization that has been certifying the cybersecurity of IoT devices for many years. She pointed out that the Cyber Trust Mark program is far from dead. To quote her email, Publicly not much has happened, but a lot of work went into the Stakeholder process from January-June, where 20-25 organizations met to discuss the Technical/Non-Technical requirements, the label design, and the surveillance/renewal requirements.”

It was a huge effort and UL submitted the recommendations[i] to the FCC on June 13. The FCC has since been reviewing all of them and we expect them to publish a Public Notice sometime soon asking for the public's comments.”

Note that UL Solutions (the former Underwriters Labs that many of us know from their seal of approval found on electrical products) is currently the Lead Administrator for the Cyber Trust Mark program, which has a three-tier structure of participants. The Lead Administrator is the top tier. The next tier is the nine Cyber Labeling Authorities (including ioXt), which administer labels under the program. The final tier is the authorized Cyber Labs, which will test and inspect devices for compliance with the labeling requirements once the FCC opens the application process and approves them.

Grace provided me with the documents that UL submitted as their recommendations on June 13. When I get time (hopefully soon), I’ll summarize these and provide further observations on the program. 

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com or comment on this blogs Substack community chat.


[i] If you can’t download the documents from this link (I couldn’t, but Grace can) and want to see them, please drop me an email and I’ll send them to you (they’re public documents, of course),.

 

Monday, September 15, 2025

Upcoming NERC webinar on BCSI

 

Note from Tom:

I have moved to Substack as my primary blog platform. If you want to see all my new posts, as well as my 1200+ legacy posts starting in 2013, please support me by becoming a paid subscriber to my Substack blog. The cost is $30 a year. Thanks!

 

If you’re interested in the NERC CIP “cloud problem”, you may know that I’ve been pointing out for a while that:

1.      Use of BCSI (BES Cyber System Information) in the cloud has been “legal” since two revised NERC standards, CIP-004-7 and CIP-011-3, came into effect on January 1, 2024. The main reason why this is important is that, before that date, NERC entities with high and/or medium impact BES environments couldn’t officially use SaaS (i.e. cloud-based software) products that require BCSI access.

2.      However, since that date, very few (if any) new SaaS products that use BCSI have been introduced, probably because few NERC entities today feel they understand the new and revised BCSI requirements well enough to comply with them.

3.      NERC entities especially need to understand what compliance documentation their SaaS provider will need to give them, since few if any SaaS providers to the power industry today even know they have a role to play in complying with the two revised standards.

Unfortunately, neither NERC nor any of the Regions (to my knowledge) has stepped up to fill this understanding gap using webinars or other means. Until last week, when NERC announced a webinar on the topic to be held on September 29; signup is here. NERC’s description of the webinar is:

The ERO Enterprise will conduct a webinar on September 29, 2025 at 1:00 p.m. Eastern to provide information on protections and controls related to BES Cyber System Information (BCSI) in the cloud. The webinar will review examples, considerations, and best practices. 

Since I’m not involved in this webinar and don’t know the presenters (two CIP auditors, I believe), I can’t tell you in advance whether it will be good or mediocre (I’m sure it won’t be bad). I can say it’s worth watching, if you’re at all involved with this question.

 

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com, or even better, sign up as a free subscriber to the Substack community chat for my subscribers and make your comment there.

 

Sunday, September 14, 2025

A missed opportunity to get cybersecurity regulation right

 

Note from Tom:

From now on, my Substack blog will continue to carry all of new posts, as well as my over 1200 "legacy" posts from 2013 on. Since I will stop posting new posts on Blogspot in the future, I urge everyone to sign up for either a free or paid subscription on Substack now. The cost of a paid subscription is $30 per year or $5 per month. Anyone who can’t pay the $30 should email me, so I can set you up with a free one-year "paid" subscription. Enjoy!

 

Ever since it was mandated in Executive Order 14028 in May 2021, I’ve liked the idea of a “device labeling program”. Briefly, this is a program in which some central authority – usually a government body – authorizes a government agency to issue a certification (called a label but actually a website) of the cybersecurity of intelligent devices. These programs were pioneered in Finland, Germany and Singapore, so this wasn’t a new idea when the Biden White House included it in their EO.

EO 14028 mainly dealt with the cybersecurity of software; it has already led to a profound impact on the software industry. However, the device labeling program has had trouble finding a home. The EO didn’t specify which federal agency would oversee the program, although it seemed to suggest that the Federal Trade Commission would be appropriate (I agreed with that idea at the time, since this seemed like something they should run).

The EO required NIST to take the preliminary steps for the program by developing the requirements on which the labeling program will be based. NIST jumped at that opportunity. They had already put out multiple frameworks having to do with IoT cybersecurity, so it was natural that they would develop the requirements for the device labeling program.

However, NIST went beyond that mandate to try to design the program itself (on the idea that they would administer it later).  It became clear before long (at least to me) that they shouldn’t be in charge of the program itself.

Nevertheless, in 2022 NIST released a new document, NIST.IR.8425. This document seemed to me (and still seems today) to be perfectly aimed at the “consumer” IoT market, which is what the EO had mandated. NIST understood that “consumer IoT devices” can include a lot more than baby monitors and smart lightbulbs. It can also include devices used by small- and medium-sized businesses and government agencies – everything but large enterprises, which have a very different set of cybersecurity concerns.

Why was I so enamored with NISTIR 8425? I’m glad you asked. I see three different types of cybersecurity risk to IoT devices:

1.      Risks due to security measures not implemented in the device. This is how a lot of people think about device security: It’s a question of how the device is put together and what policies are “baked” into it – more correctly, what policies are not baked into it. To certify the device, a lab needs to examine it and answer questions like “Are there default passwords?”, “Can all external access be controlled and tracked?”, and “In case of compromise, is it easy to perform a factory reset?”

2.      Risks due to the lack of specific cybersecurity policies and practices in the environment where the device is installed, such as a factory or a water treatment plant. Questions here include: “Is the network properly segmented so that higher-security zones are protected from attacks originating in lower-security zones?”, “Is communication between zones restricted to defined and protected ‘conduits’, so that all communications are monitored and audited?”, and “Is the safety-related network strongly protected from the operational network?”

3.      Risks due to the lack of specific policies and practices of the device manufacturer, e.g., “Do they sufficiently protect and monitor their development environment, so they are unlikely to fall victim to a devastating supply chain attack like SolarWinds?”, “Do they make patches for serious vulnerabilities available soon after the vulnerability is reported – rather than wait up to three years for the next full device update?”, and “If they are unable to deliver a patch for a serious new vulnerability right away, do they still notify their customers and recommend mitigation steps?”

After reviewing NISTIR 8425, I realize that it addresses just the first and third types of device cybersecurity risk, but not the second. This is undoubtedly because households and small businesses don’t have complex networks that require paying attention to topics like network segmentation or zones and conduits. On the other hand, the ISA/IEC 62443 standard is intended mostly for larger enterprises; it includes measures that address all three types of risk.

In July 2023, the White House announced that the Federal Communications Commission (FCC) would run the device labeling program, now branded “Cyber Trust Mark”. In February 2024, the FCC made public proposed details of the program in a Notice of Proposed Rulemaking. After that, the FCC announced various details of the program; the announcements culminated on January 7, 2025, when the White House announced the “launch” of the program.

What’s happened since that date? Nothing. Of course, January 20 marked the start of the new presidential administration, which since then hasn’t evinced a burning desire to expand what the US is doing about cybersecurity. In fact, CISA has already lost a lot of people and the bloodletting isn’t over yet, although the FCC has lost relatively few employees. However, the FCC has not previously had major cybersecurity responsibilities, so if they were to really implement the device labeling program, they would have to add staff – which might be hard to pull off today, given the current emphasis on downsizing the federal government.

This is a shame. I really liked the approach taken by the FCC, which I described at the beginning of this post. The Cyber Trust Mark program (and device labeling programs in general) takes the carrot approach to regulation, where the regulator tries to encourage good behavior, not just discourage bad behavior. While it’s not always possible to do that, this is one case where it is possible. In fact, the program was based in large part on the Energy Star program, which – from at least one news report that I’ve seen – may be eliminated soon. Energy Star is – or was – quite successful in encouraging consumers to demand energy efficiency in home appliances, as well as in encouraging manufacturers to compete on the basis of efficiency.

In that post, I wrote:

When I think of positive approaches, I usually think of my elementary school classes, where I would get to wear a gold star on my forehead for turning in my homework on time or getting all the answers correct on a spelling test.

I certainly hope we haven’t heard the last of both programs: Cyber Trust Mark and Energy Star!

 

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com or comment on this blog’s Substack community chat.

Wednesday, September 10, 2025

How can certifications be used in the “Cloud CIP” standards?


This post is available to free and paid subscribers to my Substack blog. If you're not already a subscriber, you can sign up when you open the post. 

Thursday, September 4, 2025

Two types of cloud risk to the Bulk Electric System

This post is available to free and paid subscribers to my Substack blog. If you're not already a subscriber, you can sign up when you open the post.