A Dictionary For Vulnerabilities

 
 
By Larry Seltzer  |  Posted 2003-06-23 Email Print this article Print
 
 
 
 
 
 
 

CVE gives users, vendors, and toolmakers a common vocabulary for vulnerabilities. Unfortunately, the bad guys move quite a bit faster.



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.
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel