Event ID: 46, description: Unable to allocate development resources for security

It's been said before, I'll say it again: security does not come from tools.

The latest and greatest web app scanner or static analysis tool will not, on it's own, make your applications and your business more secure. Unfortunately, many development groups and IT organizations, under the pressure of time lines and budget guidelines, believe that these tools will offer a solution to their application security woes.

That belief is . . . . . . . . . . . . FALSE.

While these tools can be part of the solution, they are not THE solution. The real solution is to build a better process for developing code and deploying applications that contain fewer security vulnerabilities.

Such a process requires resources: people and time. This is a hard pill for development managers to swallow. From one manager: "I thought this static analysis tool was supposed to make things easier. Instead, you're asking us to do more work? WTF!"

The only reason it requires MORE work is because they were not dedicating any man hours to security. Yes, a scanner will let you find a large amount of vulnerability data in minutes. But to get any value from it, the vulnerability data needs to be analyzed and the problems need to be fixed. This takes hours, days, even weeks.

I don't ask for a lot of resources - that scares people off. I start by asking dev management to pick one person on the development team to be in charge of security and source auditing. Once they pick someone, I ask for 8 hours per application, per week, and bargain down from there. If I get a development group to dedicate 8 man hours per month to security, up from zero hours, I consider that a win.

Before we even begin looking at the source and using tools, I get the newly crowned security lead, and possibly their entire team, enrolled in basic application security training. Too many times I've scanned code with a developer only to find them not understanding what the vulnerability data actually means. Training is the only way to prevent that.

I also try to motivate the security lead to really become a security leader on their development team! They should be the one on the team who is excited about security, and works to schedule additional training for everyone, gets management to spring for new books, etc.

To sum up, development organizations need to learn to write secure code for themselves. Businesses cannot solely rely on consultants and security tools to fix the problems with application security, as this is expensive and ineffective.