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 is 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:

  • 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.

Definition

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: 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: 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.