User: Password:
|
|
Subscribe / Log in / New account

RHEL, kernel vulnerabilities, and days of risk

RHEL, kernel vulnerabilities, and days of risk

Posted Mar 23, 2005 23:24 UTC (Wed) by mjc@redhat.com (guest, #2303)
Parent article: RHEL, kernel vulnerabilities, and days of risk

The headline metrics in the Security Innovation don't seem to match the stats we keep ourselves, and it would be interesting to see their raw data to see if there is some error in their methods, or perhaps if it's an effect of sampling on the package or vulnerability set they used.

The Red Hat Security Response team publish all our raw data so you can run your own metrics of interest against any set of vulnerabilities. For every CVE name we also give the impact we assigned to the issue (and running the metrics you'll see we do fix things that are most important quicker).

A link to the data and a small perl script to run metrics is available
with a link from http://blogs.redhat.com/people/archive/000201.html

But "days of risk" only tells you a portion of the story: it doesn't tell you how long a vendor knew about an issue before it was known to the public, or how long it was being exploited before being reported. We're trying to be a bit more transparant on that too, if you follow the bugzilla links in RHSA or Fedora Core advisories we've started this year adding "reported" date fields to the status_whiteboard section.


(Log in to post comments)

RHEL, kernel vulnerabilities, and days of risk

Posted Mar 24, 2005 9:11 UTC (Thu) by freddyh (guest, #21133) [Link]

But "days of risk" only tells you a portion of the story: it doesn't tell you how long a vendor knew about an issue before it was known to the public, or how long it was being exploited before being reported.

Indeed. More than often, Microsoft replies to bug-reports with: "no, that's not a problem". 3 Months later they come out with a patch saying: "we found this 3 weeks ago during our own tests". What also sometimes happens is that Microsoft brings out a patch for a problem, that doesn't really solve anything. When people complain, the response usually is: "no, this is a new problem", causing the counter to start all over again.

This *is* a problem, as most people higher up in organisations tend not to look to deep into how things were compared and simply draw their conclusions. "If it's written down, it must be true..." On the other hand, I tend to agree with Jonathan: we are doing very well, but could still do better...

FreddyH


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds