Last week, I read what I expect to be the most intelligent tweet of 2011. A member of the OWASP board with the handle EoinKeary tweeted the following:
"Let's be very clear, #owasp is about secure dev , testing is second fiddle, IMHO."
It's funny because it's been months now that I've intended to publish a post here on the very topic. Sadly, Eoin captured in 81 characters what I intended to drone on about for much longer than that. On the plus side though, the tweet has motivated me to stop procrastinating and put my thoughts together. So here goes . . . .
First, the comment is about what OWASP's goal is, but it also speaks to application security (and more generally security for IT systems in general). The point Eoin is making though is that OWASP's goal and efforts are to improve tools and resources primarily in the secure development arena and secondarily to improve security testing. My opinion is that Eoin's comment is more broad than just OWASP though, and says a lot about what is wrong with the field of information security. I'm not sure Eoin would agree, but my point is that more generally if you are looking to spend a finite amount of resources on secure development or on security testing, then secure development needs to be the first priority.
The problem is that in most situations I've seen, the priorities are reversed . . sometimes pretty drastically. There was recently a good article on the gap between security and developers here. This got talked up around the 'net quite a bit so it's obviously hit on some truth. There is a gap between security and developers.
I see the gap quite a bit. I think one of the most illuminating indicators is the difficulty organizations have in even dealing with security requirements. Go talk to a lot of developers, architects, and requirements folks and I'm willing to bet they would argue there is no such thing as a functional security requirement. Requirements often get buried down in NFRs. NFRs are always the first to get dropped when the project hits budget or schedule issues. Aside from that, there is such a thing as a functional requirement!
As far as testing goes, it's a well established security service/function. Unfortunately, most regulations driving security are either correctly or incorrectly interpreted to be mostly a testing requirement. Look at PCI. There's no qualified security architects you can hire as part of the regulation, but you have to perform quarterly vulnerability scans and annual penetration testing. FISMA is similar. A lot of focus was placed on testing in support of certifications (as well as documentation). Unfortunately, the other requirements included in these regulations have been overshadowed, and often not implemented as intended due to the focus on testing.
The reason that prioritizing testing over development is a mistake is that testing will only ever find flaws after they've been baked into a system/application. This much is obvious. I think everyone also understands on a conceptual level that fixing a bug/vulnerability in development is significantly cheaper than fixing the same issue after deployment. We've all seen that graph which shows it's something crazy like 150 times more costly to fix a defect during operations than if it had been identified and addressed during development.
The problem is that there is a roadblock between recognizing the issue, and working on addressing it. A lot of security programs have been developed around testing. Awareness and training programs are generally severely lacking, especially in the area of secure coding and development. What we're left with in many cases is a security program is tailored towards being reactive, and at identifying issues at a point in the SDLC when it is costly to fix them.
Sometimes it seems that the talented folks in the pen testing field are the closest things to rock stars we have in the industry. And obviously there's value to vulnerability scanning, penetration testing, system reviews and audits, and other forms of testing. However, it should be priority number two, behind the things that comprise the development side: actual coding, code reviews, and security architecture.
So, kudos on the tweet Eoin. It's the most poignant thing under 140 characters that I've read so far this year.