How Does Agility Impact the Security of Software Development?

Posted by Tom Bain on March 1, 2012 at 11:17 AM

Another day, another dollar at RSA. But more good stuff all the way around. I attended an interesting session entitled Security in an Agile World, moderated by Chenxi Wang of Forrester. Panelists were Joel Scambray of Cigital, Jeremiah Grossman of White Hat and Ido Berger of F5.

What struck me as interesting off the bat was the drum-beating that still has to be done around application security. Application-layer attacks continue to increase in terms of severity of impact, sophistication of code engineering to execute attacks and overall, the notion that its becoming more lucrative for bad guys to hack software for financial gain.

And again, it’s the age-old argument – do I prioritize network security or securing my applications? Chenxi pointed out that in a poll Forrester conducted recently, for every dollar organizations are spending on application security, they are spending $10 spent on network security. Personally I think that is starting to change and that the gap is no longer widening, but it still exits nonetheless.

One interesting question addressed was that with the sprints within a shorter development life cycle, is it leaving less time to build in security best practices? Great question, one we deal with every day. One recommendation from Cigital was to stick to fundamentals, and adapt to the development process and how it’s changing. It's more complex now, but sticking to threat modeling for example is a risk assessment t process and a good place to start so that you can prioritize by risk.

However, Jeremiah had a slightly different take. Essentially he pointed out that organizations have to establish their own frequency of scanning web apps, and what their goals are in doing so. He commented that the move to an agile methodology doesn't really dictate frequency of scans. He recommends that organizations should scan as often as you are being attacked, or, in other words, adapt to how the attackers are attacking you. If that means every day, do it every day. His quote that drew a few laughs was “Agile is just an excuse to release crappy code, more often.”

Remediation was the next topic posed in this discussion. Cigital pointed out that the real limitation was time. And when you are assessing potential vulnerabilities in your code, and you know you are not going to fix those anyway, why do you even bother performing a scan?

White Hat pointed out that what mattered most was communication on finding and then ultimately fixing problems. And that there is a distinct difference between calendar time and actual delivery time for apps for development organizations.

Summarizing the session, it was clear that one of the major discrepancies in prioritization between security and development is with web app vulnerabilities, can't just go get a patch. If you take a developer off a revenue generating project, there is a certain element of risk in doing that, just as much as there is releasing insecure software to meet revenue goals.

The audience felt that there’s a significant lack of emphasis organizationally on training, and how to train developers on coding securely. And how to measure training. White Hat took an interesting stance saying that you can measure secure software development training if the developer is still there after 18 months. Tying in training with code scanning (and to some extent a WAF) seemed to resonate with the folks in attendance, as well as getting academia more involved with specific programs to train in security and development best practices.

With 1.2 m web sites that serve up SSL and that will never get fixed, application security professionals will certainly be in high demand for years to come. But if organizations continue to spend 1% of development budget on security, with 17M developers globally, that itself would require 340K security professionals (anecdotally) to counter this problem. We have our work cut out for us folks!

Topics: application security, sdlc

Tom Bain

Written by Tom Bain