Columns

Online Treasure Chest for Security Pros

• By Kathleen Ohlson
• October 1, 2005

Developers tracking the latest product vulnerabilities now have a central location to check—the National Vulnerability Database. The NVD (nvd.nist.gov) is the brainchild of Peter Mell, a senior computer scientist at the National Institute of Standards and Technology. During an interview with ADT, Mell discusses the reasons for NVD and how it will help developers.

Q: There are a lot of sites listing the current vulnerabilities in products. Why create this database?

A: There’re three reasons this database is needed, and we have a unique mission and mandate, unique capabilities and standard support. We’re the only database built on the [Common Vulnerabilities and Exposures] standard.

The unique capabilities driving the search engine is a [collection] of all the resources out there and not just the ones that we provide. The U.S. government resources are within the database, and we have links to around 50,000 industry references. {The Homeland Security Department’s National Cyber Security Division sponsors the NVD.} To view this information, you have to go to the Web sites separately; we’ve integrated [them] into one search engine and a one-stop shop.

We also provide a statistic query engine. You can look at number of vulnerabilities in Microsoft products year to year and chart what they’ve done. The answer is they’ve done pretty well. Since 2002, there’s a huge drop-off in the number of vulnerabilities found in Microsoft products. The industry as a whole—there’s more vulnerabilities found every year.

[NVD’s] mission and mandate is to warn the public about vulnerabilities; our objective is to protect people. We give the entire database for free in XML. They can incorporate it into own database and do whatever they like. We’re not trying to compete with the private sector; we’re trying to make the basic level of information available to everyone.

Q: How do you rate which vulnerabilities are worse than others? Do you go by standards? If so, which ones?

A: We simply rate them high, medium and low severity. High severity is one that allows remote attacks to get some use of machine, or a local attacker that gets complete control. A low severity—a hacker doesn’t gain control of the machine, or they don’t yield information consequential for most corporations. Why is this a good method, or is there a better method? What we’ve done is good, but we’re interested in the [Common Vulnerability Scoring System] put out by the National Infrastructure Advisory Council earlier this year. We’d really like for the standard scoring system to succeed and we look forward to using it.

Q: What about credibility? Who issues these warnings? Are there transparency issues hindering the process?

A: We’re completely synchronized… with the people that run [CVE]. We research each vulnerability and provide an encyclopedia-like vulnerability summary. Then the next question is how do they know? They monitor publicly available information feeds every day and have relations with vendors and security companies.

A company discovers vulnerability internally— but it’s a complex vulnerability, and it may take six months to make a patch. They may wait to announce it when a patch is developed. Hackers find the vulnerability, tell the software company, the software company may delay fixing it, or they can’t make it fast it enough. Hackers create exploit code, and a company works like mad to fix it. A company isn’t making any money if it fixes [the vulnerability], but it loses money if it doesn’t fix it.

Q: Is there something going wrong in the development process that’s causing these vulnerabilities?

A: Yes and no. The yes answer is if you look at my stats engine and look at buffer overflows, you will see that for the past decade the percentage of vulnerabilities has decreased slightly in only the last two years. Buffer overflows have been known for decades; they can be easily fixed by using certain libraries while you’re programming, and certain languages solve that problem for you.

You see this year, 14 percent of vulnerabilities are buffer overflows. My point is that it’s been known for decades, we have tools to solve the problem and it’s an easy problem to fix that a student from elementary school could fix it. It’s a matter of programming education and the use of more buffer overflow safe languages.

The no is that there isn’t a problem. Software companies fixing these problems are declining or remaining steady, while their product suites are expanding and the product complexity is increasing. You would expect to have more vulnerabilities as they become more complex. With some software companies and products, that’s definitely evident, but it shows that they’re doing a good job. I don’t know of any software company that’s completely eliminated vulnerabilities.