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." _________________________________________ Open Source Vulnerability Database (OSVDB) Everything is Vulnerable - http://www.osvdb.org/
This archive was generated by hypermail 2.1.3 : Wed Aug 11 2004 - 01:14:59 PDT