[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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:
* pastebin, 
* 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), 
* reddit, 
* IRC, 
* 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,
Ken


-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Art Manion
Sent: Tuesday, October 04, 2011 12:54 PM
To: Mann, Dave
Cc: cve-editorial-board-list
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
available):

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
arbitration)
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 
>   NISCC
>   AUS-CERT
>   CIAC
> 
> 
> CNA Published Information
>   CMU/CERT-CC
>   Microsoft
>   RedHat
>   Debian
>   Apache
>   Apple OSX
>   Oracle
> 
>   
> Non-CNA Vendor Advisories
>   Solaris 
>   Suse 
>   Mandriva
>   HP-UX
>   SCO
>   AIX
>   Cisco IOS
>   Free BSD
>   Open BSD
>   Net BSD
>   Gentoo (Linux)
>   Ubuntu (Linux)
> 
> 
> 
> Mailing Lists & VDBs
>   Bugtraq
>   Vuln-Watch
>   VulnDev
>   Full Disclosure
>   Security Focus
>   Security Tracker
>   OSVDB
>   ISS X-Force
>   FRSIRT
>   Secunia
>   Packet Storm
>   SecuriTeam
>   SANS Mailing List (Qualys)
>   Neohapsis (Security Threat Watch)



 - Art



 
Page Last Updated: November 06, 2012