I'd be willing to bet that most of the people reading this article would identify themselves as "gadget guys" or "gadget girls." Admit it-you've always got to have the latest video game console, cell phone, or scrolling LED belt buckle. You buy your new cars packed with bells and whistles like GPS navigation systems and Blu-ray players. And you like your software-both that which you use and that which you develop yourself-the same way. Speaking on behalf of the entire programming community, I can say that we love to add new, shiny features to our applications. Best of all, these "exciter" and "delighter" features go a long way towards keeping users happy, too.

Unfortunately, there is a downside. Every new bell or whistle you add to your application represents a new potential for something to break; or, more to the point of this article, it represents a new potential vulnerability that an attacker could exploit. In security parlance this is called "attack surface." For example, take the GPS navigation system I mentioned earlier. These systems can help you find the closest gas station if you're getting low on gas. They can help you find your way home if you're lost. They can do all sorts of helpful things, but they also add a certain amount of attack surface. If a car thief steals your car, he can use the "home" feature on your GPS to find your house and rob that too. He can even use your automatic garage door opener to let himself in your house without having to break down the back door.

This example may be a little farfetched, but real-world examples of software vulnerabilities are easy to find. For example, the vulnerability CVE-2007-2815 in IIS 5.0 allowed remote attackers to bypass authentication and access private files on the server. What makes this vulnerability particularly relevant in terms of attack surface is that IIS 5.0 was installed by default on Windows 2000. So, every Windows 2000 machine had to be patched in order to defend against this attack, whether or not that machine was actually being used as a Web server. Thousands-maybe even millions-of Windows 2000 users never used IIS but were nonetheless exposed to the attack.

The solution to this problem is not to stop building new features. As I said before, features make users happy and are fun to develop, too. I'm not giving up my GPS or my IIS 7 any time soon, but both are features that I opted into; they were not installed for me by default. In the years since Windows 2000 and IIS 5 were written, Microsoft has developed the Security Development Lifecycle, which (among many other requirements) specifies that applications must disable by default any features that are unlikely to be used by 20 percent or more of users. This is the way that Windows 7, Server 2008, Vista, and all other versions of Windows back to Server 2003 work with IIS. It's available for you to use, but you explicitly have to enable it. I highly recommend following the same 80/20 rule in your own products. If at least 80 percent of your users aren't going to use the feature, install it as disabled.

Another effective way to manage the additional attack surface added by new features is by managing who can use those features. Does your feature need to be available to everyone all the time, or can you lock it down to only certain users at certain times? Simply requiring users to be authenticated in order to use certain features can dramatically reduce attack surface. Taking the additional step of authorizing certain users or groups to use the feature is even better. This is obvious for administrative functionality, but it also can work on a finer-grain level. A GPS may not have any concept of an authenticated user, but it can tell whether or not it's in motion. My particular model of GPS allows me to type in the names of "points of interest" like restaurants and parks; however, that feature only works while the car is stopped. By disabling the keyboard while the car is in motion, the GPS reduces its "attack surface" by reducing the possibility that the driver will crash the car while playing with the GPS.

If you're interested in learning more about additional strategies and tactics for reducing your product's attack surface, please read the paper "Measuring Relative Attack Surfaces" by Michael Howard, Jon Pincus, and Jeannette M. Wing.