Vulnerabilities and Exposures
On the Common Vulnerabilities and Exposures website there is a terminology page that presents two definitions; one for vulnerability and another for exposure. Having recently discussed and pondered the implications of broadly defining vulnerability, it was nice to see some precision. I’m surprised I hadn’t come across this before.
The challenge with one’s defintion of vulnerability surfaces when you attempt to calculate some form of probabilities or impact of a given vulnerability. Some “conditions” that are typically labeled as vulnerabilities by many tools are really nothing more than configuration errors or omissions. The CVE definitions make room for such errors and omissions by calling them exposures. The defining characteristic, in my estimation, is whether or not such a condition leads to the direct compromise. If it is direct, in most cases it is a vulnerability. If it is indirect or a “stepping stone” then it is an exposure.
The caveat sprinkled throughout the page makes it clear that there is some form of “reasonable security policy” by which to measure. This policy should not be confused with an organizations over-arching security policy, but those characteristics that are expected of a given product/application. This works nicely I think. It gets interesting in organizations whose core business is not the distribution of software. Why is this the case? Some environments having varying degrees of “reasonable security policies” when it comes to applications. Most of the time it is in the form of, at best, non-functional requirements or, at worst, some language thrown together ad-hoc from vague high-level security policies. The further away an organization is from this policy the more the notions of vulnerability and exposure merge together. This is only difficult when, as I mentioned early, one tries to measure probability and impact. A true exposure does not have the same measurable characteristics that a vulnerability does. For instance, vulnerabilities have properties like exploitability and reproducibility. These properties do not measure at all with exposures. Or if they do, they do not accurately communicate risk. The nature of a vulnerability is its ability to directly compromise. The measurement is an attempt to reflect the probability of that direct compromise. Exposures typically do not have that sort of capability . To measure them in such a way artificially inflates the inherent risks of exposures.
Are you still with my meandering? Good, because now we get back to the non-software selling organizations. In order to make these distinctions meaningful and the rating useful there must be an effort to create this sort of reasonable security policy (the kind mentioned above). Without such a standard things inevitably gravitate to the vulnerability class in order to rate it and have some corrective action performed. When this happens our measurements of risk behave in strange ways. For organizations in this situation it seems that the easiest way out is to create a minimal set of security requirements that directly address these exposures.