What's a security vulnerability? You might think that this would be an easy question to answer, but in fact it turns out not to be. In this article, I'll discuss the informal definition that we in the Microsoft Security Response Center use.

It may not be obvious at first why it's worth devoting several pages to discussing the meaning of the term. After all, you can look up both "security" and "vulnerability" in a dictionary and come to a reasonable understanding of what it means. If you did this, you might conclude that a security vulnerability is anything that offers a potential avenue of attack against a system, including things like viruses, 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.

In the context in which it's usually used among security professionals, a security vulnerability is a security exposure that results from a product flaw, and which the maker of the product should fix. This gives the term special relevance to us in the Microsoft Security Response Center, since it's our job to find such flaws whenever they exist and correct them. We've developed the definition discussed below to help identify problems that we can and should fix. We've written this article to help customers understand what types of issues we generally address via 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 we receive a report from a customer of a potential security problem, we conduct an investigation. If we're able to reproduce the problem, we apply two tests 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—that it, does it break the "security promise" the product made?

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 we won't take any action, though. For example, if an investigation shows that there's a bug but not a security vulnerability, we'll work with the product team to fix it—but we'll likely deliver the fix as part of a service pack or future version of the product, rather than through a patch and security bulletin.

If the problem does meet the definition of a vulnerability, the next question is whether it violates the product's security policy. Every product has a set of assumptions about how it will be used, and a set of promises it makes about the security it will provide when it's used properly. For instance, Microsoft Windows® 2000 promises that, if installed on an NTFS volume, it will enable the owner of a file to regulate who can access it. However, Windows 95 does not make this promise, and instead assumes that the owner of the file will physically protect the computer. As a result, it's possible that the same problem, affecting both Windows 2000 and Windows 95, would only violate the security policy of Windows 2000, and that we'd only release a Windows 2000 patch for it.

We're currently working with the various product teams to develop documentation that specifically addresses the security policy for each product, and will publish them when available. In the meantime you can determine a product's security policy by reading the product documentation, which discusses normal use and the product's security features. As you read the definition below, be sure to keep in mind that the entire discussion needs to be held within the context of the product's security policy.

A Little Fine Print Before We Begin

A final point before discussing the definition: it isn't intended as a legal document. The chief goal in developing it was to make it simple and understandable—even if doing so meant that we would leave a few gray areas. As a result, we need to point out that:

• The definition is not a warranty—it's a tool that helps us assess whether we should address an issue via a security bulletin. In the end, the decision about which issues warrant bulletins is a judgment call, based on our desire to give our customers the best protection we can. Sometimes we develop bulletins 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 we believe customers would be better served if we focused our resources on other, more pressing problems.

• The definition isn't a Microsoft corporate standard. It's an informal definition that we in the Microsoft Security Response Center use because it helps us do our jobs. It isn't a logo requirement or part of any other corporate standard.

Definition

With the introductions and caveats out of the way, we're finally ready to look at the definition. Here it is:

A security vulnerability is a flaw in a product that makes it infeasible – even when using the product properly —to prevent an attacker from usurping privileges on the user's system, regulating its operation, compromising data on it, or assuming ungranted trust.

Now let's flesh out exactly what the definition means. In the discussion that follows, we list critical phrases and words from the definition, discuss exactly what we mean by each, and give examples of how the definition could be applied to real-life cases.

…a flaw in a product…

• Flaw : 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 128-bit cipher to discard half the bits in the key would be a security vulnerability.

• Product: Security vulnerabilities are a result of a problem in a product. Problems that result from adhering to imperfect but widely accepted standards are not security vulnerabilities.

  Examples: A browser that, when connecting to an FTP site, conducts the session in plaintext would not be considered to have a security vulnerability, since the FTP specification calls for plaintext sessions. However, if the browser conducted SSL sessions in plaintext, it would constitute a security vulnerability since the SSL specification calls for encrypted sessions.

…that makes it infeasible… to prevent…

• Prevention: Security vulnerabilities involve a loss of control. That is, in order for a flaw to constitute a security vulnerability, it must be possible for an attacker to compel the victim to submit to the attack despite reasonable efforts to avoid it.

  Examples: Suppose a flaw in a web browser could be misused by a website to "hang" the browser of any user who visited the site. If the user were able to resume normal operation by stopping the browser, restarting it, and avoiding the attacker's website in the future, the flaw would not constitute a security vulnerability. However, if the flaw enabled the website to force the user to return to it and submit to a new attack each time the browser was restarted, it would constitute a security vulnerability. (Of course, much depends on the specific scenario. If the flaw allowed, for instance, data to be compromised, it would not matter whether the user could be forced to return to the site—stumbling onto the site one time would be sufficient to allow the attacker to exploit the flaw).

…even when using the product properly…

• Proper usage: Every product has documentation that describes how it is intended to be used. In addition, best practice guides discuss reasonable and customary ways of using products. In order for a flaw to be a security vulnerability, it must occur when the product is used in the expected, required, or reasonable way.

  Examples: Suppose a Web server contained a security flaw that was only exposed if all website visitors were given administrative privileges on the server. The flaw would not constitute a security vulnerability, because widely-accepted best practices warn against ever giving website visitors administrative privileges. However, if the flaw were exposed even when visitors to the site were given only the normal and expected privileges, it would constitute a security vulnerability.

…usurping privileges on the user's system…

• Usurping: Privilege elevation vulnerabilities involve assuming unauthorized capabilities.

  Examples: A flaw that allows an administrator to change the permissions on any file on the computer would not be a security vulnerability, because an administrator already has this capability. In contrast, if a flaw allowed an unprivileged user to do the same thing, it would constitute a security vulnerability.

…regulating its operation…

• Regulating: Regulating a system's operation is actually a special case of usurping privileges, but we've addressed it separately because of the importance of denial-of-service and similar attacks.

  Examples: A flaw 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.

…compromising data on it…

• Compromising: The ability to access data contrary to the owner's or the administrator's efforts constitutes a security vulnerability. Depending on the scenario, this could involve reading, adding, or modifying data.

  Examples: Suppose an operating system provides file-by-file access control. A flaw that allows one user to read another user's data, regardless of the permissions on the file, would constitute a security vulnerability. On the other hand, if the default permissions on a newly-created file provided global read access, this would not constitute a security vulnerability. Likewise, if the operating system didn't provide file-by-file access control, and this fact was documented, it wouldn't constitute a security vulnerability.

• On: There is a subtle but important difference between data on a system and data about a system. Data on a system includes information whose compromise poses a danger as a primary effect. Examples of data on a system include user data files, cryptographic key stores, etc. Data about a system includes information whose compromise, if it poses a danger at all, poses it as a secondary or tertiary effect. Examples include information about the logical structure of the system such as network topology, file locations, and so on.

  Examples: A flaw in a Web server that enables a visitor to read a file he should not be able to read would constitute a security vulnerability. However, a flaw that revealed the physical location of a file would not constitute a vulnerability—although such a flaw 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 Microsoft has traditionally chosen to develop patches in such cases anyway).

…gaining ungranted trust…

• Ungranted trust: Many products enable the user to specify people or organizations that they trust, and regulate their actions accordingly. Flaws that enable an attacker to gain a level of trust the user didn't grant constitute security vulnerabilities.

  Examples: A flaw that enabled a website to engage in an SSL session with a browser in the guise of another, trusted site would be a security vulnerability. However, spoofing based on social engineering—for instance, giving a phony name on an IRC channel as a means of persuading someone to run Trojan horse software—would not constitute a security vulnerability.

Definition in Practice

As you no doubt noticed, there's quite a bit of room for judgment in the definition. However, we try to let common sense and a desire to protect our customers be the final arbiter. A quick scan of the listing of security bulletins will show that we generally use a fairly expansive reading of the definition. If you think you may have found a security vulnerability in a Microsoft product, please be sure to report it to us at the Security Response Center—we'll investigate it immediately and let you know whether it meets the definition.

Scott Culp is a security program manager with the Microsoft Security Response Center.