1. Data acquisition
- keep track of vulnerabilities
- CVE (a good start but it should not be the only source of data)
- vulnerability databases (Bugtraq, OSVDB, Secunia...)
- mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
- other distros (they might have caught something we missed)
- Oval?
- weed out bogus reports (false reports, issues for MS Windows...)
- merge duplicate reports
- update existing reports when needed (exploit availability...)
That's a good summary of the process the Red Hat security response team
currently follow -- with the addition that when we discover something by
tracking that doesn't have a CVE we ensure that it gets a CVE name
assigned to it. Therefore the CVE list can be used as a definitive list
for anything that may affect Red Hat or Fedora (indeed for Fedora tracking
right now we base it off the CVENEW mails)
(OVAL just provides a way of expressing how to detect the presence of some
particular CVE named flaw)
This sounds like a task for CVSS:
I don't believe CVSS really works for open source software (or indeed any
software that is shipped by multiple vendors). Even assigning a Base
score is tricky to do. Is that flaw in ImageMagick where a buffer
overflow could be triggered if you open a malicious file you were given
"remote" or "local"? The attacker is remote. If you argue it's "local"
then how about a flaw in something like xpdf? is that also local?
NVD say these are "user complicit" and marked as local. But doesn't it
depend on if xpdf is associated with pdf files in your web browser? It's
no user complicit if all you need to do is visit some malicious website.
How about if the flaw is in some widely used library like libpng; won't
the local/remote rating depend on exactly what software is using that
library in what ways?
Then you have to take into account the version of Fedora Core or RHEL as
each has different security technologies. Some double-free flaws can lead
to a complete loss of integrity on some systems, but no loss of integrity
but partial availability on others.
We do currently assign severities though, but we use a simple 4-level
scale with defined actions and goals for dealing with each level (for
example we aim to get a fix out for a critical vulnerability within a day
of it being public so we have to start paging people).
Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team
--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list
