RE: CVE Information Sources & Scope
Btw, the list below was definitely not meant to be complete. I also frequently find new (to me) vuln info on Facebook, Google+, many non-security forums, etc, etc.
I also very regularly find unpublicized vulnerabilities in just about every networked device or software I own, including TVs, AV receivers, printers, cable boxes, and even the GM service manual software for my car (old version of Tomcat).
At the end of the day, we'll just need to select the business critical/important technologies to track, and ignore the rest.
Thanks and regards,
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Williams, James K
Sent: Tuesday, October 04, 2011 1:17 PM
To: Art Manion; Mann, Dave
Subject: RE: CVE Information Sources & Scope
Good points, Art. In particular, quicker issuance of CVE identifiers would be great.
As far as monitoring of twitter and blogs goes, we also need to consider monitoring:
* smaller vendor bugtracking systems (I find vulns every week, in widely used software, that never makes it to BugTraq, Secunia, or CVE),
* discussion forums (in a variety of languages, and many require registration),
* and whatever other communication/dissemination mediums become popular (again) next month.
When expanding monitoring of these types of sources, extensive automation is necessary.
Thanks and regards,
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Art Manion
Sent: Tuesday, October 04, 2011 12:54 PM
To: Mann, Dave
Subject: Re: CVE Information Sources & Scope
On 2011-10-04 10:39, Mann, Dave wrote:
> The yard-stick by which to consider these is, does CVE need to capture vulnerabilities from this source in order to full-fill its charter?
IMO, the bigger discussion is the future of CVE, and therefore the future (or revised, reviewed, refreshed) charter.
Is CVE looking for original sources of vul information? Or broad coverage? Or efficient coverage of the "biggest" news in vuls?
The list below is adequate if a bit dated, and duplicative (CIAC changed their name, CIAC and AusCERT only republish vul information IIRC).
We (CERT/CC) have a similarly adequate, but dated list. We're also possibly more interested in the first hints of a new vul report instead of something more authoritative that is ready for a CVE ID.
More new vul information comes out via twitter and blogs these days.
Seems most of it probably reaches the sources below at some point.
Exploit lists (metasploit, exploitdb) are other sources of new vul information, depending on what CVE is looking for.
Back to the bigger picture, I'm on the side of issuing more CVE IDs faster for more vul reports, having reasonable ways to distribute assignment and manage duplicates and false alarms. Accurate analysis is great, but can come a few days after the ID is issued. So my opinion is that CVE should refocus on being *the* leading, fairly comprehensive source of IDs (enumeration) for vul reports. Some other capability can do analysis or add further value later.
Goals, in time order (and as more information about a vul report becomes
1. Assign ID to vul report (More CNAs? More active CNAs?) 2. Manage duplicates, mistakes, etc.
3. Refine assignments (further duplicate resolution, merge/splits, final
4. Accurate analysis
Don't wait for #4 to issue a CVE ID. Users need to be able to talk about "the thing" (a vul report), even (unfortunately) if "the thing"
turns out to be a duplicate or false alarm.
> Government Information Sources
> US-CERT Advisories (aka CERT-CC Advisories)
> US-CERT Vulnerability Notes (CERT-CC)
> US-CERT Bulletins (aka Cyber-Notes)
> DoD IAVAs
> CNA Published Information
> Apple OSX
> Non-CNA Vendor Advisories
> Cisco IOS
> Free BSD
> Open BSD
> Net BSD
> Gentoo (Linux)
> Ubuntu (Linux)
> Mailing Lists & VDBs
> Full Disclosure
> Security Focus
> Security Tracker
> ISS X-Force
> Packet Storm
> SANS Mailing List (Qualys)
> Neohapsis (Security Threat Watch)