We are failing at application security. Need proof? Look no further than the vulnerability statistics released by Mitre earlier this year. While network vulnerabilities such as buffer overflows have slowly been decreasing over the years, web application vulnerabilities including cross site scripting, SQL injection and remote file inclusion, have gone from being nearly non-existent in 2001 to being the three most prevalent vulnerabilities that we face today. Not enough proof? Type common application attack terms such as ‘phishing' or ‘cross site scripting' into a news search and note the number of hits. Whenever ‘geek speak' hits the main stream media, the problem has reached critical mass.

When network vulnerabilities reached a similar critical mass at the turn of the century, we responded by creating security teams to handle the problem. We're sticking with that same solution for application vulnerabilities and it isn't working.

Why can security teams battle one class of vulnerabilities and not another? Security teams can successfully battle network vulnerabilities because they have the knowledge and skills to find the vulnerabilities and they're empowered to fix them. How do we protect a sensitive server from attack - we add a firewall rule and restrict access to it. When Microsoft informs us of a new vulnerability, we patch it. These are activities that the security team is responsible for.

Application vulnerabilities are a completely different beast. While security teams are fully capable of identifying SQL injection vulnerabilities or Cross Site Request Forgery attacks, they don't have the power to fix them. Sure, a security professional can throw up an application firewall, but that hasn't fixed the problem, it's just masked it. It is the development team that has the power to correct vulnerabilities in custom applications, yet we don't consider them to be members of the security team. Ask a developer what they do to ensure security in their code and they're likely to tell you that the security team takes care of that. If security exists in a silo, but the security team can't correct the problem, we've just created a catch-22 whereby the same mistakes will be made over and over again.

How do we attack the problem? We need to change our approach to application security. Application security is not the security team's problem. It's everyone's problem. Management, the QA team, developers and of course the security team themselves must all take responsibility for security. That's easy to say but hard to do as it requires a fundamental change to your software development lifecycle so that security is embedded throughout the process. It's a radical but necessary change and fortunately there are some third party resources available. Microsoft has published a methodology known as the Security Development Lifecycle (SDL), which is essentially a parallel process detailing all that should be done from a security perspective throughout the SDLC. If you want all the gory details, you can purchase the SDL book written by Microsoft security guru Michael Howard. Still not willing to utter ‘Microsoft' and ‘security' in the same sentence? No worries, try a neutral approach such as the Application Security Assurance Program promoted by the Secure Software Forum. Finally, Google can help you find many more resources. Don't expect any of these approaches to be turnkey solutions. Just as your development process is unique to your business, so too will be your efforts to embed security throughout that process. Sorry, no silver bullet. Hard work is ahead, but it's time to get started.

- michael