How Much Security Do I Need?

This is an excellent question to start with. Every security countermeasure trades off against something. That something could be ease of use, cost, ease of deployment, ease of administration, and so on. For example, consider password complexity requirements. If your Web application is simply giving people access to publicly available weather information, the tradeoff of requiring strong passwords is probably not worth it. In fact, you may not need to annoy your users with a login at all. On the other hand, if you are protecting company assets or personally identifiable information for your users, then having a strong password policy is a critical step toward making your Web application secure enough.

Ultimately, that's your job: to build your Web application to be secure enough considering the real threats that it faces. Choosing an appropriate security posture means thinking about how valuable the assets you have are to an attacker, how far he'd be willing to go to get at those assets, and how much you're willing to pay (or trade off) to protect those assets. A great way to approach this problem is to build a threat model, which you can learn more about at the Microsoft patterns & practices Web site.^[1] With a threat model in place, you can streamline your effort because you'll have a prioritized list of threats and vulnerabilities. There is never enough time or resources to implement all of the security features you would like, and it's wise to use whatever precious time you do have to address the highest priority security issues first.

^[1] Start at msdn.com/securityengineering and look for guidance on threat modeling Web applications. Another great resource is the ACE threat modeling tool that is in version 2.0 as of this writing. You can find this latter tool by visiting http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/ or http://blogs.msdn.com/threatmodeling/.

This chapter covers many of the new security features in ASP.NET 2.0, but ironically most of the worst security breaches have nothing to do with security features at all. The common SQL injection vulnerability that allows an attacker to pilfer private information from your database (or even worse, make subtle changes or destroy your database entirely) is introduced not by the person building security features, but by the new hire who is simply writing naïve database access logic. Consider the filename canonicalization bug that allows an attacker to download your entire membership database or, even worse, your security accounts manager (SAM) database that contains the password hashes for the Windows accounts on your server. Cross-site scripting is another nasty vulnerability that allows an attacker to completely change the look and functionality of your Web site and to create virtually undetectable phishing attacks against legitimate users (this is especially dangerous if the attacker knows how to write grammatically correct sentences).

All of the developers on your team need to have a basic understanding of these coding errors, so be sure to educate them by giving them good security guidance. The patterns & practices Web site has some excellent guidance you can use, including some free security training modules^[2] that can help your team learn about some of the common input validation issues in Web applications. The book Writing Secure Code, 2nd edition, by Michael Howard and David LeBlanc is also an excellent resource.

^[2] See http://pluralsight.com/blogs/keith/archive/2006/02/22/18995.aspx, or search for "Keith Brown input validation modules."