Agile is not an ideal development methodology from a security perspective, but then again - what is? the Agile family of methodologies represent the dominant approach to building software today. In some ways they are quite helpful to security, not when compared to theoretical SDL approaches but when compared to actual, real world alternatives. So while Agile is not the be all, end all from a security viewpoint, as your Mom told you - make the best of it. Here are some things that work well in many Agile projects
* Test focus - this is easy. From the beginning Agile, XP et al emphasized Test Cases over almost everything else. This actually plays well with infosec's primary strength - white box and black box testing, putting the tools to work here make sense assuming that we can cope with...
* Short release cycle - infosec must be able to deal effectively with fast iteration of Agile projects, being ready to execute vulnerability assessments every few weeks, automation is a must have, and this is possible if you have...
* Dedicated staff - infosec needs team members dedicated to Agile projects, in the same way DBAs are assigned to support developers, infosec must assign appsec people to work with specific projects. To make this work, the security team must change from its traditional structure. The infosec team cannot sit in a separate group that checks in once a month or less frequently with development teams, they must be way more engaged with a infosec person carving out dedicated time to each project. Infosec should have a representative identified for each Agile project, they may not be in each and every daily Scrum meeting (though this is ideal) but they need to know the feature list, backlog list, prioritizations and other project drivers as well as everyone else on the team
Staffing up to deliver on the above positions infosec to get some ancillary benefits by being embedded with the project teams:
* Emphasis on roles - one strength of Agile is a focus on actor roles, this is a good head start on working on RBAC models for applications
* Close communication - helps to understand dev team priorities, and what and how much security is potentially going to be able to ship with which release. Visibility into what else is in the bug list
* Short release cycle - less time to to identify issues
* Heads up on what is shipping - gives better view into the assets that are being deployed, ability to inventory what may need to be fed into operational monitoring systems, and IAM
* Discover dependencies -whiteboards don't crash, but code does. Often not thinking through dependencies is the root of future problems, so being close to the ground with the development teams is essential to shake out these issues early
Permit me to dream, a bit. The issue in Agile, and all other methodoloigies, that always comes is the negative requirements that security has in spades. The long list of things we don't want to happen, these can be expressed via Threat Models, Misuse Cases and non-functional requirements, but these rarely fit well in an Agile project. Checklists can help to fill this gap by enumerating known bad ways to do things and giving specific guidance on how to avoid.
So Agile is not be everything you need for a successful appsec program, but most security teams do need to figure out how to work with Agile to make appsec happen. What have you seen be successful (or not) in Agile appsec?
In response to your question at the end of the blog post: Last year, I summarised my thoughts (which I am trying out in real life) in a write-up I posted at http://www.fokkusu.fi/agile-security/ . It mainly talks about managing backlog items that may be negative requirements. Might be helpful to some organisations.
Btw. Your comment captcha dpesn't seem to work so if this is posted in triplicate, that's because.
Posted by: Anttivs | May 31, 2012 at 03:20 PM
Gunnar,
Security experts are often closed out of scrum and other Agile efforts as part of the 'closed communication' agile tenant to maximize efficiency and focus. Having them participate in scrum and planning is important.
Checklists are one way of providing the 'what not to do' list that should be part of a pre-code check-in, or at the very least a 'before you hand this to QA' checklist. I usually put the requirements into the coding standard as well, but most developers read that once and forget it exists.
Do you advocate the automation of check lists into unit tests or other automated means, or is this a more abstract application of design and coding principles?
-Adrian
Posted by: Adrian | June 07, 2012 at 09:40 AM
@Anttivus - thanks for attaching, very interesting work
@Adrian - automation is very important. Some things on the checklist may not lend themselves to automation, because they are just as often mistake avoidance. But yes this is welcome where possible. I agree that security is often closed out of the SDLC, but there are still some incremental places to play if we come with practical guidance. Chopping checklists up into smaller bits like stuff to do Before Coding, During Coding and QA is one way to accomplish this
Posted by: gunnar | June 11, 2012 at 09:25 AM