Tuesday, January 27, 2009

Secure Coding, Web Application Security Tools and a Hammer

Tools and automation are the natural evolution of every industry from medicine, to automobile manufacturing, to structural analysis of bridges and buildings. What I never understood is the professional services industry's negative stance against the tools that have been developed to assist with debugging code. Granted, they're not perfect or 100% accurate - but then this is still a new science.

I found something very interesting in an archived Microsoft BlueHat Security Video from Fall 2008, from Vinnie Liu called "Using the Right Tools in the Right Place at the Right Time". The video and presentation is well worth the ~40 minutes or so of your time - Vinnie's a smart guy with a wit to match... but makes several points in the talk I wanted to expand on.

My favorite point is his quote "When all you have is a hammer, everything appears to be a nail". How true.

I've said this so many times it still echoes in my head - learn to write secure code, don't just learn how to fix specific point issues identified by tools (or consultants). American Express had this issue... So what's really going on? The answer is quite simple - no one is teaching developers to write better code, they're simply being shown specific instances of a breakage and told to "fix it".

Tools are partly to blame, because when an organization bases its entire secure coding strategy around a specific tool (and nothing else) the results are disastrously clear. Tools aren't to blame though, and I would content the organization has only itself to point the finger at. Tools, as Vinnie puts it, have a specific purpose and when used properly provide a tester with more accurate, faster, and more consistent results.

As far as building a program around a specific set of tools, or consultant's advice... if you do you're asking for trouble. A solid program is always grounded in process. Period, end of story. What ends up happening otherwise is developers have mistakes pointed out to them, and instead of fixing the actual problem... they fix the instance of the problem in their code. They will then repeat the mistake over, and over, and over again. This wouldn't likely happen if there was a program and process in place, founded on education and grounded with some automation tools.

So my advice? If you're entirely clueless on web application security... don't start by buying tools. Get expert advice and build yourself a SDL-integrated process, which includes a baseline of education and cooperative feedback from the development teams. Then roll that into a full-scale program which includes tollgate reviews with architects, lead developers, and program managers to ensure that someone will be listening. Once people are more aware of the problem and understand the base causes for things like Cross-Site Scripting, SQL Injection, logic flaws, etc... bring in a good set of SDL-integrated tools to make your program efficient and consistent. Oh... and don't forget to regularly use a 3rd party to checkpoint your code and process... they're expertise will far-surpass your in-house knowledge any day of the week.

If you want free advice feel free to ping me directly. I promise I won't sell you anything, only my experience. You don't have to go at it alone... and fail.

No comments: