"JIRA Risk Workflow" Book , alpha version published at Leanpub

To expand the ideas I presented with Using JIRA to manage RISKS,  I decided to create a smallish book focused on how that workflow works. 

A key objective is to document the workflow better and allow to teams to implement it using their own version of JIRA (I have done multiple presentations where one of the follow up questions is "Ok, we like it, now what")

You can get this book from Leanpub (with option to get it for free) at 

https://leanpub.com/jira-risk-workflow

Please take a look and let me know what you think of the structure, font, layout, order, content, voice, idea, etc...

Using JIRA to manage RISKS - v1.0 - OWASP AppSec EU - June 2016

Here is the presentation I just delivered at OWASP's AppSec EU in Rome

Using jira to manage risks v1.0 - owasp app sec eu - june 2016 from Dinis Cruz

JIRA RISK workflow handling of 'Risk Fatigue'

On a email thread related to Updated JIRA RISK workflow (now with a 'Fixing' State), I received this great question:

I really like the idea of forcing someone to almost sign that they accept the risk. Forces them to really think about it.

One thing I'm curious about is whether there is such as thing as "risk fatigue" like you have "monitoring fatigue". So, the first few times you accept risk you do so with a heavy heart, but each time you do it and there are no perceived negative consequences, it gets a little easier. That is until the point when you're completely exposed and something bad does actually happen. Having said that, the alternative of not physically accepting the risk in some way is far worse IMO, and that by using something like Jira you can at least measure the ratio of fixed vs risk accepted over time. Hopefully it moves in the right direction!

And here is my answer:

Updated JIRA RISK workflow (now with a 'Fixing' State)

As an improvement of the workflow I showed at JIRA Workflows for handing AppSec RISKS here is a version that adds a 'Fixing' state between 'Allocated for Fix' and ‘Test Fix’.

The reason for this change, was to take into account projects (or components) that have a large number of open issues that want to be fixed (vs risks to be accepted).

Since we try to use an Kanban 'Work in Progress' model for the issues to fix (i.e. no more than 3 to 4 active items), this new state helps to keep a nice separation between the issues that:

• need to be 'Risk Accepted' (i.e. there is no intention (or resources) to fix in the next couple months)
• have been reviewed and are 'Allocated for Fix'
• are currently being worked on (i.e. in a 'Fixing' state)

JIRA Workflows for handing AppSec RISKS

Recently I have been acting as 'head of Application Security' for a couple UK companies, and one of my most effective actions has been to setup the JIRA workflow that you can see below.

The key to this workflow (and the secret of its success) is the action to get the business owners to click on the 'Accept Risk' button. 

That simple action makes the whole difference, since that is the moment that a particular RISK become REAL.

Now, the responsibility/decision/liability of NOT fixing an issue, is clearly mapped to an individual (which in some cases can even be the CTO).

Note that the definition of 'not fixing' should be 'will not be fixed in the next couple weeks'