The CVE Approach: A Reductionist Way to Handle the Attack Surface

As recently as the 1990s, the information security industry lacked a fundamental mechanism to deal with the notion of sharing both hardware and software vulnerabilities using any sort of meaningful taxonomy. Previous efforts—largely encumbered by vendor-specific naming convention inconsistencies or by the lack of a community consensus around establishing classification primitives—were centered on multidimensional methods of identifying security problems without regard for interoperability; in a seminal progress report, MITRE will later refer to this budding cacophony of naming schemas as the vulnerability "Tower of Babel." Over the years, a community-led effort formally known as the [Common Vulnerabilities and Exposures (or CVE) knowledge base, will grow to become the vulnerability enumeration product that finally bridged the standardization gap. A (very) brief history of CVE In 1999, as David E. Mann and Steven M. Christey (The MITRE Corporation) were trying to gather momentum for a publicly disclosed alternative to early attempts by organizations at sharing any discovered computer flaws, the internet was already buzzing with a growing number of cybersecurity threats. Consequently, CVE's meteoric rise through corporate networks clearly meant that the industry was ripe for a departure from siloed databases and naming conventions to a more centralized approach involving a unified reference system. Thus, CVE evolved as a practical evaluation tool—a sort of dictionary, if you will—to describe common vulnerabilities across diverse security platforms without incurring the penalty of having a multitude of references attributed to the same exposure. Its subsequent endorsement will come in many forms, including being the point of origin of countless new CVE-compatible products and services originating from the vendor community at large. In addition, as the CVE initiative grew, so did the number of identifiers (or CVE entries) officially received and processed through several refinement phases and advisory boards—from a modest 321 entries back in 1999 to over 185K as of this year; the list keeps growing. A second major catalyst for integration orients us toward operating systems and their inclusion of CVE-related information to deal with software bugs and the inherent asymmetries that arise from product release to patching, as it is well understood that the presence of any high-impact vulnerabilities exponentially increases the probability of a serious breach. Finally, CVEs are the cornerstone of threat-informed defense and vulnerability management strategies in a digital world visibly marked by the presence of miscreants in practically every area, combining these under the banner of the MITRE ATT&CK® framework. This sort of objectivity distills and contextualizes the impact of security vulnerabilities together with adversarial tactics against the risk assessment backdrop, providing defenders with a unique opportunity to plan any mitigation responses accordingly. But, what qualifies as a CVE? In short, a vulnerability becomes a single CVE when the following three criteria are met: The reporting entity, product owner, hardware, or software vendor must acknowledge and/or document the vulnerability as being a proven risk and explain how it violates any existing security policies. The security flaw must be independently fixable; that is, its context representation does not involve references or dependence on any additional vulnerabilities. The flaw affects a discrete codebase, or in cases of shared libraries and/or protocols that cannot be used securely; otherwise, multiple CVEs will be required. After the remainder of the vetting process is complete, every vulnerability that qualifies as a CVE is assigned a unique ID by a body of numbering authorities (or CNAs) and posted on the CVE website for public distribution. CVE and the attack surface With the frantic expansion of the attack surface beginning some years ago came the visibility i...