[ISN] Databases, Tools Aiming at Software Vulnerabilities

[InfoSec News]

http://www.kpmginsiders.com/display_search.asp?content_id=449029

Databases, Tools Aiming at Software Vulnerabilities
By Dave Pelland, Managing Editor, Technology Insider
July 14, 2004

As the growth of known software vulnerabilities shows no sign of
abating, databases and management tools are emerging to help network
administrators automate the identification and triage process.

The tools, which include hardware or externally provided services,
typically perform functions such as conducting an inventory of a
network's technology assets and notifying administrators about
emerging vulnerabilities.

This generally involves describing a software flaw and its potential
effects, as well as providing information about any patches or
technical workarounds needed to mitigate the exposure.

"At a basic level, you get the data, figure out if or where it affects
you, and decide whether you need to fix it or not, based on your
environment," says Rick Trapp, VP of product management for Computer
Associates' vulnerability management unit.

Vulnerability management tools obtain information about emerging
problems from numerous sources, including software providers, Web
sites aimed at security professionals and hackers, online newsletters,
and databases maintained by security vendors and non-profit
organizations.

In addition, security researchers look for surges in hacking activity
that may indicate attempts to exploit a previously undiscovered
vulnerability. The role of vulnerability databases has been expanding
over the past few months. New entities have emerged, such as the
United States Computer Emergency Readiness Team (US-CERT) Web site,
operated by the Department of Homeland Security and the private
sector. The Open Source Vulnerability Database (OSVDB) has joined
established resources such as CERT Coordination Center at Carnegie
Mellon University and the Common Vulnerabilities and Exposures (CVE)
list maintained by the non-profit Mitre Corporation.

Despite its name, OSVDB examines commercial software as well as open
source applications. The "open source" designation refers to its use
of volunteers compiling information, much in the way open source
programs are examined by a community of developers.

Administrators will check the databases when network performance
degrades after an incident, or during routine system maintenance.

"From what I have seen, most security folks use vulnerability
databases for convenient reference," says Brian Martin of OSVDB. "In
some cases, they use it to help during auditing or certification [to
verify that] the system doesn't have any of the documented
vulnerabilities."

Where things become a bit trickier for databases is deciding how to
distinguish between the vulnerabilities that are public knowledge and
those that only a few researchers may have uncovered. Database
managers have to weigh disclosure of these so-called day-zero exploits
-- for which a mitigation strategy or patch have not been developed --
carefully to avoid alerting hackers.

"It gets into a delicate balance," Trapp says. "Say we know there's
something out there that can be exploited, but there's no indication
of exploit activity. What do you do with that?"

Trapp says if researchers uncover a vulnerability, they contact the
vendor that released the product to see if the company is aware of it,
if they've seen any exploits and if they've developed a patch. If a
problem is not disclosed publicly, Trapp says they'll avoid giving
hackers a head start on developing malicious code by delaying any
information release until a patch is available.

OSVDB's Martin agrees on the importance of withholding information
about unpatched vulnerabilities.

"One rule that governs the information we make available is that it
must already be public in another forum," Martin says. "We will not
publish information that has not been sent to a vendor [without giving
them] adequate time to assess the issue, unless it has already been
published."

Perhaps more important than their role in notifying administrators
about a vulnerability is the databases' ability to provide information
about resolving it -- either by providing a link to the vendor's patch
or, if a patch has not been released, workarounds to help reduce
problems.

"If a site doesn't tell you how to fix a solution, they aren't
providing what you need," says Donald L. Pipkin, a security consultant
and trainer and author of "Halting the Hacker."

"Providing information about the solution is critical to the
legitimacy of these organizations. If a database is not cooperating
with vendors or linking to the solutions, how legitimate are they?"

According to Computer Associates' Trapp, some information providers
might release information about an unpatched vulnerability or provide
code that enables an exploit to be developed, ostensibly for testing
purposes. But he says using such exploit code to test a network is
similar to using gasoline and matches to test if something is
flammable.

Organizations maintaining vulnerability databases and lists are
increasingly cooperating by sharing information and formatting data in
compatible formats so users of vulnerability tools can coordinate
reports of software flaws from a variety of sources.

"If you go back seven or so years ago, when we first started
collecting vulnerability data, the first thing that would happen when
we contacted a vendor would be the vendor going into denial," Trapp
says. "Now instead of denial, most have become cooperative and it's
viewed as a responsible industry action to help protect the
environment."

Martin says this cooperation among information sources is integral to
protecting networks.

"We have been in constant contact with members of CVE regarding our
databases, working together to cross-reference each other," Martin
says. "Technically, there isn't a need to coordinate with them, but we
feel strongly that it benefits all parties to keep a line of
communication [that] will only help each database improve."