Appendix N: SDL Security Bug Bar (Sample)


Note: This sample document is for illustration purposes only. The content presented below outlines basic criteria to consider when creating security processes. It is not an exhaustive list of activities or criteria and should not be treated as such.

Please refer to the definitions of terms in this section.

On This Page

Server
Client
Definitions of Term

Server
Please refer to the Denial of Service Matrix for a complete matrix of server DoS scenarios.

The server bar is usually not appropriate when user interaction is part of the exploitation process. If a Critical vulnerability exists only on server products, and is exploited in a way that requires user interaction and results in the compromise of the server, the severity may be reduced from Critical to Important in accordance with the NEAT/data definition of extensive user interaction presented at the start of the client severity pivot.

Critcal

Server summary: Network worms or unavoidable cases where the server is “owned.”

  • Elevation of privilege: The ability to either execute arbitrary code or obtain more privilege than authorized
    • Remote anonymous user
      • Examples:
        • Unauthorized file system access: arbitrary writing to the file system
        • Execution of arbitrary code
        • SQL injection (that allows code execution)
    • All write access violations (AV), exploitable read AVs, or integer overflows in remote anonymously callable code

Important

Server summary: Non-default critical scenarios or cases where mitigations exist that can help prevent critical scenarios.
  • Denial of service: Must be "easy to exploit" by sending a small amount of data or be otherwise quickly induced
    •  Anonymous
      • Persistent DoS
        • Examples:
          • Sending a single malicious TCP packet results in a Blue Screen of Death (BSoD)
          • Sending a small number of packets that causes a service failure
      • Temporary DoS with amplification
        • Examples:
          • Sending a small number of packets that causes the system to be unusable for a period of time
          • A web server (like IIS) being down for a minute or longer
          • A single remote client consuming all available resources (sessions, memory) on a server by establishing sessions and keeping them open
    • Authenticated
      • Persistent DoS against a high value asset
        • Example:
          • Sending a small number of packets that causes a service failure for a high value asset in server roles (certificate server, Kerberos server, domain controller), such as when a domain-authenticated user can perform a DoS on a domain controller
  • Elevation of privilege: The ability to either execute arbitrary code or to obtain more privilege than intended
    • Remote authenticated user
    • Local authenticated user (Terminal Server)
      • Examples:
        • Unauthorized file system access: arbitrary writing to the file system
        • Execution of arbitrary code
    • All write AVs, exploitable read AVs, or integer overflows in code that can be accessed by remote or local authenticated users that are not administrators (Administrator scenarios do not have security concerns by definition, but are still reliability issues.)
  • Information disclosure (targeted)
    • Cases where the attacker can locate and read information from anywhere on the system, including system information that was not intended or designed to be exposed
      • Examples:
        • Personally identifiable information (PII) disclosure—see the Microsoft Privacy Standard for Development (MPSD) for detailed definitions and examples of PII
          • Disclosure of PII (email addresses, phone numbers, credit card information)
          • Attacker can collect PII without user consent or in a covert fashion
  • Spoofing
    • An entity (computer, server, user, process) is able to masquerade as a specific entity (user or computer) of his/her choice.
      • Examples:
        • Web server uses client certificate authentication (SSL) improperly to allow an attacker to be identified as any user of his/her choice
        • New protocol is designed to provide remote client authentication, but flaw exists in the protocol that allows a malicious remote user to be seen as a different user of his or her choice
  • Tampering
    • Modification of any “high value asset” data in a common or default scenario where the modification persists after restarting the affected software
    • Permanent or persistent modification of any user or system data used in a common or default scenario
      • Examples:
        • Modification of application data files or databases in a common or default scenario, such as authenticated SQL injection
        • Proxy cache poisoning in a common or default scenario
        • Modification of OS or application settings without user consent in a common or default scenario
  • Security features: Breaking or bypassing any security feature provided.
    Note that a vulnerability in a security feature is rated “Important” by default, but the rating may be adjusted based on other considerations as documented in the SDL bug bar.
    • Examples:
      • Disabling or bypassing a firewall without informing users or gaining consent
      • Reconfiguring a firewall and allowing connections to other processes

Moderate

  • Denial of service
    • Anonymous
      • Temporary DoS without amplification in a default/common install.
        • Example:
          • Multiple remote clients consuming all available resources (sessions, memory) on a server by establishing sessions and keeping them open
    • Authenticated
      • Persistent DoS
        • Example:
          • Logged in Exchange user can send a specific mail message and crash the Exchange Server, and the crash is not due to a write AV, exploitable read AV, or integer overflow
      • Temporary DoS with amplification in a default/common install
        • Example:
          • Ordinary SQL Server user executes a stored procedure installed by some product and consumes 100% of the CPU for a few minutes
  • Information disclosure (targeted)
    • Cases where the attacker can easily read information on the system from specific locations, including system information, which was not intended/ designed to be exposed.
      • Example:
  • Spoofing
    • An entity (computer, server, user, process) is able to masquerade as a different, random entity that cannot be specifically selected.
      • Example:
        • Client properly authenticates to server, but server hands back a session from another random user who happens to be connected to the server at the same time
  • Tampering
    • Permanent or persistent modification of any user or system data in a specific scenario
      • Examples:
        • Modification of application data files or databases in a specific scenario
        • Proxy cache poisoning in a specific scenario
        • Modification of OS/application settings without user consent in a specific scenario
    • Temporary modification of data in a common or default scenario that does not persist after restarting the OS/application-/session
  • Security assurances:
    • A security assurance is either a security feature or another product feature/function that customers expect to offer security protection. Communications have messaged (explicitly or implicitly) that customers can rely on the integrity of the feature, and that’s what makes it a security assurance. Security bulletins will be released for a shortcoming in a security assurance that undermines the customer’s reliance or trust.
      • Examples:
        • Processes running with normal “user” privileges cannot gain “admin” privileges unless admin password/credentials have been provided via intentionally authorized methods.
        • Internet-based JavaScript running in Internet Explorer cannot control anything the host operating system unless the user has explicitly changed the default security settings.

Low

  • Information disclosure (untargeted)
    • Runtime information
      • Example:
        • Leak of random heap memory
  • Tampering
    • Temporary modification of data in a specific scenario that does not persist after restarting the OS/application


Client
Extensive user action is defined as:

  • "User interaction" can only happen in client-driven scenario.
  • Normal, simple user actions, like previewing mail, viewing local folders, or file shares, are not extensive user interaction.
  • "Extensive" includes users manually navigating to a particular website (for example, typing in a URL) or by clicking through a yes/no decision.
  • "Not extensive" includes users clicking through e-mail links.
  • NEAT qualifier (applies to warnings only). Demonstrably, the UX is:
    • Necessary (Does the user really need to be presented with the decision?)
    • Explained (Does the UX present all the information the user needs to make this decision?)
    • Actionable (Is there a set of steps users can take to make good decisions in both benign and malicious scenarios?)
    • Tested (Has the warning been reviewed by multiple people, to make sure people understand how to respond to the warning?)
  • Clarification: Note that the effect of extensive user interaction is not one level reduction in severity, but is and has been a reduction in severity in certain circumstances where the phrase extensive user interaction appears in the bug bar. The intent is to help customers differentiate fast-spreading and wormable attacks from those, where because the user interacts, the attack is slowed down. This bug bar does not allow you to reduce the Elevation of Privilege below Important because of user interaction.

Critical

Client summary:
  • Network Worms or unavoidable common browsing/use scenarios where the client is “owned” without warnings or prompts.
  • Elevation of privilege (remote): The ability to either execute arbitrary code or to obtain more privilege than intended
    • Examples:
      • Unauthorized file system access: writing to the file system
      • Execution of arbitrary code without extensive user action
      • All write AVs, exploitable read AVs, stack overflows, or integer overflows in remotely callable code (without extensive user action)

Important

Client summary:
  • Common browsing/use scenarios where client is “owned” with warnings or prompts, or via extensive actions without prompts. Note that this does not discriminate over the quality/usability of a prompt and likelihood a user might click through the prompt, but just that a prompt of some form exists.
  • Elevation of privilege (remote)
    • Execution of arbitrary code with extensive user action
      • All write AVs, exploitable read AVs, or integer overflows in remote callable code (with extensive user action)
  • Elevation of privilege (local)
    • Local low privilege user can elevate themselves to another user, administrator, or local system.
      • All write AVs, exploitable read AVs, or integer overflows in local callable code
  • Information disclosure (targeted)
    • Cases where the attacker can locate and read information on the system, including system information that was not intended or designed to be exposed.
    • Example:
      • Unauthorized file system access: reading from the file system
      • Disclosure of PII—see the Microsoft Privacy Standard for Development (MPSD) for detailed definitions and examples of PII
        • Disclosure of PII (email addresses, phone numbers)
      • Phone home scenarios
  • Denial of service
    • System corruption DoS requires re-installation of system and/or components.
      • Example:
        • Visiting a web page causes registry corruption that makes the machine unbootable
    • Drive-by DoS
      • Criteria:
        • Un-authenticated System DoS
        • Default exposure
        • No default security features or boundary mitigations (firewalls)
        • No user interaction
        • No audit and punish trail
        • Example:
          • Drive-by Bluetooth system DoS or SMS in a mobile phone
  • Spoofing
    • Ability for attacker to present a UI that is different from but visually identical to the UI that users must rely on to make valid trust decisions in a default/common scenario. A trust decision is defined as any time the user takes an action believing some information is being presented by a particular entity—either the system or some specific local or remote source.
      • Examples:
        • Displaying a different URL in the browser’s address bar from the URL of the site that the browser is actually displaying in a default/common scenario
        • Displaying a window over the browser’s address bar that looks identical to an address bar but displays bogus data in a default/common scenario
        • Displaying a different file name in a “Do you want to run this program?” dialog box than that of the file that will actually be loaded in a default/common scenario
        • Display a “fake” login prompt to gather user or account credentials
  • Tampering
    • Permanent modification of any user data or data used to make trust decisions in a common or default scenario that persists after restarting the OS/application.
      • Examples:
        • Web browser cache poisoning
        • Modification of significant OS/application settings without user consent
        • Modification of user data
  • Security features: Breaking or bypassing any security feature provided
    • Examples:
      • Disabling or bypassing a firewall with informing user or gaining consent
      • Reconfiguring a firewall and allowing connection to other processes
      • Using weak encryption or keeping the keys stored in plain text
      • AccessCheck bypass
      • Bitlocker bypass; for example not encrypting part of the drive
      • Syskey bypass, a way to decode the syskey without the password

Moderate

  • Denial of service
    • Permanent DoS requires cold reboot or causes Blue Screen/Bug Check.
      • Example:
        • Opening a Word document causes the machine to Blue Screen/Bug Check.
  • Information disclosure (targeted)
    • Cases where the attacker can read information on the system from known locations, including system information that was not intended or designed to be exposed.
      • Examples:
        • Targeted existence of file
        • Targeted file version number
  • Spoofing
    • Ability for attacker to present a UI that is different from but visually identical to the UI that users are accustomed to trust in a specific scenario. "Accustomed to trust" is defined as anything a user is commonly familiar with based on normal interaction with the operating system or application but does not typically think of as a "trust decision."
      • Examples:
        • Web browser cache poisoning
        • Modification of significant OS/application settings without user consent
        • Modification of user data

Low

  • Denial of service
    • Temporary DoS requires restart of application.
      • Example:
        • Opening a HTML document causes Internet Explorer to crash
  • Spoofing
    • Ability for attacker to present a UI that is different from but visually identical to the UI that is a single part of a bigger attack scenario.
      • Example:
        • User has to go a “malicious” web site, click on a button in spoofed dialog box, and is then susceptible to a vulnerability based on a different browser bug
  • Tampering
    • Temporary modification of any data that does not persist after restarting the OS/application.
    • Information disclosure (untargeted)
      • Example:
        • Leak of random heap memory


Definition of Terms
authenticated
Any attack which has to include authenticating by the network. This implies that logging of some type must be able to occur so that the attacker can be identified.

anonymous
Any attack which does not need to authenticate to complete.

client
Either software that runs locally on a single computer or software that accesses shared resources provided by a server over a network.

default/common
Any features that are active out of the box or that reach more than 10 percent of users.

scenario
Any features that require special customization or use cases to enable, reaching less than 10 percent of users.

server
Computer that is configured to run software that awaits and fulfills requests from client processes that run on other computers.

      Critical. A security vulnerability that would be rated as having the highest potential for damage.

      Important. A security vulnerability that would be rated as having significant potential for damage, but less than Critical.

      Moderate. A security vulnerability that would be rated as having moderate potential for damage, but less than Important.

      Low. A security vulnerability that would be rated as having low potential for damage.

targeted information disclosure
Ability to intentionally select (target) desired information.

temporary DoS
A temporary DoS is a situation where the following criteria are met:

  • The target cannot perform normal operations due to an attack.
  • The response to an attack is roughly the same magnitude as the size of the attack.
  • The target returns to the normal level of functionality shortly after the attack is finished. The exact definition of "shortly" should be evaluated for each product.

For example, a server is unresponsive while an attacker is constantly sending a stream of packets across a network, and the server returns to normal a few seconds after the packet stream stops.

temporary DoS with amplification

A temporary DoS with amplification is a situation where the following criteria are met:

  • The target cannot perform normal operations due to an attack.
  • The response to an attack is magnitudes beyond the size of the attack.
  • The target returns to the normal level of functionality after the attack is finished, but it takes some time (perhaps a few minutes).

For example, if you can send a malicious 10-byte packet and cause a 2048k response on the network, you are DoSing the bandwidth by amplifying our attack effort.

permanent DoS

A permanent DoS is one that requires an administrator to start, restart, or reinstall all or parts of the system. Any vulnerability that automatically restarts the system is also a permanent DoS.

Denial of Service (Server) Matrix

Authenticated vs. Anonymous attack Default/Common vs. Scenario Temporary DoS vs. Permanent Rating
Authenticated Default/Common Permanent Moderate
Authenticated Default/Common Temporary DoS with amplification Moderate
Authenticated Default/Common Temporary DoS Low
Authenticated Scenario Permanent Moderate
Authenticated Scenario Temporary DoS with amplification Low
Authenticated Scenario Temporary DoS Low
Anonymous Default/Common Permanent Important
Anonymous Default/Common Temporary DoS with amplification Important
Anonymous Default/Common Temporary DoS Moderate
Anonymous Scenario Permanent Important
Anonymous Scenario Temporary DoS with amplification Important
Anonymous Scenario Temporary DoS Low

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.

This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft Corporation. All rights reserved.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

Show:
© 2014 Microsoft