Who will audit the CSPs?

One question that the current NERC “Risk Management for Third-Party Cloud Services” drafting team is discussing a lot is: What actions need to be taken to verify the security posture of the CSPs? By CSP I mean the two or three major “platform” cloud service providers, not other providers, like providers of SaaS and security services that are usually deployed on one of the major CSP platforms.

This question came up before, when CIP-013, the NERC supply chain cybersecurity standard, was developed. In that case, the answer to the question was quite clear: Like all NERC Reliability Standards, the CIP standards only apply to entities that own and/or operate facilities that are part of the Bulk Electric System (BES). Third parties that supply hardware, software and services that go into medium and high impact BES Cyber Systems do not fall under that designation. They do not have to comply with any of the CIP standards directly, but they do have to cooperate with their NERC entity customers, in some cases by providing them with evidence they need to present at audit.

Will the same consideration apply in the case of platform CSPs once the “Cloud CIP” standard(s) are in place (even though those standards are still years from being enforced)? After all, the platform CSPs will furnish not only the hardware and software on which BES Cyber Systems (and other systems like EACMS and PACS) operate, but they will also furnish the entire environment, including full IT staff, in which the hardware and software operate. Will that consideration “push them over the line” into being regulated as NERC entities?

No, it won’t. It’s qsafe to say that the CSPs will never be regulated as NERC entities, even if a significant amount of generation capacity (e.g., DERs) is deployed on their platforms. Platform CSPs also host systems that control pharmaceutical production. Does that mean they should be regulated by the FDA? Or, since farmers’ tractors now depend on cloud data to determine exactly where to drop seeds, should the CSPs be regulated by the Department of Agriculture?

On the other hand, there’s no question that the electric power industry needs to conduct some oversight of the CSPs. How should this be done, if they aren’t NERC entities? The answer in CIP-013 was for the NERC entities themselves to be responsible for vetting the suppliers. The easiest (and by far the most widely used) method for a customer organization to assess a CSP’s security is simply to ask the CSP about their certifications. If the customer likes the names they hear – FedRAMP, ISO 27001, etc. – those will often be all they want to hear.

Of course, the problem with this method is that it hides the details of the certification audit. The audit may have uncovered an issue with, for example, the CSP’s employee remote access procedures, but their customer won’t learn about this unless they ask to see the audit report. A better assessment method is to ask the CSP for their certification audit report and query them about any issues noted in the report.

However, there’s a problem with this second method as well: I’ve heard employees of two huge platform CSPs that are widely used by the electric power industry state unequivocally that although their employers will be pleased to provide access to FedRAMP, SOC 2 Type 2 or ISO 27001 compliance assessment materials, they can’t provide individualized responses to security queries by NERC entities. In other words, the NERC entity will be able to learn about issues that came up during the compliance audit, but they won’t be able to ask about them.

If certification audits always asked every question that’s relevant to a CSP’s level of security, that would be fine, since the audit report would provide a complete picture of the CSP’s security posture. But is this really the case? In short, the answer is no. Consider the following Tale of Two CSPs:

CSP 1

In 2019, one of Platform CSP 1’s customers suffered a devastating breach in which over 100 million customer records were accessed. The attacker was a CSP 1 employee who had been laid off and was out to get revenge. The attacker took advantage of a misconfigured web application firewall and later bragged online that lots of CSP 1’s customers had the same misconfiguration. In fact, the attacker asserted they had been able to penetrate the cloud environments of over thirty CSP 1 customers by exploiting that misconfiguration.

Of course, the platform CSP can’t be blamed for every customer misconfiguration. However, the fact that at least thirty customers of that one CSP all had the same misconfiguration points to a clear problem on the CSP’s part: They need to offer free training to their customers about avoiding this misconfiguration, as well as any other common misconfigurations (in fact, I ended up meeting with CSP 1 later, after I had made this suggestion in one of my posts. They were receptive to what I said, and I imagine they followed up as well, if they hadn’t done so already).

CSP 2

CSP 2’s problem was that they utilized third party access brokers to sell access to a popular hosted service on their platform, but they hadn’t adequately vetted their security. At least one of these access brokers was compromised, leading to the compromise of about 40 of their customers; all the compromises were on CSP 2’s platform.

But there’s more: This may have been a multi-level supply chain attack. Not only did the compromise of the access broker lead to the successful attacks on 40 customers of the access broker, but at least one of those 40 customers later was the victim of a hugely consequential attack. Have you heard of SolarWinds? I thought so. They were one of the access broker’s customers that was compromised, although I don’t think it’s been proven that the attackers got into SolarWinds through the broker.

There are three important lessons to be learned from these two attacks:

1.      Both CSPs were up to date on their security certifications.

2.      Because the failings of both CSPs should have been discovered in their compliance audits if the right questions had been asked, it’s a safe bet that none of the major security certifications for CSPs addresses either of these failings. Of course, there have been a number of other cloud breaches in recent years whose root causes are also probably not addressed by the major certifications. 

3.      Therefore, it would be a mistake to rely on one or more certification audit reports to provide a good picture of the state of security of a platform CSP.

This leaves us with a problem: Since a certification audit report won’t give us a complete picture of a platform CSP’s security posture, something more should be required by the new “Cloud CIP” standard(s). That is, there will need to be a custom assessment of the CSP that will go beyond the set of questions that the certifications ask. However, the NERC entities can’t be required to ask these questions, since I’ve already pointed out that the platform CSPs are not going to answer questions from individual NERC entities. How do we square this circle?

The only viable path out of this problem that I can see is for NERC itself, or a third party engaged by NERC, to conduct the assessment. Specifically:

a.      A NERC committee (perhaps the current “Cloud SDT”, although it might be a separately constituted committee) will review records of cloud breaches (like the two above), as well as other vulnerabilities and attacks that are only likely to affect the cloud (and thus are not likely to be included in audits based on standards like ISO27001. Based on this review, they will compile a list of perhaps 10-15 questions to pose to a platform CSP. For example, “How do you vet the security of cloud access brokers that utilize your platform?”

b.      Every year, the committee will conduct a new review and update the list of questions.

c.      Every year, NERC or a designated third party will get oral and/or written answers from the platform CSPs to the questions on the current list.

d.      NERC will summarize the responses received from each CSP and share the summaries with NERC entities that utilize the CSP for OT applications.

e.      NERC will not draw from the questionnaire responses any conclusion regarding the suitability of the CSP for use by NERC entities. Each entity will need to decide for itself whether to continue using the services of the platform CSP, based on their questionnaire responses, certifications, news articles, or any other evidence they wish to consider.

There’s only one fly in the above ointment, although it’s a big one: The current NERC Rules of Procedure would never allow what I’ve just described to happen. I would hope (but I can’t be sure) that there will be broad support for making this change to the RoP, but that change will probably need to be made through a separate process; that will take time (probably at least a year). This is why I still doubt that the new Cloud CIP standards will be approved and in effect before 2031 or 2032 – unless some action is taken to accelerate this whole process.[i]

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome, but I would greatly appreciate it if regular readers can donate $20 per year – consider that my “subscription fee”. Thanks!

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. And while you’re at it, please donate as well!

---

[i] It isn’t out of the question that the standards development process could be accelerated, or more correctly, bypassed. There’s a section of the NERC Rules of Procedure that provides for this, but it requires a special vote of the Board of Trustees. However, this is no longer out of the question, since the urgency of making the cloud fully “legal” is growing all the time.

Can you accept risk in NERC CIP?

I haven’t been able to attend many of the meetings of the Risk Management for Third-Party Cloud Services Standards Drafting Team (SDT), which started meeting last fall. However, I was able to attend last Thursday’s meeting. I was quite pleased to see that the team is now starting to discuss some of the weighty issues that the group will have to address as they draft the new and revised standards that will be required to make full use of the cloud “legal” - for NERC entities with high or medium impact NERC CIP environments. The weightiest of these issues are those that have to do with risk.

In many ways, this SDT resembles the CSO706 (“Cyber Security Order 706”) SDT, which in 2011 started drafting the CIP version 5 standards. CIP v5 completely revised the framework that was in place for CIP versions 1-3. Those three versions were based on the concepts of Critical Assets, Critical Cyber Assets, and the Risk Based Assessment Methodology (which was the opposite of risk-based). In CIP v5, they were replaced with new concepts like Cyber Asset, BES Cyber Asset, BES Cyber System, the Impact Rating Criteria, Electronic Security Perimeter, Interactive Remote Access, Intermediate System, External Routable Connectivity, Electronic Access Control or Monitoring System, Physical Access Control System, and more.

Of course, when they started to work on CIP v5 in early 2011, the CSO706 SDT didn’t set out to discuss all of these concepts; instead, the need for the concepts arose from the team’s discussions of the problems with the then-current CIP v3 framework. In fact, the more controversial topics, like External Routable Connectivity and the meaning of the term “programmable” in the Cyber Asset definition, continued to be discussed - sometimes heatedly - in the 2 ½ years between FERC’s approval of CIP v5 in November 2013 and when the v5 standards came into effect (simultaneously with the v6 standards) on July 1, 2016.

So, I was pleased to find out yesterday that the “Cloud” SDT’s discussions have already ventured into the conceptual realm; the changes required to bring the NERC CIP standards into the cloud era (which almost every other cybersecurity framework entered at least a decade ago) will beyond a doubt require both new concepts and fresh thinking about old concepts. Any attempt to just start writing the new (or revised) requirements without first agreeing on the concepts that underlie them is guaranteed to be unsuccessful.

One of the many concepts that came up in Thursday’s meeting was acceptance of risk. Of course, in most areas of cybersecurity, it is almost a dogma that successful practice of cybersecurity requires being able to accept some risks. After all, there will always be some cyber risks that, for one reason or another, an organization can do nothing about. As long as the risk is accepted at the appropriate level of the organization, the organization has done all it can.

During the meeting, someone pointed out the need for NERC entities to be able to accept risk in cloud environments. I pointed out that the requirements in CIP version 1 almost all explicitly allowed for “acceptance of risk”, if the NERC entity decided that was a better course of action than complying with the requirement. However, FERC’s Order 706 of January 2008 approved CIP v1 but at the same time ordered multiple changes; these were at least partially incorporated into CIP versions 2, 3, 4, and especially 5.

One of the changes FERC mandated in Order 706 was for all references to acceptance of risk to be removed. FERC’s reasoning was that the purpose of CIP is to mitigate risks to the Bulk Electric System (BES). Each NERC entity that is subject to CIP compliance is essentially acting as a guardian[i] of the BES, or at least of whatever portion of the BES is owned and/or operated by the entity. Therefore, the risks addressed by the CIP requirements aren’t risks to the NERC entity. This means the entity doesn’t have the choice of whether or not to accept them – their role in the BES requires they not accept them.

However, not accepting a risk isn’t the same as not doing anything about it. Since no organization has an unlimited budget for risk mitigation, any organization needs to decide which risks it can afford to mitigate and which ones it can’t afford to mitigate. Often, those are risks with high impact but very low probability – e.g., the risk that a meteorite will crash through the roof of a building.

If there were a significant probability that this could happen, it would be worthwhile to strengthen roofs enough to deflect meteorites, at least up to a certain size. However, because the likelihood of this event occurring is tiny, most organizations have at least implicitly decided they will be much better off if they allocate their limited mitigation resources toward risks with a higher likelihood – hurricanes, tornadoes, hailstorms, etc.

Until CIP version 5 appeared, there were no CIP requirements that permitted consideration of risk: You had to do X or else face a fine. We now call these prescriptive requirements. With prescriptive requirements, it doesn’t matter if the requirement mandates actions that mitigate only a tiny amount of risk, while neglecting actions that might mitigate much greater risks but aren’t required; the NERC entity needs to perform the required actions first and leave the other actions for later, if time permits.  

One example of a prescriptive requirement today is CIP-007 R2 Patch Management. This requires the entity to apply every security patch released by the patch source for a particular Cyber Asset in scope for the requirement. It doesn’t matter if the software vulnerability addressed by the patch has already been mitigated in that Cyber Asset, for example by a firewall rule; the patch still needs to be applied.[ii]

Fortunately, the NERC CIP community seems to have learned its lesson regarding prescriptive requirements. CIP version 5 introduced the first of what I call risk-based CIP requirements, including CIP-007-5 R3 Malware Protection and CIP-011 R1 Information Protection[iii]. Since then, almost every new CIP standard or requirement has been risk-based.

Given that prescriptive requirements are usually tied to individual hardware assets and it is virtually impossible to pinpoint on which cloud asset a process is running at any one time, it is inevitable that cloud-based CIP requirements will be risk-based. In fact, as I mentioned at the end of this post, it seems to me that implementing risk-based requirements for the cloud may well require changes to the NERC Rules of Procedure. Stay tuned.

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome, but I would like all regular readers to donate $20 per year – consider that my “subscription fee”. Thanks!

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. And while you’re at it, please donate as well!

---

[i] The idea of guardianship is my invention, not something FERC stated in Order 706.

[ii] I believe that most CIP auditors will not issue a notice of potential violation in a case where a NERC entity hasn’t applied a patch that clearly isn’t needed. However, the strict wording of CIP-007 R2 doesn’t allow for such exceptions.

[iii] NERC calls requirements like this “objectives-based requirements”. I think of the two terms as being virtually synonymous, since it’s hard to achieve any objective without considering risk, and risk usually arises along with attempting to achieve an objective.

Purls for commercial software

I’ve written a lot about the purl (Product URL) software identifier in the past year. While I’ve been a big fan of purl since the OWASP SBOM Forum wrote this white paper in 2022, my biggest reason for pushing the idea now is the fact that the only major “competitor” to purl, the CPE identifier used in the National Vulnerability Database (NVD), has in the last 15 months become very hard to find in new CVE records – even though almost every new record used to include one. This is causing huge problems for the vulnerability management community.

As I and others have pointed out in multiple posts over the past year, well over half of new CVE records added to the NVD since February 2024 don’t include a CPE name. NIST, which runs the NVD, has never provided a thorough explanation for this situation. The problem is that a CVE record without a CPE name is literally invisible to automated searches. Thus, someone searching the NVD today for vulnerabilities that apply to a particular software product/version is likely to be shown fewer than half of the vulnerabilities that have been identified as affecting that product/version since early 2024; the other CVEs that apply to the product never show up in a search, since there’s no machine-readable identifier that links their records to the product.

Of course, this isn’t a sustainable situation. When the NVD started having these problems in 2024, the initial reaction among most people in the vulnerability management community was that this was only temporary; it was certain that the NVD would bounce back in a few months. Indeed, the NVD itself put out stories to that effect.

However, fifteen months later the problem has grown, not improved - despite repeated assurances from the NVD that they are on their way to solving their problems. The NVD is no longer saying that, but they are pointing to longer term improvements (like AI) that they hope will save them. At this point, it’s certainly safe to say that the cavalry isn’t going to arrive anytime soon, if ever. What’s Plan B?

I’m pleased to say that the CVE Program is now making noises to the effect that purl is coming as an alternative identifier in CVE records (currently, CPE is the only identifier that can be used). In fact, I’m guessing it may be an option by the end of the year. This means that the CVE Numbering Authorities (CNAs) that create new CVE records will have the option of identifying vulnerable products using purl.

Since a CPE name is only added after a new CVE record has been incorporated into the CVE.org database and downloaded by the NVD (assuming it is added at all, of course), it is still possible that a CPE will be added to the record, even if the record already contains a purl. That’s not a problem, since the CPE and purl can be used as checks on each other. The point is that, once purl is available, there should be fewer CVE records that don’t include a machine-readable software identifier.

The most important concept in purl is that of a “controlled namespace”. This term refers to an important tool for combating the dreaded software “naming problem”, which is perhaps the biggest impediment to automated software vulnerability management. The essence of this problem is that software products are referred to with many different names throughout their lifecycle. Even at a single point in time, employees of a software developer will refer to their products with different names, depending on the division they work for, whether they worked for the predecessor company that originated the product, etc.

CPE names reflect this problem. A CPE must include a product name, but which name to include is left entirely to the discretion of the person that creates the CPE name, usually a contractor working for the NVD. There is no established name for a software product in all contexts, so the contractor is left to simply do their best. However, this means there is almost never a way for a software user to predict with certainty what the CPE name for a product is. Instead, the user will need to look through NIST’s CPE Dictionary – which isn’t a real dictionary, but simply an alphabetical list of every CPE ever created. This provides the contractor with a set of suggestions for the name, but provides no good means to determine what name to use in any instance.   

The situation is very different with purl. A software user that wants to learn about vulnerabilities found in an open source product can usually create its purl by combining the package manager name with the package name and version string in that package manager.[i] These are all pieces of information that the user should have on hand. However, if they don’t, they can easily look them up in the package manager.

What is most important is that, unlike CPE and other identifiers like Social Security number or phone number[ii], the user doesn’t first have to search for the purl in a central database. Since the operator of the package manager makes sure no two packages have the same name, the package manager has a controlled namespace. This means that, no matter who creates a purl for an open source product distributed by a package manager, it will always be the same, because it’s based on the name (and version string, if applicable) in the package manager. Anyone can verify the name at any time, simply by looking in the package manager.

The NVD lists vulnerabilities found in both open source and commercial software products. CPE can identify either type of software. However, today purl primarily identifies open source products distributed by package managers. While there are other vulnerability databases besides the NVD that identify vulnerabilities in open source products[iii], currently the NVD and a group of other databases that are built on top of the NVD are the only vulnerability databases for commercial software products.

Commercial software products are seldom distributed through package managers. Instead, a customer first completes a commercial transaction (e.g., a credit card purchase or a PO) with the supplier. Then the supplier makes the product they have purchased available to them using various means, such as a SaaS subscription, download of the binaries, etc.

With so many ways to distribute a commercial product, the supplier cannot control the product’s namespace through the distribution point, in the same way that the operator of a package manager can control an open source package’s namespace. How will a user learn the purl for a commercial product? Will they have to look it up in a central database, as they do for CPE?

As the OWASP SBOM Forum discussed on pages 4-6 of our 2022 white paper on software naming in the NVD, having to rely on a central database creates many problems. However, on pages 11-12 of that white paper, we described an idea that would allow a commercial software supplier to control the namespace for each of their products, without having to restrict their distribution to a single internet location like a package manager.

Our idea was for the supplier to create a small document – called a tag - that contains the fewer than ten pieces of information required to create a purl for the product. These include at a minimum the supplier name (“software creator”), product name and version string (if used). Because the existing SWID (“Software Identification”) tag standard, originally developed by NIST to be the replacement for CPE as the software identifier in the NVD, could easily accomplish that task, we decided in 2022 to use that as the format for the document. We created a new purl “type”[iv] called SWID.

In that paper, we suggested that, when a commercial supplier releases a new software product or a new version of an existing product, they will create a SWID tag that contains all the required and optional fields for creating a purl for the product. The supplier will make the tag available at least to their customers, but ideally to anyone who wants it (in a subsequent post, I’ll discuss options for sharing the tag).

To produce this blog, I rely on support from people like you. If you appreciate my posts, please show that by donating here. Any amount is welcome. Thanks!

However, based on discussions with industry groups about the purl SWID type, it now appears that using the SWID format for the software tag may have confused people. SWID is described in the ISO/IEC 19770-2 standard. That standard lists around 80 fields for a SWID tag, yet fewer than ten of those fields are required to create a purl (the supplier only needs to fill in those ten fields in their tag, but this might not always be apparent). Another problem is that access to the standard is not free, but costs around $150. Even though there is no need to download the standard just to create purls, some people take offense at even being asked to do so.

For that reason, the OWASP SBOM Forum has decided to lead development of our own tag format – although it will of course be made available to the entire purl and CVE communities, and anyone from those communities is welcome to join us in this effort. It will only include fields that are necessary, or at least optional, to include in the purl for a commercial product.

Regardless of tag format, perhaps the most important party to receive the software tag will be the CVE Numbering Authority (CNA) that creates new CVE Records to report vulnerabilities identified in the product. They will follow the purl specification and create a purl for the product, utilizing the product metadata included in the tag.[v]

When a customer of the product wants to learn about vulnerabilities identified in it, they will create a purl based on the same tag. Given that the tag for a product/version will never change until the version changes (e.g., the product is upgraded to a newer version), a user who received the tag from the supplier will use that to create a purl to search a vulnerability database for the product/version. Barring an error, the user’s purl should always match the purl the CNA used when they created the CVE Record, meaning that purl searches in a vulnerability database will likely have a higher chance of success than CPE searches.

However, there’s an easier way to make sure that a customer (or any other software user) always uses the correct purl: The supplier can publish the purl for a product/version along with the tag. Since neither the purl nor the tag will need to change until the version changes, a customer who has both can just use the purl, and won’t have to create it. However, someone who only has the tag – or someone who wants to validate the purl they’ve been given – will still be able to use it to create the purl.

It’s important to keep in mind the problem: Because CPE is the only software identifier currently used to identify commercial software products, the fact that so many CVE records today don’t include a CPE name means that users of commercial software products are likely to learn about fewer than half of the recent vulnerabilities (i.e., those identified since February 2024) that apply to those products. While there is no magic wand that can fix this problem immediately, the purl identifier, along with the enhancement described in this post, may well be the best permanent solution.

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. And don’t forget to donate!

[i] For example, the purl for the product django version 1.11.1, found in the PyPI package manager, is “pkg:pypi/django@1.11.1”. Note that every purl is preceded by “pkg:”.

[ii] The 2022 white paper referenced earlier discusses the difference between intrinsic identifiers like purl, which don’t require lookup in a central database, and extrinsic identifiers like CPE that do require a database lookup.

[iii] These databases almost all use purl to identify the open source products.

[iv] Every purl has a “type”; there are over 1,000 types, some of which aren’t used very much. For most open source products, the type is based on the name of the package manager where the product is found.

[v] There will probably be one or more tools in the future that ingest a SWID tag and output a purl for the product/version described by the tag.

How can we prevent AI from swallowing the power grid?

 

Note: This is a rewrite of my post of May 17. I did this to make it clearer and to focus on use of power by AI data centers, which I consider the biggest problem with AI today.

One of the biggest problems facing the power industry today is the huge electricity demands of AI data centers. This includes both those in place today and, more importantly, those being projected by data center developers, often without having a firm idea of where the necessary power will come from. Naturally, most of the discussions about this problem have focused either on how to greatly expand power supply, at least in the longer term, or on how to make the data centers more efficient, so they can do what they’re currently doing while using somewhat less power.

However, it seems to me that the real question we should be asking about AI is why it’s placing such huge demands on the power grid in the first place. After all, if “boiling the ocean” is an apt description for anything, it is for language model training, especially when the models are complex, the problems are complex, or the data aren’t well defined. Does all of this come with the territory? That is, if your goal is to recreate intelligence, is it inevitable that sooner or later you’ll have to throw every kilowatt you can find at the problem?

I’m sure this doesn’t come with the territory. After all, it’s well known that an AI model can’t even approach the level of intelligence of the common housecat. Stated another way, if there were a good way to embed a smart AI in a cat’s body, it’s highly unlikely that the AI would be anywhere near as good at catching mice as the cat is.

Of course, many people – including many scientists – used to consider any sign of animal intelligence to be simply pre-existing programming - i.e., firmware inherited from the animal’s parents. However, it’s impossible to hold such a position today. After all, what about chimpanzees that use tools? What about ravens who go back and dig up a bauble they’ve buried if they notice that a human, or another raven, was watching them when they buried it? What about Alex the Grey Parrot, whose last words were “You be good. I love you”? We should all end so fittingly.

For that matter, a living creature doesn’t need a brain to exhibit intelligence. A slime mold, which consists of a collection of disconnected cells without any central intelligence, can seek out fragrant food, even when there’s an uncomfortable barrier in the way. A Venus fly trap can count to five. And it isn’t hard to design cellular automata that exhibit intelligent behavior, even though their electronic “bodies” don’t contain a single carbon atom.

However, let’s suppose that an AI model could outwit a mouse half as intelligently as a cat could. Even if that were true, I would want to know how the likely huge amount of energy required to train that model compares with the tiny amount of energy needed to train the cat’s brain to outwit mice.

After all, it seems likely that the only training that’s required for the cat is the on-the-job training it acquires by watching its mother catch mice – along with presumably some inherited “training” (firmware vs. software). On the other hand, I would bet that training the model would require ingesting millions of documents, videos, etc. Yet the model would almost certainly prove to be nowhere near as successful as the cat for purposes that matter to cats: catching mice and other small mammals.

In other words, there is almost certainly a better way to create artificial intelligence than to boil an ocean of documents. It requires paying attention to what animals do in their day-to-day activities. The intelligence that animals exhibit in those activities goes far beyond the wildest predictions of what AI can do. Even better, no animal needs to consume huge amounts of power to learn how to perform those activities. Maybe, if we just pay attention to what animals can do and then “reverse engineer” how they do it, we will be able to develop truly intelligent systems that will require relatively little power to train or operate.

Here's an example. Let’s say a dog escapes from its home one day and wanders seemingly aimlessly around the neighborhood. There’s no way the dog could remember every tree he watered, every driveway he crossed, every rabbit he chased, etc. Yet somehow, later in the afternoon (perhaps just before dinnertime), he shows up at his home. What’s most remarkable is his master’s reaction to his return: Since the dog wanders off regularly and has never once not found his way home before dinnertime, there is nothing miraculous about his return this time. The master barely notices that his dog has returned.

Yet, it is quite miraculous. The dog doesn’t have a map or GPS. There’s no way the dog can use logic, as we can, to find its way back home. For example, the dog can’t say to itself, “When I was crossing this street a few hours ago and was almost hit by a car, I had just set out from my house. At first, I walked along this side of the street, but I didn’t cross it. Therefore, if I just keep walking along this side of the street for a little while, I’ll probably come home.”

Is there some way the dog can utilize a chain of reasoning like this without “consciously” invoking it? Perhaps, but what is the mechanism behind that result? It certainly can’t be genetic. Even if the dog was born in the neighborhood and has lived there ever since, there’s no known process by which his genome could be altered by that experience.

Could it be training? When the dog was a puppy, did its mother train it to wander around the neighborhood and find its way home? There are certainly animals, like bees and ants, that can find food outside of their “home” (e.g., their beehive) and return to instruct their peers to do the same (the bee sometimes does that by performing a dance that encodes the route it took to find a particularly abundant source of pollen for the other bees). But dogs don’t do that, and of course we’re hypothesizing that the dog was wandering randomly, rather than being in search of food (which he already knows he’ll get at home when he returns).

Yet, the dog did find its way home, and given that this is a common occurrence, it’s clear the dog in question did not utilize any extraordinary power that its fellow dogs (and other types of animals, of course) do not possess. How did it get there?

Of course, I don’t know the answer to this question. However, there are two things I know for sure:

1.      Generative AI is 100% based on statistical relationships between words. The model learns these relationships and uses that data to create whatever content it’s been asked to create. However, the model doesn’t “understand” the words it uses.

2.      Dogs don’t understand words, either. Yet the fact that a dog can demonstrate at least one type of truly intelligent behavior – finding its way home without seeming to have some fixed pattern to follow - seems to indicate there might be a different type of AI that doesn’t require the boiling-the-ocean approach to learning that Gen AI does.

What could explain why the dog can find its way home, if neither genetics nor training can? Again, I can’t answer that question for certain. However, I can point out that infants don’t have any command of words, yet they seem to be able to “reason” based on symmetry. For example, a baby – even a newborn – can recognize an asymmetrical face and react differently to it than a symmetrical face.

It seems that human infants can perform what I call “symmetry operations” without prior experience, and certainly without training. This makes it likely that other mammals like cats and dogs, and especially primates, can also perform those operations. Could symmetry operations contribute to at least some forms of intelligence, including the cat’s ability to outwit mice and the dog’s ability to find its way home?

The point is that various functions (mathematical and otherwise) can be embedded in animals and even plants. An animal might use these functions to solve certain hard problems like, “Given that I’ve been wandering all over the neighborhood this afternoon, how can I find my way home before dinnertime?”

To conclude, how do we create a system that might perform as intelligently as a cat in catching mice, or as a dog in navigation? First, we figure out what ingrained capabilities (like recognizing symmetrical objects) enable this intelligent behavior. Second, we figure out how to recreate those capabilities, either in hardware or software.

In one of my next posts, I hope to examine what are the ingrained capabilities that allow a dog to find its way home. We may learn that dogs are masters of symmetry operations.

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome. Thanks!

 

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.

 

We need more intelligence and less artificiality

 

5/19: I rewrote this post on Monday to make it more concise and emphasize the point about power consumption. You might want to check that one as well.

What is intelligence? The only good definition I’ve heard is that it’s what is measured by intelligence tests. Thus, I strongly doubt there’s any simple way to compare the intelligence of say the smartest AI in the world to the intelligence of a dog or cat. After all, even if there were a good way to embed a smart AI in a cat’s body, is it likely the AI would be as good at catching mice as the cat is? Almost certainly not.

Of course, many people – including many scientists – consider any sign of animal intelligence to be simply pre-existing programming, i.e. firmware inherited from the animal’s parents. This was certainly what I grew up on. I remember one teacher stating with a knowing smile that Doctoral candidates in biology often failed oral exams when they spoke about an animal’s actions as if there were intelligence behind them. In those benighted days, it was simply axiomatic that animals didn’t have intelligence worth speaking of. If any Doctoral candidate mentioned this idea even metaphorically, they were literally jeopardizing their careers.

Of course, it’s impossible to hold such a position today. After all, what about chimpanzees that use tools? What about ravens who go back and dig up a bauble they’ve buried if they notice that a human, or another raven, was watching them when they buried it? What about Alex the Grey Parrot, whose last words were “You be good. I love you”? We should all end so fittingly.

For that matter, a living creature doesn’t need a brain to exhibit intelligence. A slime mold, which consists of a collection of disconnected cells without any central intelligence, can seek out fragrant food, even when there’s an uncomfortable barrier in the way. And it isn’t hard to design cellular automata that exhibit intelligent behavior, even though their electronic “bodies” don’t contain a single carbon atom.

However, what seals the deal for me is the huge amount of energy consumed by training an AI, vs. the tiny amount of energy required to train the cat’s brain to catch mice. After all, it seems the only training that’s required for the cat is the on-the-job training it acquires by watching its mother catch mice. Surely, there must be a better way to train AI than having it ingest literally everything available in English on the internet.

There is a better way. It requires paying attention to what animals do in their day-to-day activities. Those everyday activities go far beyond the wildest predictions of what AI, as currently conceived, could possibly do. Even better, no animal needs to consume huge amounts of power to learn how to perform these activities. Maybe, if we just pay attention to what animals can do and then “reverse engineer” how they do it, we will be able to develop truly intelligent systems.

Here's an example. Let’s say a dog escapes from its home one day and wanders seemingly aimlessly around the neighborhood. There’s no way the dog could keep a record of every tree he watered, every driveway he crossed, every rabbit he chased, etc. Yet somehow, later in the afternoon he shows up at his home. What’s most remarkable is his master’s reaction to his return: Since the dog wanders off regularly and has never once not found his way home before dinnertime, there is nothing miraculous about his return this time.

Yet, it is quite miraculous. The dog doesn’t have a map or GPS. There’s no way he can use logic – as we can – to find his way back home. For example, he can’t say to himself, “When I was crossing this street a few hours ago and was almost hit by a car, I had just set out from my house. At first, I walked along this side of the street, but I didn’t cross it. Therefore, if I just keep walking along this side of the street for a little while, I’ll probably come home.”

Is there some way the dog can utilize a chain of reasoning like this, without “consciously” invoking it? Perhaps, but what is the mechanism behind that result? It certainly can’t be genetic. Even if the dog was born in the neighborhood and has lived there ever since, there’s no proven process by which his genome could be altered by that experience.

Could it be training? When the dog was a puppy, did its mother train it to wander around the neighborhood and find its way home? There are certainly animals, like bees and ants, that can find food outside of their “home” (e.g., their beehive) and return to instruct their peers to do the same (the bee sometimes does that by performing a dance that encodes the route it took to find a particularly abundant source of pollen for the other bees). But the dog didn’t go in quest of anything, and it wasn’t following a fixed set of instructions to get wherever it went.

Yet, the dog did find its way home, and given that this is a common occurrence, it’s clear the dog in question did not utilize any extraordinary power that its fellow dogs (and other types of animals, of course) do not possess. So, how did it get there?

Of course, I don’t know the answer to this question. However, there are two things I know for sure:

1.      Generative AI is 100% based on statistical relationships between words. The model learns these relationships and uses that knowledge to create whatever content it’s been asked to create. However, the model doesn’t “understand” the words it uses.

2.      Dogs don’t understand words, either. Yet the fact that a dog can demonstrate at least one type of intelligent behavior seems to indicate there might be a different type of AI that doesn’t require the boiling-the-ocean approach to learning that Gen AI does. Maybe we wouldn’t have to continue our headlong rush to dedicating most of our electric power infrastructure to data centers. Maybe we could leave a little power for..you know..heating homes and things like that?

So, what could explain why the dog can find its way home, if it doesn’t have a wordless Gen AI model embedded in its skull? Again, I can’t answer that question for certain, but I can point out that infants don’t have any command of words, yet they seem to be able to “reason” based on symmetry. For example, a baby – even a newborn – can recognize an asymmetrical face and react differently to it than a symmetrical face.

How does the baby do this? It’s simple: If the baby has a working knowledge of the mathematics of group theory – the “theory” that underlies symmetry – it will have no problem determining when a face is asymmetrical. Perhaps you wonder how a baby can understand group theory. The answer to that question is simple: it might be similar to how a Venus fly trap can count to five.

The point is that various functions (mathematical and otherwise) can be embedded in animals and even plants. An animal might use these functions to solve certain hard problems like, “Given that I’ve been wandering all over the neighborhood this afternoon, how can I find my way home before dinnertime?”

To conclude, how do we create a system that might perform as intelligently as a cat in catching mice, or as a dog in navigation? First, we figure out what ingrained capabilities (like recognizing symmetrical objects) enable this intelligent behavior. Second, we figure out how to recreate those capabilities, either in hardware or software.

In one of my next posts, I hope to examine what are the ingrained capabilities that allow a dog to find its way home. We may learn that dogs are masters of group theory.

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome. Thanks!

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. And while you’re at it, please donate as well!

 

What I mean by a federated vulnerability database

I’ve been writing about a Global Vulnerability Database for at least a year; my most recent post on that topic is this one. What most people probably think when they hear that term is that I’m proposing one big database that will somehow combine all or most of the existing vulnerability databases. Since a vulnerability database requires machine-readable identifiers for software (e.g., purl and CPE) and vulnerabilities (CVE, OSV, GHSA, etc.), and since different vulnerability databases often use different identifiers, combining these databases into one usually means “harmonization” of the identifiers – i.e., “mapping” multiple identifiers into one.

For example, harmonization of software identifiers might mean mapping CPE names to “equivalent” purl identifiers, or vice versa. Or maybe both purl and CPE names will be mapped to a single third identifier to be named later. But here’s the thing about identifiers, whether we’re talking about identifiers for vulnerabilities, identifiers for software products, or both: They can almost never be cleanly mapped to each other. If they could, why would there be multiple identifiers in the first place?

Here's an example of what I mean: I’ve written a lot about purl and CPE. In this post, I described how a purl usually identifies a particular software package which is made available in a package manager. Since sometimes the same (or closely similar) software is made available in multiple package managers, a purl includes the name of the package manager. This ensures that purls will be unique, since the operator of a package manager makes sure there are no duplicate names; this is called a controlled namespace.

This also ensures that, if a “single” package is distributed through multiple package managers (as sometimes happens), there will be no confusion about which package manager we’re talking about. Since the purl includes the “type” that corresponds to the package manager, the purl always tells us which package manager is being referred to.

This is especially important, because usually there will be slight variations in the product between package managers, even if they’re in theory the “same” package – e.g., OpenSSL version 3.1.8. Since the purl differs between the package managers, and since a vulnerability might be present in the same product in one package manager but not another, it’s important to know which package manager is the source of the codebase your organization uses.

However, there usually will be confusion with CPE, since CPE doesn’t have a field for “package manager”. Sometimes, the person who creates the CPE builds the package manager name into the product name in the CPE, but more often there is no way to tie the CPE name to a particular package manager. This means there’s no way to directly map a purl for an open source product distributed in a package manager to a particular CPE. There are many other examples in which a software product identified with CPE or purl (or OSV, the other major software identifier) can never cleanly map to another identifier.

The same holds true for vulnerability identifiers. CVE is by far the most widely used vulnerability identifier, but there are others like GHSA (GitHub Security Advisories), Snyk ID and OSV. There’s no way to say upfront that CVE XYZ maps directly to GHSA ABC. However, often the organization that identifies a vulnerability will report it as a new CVE Record and at the same time report an ICSA (CISA’s ICS Security Advisory), for example. If the same organization did both reports (and especially if that organization is also the supplier of the product being reported on), there shouldn’t be any objection to the fact that the two identifiers can’t usually be directly mapped to each other. They’re “mapped” because they came from the same organization.

This is all a long way of saying that there’s no such thing as “harmonization” of either software or vulnerability identifiers. And if there’s no harmonization, this means the Global Vulnerability Database (GVD) can’t be a single database.

That’s why I call the GVD a “federated” database. Offhand, that term – federated database – might seem like an oxymoron. A database usually gives a single answer, but a federated database must inherently give multiple answers. However, when I use that term, I mean there are multiple databases, but they (almost) speak with one voice. There needs to be an “intelligent front end” that takes all the queries, routes them to the relevant individual database(s), and routes the answers back to the user.

What the federated database doesn’t do is somehow combine the answers from the different databases into a single “harmonized” answer. When there are different identifiers involved, there can’t be a harmonized answer. But that doesn’t mean it’s not worthwhile to receive multiple answers. 

For example, suppose a GVD user entered a purl for an open source product and requested all vulnerabilities – of all types – that affect that purl. They might get four different responses: 

1.      The front end could query OSS Index, an open source database that supports purl and identifies vulnerabilities using CVE. That query would return one or more CVEs that affect the product designated by the purl.

2.      The front end could query GHSA, which also supports purl. GHSA might return a CVE Record, an OSV advisory, a GHSA advisory, or even two or three of those.

3.      The front end could query OSV, which also supports purl. OSV will usually return an OSV advisory, but it could also return a CVE.

4.      Since the front end is intelligent, it might query the National Vulnerability Database (NVD) and notice that there’s a CPE identifier that probably corresponds closely to the purl in the original query. Therefore, it would conduct a query using that CPE, and return one or more CVE Records that reference that CPE. 

In other words, my Global Vulnerability Database won’t even attempt to deliver harmonized responses. Instead, it will provide you with every response it receives from any of the federated databases. If you’re the sort of person who wants just one answer, you might not appreciate this arrangement. But if you understand that vulnerability management is an inexact science – in fact, it isn’t a science at all – you might appreciate having a diversity of information sources to compare. 

Someday, it may be possible really to harmonize the responses from the GVD, so that people who want a single answer and people who value diversity might both be satisfied. But we’re not there now.

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome. Thanks!

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. And while you’re at it, please donate as well!

 

The importance of being negative

The future of the CVE Program has been discussed a lot lately due to funding problems; I have contributed to those discussions. However, most of my posts that have mentioned the program in the last six months or so have been about software identification – that is, the importance of being able to accurately identify, using a machine-readable identifier, the software product or products that are affected by a vulnerability described in a CVE Record.

Before February 2024, there wasn’t a lot of discussion about the merits of different software identifiers, since the two most widely used identifiers – CPE and purl – each had their own well-understood place in the cybersecurity world. CPE reigned as king of the NVD and the other databases that are built on the NVD; on the other hand, purl was the king (queen?) of the open source world. While the NVD – which is firmly in the CPE camp - tracks vulnerabilities in both open source and commercial software, it isn’t the preferred source for the former, while it’s almost the only source for the latter.

However, in February 2024 the king stumbled. NVD staff (really contractors) drastically reduced, and at times completely stopped, their performance of their most important task: adding CPE names to new CVE Records. The records always include a textual description of the affected products, but there’s no good way to search these. But if the record for CVE-2025-12345 includes a machine-readable CPE software identifier (the only identifier currently used in CVE Records), and an NVD user searches for vulnerabilities using the identical CPE name, CVE-2025-12345 should always show up in the results.

What happens if the CPE name that’s searched for is just a little bit different from the CPE name that’s included in the CVE Record? In that case, it’s likely that no vulnerabilities will be shown to the user. What will be shown? Every NVD user’s favorite message: “There are 0 matching records.”

Will the user be crestfallen when they see this message? Not necessarily. In fact, they might be pleased, since that is the same message they will receive if there are no vulnerabilities listed at all for the product they’re searching for. In other words, the same message might mean both “This product has lots of vulnerabilities that affect it, but you need to keep guessing the CPE name in order to learn about them” and “The product you’re searching for has no reported vulnerabilities.”

The main problem with CPE is that there are lots of ways that the CPE that a user searches for might not match the CPE that is included with the CVE Record. This is because there is no way to know exactly how the NVD contractor that created the CPE name filled in the various fields. These include:

·        The vendor name in the CVE Record is “Microsoft Inc”, but the user searches for “Microsoft Inc.” (i.e., with a period) and finds nothing.

·        The product name in the CVE Record includes the text “mail integration”. The user searches for “mailintegration” and finds nothing.

·        The vendor name is “apache foundation”. The user searches for “apache_foundation” and finds nothing.

The big problem with these near misses isn’t just that the user won’t learn about a vulnerability that might apply to the product they’re searching for. More importantly, they won’t learn whether the search didn’t return results because there in fact aren’t any applicable vulnerabilities, or because they searched using the wrong character string. Humans being inherently optimistic, people are much more likely to apply the former interpretation.

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome. Thanks!

To use the first example, there are two CPE names in the NVD for which the vendor field is “Microsoft Inc”. Suppose that each of these CPEs appears in three CVE Records. A user who searches for “Microsoft Inc” will learn about those six CVEs. However, if a user enters “Microsoft Inc.”, they will see the message, “There are 0 matching records.” Rather than trying “Microsoft Inc” as well, the user may assume there are no vulnerabilities that apply to products sold by an entity with “Microsoft” and “Inc” in its name, no matter what other punctuation the CPE name might contain.

It’s annoying that the NVD makes it so easy for a user to be misled about whether a product is vulnerable. However, it’s much more serious that CPE’s quirks prevent a user from ever being able to make a clear statement that there are no vulnerabilities that apply to a particular product. This is because the user can never be sure whether the message “There are 0 matching records” means they guessed the wrong CPE name or whether it means the product truly has no reported vulnerabilities.

The purl identifier eliminates this ambiguity. Today, purl is mostly used to identify open source software packages distributed through package managers like Maven Central and npm. For example, the purl “pkg:pypi/django@1.11.1” refers to the package django version 1.11.1, which is found in the PyPI package manager.[i]

If someone wishes to verify that this is the correct purl for that package, they can always do so using a simple search in pypi.org. They should never need to guess a purl name, nor to look it up in a central database (like the CPE “Dictionary” found on the NVD website).[ii]

This means that, if a user searches a vulnerability database like OSS Index using a verified purl and finds no vulnerabilities, they can be reasonably[iii] sure there have been no vulnerabilities reported to CVE.org for the package in question. In vulnerability management, the danger posed by false negative findings is much greater than that posed by false positives.

If you receive a false positive finding from a vulnerability database, the biggest problem is that you’re likely to perform work (patching) that was unnecessary. However, if you receive a false negative finding, you won’t learn about vulnerabilities that might come to bite you. Even worse, you won’t usually know about this problem.

If CPE is the only identifier available for CVE Numbering Authorities (CNAs) when they create new CVE records (as is the case today), a user is much more likely to receive a false positive finding from the NVD, and less likely to know they’re receiving it, than if the CNA can alternatively utilize purls in CVE records.

Fortunately, CVE.org is now moving toward adding purl as an alternative software identifier in CVE records, although other things need to be in place before purl can be an “equal partner” to CPE. For one thing, there need to be vulnerability databases that can properly ingest CVE records that include a purl. Fortunately, I’m sure there are at least one or two databases that should be able to do that soon after the new records become available.

This points to the need for an end-to-end proof of concept for purl in what I call the “CVE ecosystem”. The PoC would start with CNAs including purls in CVE records for open source software products

and end with users searching for – and hopefully finding – those CVEs in vulnerability databases. If you would like to participate in or support an OWASP project to do this, please email me. 

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. And while you’re at it, please donate as well!

---

[i] Technically, PyPI is a package registry, not a package manager. However, its function in purl would be the same if it were a package manager.

[ii] That being said, a central database of purls is also being developed. This is to make it easier for people who aren’t very familiar with the purl syntax, especially when more than a few fields are required. There are also free services that will create a purl based on the user’s inputs.

[iii] I say “reasonably”, since it’s possible that the “same” vulnerability has been reported to CVE.org, yet the CPE name that was created for it didn’t have enough information to create a purl. Unfortunately, this is a common occurrence, since CPE has no field for a package manager name (sometimes the person who creates the CPE name includes the package manager in the product name. But that is obviously not part of the CPE specification). In a case like this one, OSS Index (and perhaps other open source vulnerability databases) would probably search for the package in various package managers, but success would not be certain.

Of course, this is just one example of why it is important to include purl as an optional software identifier in the CVE Program.