The more labels you have for yourself, the dumber they make you. Permalink

One of Paul Graham’s best.

If people can’t think clearly about anything that has become part of their identity, then all other things being equal, the best plan is to let as few things into your identity as possible.

Most people reading this will already be fairly tolerant. But there is a step beyond thinking of yourself as x but tolerating y: not even to consider yourself an x. The more labels you have for yourself, the dumber they make you.

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, or SEV levels (e.g., SEV-1 being most severe, and SEV-2+ being increasingly less so). Using a standard SEV model, some SEV-1 incidents will be material, and all material incidents will 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.

It’ll be easiest to implement these starting with the first: define what would constitute a material cybersecurity incident for your organization. Don’t overthink it. If it prevents you from making money, serving your customers, or both then that may be a good enough start. Once you’ve defined that and believe you’d know materiality when you see it, move on to defining incident severity level and performing basic incident management, and then evolve your incident management process to include cost.

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 10¹ publicly traded companies with the most KEV entries—appears when normalized by market cap:

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.