Software Security: Managing the Attack Surface


We are a gadget-loving society and we love our gadgets to do fun things that keep us entertained or go above and beyond basic functionality. When it comes to our technological wonders, we are attracted by the "cool factor." As Bryan Sullivan notes in this article, unfortuntately those bells and whistles come with a price that must be paid for the sake of security.

I would be willing to bet that most of the people reading this article would identify themselves as gadget guys or girls." Admit it: you've always got to have the latest video game console, cell phone, or whatever is the newest technology. You buy your new cars packed with bells and whistles like GPS navigation systems and Blu-ray players. You like the software you use, 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.  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 bit extreme, 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,

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.