Successfully implementing strong application security is one of the most challenging non-functional tasks Scrum teams face. Traditional application security practices which carefully integrate security throughout the Software Development Lifecycle (SDLC) are often at odds with Scrum methodology which favors responsive development cycles that quickly produce working code. To unite the strengths offered by Scrum with the necessity of security, professors from the Munich IT Security Research Group modified Scrum allowing for the successful integration of security within the Agile framework while minimizing changes to the original Scrum methodology.

The Secure Scrum Methodology

1. Identification is the process which diagnoses potential security concerns throughout the application development process. Practically, this is accomplished by marking items in the Product Backlog when security concerns are discovered. The identification process occurs during Product Backlog creation, Product Backlog Refinement, Sprint Planning, and Sprint Review.
2. Implementation is the process which ensures security concerns are properly understood by the development team and is carried out during Sprint Planning and Daily Scrum meetings.
3. Verification evaluates an application’s security is run during Daily Scrums.
4. Definition of Done represents a criteria which establishes the threshold for completion with regards to resolving an application security concern. Source: (Christoph Pohl and Hans-Joachim Hof 2015)

Defining and linking security risks to user stories in a product backlog by marking stories which contain security risks with an “S-Mark” and then describing that concern with “S-Tags” represents the core of the Secure Scrum methodology. Adding an S-Mark and related S-Tags to a user story indicates that a security concern has beenidentified, described, and formally recognized by the development team. S-Tags provide standardized definitions of specific security concerns flagged by an S-Mark. For example, attaching an S-Tag to an S-Marked user story labelled “XSS” represents a potential Cross Site Scripting attack allows developers, including those with no security training, to understand what security risks are present and the path to their mitigation. The success of this methodology was initially confirmed in field tests where university students employing Secure Scrum produced more secure code than the control groups who did not. By guiding developers through identification, implementation, verification, and also the process which defines the conditions of completion, Secure Scrum succeeds in contributing to the development of secure applications.

A second defining feature of Secure Scrum is the linking of a descriptive security layer to a user story describing the security concern. Scrum defines a security user story as an application use case where as a consequence of anattack such as data theft, a loss “that may occur whenever the functionality that implements the user story getsattacked or data processed by this functionality gets  stolen or manipulated” (Pohl and Kohl 201). In more concrete terms, this can be represented as “If an attacker gains access to this information, we will suffer $X in damages”. Although it may not always be possible to attach a loss of value, doing so will allow decision makers to understand the significance of a potential attack by employing a consistent and systematic methodology to quantify and evaluate threat mitigation efforts. If a security team can raise the cost of exploiting a vulnerability to the point where it equals or surpasses the potential value of exploiting the vulnerability, that vulnerability is considered mitigated.

Final Thoughts

The Secure Scrum methodology offers a clear, systematic, and effective means of  integrating security, however, it also inherits a number of Scrum’s weaknesses. In particular, Secure Scrum’s ability to establish and schedule longer term goals remains problematic, a problem it inherits from Scrum which overlooks documentation processes critical to many security practices. Another challenge posed by Scrum is the expectation that team members have interchangeable skillsets which would mean developers need to know security controls and secure programming techniques . Within the field of application security, this represents an ambitious undertaking as the skillsets of application security professionals are often difficult to duplicate and also in high demand.

With minimal modifications to Scrum’s agile methodology, Secure Scrum allows the integration of security practices that contribute to secure application development while also conserving Scrum’s quick, responsive approach. Although long term planning and the creation of documentation remain challenging activities, as is generally the case with agile methodologies, its success at integrating security within the software development life cycle makes Secure Scrum a clear upgrade over Scrum for identifying and mitigating application security concerns.

Related Reading

• Secure Scrum: Development of Secure Software with Scrum (Christophe Pohl and Hans-Joachim Ho 2015)
• Secure Scrum (opensecurityarchitecture.org)