Original URL: http://www.theregister.co.uk/2008/05/28/agile_security/
Too much code, too few application security specialists
Time to loosen up
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.
How does this work? The basic idea is that in the planning sprint, the project team works with the security team and the customer to identify key assets and threat agents - like a very high-level threat model. Then the team captures the key risks in "security stakeholder stories" that detail the security interest at stake and the recommended security control. These stories are implemented and tested just like any other stories in agile projects. The outcome is a narrow assurance argument, limited only to the particular story being implemented.
Using test-driven development is excellent for security. By defining a suite of security test cases before development starts, the team is much more likely to include the right controls and use them properly. These tests may not be quite as extensive as a full penetration test by application security experts, but it's certainly a good start.
Over time, organizations will develop a library of threat models, security stakeholder stories, test cases, security controls, and other artifacts that make the process more efficient.
Waterfall dries up
We create several billion lines of new code every year. Its therefore critical that we do more to involve development teams in securing this code. There are simply are not enough application security specialists to handle the new code, never mind the trillions of lines of code already in existence.
Agile can be used to create a well-developed assurance argument complete with test cases proving that the protection is in place. At a minimum, the tight coupling with stakeholder security stories in the agile security approach will get developers more involved with security. Of course, security specialists will still be required to provide guidance and to verify applications for more complex risks.
The application security community has a lot to learn from the agile movement. In a short few years, they have achieved impressive penetration into the software development world. By contrast, only a very few organizations have adopted a "secure" software development methodology. We are in desperate need of new methods for creating security assurance, and agile may hold the key.
Jeff Williams is the founder and CEO of Aspect Security and the volunteer chair of the Open Web Application Security Project. His latest project is the Enterprise Security API, a free and open set of foundational security building blocks for developers.