The 411 on CVE

June 24, 2011
Larry Pesce, manager of information systems security for Care New England, Providence, R.I., cannot imagine doing his job without tools that support

"Well, actually, I can, but I don't really want to," Pesce says.

Yet, despite its name, the CVE — developed and maintained by the federally funded MITRE Corp., Bedford, Mass. — is not commonly used as a reference by security administrators. In fact, although it has been in existence for seven years, it isn't even common knowledge. Gary Miliefsky, founder and chief technology officer of NetClarity, Bedford, Mass., says as recently as six months ago, not one of 30 healthcare information technology executives at a conference in which he spoke had even heard of CVEs.

Why this widespread ignorance of the resource continues is a bit of a mystery to vendors and the government computer scientists working on CVE and its related technologies. Security vendors have already manufactured more than 300 products and services that are certified CVE-compatible, meaning they all refer to the same CVE reference documentation, enabling different vendors' products to interoperate.

Before the CVE list was originated in 1999, vendors would often give the same vulnerability wildly divergent names in an attempt to differentiate themselves from their competitors. This resulted in a ball of confusion for security administrators who were charged with trying to ascertain exactly which vulnerabilities affected which ports and applications.

Cost-effectiveness research done by both end users and vendors has shown CVE-based technology is worth the money. And, despite slow progress in coordinating government efforts to enhance the usefulness of CVE and other core security references, the infrastructure around it has made impressive strides recently.

In August 2005, the National Institute of Standards and Technology (NIST), Gaithersburg, Md., launched the National Vulnerability Database (, which is updated in real time with the latest CVE descriptions plus enhanced analysis, a database, and fine-grained search capabilities.

"In the past couple of years, we've seen a combining of all these efforts, and it's absolutely great to have all that information in one spot," Pesce says. "To me, the CVE and NVD reference is sort of the Rosetta Stone of threats and vulnerabilities, and a good number of the vendors haven't really realized that, or realized the value of that."

Pesce says the CVE-compatible automated penetration testing tool he uses (Core Impact from Core Security, Boston) has saved Care New England — which includes three hospitals, community wellness centers in Providence and Warwick, R.I., and a visiting nurses' association — the cost of hiring one to two full-time network administrators. Pesce says the organization's senior management decided it wanted complete penetration testing of all network resources every quarter to meet Health Insurance Portability and Accountability Act (HIPAA) security due diligence requirements. To do that manually, he says, would have been a monumental task, and also quite dangerous, as homebrewed penetration tests might very well bring a network down accidentally.

Pesce's cost-savings analysis is backed by another industry veteran. Billy Austin, chief security officer of Saint Corporation, Bethesda, Md., which recently introduced a CVE-compatible integrated vulnerability scanning and penetration testing tool, says his company's research shows users who take advantage of the CVE reference infrastructure save an average of 2.5 hours of staff time over doing Internet searches for any given vulnerability's attack vectors, likely impact of an exploit, and remediation steps.

Considering that the latest estimate of vulnerabilities stands at about 17 newly discovered ones per day, according to NIST senior computer scientist Peter Mell, those hours can add up quickly.

Where's the momentum?

Mell, the NVD project lead and creator, says the new NVD/CVE capabilities are a significant step ahead for network administrators.

"End users need a way to prioritize the constant stream of vulnerabilities that are coming out," Mell says. "IT organizations need to know the answer to, 'Do I panic right now?' or, 'Can this be part of my usual configuration management update I can do in two weeks?' By integrating the NVD and CVE, we've made a significant step toward helping people to do that.

"But — and it's a big but — what we're doing is helpful, but not revolutionary in terms of how the industry does things."

Mell thinks the revolution, in which NVD and CVE could be major weapons, would also include automated compliance checking and configuration, according to the relative severity of any discovered vulnerabilities. That could be accomplished using OVAL (Open Vulnerability and Assessment Language) — also being developed by MITRE and XCCDF (Extensible Configuration Checklist Description Format) — the XML-based checklist technology developed by NIST and the National Security Agency.

XCCDF is meant to simplify the security checklist requirements for software applications used by federal agencies, mandated by Congress in the Cyber Security Research and Development Act of 2002. Such a dynamic deployment would go far in providing HIPAA auditors proof that a user's network was regularly updated to mitigate any security flaws.

"So you could link NVD and the checklist together and get both sets of information," Mell says. "If we could get to that point, then that would be an industry-changing moment, where you could run a tool and automatically find the vulnerabilities, find the misconfigurations, and score yourself. Then people could truly show lots of due diligence."

In fact, one federal agency, the Department of Defense, has taken the formal step of requiring that information assurance vendors supply CVE- and OVAL-capable products, and MITRE engineers have outlined the way these technologies would interact with XCCDF in automated machine-to-machine vulnerability mitigation operations. Mell says he is unaware of any such initiative at the Department of Health and Human Services, though he says several HHS staff members do subscribe to the NVD information feeds. (An HHS spokeswoman requested questions via e-mail but did not answer them.)

All bark, no bite

In the civilian market, both Austin and Miliefsky say they have seen little or no enforcement security action from HHS, a full year after the HIPAA regulations took effect, and that might be affecting the rate of market pickup on CVE-compatible tools.

"In banking, a slap on the wrist is so severe that the banks are really ahead of everybody else in understanding what a CVE is and using it, but in healthcare there have been no real fines," Miliefsky says, "no intentions to shut down providers who aren't compliant — none of that happens."

"I talk to a bunch of small banks and small healthcare organizations where they receive nothing but a port scan, which is not sufficient," Austin says, "and where the auditors have actually passed it, it's nothing more than to see what ports are open. Some people don't even really care about what's in the report, whether it's a CVE number, or whether the vulnerability data is there or not. All they care about is clicking the little checkmark button on the HIPAA requirements to say they've now done their assessment."

Austin says the security community's cooperative effort has not been appreciated by the intended beneficiaries of the CVE work.

"What typically happens in the technology market space is, the end users are crying for vendors and the enforcers and government agencies to all come together. Well, here's what's funny — we've all come together, and now we're waiting for the market and the people who started this initiative to come enforce it and put it in place. We did what HHS asked from a technological perspective."

Pesce says the CVE- and NVD-compatible tools are valuable enough that responsibility to advance these public resources should not fall on government agencies.

"The customer should tell vendors, 'This is a valuable resource. It saves me time and gives me more reason to buy your product,’” he says. "You'd think a good security professional should know about this stuff, and that security professionals will be educating other security professionals."

Author Information:Greg Goth Greg Goth is a freelance writer based in Oakville, Conn.