Thursday 3 March 2016

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:
Yes, that 'Risk Accepted' button is the KEY for this workflow, since that needs to be done by the 'business owners' and leaves a trail of responsibility.

Once the Risk is accepted by the business owner, that risk:

a) needs to be approved by AppSec/CISO
b) is added to the list of 'accepted risks' of that team, app, product (which is distributed every week to multiple parties, including their bosses ... all the way to the CTO)

The way you deal with Risk Fatigue is to make it very real to them (i.e. what this means is that they are accepting risk). And since security issues tend to describe real probs with apps, every now and then, there is a big incident created by one of those issues (real attack or murphy), which makes it even more real (and injects more energy in fixing them)