[Owasp-Mumbai] Too much code, too few application security specialists
secureas at gmail.com
Mon Jun 2 14:42:35 EDT 2008
Interesting.. except i have no idea what agile is :-(
Can someone (any developers in here?) explain in a few sentences? Seemed
like a development methodology?
2008/6/2 Dharmesh Mehta <dharmeshmm at owasp.org>:
> Too much code, too few application security specialists By Jeff Williams<http://forms.theregister.co.uk/mail_author/?story_url=/2008/05/28/agile_security/>
> Published Wednesday 28th May 2008 05:02 GMT
> Agile dominates software development. According to Scott Ambler<http://www.ambysoft.com/scottAmbler.html>(
> 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 Front<http://c2.com/xp/BigDesignUpFront.html>(
> 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.
> OWASP-Mumbai mailing list
> OWASP-Mumbai at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Mumbai