Brian Krebs has a fantastic post on his blog covering the time it takes for Microsoft to release a patch, and if they are getting any better at it. Here are a few relevant paragraphs from it, but I encourage you to read the entire article. It appears to be a well developed article that is heavily researched and quite balanced. Makes me wonder if his editors shot it down for some reason. If they did, shame on them.
A few months back while researching a Microsoft patch from way back in 2003, I began to wonder whether anyone had ever conducted a longitudinal study of Redmond’s patch process to see whether the company was indeed getting more nimble at fixing security problems.
Finding no such comprehensive research, Security Fix set about digging through the publicly available data for each patch that Microsoft issued over the past three years that earned a “critical” rating. Microsoft considers a patch “critical” if it fixes a security hole that attackers could use to break into and take control over vulnerable Windows computers.
Here’s what we found: Over the past three years, Microsoft has actually taken longer to issue critical fixes when researchers waited to disclose their research until after the company issued a patch. In 2003, Microsoft took an average of three months to issue patches for problems reported to them. In 2004, that time frame shot up to 134.5 days, a number that remained virtually unchanged in 2005.
First off, these are the kind of statistics and research that I mean when I talk about the lack of evolution of vulnerability databases. This type of information is interesting, useful, and needed in our industry. This begins to give customers a solid idea on just how responsive our vendors are, and just how long we stay at risk with unpatched vulnerabilities. This is also the type of data that any solid vulnerability database should be able to produce with a few clicks of the mouse.
This type of article can be written due to the right data being available. Specifically, a well documented and detailed time line of the life of a vulnerability. Discovery, disclosure to the vendor, vendor acknowledgement, public disclosure, and patch date are required to generate this type of information. People like Steven Christey (CVE) and Chris Wysopal (VulnWatch) have been pushing for this information to be made public, often behind the scenes in extensive mail to vendors. In the future if we finally get these types of statistics for all vendors over a longer period of time, you will need to thank them for seeing it early on and helping to make it happen.
This type of data is of particular interest to OSVDB and has been worked into our database (to a degree) from the beginning. We currently track the disclosure date, discovery date and exploit publish date for each vulnerability, as best we can. Sometimes this data is not available but we include it when it is. One of our outstanding development/bugzilla entries involving adding a couple more date fields, specifically vendor acknowledge date and vendor solution date. With these five fields, we can begin to trend this type of vendor response time with accuracy, and with a better historical perspective.
While Krebs used Microsoft as an example, are you aware that other vendors are worse than Microsoft? Some of the large Unix vendors have been slow to patch for the last twenty years! Take the recent disclosure of a bug in uustat on Sun Microsystems Solaris Operating System. iDefense recently reported the problem and included a time line of the disclosure process.
08/11/2004 Initial vendor contact
08/11/2004 Initial vendor response
01/10/2006 Coordinated public disclosure
Yes, one year and five months for Sun Microsystems to fix a standard buffer overflow in a SUID binary. The same thing that has plagued them as far back as January 1997 (maybe as far back as December 6, 1994, but details aren’t clear). It would be nice to see this type of data available for all vendors on demand, and it will be in due time. Move beyond the basic stats and consider if we apply this based on the severity of the vulnerability. Does it change the vendor’s response time (consistently)? Compare the time lines along with who discovered the vulnerability, and how it was disclosed (responsibly or no). Do those factors change the vendor’s response time?
The answers to those questions have been on our minds for a long time and are just a few of the many goals of OSVDB.
At the Black Hat and Defcon security conferences, security community volunteers announce two important new services for the security community and a new partnership for community-based security information sources. The first is the VulnDiscuss mailing list, a new full disclosure forum that compliments the existing VulnWatch accouncement list. VulnDiscuss is meant to foster the discussion of security issues and vulnerabilities by providing a forum for recent security announcements to be discussed. VulnDiscuss will be under moderator control to keep it topical, and access is open to anyone who wishes to participate or observe.
The second is the Open Source Vulnerability Database (OSVDB). OSVDB – A database built and maintained for the community, by the community. The goal of the Open Source Vulnerability Database is to provide accurate, technical, up to date, unbiased, and reliable vulnerability information to the community for free.
The redundant time, effort and money that individual people and companies put into maintaining proprietary databases will be cut by exorbitant amounts by participating in a community that is working toward a common goal. The database will have no commercial licensing restrictions, allowing corporations, businesses, and individuals alike to use this information in any way they wish without having to pay a dime.
The OSVDB project will be debuting with thousands of vulnerability entries provided by databases donated by Digital Defense, Inc., and SensePost. This will provide a strong base to start from, allowing OSVDB to immediately track new vulnerabilities and provide quality data from the start. The continued help of Farm9, NMRC, Neohapsis, Packetstorm, VulnWatch, and many other industry experts is invaluable to this project.
And finally the third is a formal partnership between multiple community-based security information sources: PacketStorm, Open Source Vulnerability Database, Alldas.org, and VulnWatch. The partnership will come together under the Internetworked Security Information Services initiative (ISISi) title, which will remain a non-profit, vendor-neutral entity run by volunteers from the security community. All involved projects share the common goal of providing accessible information security resources useful for researchers, IT Professionals, and the general public, while adhering to a not-for-profit operation model. The initiative allows the projects to share resources and volunteers, eliminate redundancy, and provide a single organized access point to all information which is currently dispersed amongst the individual projects. Current ISISi information is available at www.isisi.org.
“[ISISi] allows us to pool our resources and increase the effectiveness of our respective initiatives while giving information security professionals co-ordinated, higher quality, open source security information than was possible previously.” — Emerson Tan, Spokesman and Ideologue, Packetstormsecurity.org.
“Each of the projects involved in this initiative have committed to remaining independent and not-for-profit, this is a key requirement for participation as we want this to be a community supported effort, for the community by the community.” — Steve Manzuik, founder and co-moderator of VulnWatch.
The individual projects can be contacted at the addresses below.
- VulnWatch. Full disclosure security forums and resources. Press contact: Steve Manzuik, email@example.com.
- Alldas.org. The most complete and up to date mirror of web site defacements that includes statistics and trend analysis. Press contact: firstname.lastname@example.org.
- PacketStorm. Repository of vulnerability and exploit information. Press contact: Emerson Tan, email@example.com.
- OSVDB.org. A database built and maintained for the community, by the community. Press contact: firstname.lastname@example.org.