Defining security outcomes

I’ve long viewed incidents as one of an organization’s very best tools for measuring everything from cybersecurity effectiveness, to overall operational maturity. Unsurprisingly, I’d also recommend using incidents to define and understand security outcomes (i.e., whether your costly security-related investments are getting the job done).

Here are three relatively simply incident-centric cybersecurity outcomes to consider:

  • The one security outcome to rule them all is the material cybersecurity incident. Although this term was popularized by the U.S. Securities and Exchange Commission, every organization—regulated or not—defines “materiality” for itself. This creates a neat, tidy, binary condition: either you have had a material cybersecurity incident or you have not.

  • Beyond material incidents, incidents at-large can be categorized using organization-specific definitions or common severity (SEV) levels (e.g., SEV-1 being most severe, and SEV-2+ being increasingly less so). If using a standard SEV model, some or all SEV-1 incidents will be material, and all material incidents should be classified as SEV-1.

  • A third outcome is cost per incident, which encompasses the expenses of technical controls, personnel, and external partners. Typically, lower-severity incidents incur lower costs, while costs rise exponentially with severity.

8-K filings for material cybersecurity incidents should require disclosure of all cybersecurity controls (software and services) in place when the event occurred.

January 17, 2025

Known exploited vulnerabilities by market cap

It’s easy to criticize vendors for the number of known exploited vulnerabilities in their software, but raw counts lack context. A company with 100 software products will naturally have more vulnerabilities than one with a smaller portfolio. However, product count alone doesn’t account for a company’s size or resources.

Microsoft is a prime example: as of this writing, it accounts for 311 entries in CISA’s Known Exploited Vulnerabilities (KEV) catalog—25% of all entries. This is often dismissed because of Microsoft’s size and expansive product portfolio. However, a common counterpoint is that its scale affords the company more resources for product security than most.

How do we perform a simple comparison of product security effectiveness across organizations of various sizes, making different types of products for different types of customers? We use the great equalizer: United States Dollars.

Here’s how the CISA KEV leaderboard—specifically the 101 publicly traded companies with the most KEV entries—appears when normalized by market cap:

Vendor KEVs Market Cap (USD) KEVs per $1B Market Cap
Adobe 73 $181,670,000,000 0.402
Cisco 74 $236,300,000,000 0.313
Fortinet 15 $70,890,000,000 0.212
Atlassian 13 $64,200,000,000 0.202
Microsoft 311 $3,090,000,000,000 0.101
Palo Alto Networks 11 $114,300,000,000 0.096
Oracle 38 $437,190,000,000 0.087
Samsung 11 $245,566,881,889 0.045
SAP 11 $323,720,000,000 0.034
Google 73 $2,330,000,000,000 0.031
Apple 77 $3,510,000,000,000 0.022
D-Link 20 $404,068,003 0.000

Updated 2025-01-15 // Notes: Google = Google + Android; D-Link is a conversion from TWD; Samsung is a conversion from KRW

Nothing’s perfect, but this approach offers a fair way to compare product security effectiveness without relying on subjective or manipulatable criteria. A known exploited vulnerability represents an objectively poor security outcome. Using market cap as the denominator avoids debates over distinctions like product lines, software versions, platforms, and more.

  1. Depending on when this was last updated, there may be more than 10 companies listed due to a tie. 

Cybersecurity stat of the day: The average delta (in years) between CVE assignment and addition to the CISA Known Exploited Vulnerability (KEV) catalog is 2.8 years. 🤯

January 14, 2025