As an IT professional, you’ve no doubt heard the term CVE many times and you probably have a general understanding of it. However, unless your main focus is patching security, you may not know the ins and outs of the CVE system and how to use it. This short guide consolidates the information you need to know CVE system in less than a five minute read.
For as long as software and hardware have existed, so have vulnerabilities. In the most basic sense, these flaws provide someone (a) access they shouldn’t have and (b) the ability to take an action that they shouldn’t be able to take. From data theft to denial of service attacks to ransomware requests, the costs associated with cyber attacks is already in the trillions of dollars and is only going to increase.
Prior to 1999, it was difficult to fully protect yourself against these threats. When new vulnerabilities were discovered, information security companies used proprietary databases, assigned their own naming conventions, and scored severity differently, without the thought of consulting with other vendors. Without industry standards to ensure consistency from one tool to the next, there was no way to know if you had protected yourself from all of the known vulnerabilities that existed.
In 1999, CVE or Common Vulnerabilities and Exposures was launched as a dictionary of common names for known cybersecurity threats in an effort to standardize the classification and severity of known vulnerabilities. It was quickly adopted and by 2000 became the defacto standard for known threats. CVE uses common identifiers so data can be shared with across databases and networks seamlessly. CVE is currently sponsored by the Department of Homeland Security and is maintained by MITRE Corporation.
According the the MITRE website, CVE is:
- One name for one vulnerability or exposure
- One standardized description for each vulnerability or exposure
- A dictionary rather than a database
- How disparate databases and tools can “speak” the same language
- The way to interoperability and better security coverage
- A basis for evaluation among tools and databases
- Free for public download and use
- Industry-endorsed via the CVE Numbering Authorities, CVE Board, and CVE-Compatible Products
CVE delinates two types of threats, vulnerabilities and exposures. A vulnerability is defined as a weakness in the computational logic (e.g., code) found in software and some hardware components (e.g. firmware) that, when exploited, results in a negative impact to confidentiality, integrity, or availability.
An exposure is defined as a system configuration issue or a mistake in software that allows access to information or capabilities that can be used by a hacker as a stepping-stone into a system or network.
HOW IT WORKS
When a new threat is detected, it is reported to MITRE who will research the threat to determine if it has already been identified. If it is a new threat, it will be assigned a CVE Identifier by the CNA (CVE Numbering Authority) and added to the database. MITRE works with large software vendors, such as Microsoft or Adobe, as the CNA for their own products.
The CVE Identifier is unique to the assigned threat. Each identifier begins with CVE, is followed by the four digit year it was assigned, and finally a series of unique numbers for that specific CVE. For example, CVE-2017-123456. Prior to 2014, the final series of numbers was limited to four, which limited the number of CVE’s for a year to 9,999. Unfortunately, there are more than that in any given year, and the restriction on the final series of numbers was removed.
The CVE Identifier contains common reference materials as well as a brief description that provides relevant details of the threat including the product and vendor affected, what versions are impacted, how the vulnerability can be exploited, and the involved code components.
The CVE Master List is maintained by MITRE. However, the CVE identifiers are also used to feed the National Vulnerability Database (NVD) maintained by NIST. In addition to the government, CVE also enables private sector databases to communicate with a common “language”. This provides companies the ability to more effectively address security concerns.
Of note, CVE doesn’t contain the severity, fix, impact, or technical information. CVE is just the standardized identifier with a basic description and references to advisories and reports. The NVD provides additional information and context to the CVE including remediation details, impact rating, severity score, as well as more sophisticated search features that enable users to more easily find specific CVE’s and drill down into the ramifications of them.
It is also important to note that neither MITRE nor the NVD track every threat and related vulnerability that exists. CVE identifiers are only guaranteed for specific vendors. However, anyone can request a CVD for any vulnerability.
CVE has become a cornerstone in cyberattack defense. Providing a standardized identifier enables vendors and companies to deploy patches quickly and accurately. But knowing what CVE’s exist is only half the battle.
The speed at which you patch CVE’s matters.
It takes an average of three months for companies to patch known vulnerabilities, yet the probability that a vulnerability is exploited hits 90% after just 40 days. The old manual patching process has evolved, and automated solutions have made patching CVE’s faster and easier than ever. Which is helpful since patching is becoming a requirement.
Automox has changed the patching game. Their automated platform patches any OS (Linux, Mac, and Windows) as well as any 3rd party software in just minutes a day. The solution is simple, fast, and effective. From free lifetime systems monitoring to fully automated patching to complete patch workflow control, there is an option that meets your needs and your budget.