As a business software company, we need to take security very seriously. As an Internet services company, we also must be agile to survive. Agility in software development and security often conflicts with one and the other. Agility involves rapid iterative development of new functionality. Securing a system involves being rigorous about securing functions and data through detailed designs and reviews, which normally slows down an agile process. Agile methods come with several weaknesses from a security point of view:
- Lack of sufficient documentation for proper security reviews.
- Iterative life-cycle that makes is hard to determine when to conduct reviews.
- Re-factoring which means code can change radically in the middle of a development cycle.
In order to meet our objectives, we have defined our process based on Agile methodology (we use scrum), but with some augmentations to ensure we consider security throughout the process. This makes security part of our DNA, but also enables us to work in an agile and efficient way. We base our augmented process on an analysis by Beznosov & Kruchten[1], who analyzed the mismatch between Agile processes on one hand and processes for delivering secure software on the other.
Even though we strive to work according to an agile process, we do produce some specifications as part of the process. We normally create interaction designs and product requirements as a starting point for a sprint. Product requirements are short stories and if necessary a more comprehensive description of the functionality.
If the functionality is complex, we further create a engineering requirements document (ERD), which spells out the different trade-offs from an implementation and architecture point of view. An ERD may become obsolete as we continue iterating, but since ERDs are documented as wikis and discussions related to wikis, they tend to stay fairly updated. In particular, we keep the security aspects of the ERD updated. The important role of the ERD is to ensure that certain aspects such as security and scalability are considered closely as part of our iterative development process. It is also something that can be reviewed and be used as a basis for security reviews.
We have identified a few points in our process where we conduct reviews from a security perspective. We try to do things multiple times and our experience have shown that we get best results if we conduct the review after initial PRD (during ERD, if it is needed) and at the end of the sprint. Philosophically, I compare this to the end-to-end argument in distributed systems design, which argues that certain checks are best done high in the communication stack.
Finally, we have a security gate keeper in the project. The gate keeper has the role of continuously challenging designs and implementations from a security perspective. This role has been particularly useful for us.
The following table summarize our augmentation of agile processes to ensure we develop secure enterprise software:
| Aspect | Problem | Our Approach |
| Documentation | Lack of appropriate documentation to understand security problem and approach. | We scope requirements before a sprint to identify security requirements. If complex functionality, we create a living (wiki) document called ERD that is the central point for all important design and architecture decisions, in particular security. It is central point in the sense that some aspects are described in related discussions and files, rather than the wiki itself. |
| Life-cycle | In agile processes it is difficult to find the right time to inject security reviews etc. | We have a role in the project called the security gate keeper. (The Scrum Wizard) |
| Re-factoring | Code can change radically several times during the course of a sprint. | We apply the end-to-end argument in software engineering context. We review when first version of ERD is produces, and at the end of a sprint. In between we allow re-factoring. |
I am sure other software companies deal with this in other ways and would be interested in hearing more about how you approach it?
[1] Beznosov, Konstantin & Kruchten, Phillipe. “Towards Agile Security Assurance,” 47–54. Proceedings of the 2004 Workshop on New Security Paradigms. White Point Beach Resort, Nova Scotia, Canada, September 20-23, 2004. New York, NY: Association for Computing Machinery, 2005.
