Secure Development in an Agile Environment

Water and oil. Cats and dogs. Secure development and Agile environments.Everyone knowsthese things don’t mix. While the first two pairings are obvious, the later may need some explaining.  The reason that secure development and Agile methodology don’t mix is that the later hurts the former. Agile is focused on rapid and frequent deliveries with changing business requirements. Secure applications, on the other hand, often require more upfront design with an overall goal of eliminating vulnerabilities early in a development life cycle.The clash of these forces is materialized in many ways:

• Secure development practices often don’t fit well on task cards
• Can’t complete security related activities in a single sprint
• Security specialists are often not part of the daily scrum

Does this mean that there is no hope of performing secure development in an Agile environment then? Not exactly. Merging these two worlds can be done, but it takes a concerted and directed effort to align the goals of each.

 

The Solutions: 

In order to ensure that secure development takes place on an Agile team, make sure you:

1. Add a security specialist to the teamThe security specialist will be responsible for ensuring that a secure application is being developed.The individual will concern themselves with ensuring that the team has documented standards, appropriate training and a security process. Additionally, this person should be updating the threat model. Documentation should be as light as possible, as to not weigh the team down unnecessarily.
2.  Classify security tasks by time and repetition Security tasks should be classified into one of three categories.
   1. One-time requirement: Tasks that must be completed for the project to be a success. These consist of items such as establishing a security response plan or baselining the threat model.
   2. Every-sprint requirement: Items that help prevent introducing vulnerabilities. These requirements involve tasks such as updating the threat model and communicating to the security specialist any design changes that might have security repercussions. It is important that proper training was given, as programmers must follow OWASP guidelines throughout each sprint.
   3. Repeated tasks: Security related tasks that must be completed every 6 months. Examples include security verification tasks such as manual code reviews and design tasks like updating an in-depth threat model. These tasks need to be scheduled into sprints to ensure that each is completed at least every 6 months.
3.  Introduce automated security testing into your continuous integration Security tests must be run frequently so that they are uncovered as quickly as possible, and should be fixed before a sprint is released. Automation is key. Developers should have unit tests for secure requirements just like any other business requirement. Additionally, automated code analysis and vulnerability scanning should be run within the team’s continuous integration server.
4. Perform a final security review after each sprint. At the end of each sprint, the following checklist should be reviewed:
   1. All one-time requirements for this sprint are complete
   2. All every-sprint requirements have been satisfied
   3. No repeated task is more than 6 months old
   4. No security bugs are open.

Just like mixing cats and dogs in a household or oil and water in a recipe, secure development in an agile environment can occur. It simply takes a directed effort to align the goals of each. Combining a security specialist, classification of security tasks, introduction of automated security testing and a final security review into the mix will allow you to perform secure development in an Agile environment.

 

Have you performed a secure development in an Agile environment? What was your experience? Do you have any other tips? Let us know in the comments section below or join the conversation on Facebook, Twitter, or LinkedIn! 

Thanks to uvw916a for the use of their respective images.