A good webinar on vulnerability management, and progress on the CVE front!

This morning (Chicago time), I participated in an excellent webinar that was part of Infosecurity Magazine’s 2-day Online Summit. If you missed it, the recording is already available (separately from the other presentations in the Summit) here. Besides me, the guests included Rose Gupta, Senior Security Engineer of Assured Partners, and Lindsey Cherkovnik, Branch Chief, Vulnerability and Coordination of CISA.

Rose provided a very articulate discussion of the challenge of putting together a vulnerability management program for a medium-to-large-sized organization (especially given the current problems with the NVD). It was refreshing to have a true end user perspective in the webinar, since it’s unusual to hear such a perspective in a security webinar (or even just a security discussion) today.

Lindsey, who is responsible for KEV (a very successful program, IMO) and CISA’s coordination with CVE.org (which CISA funds), revealed some of the big challenges that CISA and CVE.org face. Besides the big slowdown in the NVD that started in February (which is still largely unexplained), there has been a huge increase in the number of new CVEs reported (an estimated 36,000 for 2024, vs. about 29,000 in 2023. That’s on top of about 25,000 in 2022).

Of course, the fact that reported CVEs are increasing is good news, even though it might at first appear otherwise. It’s unlikely that software developers have suddenly had all the knowledge of good coding practices they’ve accumulated over the years wiped from their brains, so they now turn out software that’s loaded with vulnerabilities. Au contraire, the developers are probably a) more aware than ever of weaknesses in their software and b) more willing than ever to inform their customers (and the rest of the world) about a vulnerability after they have made a patch available for it.

Lindsey also pointed to some good news regarding the CNAs – CVE Numbering Authorities. The CNAs are the organizations (now numbering over 400) that assign CVE numbers (e.g., CVE-2024-12345) to new vulnerabilities and create a CVE report for each new CVE. They include large software developers like Microsoft, Red Hat, Oracle and HPE (who mostly report vulnerabilities in their own products), as well as other organizations like GitHub, CISA, MITRE, Amazon and Apache Software Foundation.

The CVE report consists mostly of text when the CNA uploads it to CVE.org; the text describes the vulnerability and identifies one or more products that are vulnerable to it. However, after CVE.org loads the report in their own database, they pass it on to the NVD. Until February 12 of this year, the NVD almost always added three types of machine readable information to the report (a process called “enrichment”):

1.      CWEs (Common Weakness Enumeration),

2.      CVSS (Common Vulnerability Scoring System); and

3.      CPE (Common Platform Enumeration).

In February, the NVD drastically slowed the rate at which they added these three pieces of information to CVE reports that they received from CVE.org. As a result of this slowdown, there are now over 18,000 “unenriched” CVE records in the NVD, which lack these three types of information; these CVE records are essentially invisible to automated searches of the NVD.

For example, suppose a user searches the NVD today for the CPE name of a product they use, and that product has been named in the textual discussion in five CVE reports since February 2024. Since the NVD has enriched fewer than 20% of CVE records this year, that means it’s unlikely the search will locate even one of those CVEs. Thus, the user will go blissfully on their way, thinking their product is quite secure, when in fact it has at least four unpatched vulnerabilities they don’t know about. And since the backlog of unenriched vulnerabilities is increasing almost every day, this problem will only grow over time.

In April 2024, CVE.org (aka the CVE Program) decided that the CNAs should start adding at least the first two of the three items listed above, CWE and CVSS score, to each CVE report that they create. Since the CNA is often the developer of the vulnerable product, it makes sense that they should understand the cause (CWE) and severity (CVSS score) of the CVE described in the report. What was interesting was that the CVE program didn’t require the CNAs to do this, by for example threatening to reject any CVE report that didn’t include those two items.

Instead, the CVE program decided to use positive reinforcement to obtain their goal. Rather than beating the CNAs upside the head to get them to do this, they announced they would publish a “CNA Enrichment Recognition List” every two weeks; CNAs that had included a CWE and a CVSS score on 98% of the CVE reports that they had submitted during the two week period will be recognized in the list published for that period.

In the webinar, Lindsey announced (proudly, I might add) that there were over 100 CNA names on the list for the first two week period, which was released yesterday. Since there are over 400 CNAs now, it might seem that 100 isn’t something to be proud of. However, a lot of CNAs don’t create any CVE reports in a given two-week period. The fact that about a quarter of those who did create one or more reports enriched them 98% of the time is quite impressive. It shows that the CNAs were strongly motivated to do this even though, of course, they received no material reward (don’t be fooled by the fact that the program had “enrichment” in the title. This is the government, after all!).

It's nice to have good news every now and then. It breaks the monotony.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. 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.

I lead the OWASP SBOM Forum and its Vulnerability Database Working Group. These two groups work to understand and address issues like what’s discussed in this post; please email me to learn more about what we do or to join us. You can also support our work through easy directed donations to OWASP, a 501(c)(3) nonprofit, which are passed through to the SBOM Forum. Please email me to discuss that.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.

 

NERC CIP: Why deploying low impact BCS in the cloud shouldn’t be a problem, after all

Until I wrote this post in August, I had always thought there was no problem if a NERC entity utilizes cloud workloads that meet the definition of low impact BES Cyber System – for example, a renewables producer that utilizes cloud-based SCADA software to perform some or all of the functions of their low impact Control Center, even though this same operation would be literally impossible (from a CIP compliance point of view) for a medium or high impact Control Center.

However, in that post, I looked at the most important (in fact, the only) CIP Requirement that applies to low impact BCS: CIP-003-8 Requirement R2. R2 requires the entity with low impact BCS to “…implement one or more documented cyber security plan(s) for its low impact BES Cyber Systems that include the sections in Attachment 1.”

Attachment 1 is found on pages 23-25 of CIP-003-8. It includes five Sections; the Responsible Entity needs to document a plan to address each of those Sections. Using primarily Sections 1 and 3 as examples (although the same argument would apply to Sections 2, 4 and 5 as well), I showed in the post that it would be almost impossible for a NERC entity that utilizes cloud-based low impact BCS to provide the required evidence of compliance at an audit.

The reason I stated for this is the same one I’ve stated for medium and high impact BES Cyber Systems: Since the current NERC CIP requirements were written under the assumption that they would apply to on-premises systems (or else systems located on a third party’s premises that are under the complete control of the Responsible Entity), the required evidence could never be provided by the Cloud Service Provider (or SaaS provider). I concluded that technically, utilizing cloud-based workloads is no more “legal” for low impact BCS than it is for medium or high impact BCS, although I also opined that an auditor was much more likely to give the entity a “pass” for low BCS in the cloud than for mediums or highs. Therefore, I didn’t recommend that anybody rip their low BCS out of the cloud, at least for the time being.

However, on further reflection recently, I realized that this argument doesn’t take into account the unique way in which CIP compliance for low impact BCS differs from compliance for high and medium impact BCS. I’ll warn you that my explanation below requires diving into the deepest and darkest recesses of CIP-002-5.1a:

1.      CIP-002-5.1a Requirement R1 starts by listing six types of “assets” (a term which has never been defined, even though it has played a fundamental role in CIP since version 5 came into effect in 2016. Essentially, it refers to locations in which BES Cyber Systems might be deployed. Any system deployed outside of one of those locations will never be a BCS). R1 states that the Responsible Entity should consider each asset that falls into one of those types “…for purposes of parts 1.1 through 1.3”.

2.      Requirement Part R1.1 mandates that the entity “Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset”. R1.2 mandates the same for medium impact BCS.

3.      However, R1.3 reads quite differently from R1.1 and R1.2. It requires the entity to “Identify each asset that contains a low impact BES Cyber System according to Attachment 1, Section 3, if any (a discrete list of low impact BES Cyber Systems is not required).” In other words, the entity isn’t required to identify low impact BCS at all – just the assets that contain them. In fact, the parenthetical expression warns the auditor not to even ask to see a list of low impact BCS.

4.      Clearly, we need to run down to Section 3 of Attachment 1 (page 16 of the standard) to figure out what’s going on here. However, when we get there, we learn that we’re really identifying BES Cyber Systems after all, not assets, as we were just told. Specifically, we need to identify “BES Cyber Systems not included in Sections 1 or 2 above that are associated with any of the following assets and that meet the applicability qualifications in Section 4 - Applicability, part 4.2 – Facilities, of this standard”. This is followed by the same list of six asset types we saw in R1.

Perhaps the above steps seem confusing to you. They certainly are to me, and they have been since I first studied the language of CIP-002-5 immediately after FERC announced in April 2013 that they were going to approve the CIP version 5 standards and “de-approve” the CIP v4 standards (which they had approved almost exactly a year earlier – that’s another story). Here is what I currently understand regarding identification of low impact BCS and the assets that contain them:

As already noted, Requirement R1 Part 1.3 doesn’t mandate that the entity identify low impact BCS, as R1.1 and R1.2 do for medium and high impact BCS respectively. Instead, it requires that they identify “assets that contain low impact BCS”. It refers them to Section 3 of Attachment 1 for information on how to identify those assets.

But Section 3 starts with the words “BES Cyber Systems not included in Sections 1 or 2 above…” That seems to indicate that the entity needs to start the asset identification process by identifying all the BCS they own or operate, regardless of impact level. Then, they subtract from that universe the high impact BCS they identified in Section 1 and the medium impact BCS they identified in Section 2. The BCS that are left are low impact. That sounds simple. What’s the matter with that?

Of course, the problem here is that R1.1 has already stated that “a discrete list of low impact BES Cyber Systems is not required”. So, it seems we didn’t really start by identifying BCS of all impact levels; instead, we started with the universe of BES assets owned or operated by the Responsible Entity. We subtracted the high and medium impact assets identified in the Section 1 and Section 2 criteria. The remaining assets are low impact.

However, R1.1 indicates clearly that there are no low impact assets (it doesn’t refer to medium or high impact assets either, of course); there are only “assets containing low impact BCS”. It seems clear that a low impact BCS is simply a BCS contained in a low impact asset.

We’re now at the point where we can answer the question of how to determine when a BES Cyber System is low impact. The answer is that a low impact BCS is one that’s contained in a low impact asset. However, a low impact asset is defined as one that contains a low impact BCS. Of course, this is a perfectly circular argument: A low impact asset is one that contains a low impact BCS, and a low impact BCS is one that is contained in a low impact asset.

Of course, this post is about low impact BCS in the cloud. Even though I said in August that I don’t think low BCS are “legal” in the cloud, I started this post by implying that I’ve changed my mind again: I now believe there is no impediment to deploying low impact BCS in the cloud. I say this because of the “definition” of low impact BCS that I’ve just derived: a BCS that is contained in a low impact asset.

Can “the cloud” ever be a BES asset – low, medium or high impact? Since it’s not on the list of BES assets in CIP-002-5.1a R1.1, it clearly can’t be a BES asset now. It might be in the future, but the important thing to know about the future is that it hasn’t happened yet.[i] The point is, since a low impact BCS is always deployed in a low impact asset and the cloud isn’t a low impact asset, a workload that would meet the definition of low impact BCS, if it were deployed in one of the six BES asset types, has no meaning for CIP compliance if deployed in the cloud.

Therefore, there is no such entity as a low impact BCS deployed in the cloud, any more than there are entities like Bigfoot or LGMs (little green men) from Mars. None of these entities is subject to compliance with the NERC CIP standards.

Q.E.D.

Are you a vendor of current or future cloud-based services or software that would like to figure out an appropriate strategy for selling to customers subject to NERC CIP compliance? Or are you a NERC entity that is struggling to understand what your current options are regarding cloud-based software and services? Please drop me an email so we can set up a time to discuss this!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. 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.

---

[i] I don’t think Yogi Berra ever said that, but it certainly sounds like a “Berrism”. Can I patent it?

Webinar: “Tackling rising software vulnerabilities sustainably”

Next Wednesday at 10:45AM EDT, I’ll be participating in a webinar with the above title, which is part of the Autumn Online Summit of Infosecurity Magazine. Here’s the official description of the webinar:

Software vulnerabilities are one of the biggest cyber-threats to organizations, with a record number of vulnerability disclosures in 2023. Zero days are being actively exploited by sophisticated threat groups, as demonstrated by the Ivanti vulnerabilities that were discovered earlier this year.

The continuous process of applying fixes to vulnerabilities across all software stacks is an overwhelming task for many organizations. A new strategy is needed to make vulnerability management a sustainable and effective process.

A panel of experts will discuss best practice approaches for a modern vulnerability management program, tailored to business risk and prioritization.

Sign up (for free) to hear:

·        How threat actors target software vulnerabilities, and why this tactic is often so damaging

·        Vulnerability management challenges across an increasingly complex tech stack

·        How to create a sustainable software patch management program, tailored to business needs.

One of the other two panel members is Lindsey Cerkovnik, Branch Chief, Vulnerability Response and Coordination, CISA. In our prep meeting last week, I brought up the fact that the NVD now has a huge backlog of CVEs lacking a CPE software identifier. Since a CVE report without a CPE name is currently useless for purposes of automated vulnerability management, this means any organization searching the NVD for vulnerabilities applicable to the software products it uses will see only a tiny percentage (less than 1%) of vulnerabilities that might apply to those products, if those vulnerabilities were identified after early February.

Lindsey pointed out that CVE reports can now include purl identifiers for software, so the lack of CPEs today might become a non-issue soon. However, I noted that at the moment, there are a number of roadblocks to including purls in CVE reports. These include the fact that there’s no agreed-upon method for creating a purl for a proprietary software product – although I also noted that the SBOM Forum has two good ideas for how to overcome this problem.

It should be an interesting webinar! If you can’t make it, a recording will be available for anybody to access.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. 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.

I lead the OWASP SBOM Forum and its Vulnerability Database Working Group. These two groups work to understand and address issues like what’s discussed in this post; please email me to learn more about what we do or to join us. You can also support our work through easy directed donations to OWASP, a 501(c)(3) nonprofit, which are passed through to the SBOM Forum. Please email me to discuss that.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.