1 Raindrop

Pseudorandom thoughts on how to make the best of Agile

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?

App Security at QCon

The first App Security track is in full swing at QCon. I have to hand it to the folks at InfoQ and JAOO, they might be the first big development conference to take a real shot at doing a full blown app security track. Right now, Jeff Williams is presenting an Enterprise Security API (sorely needed for consistency and integration), which is slated to be released next week at OWASP's conference. The slides for the App Security track are all being added to the QCon site.

Kent Beck did a keynote and two of the main points he stressed were developer accountability and transparency. This was a perfect lead in to Brian Chess' presentation on static analysis, which remains one of the cost effective and scalable app security tools we have.

Next, John Steven presented some advanced threat modeling techniques, because this is a developer conference in 2007 most people haven't done threat modeling so it was a learning experience with a lot of real world q&a. The responses from developers who heretofore have not focused too much on security has been really positive which is nice to see.

There have been some great sidebar conversations. There are a lot of agile disciples here (of course), and they are somewhat concerned about how (and how much) security to add in to their process. This gave me a chance to reference one of my favorite papers of the year - Johan Peeters and Paul Dyson's paper on Cost Effective Security, which sorts out app security concerns in an agile way.

Cost Effective Security - Avoiding the Bridge to Nowhere

I am really happy to say that the latest IEEE Security & Privacy Journal (subscribe if you don't already - $29/year), has a great article called Cost Effective Security, its by my friend Johan Peeters and Paul Dyson. It is not really possible to overstate the importance of cost effectiveness in security. The classic IT security approach of "its perfect or its broken" is a bridge that leads nowhere. Its not a strategy for security, its a CYA. If you can't operationalize and implement your security strategy, then you don't have a security strategy. Its all about tradeoffs, ideally in some sort strategic context that helps you make progress over time, like a security architecture blueprint.

This is what makes me grateful that Johan and Paul wrote Cost Effective Security, they understand the logistics of software development, and describe ways to move forward and improve security in the real world. Additionally, they show how to account for security in an Agile process so it is not just a Big design up front exercise. One of the main issues, the authors tackle is the art and science of creating abuser stories and associating them with user stories in an Agile process. This is very important for three reasons.

1) It gets security out of the passis auditor only mode, where they come in and a) bless or b) complain about a system; and into an active collaborator and implementer -- this is the future for security groups who want to add value to their enterprise.

2) It gets security involved on day 1 of the development project, not the last week before go live when it is too late.

3) It helps security make real, live business tradeoffs anchored in a business value assessment.

The anchoring is provided, not by a "perfect security policy", but by understanding the user stories and their business goals, and then mapping abuser stories to them.

The specification and prioritization of nonfunctional requirements has so far been a somewhat black art in agile development projects. Agile’s fundamental goal is that development projects should deliver systems that are “fit for purpose” rather than ones that deliver grand technical solutions at the expense of functionality or fail to deliver anything at all, but the definition of "fit for a purpose" must include the system's non-functional requirements.

Agile is about early delivery of business value, security needs to get out of the ivory tower, stop building bridges that lead nowhere, and into the business of delivering value, security services that exist in a business context.

See Johan's blog on "Dreams and Nightmares" for some additional thoughts on associating non-functional requirements in an Agile project.

Johan Peeters on Dreams and Nightmares

Johan Peeters' Thinking Aloud blogs on the unforseen challenges of security in the SDL, specifically focusing on the challenges of dealing with security in an Agile approach:

The question is not whether and when to let economics guide planning as opposed to technical considerations. In the end, economics always win. The problem, in my view, is that we tend to see the value of a new feature, but not its cost. By cost, I do not mean the effort we need to invest into implementing the feature, but rather the cost of the nightmare scenario's that may execute as the system offers some new functionality.

This is am issue that stymied many a security mechanism. One way to look at this issue is to develop Misuse Cases that show the system from an attacker point of view in parallel with user story development, which show features and functionality. The advantage of a little extra effort spent in desgn becomes clear during future iterations and operations

Like functional requirements, non-functional requirements deserve to be revisited at each iteration. It may be comforting to think that, if you get it wrong, you get a second crack at the whip. On the other hand, you are never really done since new non-functional requirements may emerge throughout the duration of the project and old requirements that were initially deemed of secondary importance may take on an increased significance.

How many times have you seen authentication and authorization mechanisms that are weak, broken, or don't reflect a current threat model (hi MQ Series!)? But by the time the system is in production or just close to go live, it is too hard/too late to rip out all the authN and authZ because these require a full system test cycle, and so on. The examples from Johan Peeters and Paul Dyson's workshop are focused on Agile, but these issues apply across all software development methodologies.

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).