Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
This is the final post in my 3 part series trying to get an accurate view of disclosed, but unpatched issues for Windows and Linux.
In Part 1, I looked at Secunia "unpatched" warnings and raised the question of whether the unpatched data was accurate and whether the data was tracked consistently between different products.
In Part 2, I acknowledged how challenging it is to get a "now" view of unpatched data for Linux distributions and explored some methods for charting unpatched data over periods of time.
This is Part 3, and we're going to see some of the results from applying the method.
The Contenders - Red Hat Enterprise Linux and Microsoft Windows
Past readers know I maintain my own database of vulnerability data and "first public disclosure" dates and give periodic updates a few times a year on different products. You don't have to have that though, as much of that data you would need is also maintained by Mark Cox of Red Hat here and from advisories.
I'm going to start off with Red Hat Enterprise Linux (rhel) 3 Workstation, and then I'll follow with rhel4ws and Windows XP. And yes, I understand that Red Hat is not Linux, but it is the Enterprise Linux leader, so I think it is a fair representative to choose for Linux distros.
NOTE: To review the methodology at a high level, take a look at Part 2.
Red Hat Enterprise Linux 3 Workstation
Red Hat Enterprise Linux 3 WS shipped on 10/23/2003 and the 3+ years it has been availalable, Red Hat has issued 316 Security Advisories addressing 786 vulnerabilities. I put those in a spreadsheet, along with the disclosure date, which allows me to calculate a "time-to-fix" (TTF) value for each vulnerability. For the 21 vulnerabilities that were publicly disclose prior to the Ship Date, I used the 10/23/2003 date as the disclosure date. [NOTE: If that doesn't make sense to you, post a comment and we can discuss.] Using the TTF values, I created a histogram and cumulative distribution function to identify how far we had to go back in time to have a 95%+ accurate chart - it shown on the left below.
Next, for each day since release up to 1/26/2006, I calculated how many vulnerabilities were already disclosed, but did not yet have a fix and charted it:
Now to put a bit of interpretation on this chart, there were 21 disclosed issues on the day the product shipped and it looks like new disclosures outpaced the patching rate until about early/mid 2005 where rhel3ws reached a peak of 112 publicly disclosed, but unpatched issues. Since then, it looks like their response team has been fixing faster than new issues have been disclosed, though the total has not went below 29 since the start of 2004.
Key Data Table
Having went through the full detail once, let me fast forward to give you a table that shows the key bits of data for each of the 3 products and then I can post up the DVE (daily vulnerability exposure) chart for each of the other two.
GA = General Availability
TTF = time-to-fix
CDF 95%+ = Cumulative data function point indicating the number of days to wait to ensure 95% of disclosed issues will have a fix.
Red Hat Enterprise Linux 4 Workstation
The rhel4ws DVE chart shows a little bit different story from rhel3ws, starting off with 69 disclosed and unpatched issues on the day of release, 2/15/2005. [Note that this would be in addition to the 64 vulns fixed on day 1, as described in this previous post.] The Red Hat security response team has fought a hard battle since release, though, staying ahead of new disclosure and driving down the unpatched issues to a low of 41 in January of last year.
Note that the rhel4ws chart is scaled to the same axis (120) as rhel3ws, so that you can easily make side-by-side comparisons.
Windows XP has been around for 2 years longer than rhel3ws, but has had half as many vulnerabilities so far. Also, the lower average Time-to-fix numbers for XP mean that we can have a reasonably accurate DVE chart up through 8/3/2006. As I did for rhel4ws, the Windows XP DVE chart is scaled to the same height as the rhel3ws DVE chart, making visual comparisons easier. The Microsoft team has kept the unpatched numbers to a fairly tight range over the life of the product, reaching a maximum of 12 unpatched in August 06.
I started off Part 1 of this series saying "Security, perception, reality. What security professional hasn't struggled with the gaps between those three things? Is there anything worse for security than a false sense of security?" and I want to wrap up by coming back to that.
Exposure to unpatched issues is a metric that I'm sure is of interest to professionals trying to explore the potential vulnerability of a given product. Secunia and their customers see value in the statistic, as evidenced by the prominent place unpatched statistics takes on their product advisory pages. Though I've come to acknowledge in this investigation that it is a challenge to get a current and accurate view of Linux distributions, I assert that this reality may be too complex for the common layman to understand, and that they could get an incorrect perception looking at the data commonly available on vulnerability/security web sites.
Using the method here, I think we've explored enough to know that rather than having zero unpatched issues, as may have been the perception, Linux distributions (at least as evidence by the Red Hat products explored) will typically have several unpatched issues that have been publicly disclosed. If you thought differently about your Linux distribution, you may have been suffering from a false sense of security and I encourage you to dig a little deeper and discover the reality for yourself.
Best regards - Jeff