|GPA's Definition of a Security Vulnerability|
What's a security vulnerability? Most people think this would be an easy question to answer, but in fact it turns out not to be. This article discusses the definition currently used by the Microsoft Security Response Center and adopted by GPA to categorize the variety of issues we examine every day.
It may not be obvious at first why it's worth devoting several pages to discussing the meaning of the term. After all, it’s possible to look up both "security" and "vulnerability" in a dictionary and come to a reasonable understanding of what it means. By doing this, you might conclude that a security vulnerability is anything that offers a potential avenue of attack against a system, including things like malware, incorrectly configured systems, passwords written on sticky pads, and so on. It's true that issues like these do increase the risk to a system. However, this is a somewhat broader connotation than what's generally used within the security community and as we assess issues.
For the context used in the software security industry and by GPA, a vulnerability is:
A security exposure that results from a product weakness that the product developer did not intend to introduce and should fix once it is discovered.
This gives the term special relevance to GPA, whose job it is to find such weaknesses whenever they exist in GPA products and correct them. The definition discussed here helps identify problems that can and should be fixed and will help you understand what types of issues are generally addressed by security bulletins.
Putting the Definition in Context
It's important to understand that the definition isn't the final word on whether an issue warrants a security bulletin — instead, it's the first word. Whenever GPA receives a report of a potential security problem, an investigation is begun. If the problem can be reproduced, the following two questions are asked to determine whether a bulletin is needed:
Think of the security vulnerability definition as an initial filter that's applied to all issues. If a particular security issue doesn't meet the definition of a security vulnerability, it's unlikely that it would warrant a security bulletin. This doesn't mean there won't be any action taken though. For example, if an investigation shows that there's a bug but not a security vulnerability, GPA works to fix it, but the fix would be delivered as part of a service pack or future version of the product rather than through a security update and a bulletin.
If the problem meets the definition of a vulnerability, the next question is whether it violates the product's security boundaries. Every product has a set of assumptions about how it will be used, and a set of promises it makes about the security provided when it's used properly. For instance, User Access Control (UAC) is a technology introduced with Windows Vista that provides a method of separating standard user privileges and tasks from those that require Administrator access. If a Standard User is using the system and attempts to perform an action for which the user has no authorization, a prompt from Windows appears and asks the Administrator account’s password. If an Administrator is using the system and attempts to do the same task, there is only a warning prompt. That prompt is known as a “Consent Prompt” because the administrator is only asked to agree to the action before proceeding. A weakness that would allow to bypass the “Consent Prompt” is not considered a security vulnerability, since that is not considered a security boundary.
A Little Fine Print
A final point before discussing the definition of vulnerability: it isn't intended as a legal document. The main goal in developing it was to make it simple and understandable, even if doing so meant that there are few gray areas. As a result, here are some disclaimers.
In the context of GPA products, here is a more precise definition of a security vulnerability:
A security vulnerability is a weakness in a product that could allow an attacker to compromise the integrity, availability, or confidentiality of that product.
In the discussion that follows, the critical phrases and words are listed from the definition, defined precisely, and explained with examples with how the definition could be applied to real-life cases.
... a weakness in a product...
... that could allow an attacker to compromise the integrity...
As you can see, integrity, availability, and confidentiality are the three main goals for security. If one or more of these three elements lacks, there is a security vulnerability. A single security vulnerability can compromise one or all these elements at the same time. For instance, an information disclosure vulnerability would compromise the confidentiality of a product, while a remote code execution vulnerability would compromise its integrity, availability, and confidentiality.
Definition in Practice
As you no doubt noticed, there's quite a bit of room for judgment in the definition. In addition to common sense and a desire to protect our customers, we evaluate potential vulnerabilities by drawing on our years of practical security judgment, and a quick scan of the listing of security bulletins shows that a fairly expansive interpretation of the definition is applied. If you think you may have found a security vulnerability in a GPA product, please report it to GPA for immediate investigation. You will receive a response to let you know whether it meets the definition of a security vulnerability.
Original Document Source