Agile Security

Software security in agile product management
Antti Vähä-Sipilä, avs@iki.fi 2011

Preface
Intended audience
I have written this e-pamphlet for two audiences: • Security managers and specialists who one day get a visit from a young guy with a title of a ‘coach’, wearing horn-rimmed glasses, telling them that we’re agile now; • Product owners and developers who would like to bring in securityas one of the “qualities” of their product, but are afraid of the impact that security practices would cause to their agile projects. The first part of this document tries to convey the ideas behind agile and lean development that I find most important to understand when bringing security into agile. The second part delves into the actual agile security practices. The latter part builds heavilyon the concepts from the first part, and in order to ensure that our vocabularies are synchronised, I would recommend reading the sections in this order.

Some history
We started to look into software security engineering in agile product development as the company I was working for at the time was adopting agile methods, specifically Scrum and agile requirements management – product owners,epics, user stories, and so on. Our existing security development lifecycle had some challenges that I wanted to rectify. Granted, our model dated from sometime in 2002 when this topic wasn’t really yet on every conference agenda. Anyway, there was now an opportunity to polish the existing model, and at the same time, map the practices into agile software development. After about two years ofdiscussions and small trials, I believe there is now a plausible story of how security (and many other nonfunctional qualities) could be brought into an agile development environment without breaking the leanness properties. In the past events where I have been speaking, a member of the audience has proposed that writing a book would be a good idea. So, I thought – why not? But instead of a book (which,I think, should have at least 200 pages and I would be sweating over typography for longer than the actual text) I decided to publish an epamphlet, which I hear is nowadays fashionable. This will hopefully free me from having to use bullet points in the presentations and just project inspiring microstock images behind me. The ideas in this e-pamphlet have been collected and built upon fromdiscussions with several people. I would like to credit, in no specific order: Martin von Weissenberg for the initial start; Vasco Duarte and Camillo Särs for the first public shot at it with Agile 2

Finland; the participants of various events where I’ve talked about it; Heikki Mäki from my previous team; Lauri Paatero for some very valuable commentary; and finally, an agile guru from Nokia’s MobilePhones organisation who gave excellent feedback but whose identity unfortunately still remains a mystery to me.

I have also written that part for people who have not had experience with agile development, and may be wondering what it is all about, and who would benefit from it. There are probably hundreds of other treatises on what agile means, but this one is mine. When I refer to agilemethodologies and specifically Scrum, have taken to use the term Ideologically Pure Scrum, for which I mean the Scrum as described in Ken Schwaber’s and Mike Beedle’s book, Agile Software Development with Scrum (2001). I believe that Ideologically Pure Scrum does not exist anywhere where Scrum is being used. All applications of it are probably tainted by something. I’ve still chosen to use theIdeologically Pure Scrum as the measurement standard, because if you know how your specific Scrum is tainted, you can also take the advice in this pamphlet and taint that in a similar way so it fits the peculiarities of your flavour of agile.

Caveat emptor
Some teams could be claiming they use agile methods, but when you dig deeper, you see that they are in fact using cowboy agile1 – essentially a...