The essentials of Web application threat modeling

A critical part of Web application security is mapping out what's at risk -- a process called threat modeling. The term "threat" modeling is actually a misnomer. It's more like "vulnerability" or "risk" modeling, since we're technically looking at weaknesses and their consequences -- not the actual indication of intent to cause disruption (a threat).

Semantics aside, threat modeling -- even at a high level -- needs to be on your radar and part of your development process if Web application security is important to your business. Think about it. There's a lot happening within your Web applications that you may not be aware of. It's really easy to fall into the trap of assuming all's well in Web-land as long as the basics of a firewall, SSL, and strong passwords are in place. This dangerous assumption boils down to not really knowing what's at risk. It's the bane of information security today.

Let threat modeling help fill the gaps. It really does work. Here are the essential steps for getting started:

1. Determine your security goals by outlining what's in scope, what's absolutely critical, as well as what's being mandated by management, security policy, or even customers or business associates. Make sure everyone's on the same page and expectations are properly set.
2. Document the general architecture of your application and outline information flows from user to Web server, Web server to application server, application server to database server, and so on.
3. Outline what really needs to be protected such as user login credentials, session information, source code, application logic, and (especially) customer information.
4. Pinpoint the various entry points and "trust" zones that need protection, including user authentication, user management, system logging, server/application maintenance, and critical application and database interfaces.
5. Discover what can be exploited using a malicious mindset -- from both the perspective of an untrusted outsider and a trusted user.

   You'll never find or think of everything no matter how analytical your team is or how good your tools are. That's OK. Just go for the basics now. It doesn't take long to realize that the majority of Web application vulnerabilities are related to input validation, system configuration problems, and insiders abusing privileges they probably shouldn't have, including the following:

   • Cross-site scripting in search forms or message boards
   • SSL not being used or enforced throughout the application
   • Weak password requirements
   • Lack of account lockout after so many failed login attempts
   • Informative authentication errors being returned to the user, resulting in username and password harvesting
   • Weak mutual-factor authentication processes implemented per the Federal Financial Institutions Examination Council (FFIEC) requirements
   • Session keys and cookies not expiring or being easily manipulated
   • URL and/or form-field manipulation to bypass authentication or escalate privileges
   • Sensitive information returned in server errors that can give an attacker a leg up on penetrating the system

   More information about threat modeling Threat modeling key to pro-active security Threat modeling enhanced with misuse cases Application security shouldn't involve duct tape, Band-Aids or bubble gum

   Also, you may want to check out Microsoft's threat model called STRIDE that highlights the important areas of most applications:

   Spoofing identity
   Tampering with data
   Repudiation
   Information disclosure
   Denial of service
   Elevation of privilege

6. Determine what's urgent and important based on the likelihood and impact of each weakness. Always remember that not all security flaws are created equal. Focus first on the exploitable vulnerabilities in the most sensitive parts of the application or on the most sensitive systems. Some things will have a high likelihood but a low impact. Others may have a low likelihood with a high impact. Go for the items that are both high likelihood and high impact and work down from there.

   The DREAD model can be used here or you can develop your own in-house model for assessing risk. Either way, just keep your analysis consistent over time and across applications.

7. Determine what can be done about each weakness and when it can/will be resolved. As in step one, this involves setting goals and sticking to them. Your options are usually pretty simple: fix it (via code changes or other security controls) or obscure it in hopes that no one finds it. (I see that a lot, but it's not recommended long term.)

   Do you fix the problem(s) in the next release? Within six months? Never? You've got to be realistic based on how critical each item is and how much effort is involved. Also, be careful "fixing" security holes to the point that usability is affected. Aside from being hacked, the next worst thing that can happen is ticking off your users to the point where they stop using the application or create new security holes working around stringent controls.

In essence, threat modeling is analyzing your Web application to find out what information flows where, outlining who can do what and when, and determining the worst that can happen. You can do all of this manually or you can use a software-based modeling tool such as Amenaza's SecurITree to help. If you have a large development team or a complex application, I recommend using a tool if you can. It can really speed up the process, and it looks pretty for the higher-ups to boot.

Given that threat modeling affects the entire development lifecycle, it's really something that needs to be done during the design phase if at all possible. So, now is probably a good time to get started. That said, don't let threat modeling drive your entire project or get in the way of your development efforts. I see all too often where developers and their managers obsess over this stuff to the point that it does more harm than good -- especially at first. Don't drain the ocean and attempt to do everything possible to lock down your application's security. You'll just get in the way of yourself.

Instead, combine these techniques with some common sense and build out your threat modeling capabilities over the next few years and project iterations. It won't fix everything at once, but this one-bite-at-a-time approach will help get more people on board and allow your team to ease into the techniques and malicious mindset needed for effective threat modeling. In turn, you'll build better processes and bake security in up front so you don't have to worry about it as much in the future.

-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels blog and information security audio books providing security learning for IT professionals on the go. Kevin can be reached at kbeaver@principlelogic.com.