[Owasp-Mumbai] Too much code, too few application security specialists
dharmeshmm at owasp.org
Mon Jun 2 07:04:04 EDT 2008
Too much code, too few application security specialists By Jeff
Published Wednesday 28th May 2008 05:02 GMT
Agile dominates software development. According to Scott
http://www.ambysoft.com/scottAmbler.html), 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 <http://www.dynamoo.com/orange/> (
http://www.dynamoo.com/orange/), 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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Mumbai