Re: Wireless VE

[Andy Balinsky <balinsky@cisco.com>]

They claim they won't duplicate CVE, that they're trying to fill in gaps 
that CVE doesn't cover (like protocol-level vulns):
" WVE was inspired by other systems like CVE and OSVDB which catalog 
vulnerabilities. While these systems contain entries related to specific 
application issues with wireles devices such as vulnerabilities in their 
SNMP or web-based management interfaces, there are few entries which 
cover issues inherent in the wireless protocols themselves. These 
databases tend to be focused on the application layer, whereas most 
wireless vulnerabilities manifest themselves lowever in the stack, or 
are intrinsic in the medium or the protocol. WVE is designed to augment 
these existing databases—not to replicate or replace them—by focusing on 
the issues that they are not covering."

And they don't seem to have an explicit Exploit->Vulnerability mapping, 
though they do have a "References" field, and at least some of the 
exploits list WVE entries that are the related Vuln, but they don't 
identify them as such.

Andy

Alfred Huger wrote:
> 
> 
> 
> I've not yet had a chance to dig in to the WVE but I am not, as Pascal 
> mentioned, all that enthused about another mapping. For Symantec's point 
> of view it's not likely we will pick it up if the CVE meets the same 
> needs. Malcode could seriously benefit from a mapping schema but I am 
> skeptical of the need for a new vulnerability one.
> 
> -al
> 
> 
> On Thu, 8 Dec 2005, Pascal Meunier wrote:
> 
>> I was unable to find out more information using Google, e.g., what is 
>> their
>> motivation, funding, etc...  I would like to know if they have 
>> vulnerability
>> information that the CVE doesn't have.  I'd like to know how and if they
>> relate vulnerabilities to exploits, and if they have anything as 
>> flexible as
>> what I implemented in the coop vdb:
>> https://cirdb.cerias.purdue.edu/coopvdb/public/
>>
>> So, they could be doing valuable work, but I can't tell.  If it is 
>> good work
>> and they have staying power then the CVE will have to adjust.  I bet that
>> Steve and the security vendors don't relish the prospect of another 
>> mapping
>> job.  However, in theory if both they and the CVE do their job 
>> properly, the
>> vulnerability mapping should be one on one unless there are cardinality
>> issues and then it would be one to many.  The thing to avoid is an
>> irreversible mapping, where if you go from WVE->CVE->WVE you get a 
>> different
>> entry (which would be possible if there is a many-to-many relationship).
>> This situation would likely indicate that some vulnerabilities were
>> incorrectly grouped together by either effort.  Maybe WVE and CVE 
>> could talk
>> to try to avoid this situation, and establish contacts and procedures in
>> case it happens.  If it happens, either the CVE or WVE would need 
>> repairs.
>> Other comments and suggestions come to mind but they would be 
>> premature at
>> this point.
>>
>> In any case, I miss very much the discussions we used to have.  I 
>> derived a
>> great benefit from them;  for example when format string vulnerabilities
>> first started being identified, the board's discussions helped me 
>> understand
>> them.
>>
>> Pascal
>>
>> On 12/8/05 12:55 PM, "Andy Balinsky" <balinsky@cisco.com> wrote:
>>
>>> There is a new CVE clone effort out there for Wireless vulnerabilities
>>> (WVE). This brings up several issues:
>>> - What is the status of CVE, given that the editorial board hasn't had
>>> any activity for many many months?
>>> - Does this WVE effort detract from CVE and add confusion to the world
>>> by coming up with a second set of standard names for things that CVE
>>> covers, too? Or is it good to get more information categorized out there
>>> in the world?
>>>
>>> Although their entry format is very similar to CVE (as well as their
>>> structure, including an Editorial Board), they include 2 categories of
>>> entries: Vulnerabilities and Exploits. They use the same namespace
>>> (WVE-2005-????) for both vulns & exploits.
>>>
>>> Any ideas or comments?
>>>
>>> Andy
>>>
>>
> 
> Alfred Huger
> Symantec Corp.