[
Date Prev
][
Date Next
][
Thread Prev
][
Thread Next
][
Date Index
][
Thread Index
]
Re: CNA Rules Announcement
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
