Related topics

Too much code, too few application security specialists

Time to loosen up

Common Topics

Agile dominates software development. According to Scott Ambler, a prolific author of books on the subject in addition to being IBM's agile development practice lead, 69 per cent of organizations already use agile in one or more projects. Twenty four per cent of the rest are planning to start in the next year.

Unlike traditional waterfall projects, which progress through a series of horizontal layers until complete, agile projects work in vertical "sprints" to completely implement a small slice of functionality before moving on to the next one.

Agile's lack of formal requirements, architecture, and paperwork makes most in the security field shudder. Is it possible to build something secure without the traditional traceability the security folks like?

The waterfall model is burned deep into the security mindset. In the venerable Orange Book, assurance comes by way of formal models, traceability across lifecycle stages, test plans and test results. The agile brigade considers this top-down approach an "anti-pattern" - they even have a derogatory name for it: Big Design Up Front.

The agilistas might be on to something. From a security point of view, there are certainly problems with the big-design-up-front approach.

First, so many security problems are at the implementation level that getting a big design up front complete enough is exceedingly difficult. Further, projects frequently lose the traceability between requirements, design, implementation and testing, so there is a lot of wasted effort.

Perhaps the biggest issue when you go breadth-first, though, is all security issues tend to be treated the same - regardless of their criticality. This results in spending too much time validating, analyzing and testing things that are not likely to make a difference. While it's not impossible to prioritize this way, the waterfall model doesn't encourage it.

Re-arrange your evidence

Forcing traditional security activities onto an agile process just doesn't work - the security folks will think the agile team is out of control, and the developers will detest the security team for slowing them down. But if agile is so successful at producing software predictably, surely there must be a way to make it produce assurance as well.

If you're a security person, try this thought experiment - picture all the security evidence produced by your entire waterfall software development process. Now slice up that evidence and organize it into arguments demonstrating how you've addressed your most critical business risks. What if we can tune the agile process to produce these narrow arguments? You could still end up with all the same evidence, and it might even make more sense to organize it this way.