When you read technology news, security (or lack thereof) dominates many of the headlines. When you scan the titles of talks at Agile conferences, or you skim blog posts about Agile, you don’t see as much discussion about security. Agilists aren’t indifferent to security, but there are few clear guidelines for how to incorporate security into Agile practices. Fortunately, the ways to address security within Agile practices are not too hard, but as with anything related to security, the earlier you deal with it, the better.
Security often fits into the work of an Agile team in the following ways:
- Tasks needed to implement a story. Security often appears within implementation tasks (“When I write this class, I’ll need to encrypt this information”). More infrequently, security-related tasks appear on their own (“Integrate this module with single sign-on”). Security therefore appears below the level of the story, making explicit some non-functional requirements that may have been implicit in the text of the story.
- Emergent architecture. Without getting into a long discussion about Agile architecture, let’s just say that, unlike Waterfall, Agile allows for more experimentation and adjustment over time with the core system architecture, including security. Therefore, each sprint or release represents an opportunity to put the current security approach to the test, and make architectural adjustments, if needed.
- Testing. Security-related tests are commonplace: make sure the system locks out users after a certain number of failed attempts; create some tests to simulate cross-site scripting (XSS) attacks; determine what happens when the software can’t communicate with the identity management service; and so on. While these tests often happen later in the release cycle than they should, and testers could automate more of them, most teams can fit security into their Agile testing strategy.
- Security rules defined at the beginning, and verified at the end. Security is one of the reasons why Water-Scrum-Fall is a persistent feature of many Agile teams’ work, especially in IT. Before the project starts, people do a lot of up-front analysis of potential security issues. Later, someone blesses the package about to get pushed into production as presenting no known security threats. Where many Agile teams have matured their practices (particularly with continuous delivery and DevOps), there are still many Agile teams still working within these constraints.
While these approaches work fairly well, there’s still something missing. Frequently, security needs to appear at the level of user stories, not somewhere underneath them as tasks, not as architectural details outside the domain of a story. Sometimes, you need stories about security, for the following reasons:
- Security-mindedness should not be an afterthought. You’ll hear this refrain from security professionals — and they’re right. It’s much harder to re-engineer security into code that didn’t take it into account. There’s often value, in initial backlog creation, for including stories.
- The first stories for brand-new systems are often security-related already. Commonly, the first sprint or two includes some basic “here’s how you log into the system” stories. You don’t need to deal with all the related stories, such as how many log-ins to allow, within these sprints. However, it’s a good time, while you’re discussing security, to make sure you have those stories in the backlog somewhere.
- “Attacker” is a genuine persona. Which personas do you need the stories to represent? The ones that matter. Attackers certainly rise to this level, especially since they’ll use the system very differently than the “normal” users. Some “abuser” stories are definitely worth considering.
- Testers need to see the “unhappy path.” Security adds another level of challenge to defining the behaviors outside the “happy path” that someone needs to test. Not only may you need to test for malicious actions, but the security-generated cul-de-sacs into which people innocently drive. What do you do, for example, when the system puts your account in limbo because you haven’t logged in for 30 days?
- The code needs to keep pace with security threats. If new security threats generate new work items for a team, then it’s usually best to keep these work items in the format, user stories, that the team already knows how to handle. No need to create a separate queue for security-related work.
Several years ago, some critics of Agile raised the specter of “cowboy coders” indifferent to real risks, including security. Now, you don’t hear that largely unfounded accusation any longer, with Agile teams building enterprise systems, often with tough security, reliability, and scalability requirements. However, there’s still room for Agile teams to learn how to deal with security earlier and more effectively, and the security-related user story can help a great deal towards that end.