, , , ,

Ah, there’s nothing like using a false dichotomy to build a blog premise around, is there?

This post is to share some of my thoughts and findings from the research I’ve done into Agile security of late.

Agile and Security are not an either/or choice, but some aspects of typical Agile implementations can lead to insufficient attention being paid to security requirements:

  • Story/cross-cutting requirement mismatch: The cross-cutting nature of security requirements means they cannot be encapsulated within single stories or even epics/features: these requirements naturally impose themselves on a large percentage of the story base.
  • Lack of stable architecture knowledge: Existing approaches like Threat Risk Modelling rely on holistic and complete views of system architecture to find trust boundaries and threat vectors.  This information continually evolves through an Agile approach and is not complete during project Inception.
  • The YAGNI defense: The Extreme Programming philosophy of YAGNI (You Aren’t Going to Need It) can often be used to argue down attempts to rank security requirements.
  • Missing stakeholders: Security specialists are often absent as stakeholders during Project Inception, so attempts to capture security requirements rarely succeed.
  • Unbalanced prioritization criteria: prioritization is usually driven by business stakeholders who are rarely informed or incentivized around security needs.

There have been some notable attempts to merge security requirements within an Agile context however: