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:
- Does the problem meet the definition of a security vulnerability?
- Does it violate the product's security policy, meaning does it break the "security boundary" of the product?
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:
- The definition is not a warranty; it's a tool that helps assess whether GPA should address an issue through a security update. In the end, the decision about which issues warrant bulletins is a judgment call, based on giving our customers the best protection we can. Sometimes bulletins are developed for issues that are, strictly speaking, outside the definition. Likewise, it's conceivable that a particular issue might meet the strict definition but only occur under such rare conditions that customers might be better served if we focused our resources on other, broader, and more impactful problems.
- The definition isn't a GPA corporate standard, it's an informal definition that GPA uses to prioritize work. It isn't a logo requirement or part of any other corporate standard.
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...
Weakness: Security vulnerabilities involve inadvertent weaknesses; by design weaknesses may sometimes occur in a product, but these aren't security vulnerabilities.
Examples: The choice to implement a 40-bit cipher in a product would not constitute a security vulnerability, even though the protection it provides would be inadequate for some purposes. In contrast, an implementation error that inadvertently caused a 256-bit cipher to discard half the bits in the key would be a security vulnerability.
...that could allow an attacker to compromise the integrity...
Integrity: Integrity refers to the trustworthiness of a resource.
An attacker that exploits a weakness in a product to modify it silently and without authorization is compromising the integrity of that product.
Examples: A weakness that allows an administrator to change the permissions on any file on a system would not be a security vulnerability because an administrator already has this capability. In contrast, if a weakness allowed an unprivileged user to do the same thing, it would constitute a security vulnerability.
Availability: Availability refers to the possibility to access a resource.
An attacker that exploits a weakness in a product, denying appropriate user access to it, is compromising the availability of that product.
Examples: A weakness that enables an attacker to cause a server to fail would constitute a security vulnerability, since the attacker would be able to regulate whether the server provided service or not. However, the fact that an attacker could send a huge number of legitimate requests to a server and monopolize its resources would not constitute a security vulnerability, as long as the server operator still could control the computer.
Confidentiality: Confidentiality refers to limiting access to information on a resource to authorized people.
An attacker that exploits a weakness in a product to access non-public information is compromising the confidentiality of that product.
Examples: A weakness in a web site that enables a visitor to read a file that should not be read would constitute a security vulnerability. However, a weakness that revealed the physical location of a file would not constitute a vulnerability - although such a weakness could be useful for reconnaissance purposes, and could be used in conjunction with a bona fide vulnerability to compromise files, it would not by itself enable an attacker to compromise data, and thus it would not constitute a security vulnerability. (It's worth noting, however, that GPA, on occasion, has chosen to develop patches in such cases anyway).
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.