More and more organizations are adopting Agile for developing and maintaining their software systems. An Agile...
requirement management approach is mostly based on developing features. Teams using Agile often find that using user stories for defining specific security features for a product is not sufficient for developing secure products. To meet security requirements you may need additional mechanisms and practices.
Here are some suggestions for dealing with security in Agile product development:
- Stay focused on security with the definition of done (DoD).
- Validate meeting your security demands with acceptance criteria.
- Have stakeholders hack security in the product review.
- Adapt your security approach using retrospectives.
- Resolve security issues with swarming.
My opinion is that risk sessions to explore vulnerability and security still serve a purpose when doing Agile product development. You have to bring the team and stakeholders together, not only at the start of a project, but frequently, to explore what can happen and decide how you can deal with that. My suggestion is to document the decisions made in risk sessions in the DoD as criteria which need to be satisfied before software is delivered. Put the DoD on your team board to ensure that everybody stays focused on security during product development.
You can use acceptance criteria to agree on how you will validate the security of specific user stories. Acceptance criteria not only support clarifying the requirements, they also help to discuss and decide how much and which kind of security measures are needed. Defining the criteria up front helps the team to develop software that will meet security demands and to test if they are met before delivery.
In the product review, or demo as it is sometimes called, teams will show their products and ask for feedback. Stakeholders get a chance to play with the software, which also provides opportunities to break the system's security and try things that criminals or dishonest users would do to see how the system reacts. Then the team stakeholder can decide together what needs to be done to assure that the systems will remain secure.
Agile retrospectives help teams reflect on their way of working and continuously improve themselves. In a retrospective, you can explore major or recurring security problems by using a "Five Whys" exercise. It helps you to find the root causes for security issues, which can be addressed to prevent similar problems in the future. Retrospectives can also help you to fine tune how the team deals with security issues. Teams can adapt their way of working when something changes in their environment which increases the risk that a security problem can happen.
When security is breached, quick and effective actions are needed to solve the issue and prevent further damage. Swarming is an approach where a team focuses on solving one issue. People from different disciplines will work together to build a shared understanding and come up with ways to address the issue, solve it, and put the updated software into operation. Teams may need to involve some of their stakeholders, for instance product managers, program or project managers and people from operations, to be able to act quickly and effectively.
The speed and effectiveness with which security issues can be identified, analyzed and solved is important. An Agile way of working, for instance with Scrum or Kanban, can help teams deal with security by developing and delivering effective solutions quickly. My expectation is that DevOps will take this even further because the practice shortens the loops at the front end and back end of the Agile product development cycle. Issues that are detected by or reported to operations can be handled fast when development and operations people work together intensively.
Improving Agile security
How to fend off hackers
Balancing agility and security