Rank The Threats

Although the security folk in the audience might be salivating at this point, a raw list of threats is often quite unhelpful to software development people who have limited time and budgets to create new (or disable insecure ) features on schedule for the next release. Thus, it's very important to rank, or prioritize, the list of threats at this point by employing a systematic metric, so that limited resources can be efficiently aligned to address the most critical threats.

There are numerous metric systems for ranking security risk. A classic and simple approach to risk quantification is illustrated in the following formula:

Risk = Impact — Probability

This is a really simple system to understand, and even enables greater collaboration between business and security interests within the organization. For example, the quantification of business Impact could be assigned to the office of the Chief Financial Officer (CFO), and the Probability estimation could be assigned to the Chief Security Officer (CSO), who oversees the Security and Business Continuity Process (BCP) teams .

In this system, Impact is usually expressed in monetary terms, and Probability as a value between 0 and 1. For example, a vulnerability with a $100,000 impact and a 30 percent probability has a risk ranking of $30,000 ($100,000 — 0.30). Hard-currency estimates like this usually get the attention of management and drive more practicality into risk quantification. The equation can be componentized even further by breaking Impact into (Assets — Threats) and Probability into (Vulnerabilities — Mitigations).

Other popular risk quantification approaches include Microsoft's DREAD system ( D amage potential, R eproducibility, E xploitability, A ffected users, and D iscoverability), as well as the simplified system used by the Microsoft Security Response Center in their security bulleting severity ratings. The Common Vulnerability Scoring System (CVSS) is a somewhat more complex but potentially more accurate representation of common software vulnerability risks (we really like the componentized approach that inflects a base security risk score with temporal and environmental factors unique to the application). Links to more information about all of these systems can be found at the end of this chapter in the "References and Further Reading" section.

We encourage you to tinker with each of these approaches and determine which one is right for you and your organization. Perhaps you may even develop your own, based on concepts garnered from each of these approaches, or built from scratch. Risk quantification is highly sensitive to perception, and it's unlikely that you'll ever find a system that results in consensus among even a few people. Just remember the main point: apply whatever system you choose consistently over time so that relative ranking of threats is consistent. This is after all the goaldeciding which threats will be addressed in priority.

We've also found that it's very helpful to set a threshold risk level, or "bug bar," above which a given threat must be mitigated. There should be broad agreement on where this threshold lies before the ranking process is complete. This creates consistency across releases, and makes it harder to game the system by simply moving the threshold around (it also tends to smoke out people that deliberately set low scores to come in below the risk bar).

Develop Threat Mitigation Strategies

At this point, the threat modeling process should've produced a list of threats to our shopping cart application, ranked by perceived risk to the application/business. Now it's time to develop mitigation strategies for the highest ranking threats (i.e., those that surpass the agreed-upon risk threshold).

Tip 

You can create mitigation strategies for all threats if you have time; in fact, there might be mitigations to lower-risk threats that could be implemented with very little effort. Use good judgment.

Threat/risk mitigation strategies can be unique to the application, but they tend to fall into common categories. Again, we cite Microsoft's Web Application Security Frame "cheat sheet" for a useful organization of mitigation strategies into categories that correspond to common attack techniques. Usually, the mitigation is fairly obvious: eliminate (or limit the impact of) the vulnerability exploited by the threat, using common preventive, detective, and reactive security controls (such as authentication, cryptography, and intrusion detection).

Tip 

Not every threat has to be mitigated in the next release; some threats are better addressed long- term across iterative releases, as application technology and architectures are updated.

For example, in our hypothetical shopping cart application, the threat of "Brute-force credential guessing" against the authentication system could be mitigated by the use of CAPTCHA technology, whereby after six failed attempts, the user is required to manually input the information displayed in a CAPTCHA image provided in the login interface (see Chapter 4 for more information about CAPTCHA). (Obviously, any tracking of failed attempts should be performed server-side, since client-provided session data can't be trusted; in this example, it might be more efficient to simply display the CAPTCHA with every authentication challenge). In the future, if an attack is developed that can bypass the chosen CAPTCHA technology, the team can go back to the drawing board and revisit the issue. This illustrates the importance of evolving the application threat model over time and keeping abreast of new security threats.

Obviously, threat-mitigation strategies should not only help your organization mitigate threats, but also prevent inadvertent creation of new threats. A common example of this is setting an account lockout threshold of six attempts, after which the account is disabled. Such a feature might be implemented to mitigate password-guessing threats. However, if attackers can guess or otherwise obtain valid usernames (think of a financial institution where the account numbers might be simply incremental in nature), they might be able to automate a password-guessing attack that could easily create a denial-of-service (DoS) condition for all the users of the application. Such an attack might also overwhelm support staff with phone calls requesting account resets.

Implementing an account timeout, rather than lockout, feature is the better solution. Instead of disabling the account after a threshold number of failed attempts, the account could be disabled temporarily (say, for 30 minutes). Combining this delayed account lockout method with a CAPTCHA challenge would provide even further mitigation. Of course, each of these mechanisms has an impact on usability and should be tested in real-world scenarios to more fully understand the trade-offs that such security controls inevitably introduce.

Finally, don't forget off-the-shelf components when considering threat mitigation. Here is a handful of obvious examples of such threat mitigation technologies available from web applications today:

• Many web and application servers ship with prepackaged generic error message pages that provide little information to attackers.

• Platform extensions like URLScan and ModSecurity (see Appendix C) offer HTTP input filtering "firewalls."

• Development frameworks like ASP.NET and Jakarta Struts (J2EE-based) offer built-in authorization and input validation routines, and so on.