Evaluating Security Threats 

The process of evaluating security threats, called threat modeling, is necessary to determine the likelihood and ramifications of security breaches in your ADO.NET application. Threat modeling iteratively evaluates and ranks potential threats, along with appropriate mitigation techniques. You cannot protect a system against attack unless you understand all the potential attacks that it is exposed to.

Threat Examples

You cannot counter some threats simply by using secure coding techniques, running under least privilege, or other common mitigation techniques. Fire, flood, or theft can cause irretrievable damage to data if no off-site backups exist. A trusted employee could also inadvertently or maliciously damage or destroy data. To mitigate these kinds of threats you must use techniques above and beyond the scope of the software development process itself, such as ensuring that off-site backups exist, monitoring employee activities, and pursuing legal or other remedies in the case of misconduct or theft.

The STRIDE Threat Model

STRIDE is an acronym for the spectrum of security threats your application may face. The following six threat categories can help you identify vulnerabilities and potential attack vectors in your own applications.

  • Spoofing identity
    Spoofing means impersonating someone else to the computer. An example of identity spoofing is illegally accessing and then using another user's authentication information, such as user name and password.
  • Tampering with data
    Data tampering involves the malicious modification of data. Examples include unauthorized changes to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet.
  • Repudiation
    Repudiation threats involve users who can deny performing an action without other parties having any way to prove otherwise. For example, a user might perform an illegal operation in a system without the ability to trace the prohibited operations.

    By the same token, nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package.

  • Information disclosure
    Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers.
  • Denial of service
    Denial of service (DoS) attacks cause loss of service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats to improve system availability and reliability.
  • Elevation of privilege
    In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and has become part of the trusted system itself.

Applying STRIDE

The simplest way to apply the STRIDE model to your application is to consider how each of the threats in the model affects each component and each of its connections or relationships with other application components. Essentially, you look at each part of the application and determine whether any of the STRIDE threat categories exist for that component or process. The process should be an iterative one, as follows:

  1. List all of the known threats, determining how each could affect the system.

  2. Rank the threats by criticality, or impact (how much damage an attack of this nature can cause) and likelihood. For criticality, assign a number between 1 and 10, with 10 being the most severe. For likelihood, choose a number, with 1 being the most likely to occur, and 10 the least likely. Calculate the overall risk by dividing criticality by likelihood, that is, Risk = Criticality/Likelihood.

  3. Choose an appropriate technique or technology to mitigate each threat. Each threat type has specific mitigation techniques. For example, mitigating an elevation of privilege attack might involve running the application with an account with restricted permissions. The technologies and techniques employed to mitigate the threat might include prescriptions for using the configuration utilities for the software or servers, safe storage of connection information, and safe methods of retrieving connection information at run time.

  4. Start over at step 1 as the project evolves. You never have all of the facts at the start of any project, so making only one pass through the process can potentially leave the application vulnerable to attack.

Threat Modeling Resources

For more information about threat modeling ASP.NET applications, see Overview of Web Application Security Threats. Also see the Threat Modeling site on MSDN, which provides links to additional resources for understanding the threat modeling process. Finally, "Chapter 3 - Threat Modeling" from Patterns and Practices, Improving Web Application Security: Threats and Countermeasures for help identifying and rating threats that are most likely to damage your system.

See Also

Other Resources

Securing ADO.NET Applications
ASP.NET Web Site Security