|
|
|||
|
|
|
|||
|
So the answer turns out to be that if we want greater coverage of true hardware vulnerabilities, we need to figure out how to include exactly what needs to be covered in the Counting Rules definitions and then update the documentation. I think Kurt’s point about tolerances inherited from product standards and/or marketing pronouncements is a reasonable starting point.
From:
Kent Landfield [mailto:bitwatcher@gmail.com]
A vulnerability in the context of the CVE Program is defined by the Counting Rules as listed in Appendix C. In general, a vulnerability is defined as a weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, OR availability. Mitigation of the vulnerabilities in this context typically involves coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).” A vulnerability is a flaw or design oversight in software that could be used by an attacker to gain unintended access to a system or network. CVE considers a flaw a vulnerability if it allows an attacker to use it to violate a reasonable security policy for that system (this excludes entirely “open” security policies in which all users are trusted, or where there is no consideration of risk to the system).
Dropping an iPhone would not be covered by the multiple versions of the definition of a vulnerability we are using.
Maybe we want one definition ....
+1.817.637.8026
|
