The landscape of cybersecurity evolves fast, and you don’t have time to be figuring out whether a vulnerability you’ve uncovered is new or whether it’s already been addressed.
Happily, some smart cookies have figured out how to track all these existing vulnerabilities: They have standardized more than a few languages/frameworks so that known vulnerabilities can be managed effectively.
Some of those key standards include:
- CVSS (Common Vulnerability Scoring System)
- CWE (Common Weakness Enumeration)
- CPE (Common Platform Enumeration)
- CAPEC (Common Attack Pattern Enumeration and Classification)
All of these standards provide a structured and consistent approach to handling known security concerns across various tools, organizations, and industries.
Today, we’re going to focus on CVE (Common Vulnerabilities and Exposures). First, what the heck is a CVE? Is a CVE a vulnerability database?
No, CVE is not a vulnerability database. A CVE is a single vulnerability contained within a vulnerability database, which is managed by the MITRE Corporation.
The CVE program was founded in 1999 and is sponsored by the Cybersecurity and Infrastructure Security Agency (CISA) and the U.S. Department of Homeland Security (DHS). As of August 21, 2024, MITRE has cataloged a staggering 240,830 vulnerabilities in its CVE record list.
To manage such a vast number of vulnerabilities, CVE employs a systematic approach through its CVE Numbering Authorities (CNAs). These CNAs, a global network of 401 vendors, play a pivotal role in the CVE process. They utilize a policy known as the “Counting Process” along with an inclusion decision tree to determine whether a vulnerability should be included in the CVE list and whether a vulnerability may need more than one CVE identifier.
Each CVE comes with its own ID. These IDs follow a specific format to ensure clarity and consistency. They are structured as follows: CVE-{year of the vulnerability}-{number assigned by the CNA}. For instance, a CVE ID like CVE-2019-9893 indicates a vulnerability was discovered in 2019 and assigned the number 9893 by the CVE assignment team and CNAs. You can search for CVEs by their IDs using this link: https://www.cve.org/
On the occasion that a new vulnerability is discovered, it gets added to the database through a submittal process. For a new CVE ID to be generated, it “MUST HAVE” some specific bits of information. New vulnerability submissions:
- MUST identify at least one affected Product using information such as Supplier and Product names, versions, and dates.
- MUST identify at least one Product as “affected” or “unknown” (with the possibility of being affected).
- MUST identify the type of Vulnerability.
- MUST NOT only contain Products with “unaffected” status. This would not be a Vulnerability.
- MUST contain a prose description.
- MUST contain at least one public reference.
- MUST include the appropriate and approved CNA tag(s), if applicable.
- MUST use the “exclusively-hosted-service” tag when all known Products listed in the CVE Record exist only as fully hosted services. If the Vulnerability affects both hosted services and on-premises Products, then this tag MUST NOT be used.
- MUST meet any requirements set by any approved formats or submission mechanisms, for example, the CVE Record Format and the Record Submission and Upload Service (RSUS). Such requirements will be integrated into this document on a periodic basis.
If a submitted vulnerability meets these requirements and is validated as not a duplicate, it gets approved and added to the MITRE vulnerability database.
While MITRE does suggest some other pieces of information that a submission SHOULD have, they are not required. That means the information above is, at the very least, what you can expect to obtain from the database.
Ok cool, now we know a little bit about CVEs and where to find them, but how in the world do we manage all 240,000+ vulnerabilities? Sifting through one by one trying to determine if your PC or Server might be affected would be an insane task.
Luckily a team of individuals have already done this for you, and this is where your big names in vulnerability management come into play. Software companies like Qualys and Tenable, for example, have written automated ways of checking whether your device might be vulnerable to one of the many CVEs in the MITRE database.
The great thing about CVEs is that they provide a standardized “common language” for vulnerabilities. Whether a vulnerability is identified by Tenable, Qualys, or any other platform, using CVEs ensures that everyone is referring to the same issue across different systems.
38North Security can help you manage vulnerabilities, compliance, and other cybersecurity issues. Get in touch with our experts today.
About the Author
