enterprise security

SecurityTrails Blog · Jun 23 · by Gianni Perez

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

Reading time: 6 minutes
Listen to this article

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.

CVE LifeCycle

The CVE lifecycle (Source: https://www.cve.org/About/Process)

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 issues and, by default, the predicament of having unknown (or undetected) vulnerabilities trivially exposed to external entities. ASI, short for Attack Surface Intelligence, fills these visibility gaps by combining proactive vulnerability scanning with accurate asset discovery, continuous monitoring, and inventory capabilities.

CVE Attack Surface

Such an intelligence-driven approach has one particular goal in mind: to continuously arrive at a risk prioritization profile capable of significantly reducing the expanse between vulnerability discovery and remediation. In other words, ASI is bereft of any kind of historical view approach to the problem of highlighting exposures in favor of real-time artifacts depicting relevant risk factors.

As mentioned, this constant dynamic makes CVE contextualization a priority for defenders and similar stakeholders, knowing that opponents (even those with a modicum of experience) will stop at nothing to achieve their objectives.

To this end, our ASI platform includes CVE detection as one of the core functions, combining a sizable measure of detail such as affected hostname(s), screenshots, vulnerability description, and technical links related to the CVE in question as you venture further into analysis.

ASI Rules

Despite CVE’s vital role in preventing systemic exposures from remaining unchecked, in practice, the technology is only meant to support a subset of the observable attack surface landscape. That is, resilience to cyber threats can only be learned and obtained when ASI, in all its different facets, becomes a catalyst for decision-making.

Beyond CVEs

If having an ever-watchful ‘eye’ over your entire internet-facing tapestry sounds too good to be true; it really isn’t. For example, cloud misconfigurations or forgotten assets, both hallmarks of poor security oversight, can be quickly identified and resolved using ASI.

This holistic understanding of the attack surface landscape has additional benefits, such as the ability to quickly discover inconsistencies leading to open or exposed RDP endpoints and databases, staging subdomains, and self-signed certificates, as well as similar deep context domain and host data like DNS, WHOIS, etc., all within close reach through a single pane of glass.

ASI Explorer

Additionally, ASI is able to detect development mistakes such as the exposure of critical configuration settings (i.e., .env file extensions) through phpinfo pages, data exfills like MySQL dumps in public directories, or the enabling of debug mode in production websites—all valid examples of the importance of seeing the big picture, instead of just focusing on CVE detection.

ASI SnapShot

So, with this level of observability comes the pragmatic alignment of the attack surface ecosystem and misconfigurations/CVE monitoring; after all, once you’ve obtained a complete view of all your public-facing assets, why stop there? Attackers are always lurking, and they are able to make decisions in real time about what systems to target first. Quite often, the focus will be easy-to-pick, unpatched vulnerabilities ready to be exploited—with the help of increasingly sophisticated scanning infrastructure this can be accomplished in the blink of an eye.

Summary

The complexities we face in securing our ever-evolving digital platforms should never prevent us from seeking total awareness of the very systems we’re called to protect. But in 2022, as ASI continues to rise to the challenge of monitoring and safeguarding the attack surface from external threats, forgotten assets and one-offs, shadow IT, or even accidental system exposures, this tightly-knit reality is unfortunately self-evident to a handful of practitioners.

Start truly minimizing your exposure to risk today by going far beyond the classical, but static, score-based validation approach and see if there are any hidden patterns or third-party associations that may lead attackers to your prized environment. Clearly, it all comes down to visibility; essentially, what to protect and how to protect it—that is the essence of ASI as it incorporates long-held standards like CVE whose relevancy is remarkably enhanced when procured via a sound asset and vulnerability management strategy.

Gianni Perez Blog Author
GIANNI PEREZ

Gianni is a technical writer at SecurityTrails and adjunct college cybersecurity instructor with over two decades of infosec experience. He knows firsthand the demands security professionals face, and draws upon his knowledge of IT systems - from administration and software dev, as well as automation, to provide valuable security insights that make a real difference.

X