Fair warning; this post is discussing a well known analogy, and like most analogies, they are good at explaining a concept within a well defined set of bounds. Once outside those bounds, the analogy (quite rightly) tends to make little sense. I am deliberately pushing those bounds; therefore expect this analogy to collapse at some point; probably earlier than I’d hoped.

There might be swearing.

Also, I’m not a developer…

The Analogy

Several years ago, Henrik Kniberg drew the image below to attempt to explain how agile development works. Since then the image has often been deliberately (such as here) and mistakenly, misinterpreted. Henrik has since written a post to better explain his thinking behind the image. I strongly encourage you to read it before continuing; it makes a lot of sense!

Of course, the development journey to car doesn’t actually pass via skateboard and bicycle, but the image is a good approximation of how iterative development and the idea of delivering an MVP¹ to the customer should work. For my purposes I’ll stretch this analogy further than it should go and I’ll be using the security and the safety of the system interchangably. Of course, in the real world safety and security are not synonymous.

The Problem

The product vs the solution. As usual the security challenge is not really about technology; it’s about people and process.

The analogy starts with the customer wanting to get from A to B; what they really want (we think) is a car, but we can get them an early prototype (in this case a skateboard) which will allow them to start experiencing an early benefit.

In agile development projects, we tend to focus on the product; the aim is to deliver a useful product to the customer. In doing so we often forget that what the customer really needs is a solution of which, the product is only a part, alongside the additional processes and people required to deliver an operational solution.

Where the analogy falls down is that in reality, upon delivering the skateboard, whilst Bob (We’ll call him Bob) can get from A to B quicker, every second attempt results in him falling off, unable to stop or getting hit by a car.

It turns out that the customer wants a solution to get from A to B, not just the method. In this case, a skateboard might be part of a viable solution for the customer, at least until we can deliver an improvement but part of the skateboard solution is also to provide a kitemarked helmet and a couple of skateboard lessons. When you progress to delivering the car, you can ignore the helmet and provide an airbag; let’s assume Bob already know’s how to drive but you might take him throught the new controls.

Making it Work

Security as Stories

…doesn’t work!

Maybe it can work, but it usually doesn’t in practice.

The stories get de-prioritised, popped on the backlog (at the bottom) or just plain forgotten. The other issue at odds with the development mentality of “making it work”² is that security requirements or stories are often negatively posed: “It musn’t…”, turns out there is pretty much an infinite number of things a car (or an application) shouldn’t do. “The paint musn’t catch fire when exposed to moonlight” , “The steering wheel musn’t be made of chocolate…” You get the idea. (There’s probably a mathematical arguement here that this also means there are an infinite number of counter requirements)³.

The Solution

The solution to the securing agile problem is nothing new; it’s the same shit we’ve been fighting to get accepted for the last 20 years. The more an organistion, project or development team view security as an optional bolt on, or leave it towards the end of the delivery process, the less effective and more expensive the security controls tend to be.

This is the same for Agile, XP, Waterfall and even “New Trendy Development Process” and I predict it will continue to be so for the forseeable future.

So at the risk of banging the same old security drum; the solution is to ensure that security is part of every story and is not a discrete element of the process; this also ensures that the right level of security is applied at each sprint; the skateboard gets the helmet, the car gets the brakes and airbag.

How you implement this is up to you, you could:

1. Provide security training to your developers.

2. Perform a security review (technical or otherwise) to each story.

3. Provide an internal bug bounty.

4. Automate code review and testing as part of your CI process⁴.

5. All of the above?

I’ve see many of these ideas work, but what definitely won’t, is asking your security representative to rock up to your stand up and chuck a couple of security stories onto your backlog.

That aside, we as a security industry have got to get better at engaging with agile projects, moaning about a lack of documentation, design or process won’t endear us to anyone; get stuck in and grip those stories!