Hello, this is Antti Vähä-Sipilä from Nokia. I thought I’d use my first entry here as a guest blogger to talk about marrying software security and Scrum, an area which has recently kept me busy.
I’ve seen many people claim that agile methods and security are mutually exclusive, as ‘agile’ is interpreted as ‘laissez-faire’. I don’t buy this as Scrum is actually quite strict. There’s a better argument, though: As every Scrum sprint is different, mandating a specific security engineering activity in every sprint is counterproductive to agility. This is probably true.
The key observation was therefore to distinguish between actual engineering activities, such as those listed in the SAFECode Fundamental Practices for Secure Software Development paper, and security risk management, which is all about meeting an acceptable level of business risk. Scrum is a management model, and therefore, we really ought to be concerned about how risk management fits Scrum.
And after all, in Scrum, an enormous amount of trust is placed on the team. They should know best how to do the actual engineering, and to make sure they do, providing all sorts of software security training and support is necessary.
So, a scheme is required where the traditional security business risk management practices can be built into the management practices in Scrum. First, you need to identify the threats; second, you need to decide on the controls (which may be engineering practices as well, not just design decisions or features). What you’ll have left is residual risk – the part of the risks that haven’t been fully mitigated or terminated – and that has to be acceptable to the business owner.
As it happens, Scrum readily gives a lot of structure where these risk management practices can be implemented. The most complex one of these was the threat analysis part, which, when done properly, is a bit too large of an effort to squeeze into the sprint planning session. At the moment, the best proposal I’ve seen is that sprint planning only identifies the largest risks – typically those having most impact in terms of engineering – and the detailed threat analysis would be done by the team as they see fit, most likely early in the sprint.
Deciding on the controls would be done by the end of the sprint, depending on how the team organises their work. The team has three options for each identified threat: either they add new sprint backlog items and address them during the current sprint, or they postpone the work by adding product backlog items, or they make a first-level risk acceptance decision by choosing to do nothing.
The third phase, approving the residual risk, fits the sprint review. The team makes the lowest level business decision by determining whether they feel they’re ‘done’ with the sprint backlog given all the threats they’ve found, and the controls they’ve implemented. If they agree, the residual risk can then be approved by the product owner, who is also the business owner. If a product is comprised of the outputs of several Scrum teams, residual risk acceptance for particularly hard decisions can still percolate higher up if necessary.
This model has some very nice properties: if the team feels that they cannot accept a risk but they still don’t have enough time to mitigate it during the current sprint, producing a product backlog item will automatically escalate this to the product owner, and require the product owner to prioritise it for later sprints. In addition, flagging a sprint backlog item ‘not done’ in the sprint review gives the Scrum team power to voice their concerns over open security risks.
For this to work, the Scrum team does need to be acutely aware of security engineering and software security issues, and especially the threat analysis part needs to be prudently done. Security specialists should be on call. Luckily, an ideal Scrum team is also an ideal mentoring environment for security, but that will probably be a topic of another post later.