Re: CNA Rules Announcement

[jericho <jericho@attrition.org>]

On Fri, 7 Oct 2016, Chandan Nandakumaraiah wrote:

: > Moving forward sure, but retroactively trying to enforce that for 
an issue 
: > that is already abstracted to some degree does not work.
: 
: Agreed. We need a statement or rule on the interaction between new 
: assignments and assignments based on previous rules.

Also need to be careful if we unilaterally change the abstraction rules 
for CVE if it breaks from a 16 year history.

: > Not sure every scanner does that. There is a lot of value in having 
a 
: > per-vendor finding in that case, else that single finding will come 
with a 
: > list of 250+ advisories that are not easily distinguished from each 
other, 
: > that carry the solution.
: 
: We can not solve that problem by assigning 250+ different CVEs for a 
: common vulnerability. That would be like going back to pre-CVE era, 
: isn't it?

No. Pre-CVE there was BID (for 6 months) and X-Force (for 2 years), 
neither of which really faces these kind of protocol vulns. There are 
merits of each abstraction method and we should weigh the pros and cons 
looking forward, not back.

: What if the product-vendor being scanned had never produced an 
advisory 
: or fix for the 'POODLE for TLS' issue? Which of the many CVEs should 
the 
: scanner use to reference that unique issue?

If they do it right, they don't reference a CVE in that case. That is 
perhaps the most critically dangerous notion the board, or anyone in 
security, could have; that you *must* have a CVE for it to be a valid 
security issue or that an issue without a CVE is some kind of weird 
thing, 
when it absolutely is not. In fact, that is the norm [1] for many 
companies.

Brian

[1] 
http://www.csoonline.com/article/3122460/techology-business/over-6000-vulnerabilities-went-unassigned-by-mitres-cve-project-in-2015.html