If you ever read security vulnerabilities you eventually run into a notation looking like “CVE-2002-0947.” This is a standard naming convention for vulnerabilities called Common Vulnerabilities and Exposures (CVE). CVE is administered by a company called Mitre, a non-profit company that operates governmental research facilities and other such cool things. In addition to hosting the CVE list, Mitre acts as the editor for aspects of list development. But the most important decisions are made by an editorial board with representatives of security and software firms.
CVE is an important part of modern security efforts but it could be more important. The main function of CVE is to provide security-related programs a common naming set for vulnerabilities on which they may operate. Security products, vulnerability scanners for example, usually provide mappings to CVE names. For example, Netcraft has a network vulnerability scanning service called Netcraft Network Examination which provides mappings to CVE names for the vulnerabilities it finds. The CVE site has a list of CVE-compatible products, including an entry for Netcraft.
The CVE gets its initial reports from a variety of respectable sources, including the SecurityFocus vulnerabilities list and the Internet Security Systems monthly Security Alert Summary. These sources are monitored by a group of Mitre analysts. When a new vulnerability or exposure comes up it becomes a candidate for a CVE entry and gets a CAN entry in the list, such as CAN-2003-9876.
What is an exposure as opposed to a vulnerability? A vulnerability is a bug which results in a security problem; an exposure is a potential security problem resulting from correct behavior. For example, many operating systems and applications will come with default root/admin passwords of “password” or just be blank. This is correct behavior, but its a potential source of trouble.
I cant figure out for sure from the CVE site how a candidate becomes a candidate, and Mitre never got back to me. It looks like Mitre analysts make these decisions on their own, which is perhaps the best way to do it.
But the overly-formal structure of CVE keeps the data in the system old, limiting the usefulness. It seems to take a while before candidates are entered, and it can take months, seemingly ages, before they formally enter the list. Consider the MS SQL Server Slammer worm: the vulnerability behind it is still listed as a candidate, although 3 members of the editorial board have voted to accept it. This is a very old vulnerability.
In many ways the most recent vulnerabilities are the most important ones, so if a vulnerability list is not reasonably up to date its not useful. CVE is pretty out of date. As a result, CVE-compatible programs have to function without CVE names. In a sense this makes the CVE names a redundant capability, but where they exist they do add to the interoperability between security products of different vendors and the ability of administrators to digest reports.
Unfortunately, the mapping of vulnerabilities between different tools is not always very clean, even with CVE. Different tools address CVEs differently; for instance, a vendor patch might address part of a CVE or multiple CVEs. Testers might have to design one test for multiple CVEs or multiple tests for one.
Its interesting to compare this with the informal naming system that exists for viruses. Did you ever wonder how viruses get names like “W32.Sobig.C@mm?” Part of it is a standard system showing the platform and version, but the actual name part is created by researchers from various vendors who exchange information with each other on mailing lists as new outbreaks emerge. As with new elements and species, usually the first researcher to find a virus gets to name it, usually based on some string in or other characteristic of the virus. But if Marconi and Tesla can simultaneously invent radio, surely its possible for two researchers to discover the same virus in the wild. Some have suggested that the antivirus industry needs a committee like CVE to name viruses. I think the last thing we need is a way to slow down virus research.
Security Supersite Editor Larry Seltzer has worked in and written about the computer industry since 1983.
