Improving CISA KEV data integrity

3 minute read

tl;dr - Sometimes CISA removes Known Exploited Vulnerabilities catalog records. It would be awesome if they marked them as withdrawn and/or superseded instead.

Background

The Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog has fast become an integral source of vulnerability data consumed by organizations, products, researchers, and notably entities subject to CISA’s mandate to reduce the risk of known exploited vulnerabilities. Widespread adoption of KEV is a key component of the program’s charter:

The KEV catalog sends a clear message to all organizations to prioritize remediation efforts on the subset of vulnerabilities that are causing immediate harm based on adversary activity. Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework . . . Organizations should also consider using automated vulnerability and patch management tools that automatically incorporate and flag or prioritize KEV vulnerabilities.

As the CISA KEV catalog grows in terms of both data and adoption, it’s important that the schema and data support core use cases, including basic analytics and automation.

CISA KEV criteria and data structure

To be included in the catalog, a vulnerability must have a CVE ID assigned, be under active exploitation, and CISA must be able to provide remediation guidance (more on these requirements here).

Once admitted into the catalog, an entry is added based on the published schema. At the time of writing, the KEV vulnerability data structure contains the following keys:

vendorProject 
product 
vulnerabilityName 
dateAdded 
shortDescription 
requiredAction 
dueDate 
knownRansomwareCampaignUse * 
notes * 

* Not required

So, the KEV catalog is a structured data set that is the product of cyber threat intelligence collection and analysis. Structured data ensures predictable outputs, and is meant to enable ingestion into other systems, ranging from spreadsheets to vulnerability management products and frameworks. But “intelligence collection and analysis” implies that, as new information becomes available, the data set may be subject to substantive updates.

Where things break down

As CISA’s understanding of a given vulnerability changes, it may no longer make sense for the vulnerability to remain in the KEV catalog. When that happens, CISA typically does two things:

1. The vulnerability is removed from the catalog.
2. Another related vulnerability may be added or, if a related vulnerability is present, its shortDescription field is updated with a note that looks like this:

A consequence of this is that, when the catalog is exported via JSON or CSV, we cannot assume that data prior to the time of export is still valid. So, some amount of reconciliation needs to take place. Here’s how the above change looks when exporting the catalog via CSV:

The most recent entries as of 2023-10-20:

The most recent entries as of 2023-10-30:

Note that the initial entry for CVE-2021-1435 on row 1023 is no longer present on 2023-10-30, and a new entry for CVE-2023-20273 appears on that row instead (that both entries on row 1023 are related is coincidental).

This happens from time to time, and as you can see in the more detailed screenshot above, CISA does make an effort to reference related vulnerabilities in the shortDescription field. However, these notations are part of unstructured text, and make it challenging to consume and reconcile the KEV catalog on an ongoing or automated basis without error-prone parsing of these description fields (which we cannot assume will always reference related vulnerabilities in a predictable manner, or at all).

Proposal: dateWithdrawn and supersededBy

Once a vulnerability is added to the KEV catalog, it is never removed but can be marked as “withdrawn”.

dateWithdrawn - The date the vulnerability was withdrawn as a catalog entry, in the format YYYY-MM-DD

If a vulnerability is superseded by another (e.g., as CVE-2021-1435 was superseded by CVE-2023-20273), that relationship is made explicit:

supersededBy - The CVE ID that supersedes this vulnerability

Thank you, CISA!

I’ve written and said many times how valuable a service the KEV catalog is to both the public sector and to private industry. The above is not a complaint—far from it.

Making the above changes (or something like them) would improve the integrity of the catalog, ensure that vulnerability records within the catalog are preserved, and that consumers of the catalog (human or computer) aren’t burdened with any ambiguity or reconciliation tasks.

When your product becomes a feature

3 minute read

Having spent a few years using, maintaining, and building security products of every conceivable shape and size, it’s become apparent how uniquely risky it is to invest in building cloud[1] security products.

There are good reasons to build a cloud security product:

• Every aspect of cloud adoption is growing at a meaningful clip and shows no signs of slowing. “Cloud customers” as an addressable market is huge.
• Cloud products are numerous, can change at any time, and are thus easy to adopt but hard to master.
• Cloud security concerns are very real, and cloud customers are willing to spend money on cloud security products to reduce risk.

But there are very real risks from a vendor (particularly startup) standpoint:

• Because cloud security concerns are very real and cloud customers are having to spend additional money on point cloud security products to reduce risk, they are rightfully pressuring cloud vendors to improve the overall security posture of their products.
• A cloud security product cannot, in general, take any preventive or corrective action that the cloud product itself does not support.
• The cloud product vendor can, by definition, see everything that both the end customer and the cloud security product are doing (either directly or via inference).

The net of the above is that, when any cloud security problem becomes enough of a business risk to the cloud product vendor, the cloud product vendor can simply make that problem go away.

The same is true for entire classes of attacks, which a standalone product or team can focus on and solve by playing whack-a-mole, but that the vendor can oftentimes address by making the class of attack go away. Good examples of this include things like secure defaults for cloud-based storage (make the “oops I put it on the Internet” problem go away) and default multi factor authentication (make the “I got phished” problem go away).

Vulnerability half-life and the cloud

The half-life of security vulnerabilities affecting cloud-based products is nowhere near what we’re accustomed to based on decades of complex, multipurpose, customer-managed software. When building for the latter, there will always be enough attack surface and enough configuration and/or version drift to justify relatively expensive security solutions. This means that vendors building security products can expect to be paid back on their investment, and for a meaningful amount of time.

Cloud security problems only live as long as the cloud product vendor wants them to live. And as a result of (healthy) customer expectations—e.g., better security defaults—we can expect both software and configuration vulnerabilities in cloud products to be addressed with increasing efficiency and effectiveness.

Upstreaming of controls

The most effective security controls become features of the platforms they were designed to protect. Years ago, host-based firewall and application control were significant product niches. Over time, they became flagship features of larger third-party security product suites. Today, we can’t imagine an end-user operating system that doesn’t include both of these controls.

Cloud security products are no different. But unlike consumer or end user devices, where solutions may exist but are optional and/or won’t be adopted overnight, solutions to cloud security problems are oftentimes not optional and are literally “adopted” overnight.

The net of this is that many cloud security products run the very real risk of becoming obsolete, sometimes overnight and with little warning. Early entrants into the cloud posture management space felt this, as Amazon and Microsoft moved aggressively into a mix of stronger default posture, log and alert aggregation, and more.

It’s not all doom and gloom

The beauty of cloud products, including cloud security products, is that it’s far easier to build, maintain, and support than on-premise software. So, the cost to prototype, deploy, and support cloud security products may be lower than other types of security products (particularly endpoint- or device-based products, which can be notoriously high friction).

I also said that many cloud security products run the very real risk of becoming obsolete. There are plenty of cloud security needs that are much more durable than wrappers around eventually-native technical controls. In most cases, these will be cloud-optimized products that address evergreen problems, many of them operational. A few examples include:

• Log aggregation and analytics
• Threat detection, investigation, and response
• Incident management

Still, security startups must be thoughtful about the level of investment they’re willing to make and how much of a moat they can establish, understanding that cloud security problems in particular are almost always addressable upstream, and will eventually be addressed upstream.

[1] Cloud is defined for the purpose of this article as the combination of infrastructure- (IaaS), platform- (PaaS), and software-as-a-service (SaaS).

Top initial access techniques from 2019-2022, mapped to ATT&CK

less than 1 minute read

Based on initial access data from dozens of cybersecurity industry reports over the past four years, here’s a visualization of the top five initial access techniques, and how they’ve trended over the years:

More on some of the source data and the top initial access techniques from 2022 can be here.

The data

Rankings by year, used to generate the visualization above.

Not all attack surface is created equal: Why protecting security controls is critical

less than 1 minute read

Any exposed attack surface can be used by an adversary to gain or maintain access to your environment. Security controls are a uniquely high-risk part of your attack surface, because compromising a security control often provides an adversary with privileged and/or uniquely positioned access to the environment. And evidence shows that adversaries are capitalizing on exposed, vulnerable attack surface.

Compromising a security control gives the adversary the ability to perform one or more of the following:

• Manage devices
• Manage identities, including access control and management
• Alter external network access control policies, including: granting remote access to networks, allowing lateral movement between networks, or allowing network egress
• Modify, suppress, or remote logs, alerts, and other evidence of their activities
• Monitor investigative or response activities
• Access sensitive data (particularly problematic if the compromised control issues key material, or performs TLS interception a.k.a. man-in-the-middle)

By contrast, a compromised end user device or endpoint, e.g., a workstation or server, may provide some of the same abilities, but often in a much more limited capacity.

CISA Known Exploited Vulnerabilities (KEV) affecting security controls

3 minute read

Since its inception, I’ve been bullish on the value of the CISA Known Exploited Vulnerabilities (KEV) catalog, along with their periodic analysis of the top exploited vulnerabilities based on the same. The KEV catalog contains a concrete set of trailing indicators that tell you which vulnerabilities should be prioritized for patching or other forms of remediation.

For organizations with a mature, operational vulnerability management program, KEV is a valuable input. For the majority of organizations that do not have a vulnerability management program, it’s an excellent place to start. And if we’re being realistic, it’s a good alternative to doing nothing or addressing vulnerabilities ad hoc.

Enriching the Known Exploited Vulnerabilities data set

CISA makes the KEV data set available via CSV or JSON. I’ve been using the CSV version, which I’ve enriched in a number of ways, including identifying different types of products affected by these vulnerabilities:

• Security - Products designed explicitly to secure devices, networks, or otherwise. This includes endpoint and network protection.
• Edge infrastructure - Products used to connect networks, including protecting the network edge by use of access control lists or mechanisms. This includes most routers, firewalls, email gateways, and other devices that accept inbound traffic from the Internet for inspection or routing.
• Identity and Access Management - Products that provide identity, authentication, authorization, and other access management functions.

The set of products that fall into any of the above categories are treated collectively as security controls.

I also found it helpful to integrate the top exploited vulnerability lists into the same data set, which makes it possible to see some of the breakdowns below, as well as trends.

Known and top exploited vulnerabilities in security controls

Your security controls are a critical cross-section of your attack surface. While we’re busy using our security controls to monitor devices, identities, and other assets under our protection, adversaries are busy exploiting these controls, gaining tremendous leverage over (often many) victims.

As of October 2023, approximately 17% of KEV entries affect a security control.

More concerning than a known exploit in any security control is the appearance of security controls in CISA’s list of top exploited vulnerabilities. 33% of the top 12 exploited vulnerabilities in 2022 affected security controls. If we look at all 42 of the top exploited vulnerabilities in 2022, ~29% (still roughly 1/3) of the expanded set affected security controls.

The sad story of CVE-2018-13379 and CVE-2022-40684 (Fortinet FortiOS)

The top exploited vulnerability in 2022 was CVE-2018-13379, a path traversal vulnerability in the Fortinet FortiOS SSL VPN web portal. As the CVE ID suggests, this was assigned in 2018 but not published until June of 2019. Finding instantces to target was as easy as a Google search for intext:"Please Login" inurl:"/remote/login".

In 2019, a pair of exploits for CVE-2018-13379 appeared in Exploit-DB. One of these exploits was a Metasploit module, making exploitation of these systems push-button easy.

Four years after the CVE was assigned and three years after release of an exploit, CVE-2018-13379 was the most exploited vulnerability of the year, known to be leveraged by a variety of successful ransomware groups.

NOTE: This appears to have been used in conjunction with CVE-2022-40684, and it’s unclear why the former topped the last and the latter received an honorable mention.

What will happen in 2023?

It’s impossible to say what 2023’s top exploited vulnerabilities will be. But ongoing and widespread exploitation of products from Fortinet and Cisco, coupled with their place atop the KEV leaderboard as it relates to security controls, are likely to have a significant impact on top exploited vulnerabilities.

Takeaways

This is cursory analysis, but the quality of the underlying data set coupled with what we know about adversary behavior—in particular, that adversaries will always seek out high impact vulnerabilities for exploitation—tells us a lot about the importance of:

• Keeping security controls up-to-date, first and foremost. It’s best to take away the attack surface quickly and proactively.
• Being doubly sure that known exploited vulnerabilities across your attack surface are patched.
• Continuing to put pressure on software vendors to invest in product security, both proactively but also from an incident response and support standpoint.
• Acknowledging that our security controls are high value, high risk, often highly exposed, and treating them as such when it comes to monitoring and threat detection