A Time to Patch

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 timeline 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 timeline 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 (consistantly)? Compare the timelines
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.

You are a subscribed member of the infowarrior list. Visit for list information or to unsubscribe. This message
may be redistributed freely in its entirety. Any and all copyrights
appearing in list messages are maintained by their respective owners.

Reply via email to