[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IMPORTANT: CVE - Common Vulnerabilities and Exposures?
As the recent discussions on the DEFINITION content decision indicate, the term "vulnerability" is prone to terminological debate. We propose a new term "exposure" to allow us to move forward from these debates, and rename the CVE accordingly to refer to "Common Vulnerabilities and Exposures." At least two different definitions of vulnerability have arisen and been discussed. There appears to be a universally accepted, historically grounded, "core" definition which deals primarily with specific flaws that directly allow some compromise of the system. Along these lines, Gene Spafford has expressed concerns that any loosening of the definition may result in the term being coopted in much the same way as "hacker" has. (Note that a cursory review of *Bugtraq postings indicates that the term is *not* currently "misused" on these lists, perhaps due to pre-posting editing suggestions by Russ and Elias? On the other hand, other Board members have mentioned cases where a constituent has used the term in a way that the Board member did not agree with.) On the other hand, there is the "inclusive" definition, which includes things that don't directly allow compromise, but could be an important component of a successful attack. For example, some have argued for a definition of vulnerability as "a feature of a computer system that permits or constitutes a violation of a reasonable security policy." Since reasonable security policies differ from site to site (and machine to machine), it is clear that this definition would include things that would not be covered by the "universal" definition, e.g. finger on a boundary machine. The Board has tried to come up with different terms to discriminate between these universal and inclusive "vulnerabilities." "Risk" and "policy violation" could be useful, except they are fairly general and encompass both universal and inclusive "vulnerabilities." We've seen modifiers to the vulnerability term itself, e.g. "environmental vulnerability" or "contingent vulnerability" or "macrovulnerability," but they still have the term "vulnerability" in them. We suggest that the Board adopt the term "exposure" to refer to these contingent/environmental vulnerabilities. Loosely defined, an "exposure" is a feature or state in a system that is not a "universal vulnerability" in itself, but allows a violation of a reasonable security policy. Consider running a service like finger. By design, it provides useful information (account names, etc.) that could help an attacker to perform password guessing. Some reasonable security policies for certain systems require that finger should not be run, and as such the presence of finger is an exposure. Another exposure might be a system that accepts dialups to its modem while it's also connected to an internal network. A shopping cart program whose configuration inadvertently releases private customer data would be considered an exposure, since an e-commerce site's security policy is likely to consider this a concern. Even running a web server is an exposure, since it opens the system to many potential CGI attacks (or other attacks) that could successfully compromise the system. The term "exposure" is not overly used in this community. It effectively indicates that something is a "risk" without going so far as to label it a "vulnerability." Elias Levy had suggested that we change the name of the CVE and call it something else, since MITRE intends for the CVE to cover both vulnerabilities and exposures. We propose doing just that. We can keep the CVE acronym, but call it "Common Vulnerabilities and Exposures" instead. Thus the "vulnerability" term will not be diluted by the CVE name itself. We should defer discussion of the mechanism for discriminating between vulnerabilities and exposures until after the CVE's initial public release. While there are several approaches that could be taken to address this (e.g. extending CMEX by implementing the "universal" attribute or something similar), each approach will require some time to evolve. The concept itself is relatively new, and it could impact how the Editorial Board performs some of its tasks. Let's concentrate on validating the remaining draft CVE entries (whether they are vulnerabilities or exposures), adapt the DEFINITION content decision using this new terminology, then move on to the task of ACCEPTing 300 CVE entries by the big splash at SANS. Comments? - Steve and Dave