Practical Security Stories and Security Tasks for Agile Development Environments JULY 17, 2012 Table of Contents Problem Statement and Target Audience 2 Overview 2 Assumptions 3 Section 1) Agile Development Methodologies and Security 3 How to Choose the Security-focused Stories and Security Tasks? 3 Story and Task Prioritization Using “Security Debt” 4 Residual Risk Acceptance 4 Section 2a) Security-focused Stories and Associated Security Tasks 5 Section 2b) Operational Security Tasks 29 Section 3) Tasks Requiring the Help of Security Experts 31 Appendix A) Residual Risk Acceptance 32 Glossary 33 References 33 About SAFECode 34 Problem Statement and 3. Use a non-Agile development technique but Target Audience need to interoperate with Agile environments, for example, a component development out- One of the strengths of the Agile development sourced to a vendor using Agile development technique lies in it being an “early feedback system” technique. that can potentially identify defects much earlier in the software lifecycle than conventional software Overview development techniques. With Agile, necessary changes are incorporated in a dynamic fashion. This paper consists of three Sections with content Cycles/sprints are very short, usually no more than tailored specifically to the unique needs of Agile two to four weeks, and for this reason software architects, developers and testers. development teams find it difficult (if not impossi- Section 1 ble) to comply with a long list of security assurance • Provides an overview of a sample Agile meth- tasks. Consequently, more often than not, the odology and a set of security tasks that may be development team ends up skipping security tasks beneficial. altogether; shipping software with a high software security risk level. Section 2 This paper attempts to address this gap by provid- • Section 2a consists of 36 security-focused stories ing Agile practitioners with a list of security-focused with associated security tasks. The “threat stories and security tasks they can consume “as is” landscape” for this section was developed in their Agile-based development environments. based on the most common issues SAFECode The objective of the paper is to go a step beyond members are seeing in their own environ- providing a list of security flaws and translate ments. In addition, the CWE/SANS Top 25 Most secure development practices into a language and Dangerous Development Errors list (plus the 16 format that Agile practitioners can more readily act weaknesses on the cusp list) and the OWASP Top upon as part of a standard Agile methodology. To 10 list were consulted for this section to ensure simplify things further, the recommended security completeness of coverage. A list of unique tasks are broken down by roles, including architects, “security-focused stories” was derived from this developers and testers, and the tasks that most threat landscape, followed by associated com- often require specialized skills from security experts mon security tasks for the stories. are listed separately. As such, this paper can readily • Section 2b consists of a set of 17 operational serve as a first stop for organizations which: security tasks that Agile practitioners should consider conducting on an ongoing basis. These 1. Already use Agile methods and wish to incor- have been further classified as Required or porate security tasks into or enhance existing Recommended for new or existing code, or for security tasks used in their development process. the software development team in general. 2. Use the ‘waterfall’ development technique with adequate security measures already in place, but Section 3 are evaluating moving to Agile methods without • Consists of 12 advanced security tasks that re-inventing the wheel. typically require guidance from software security experts (in-house or consultants) for the first 2 few iterations or in an ongoing manner. These How to Choose the Security-focused tasks relate more to the competencies of the Stories and Security Tasks? team members and their way of working. 1. An initial round of security analysis should be Assumptions conducted to ensure that product management understands the security-relevant aspects of 1. The audience for this paper should already business requirements. These include envisioned understand the fundamental nature of Agile system functionality, policy/compliance, legal, software development. The key concepts and contractual and regulatory requirements, and in terms are derived from Scrum or Scrum-like best cases, clear security-related requirements. methodology. However, the focus is on helping For example, if the software handles and stores the reader implement a practical approach to credit card holder data, it is likely subject to building secure software via Agile concepts and the PCI DSS requirements. At this time, product not to promote any individual practice, as each management can be consulted to verify they are organization will have different needs. prepared for this and understand the potentially 2. A team’s architects, developers and testers were strict compliance obligations associated with kept in perspective, instead of the end user, such a requirement. when choosing security-focused story names. Product management should then work through While user stories center around “use cases” these individual requirements and define more that allow the user to complete a certain task, detailed backlog items that are then entered security-focused stories revolve around “abuse into the backlog along with a proper prioritiza- cases,” which don’t reflect a typical end-user tion. At this time, appropriate security-focused view of the system, and to which the end-user stories from Section 2a should be considered has no visibility or participation. to ensure user stories are covered by relevant security stories. Security stories that are purely Section 1) Agile Development non-functional, for example “as an architect/ Methodologies and Security developer, I want to ensure graceful handling In Agile, the business requirements are typically of all exceptions,” need to be placed into the defined as user stories or epics (group of related backlog as agreed with the Product Owner and user stories). These describe expected user scenarios the development team. (“use cases,” “features,” etc.) at a fairly high level. When a new development sprint starts, the The focus is on defining system functionality with development team should pick up (or be an affirmative approach (“as a user I want to access assigned) the tasks allocated for the sprint (both my private data”) instead of by negation of an functional and security-focused tasks) and com- end-state or condition (“as a user I do not want my mence the development work. data to be exposed”). These user stories are then broken into more manageable and concrete tasks 2. Security tasks listed in Section 2b should be that the sprint team implements. They can be very incorporated in an ongoing manner in your Agile detailed and technical in nature and therefore are development life cycle. prime candidates for defining the detailed security aspects of the system. 3 3. Security tasks listed in Section 3 should be comprehensive threat model may be a costly incorporated as the tasks from 2a and 2b are activity, but one that will have long-term accomplished. benefits due to the number of defects it can reveal if performed early, and which will make Note: To maximize the effective use of this work, the tasks of system architecture and documen- security tasks associated with the security-focused tation easier in the future. stories selected during sprint planning must be part of the version control pre-check-in task list for 2. Nature of your system: Another factor when new/modified code (as applicable). The QA team considering security debt is the nature of your should also create relevant test cases mapped to system, its deployment, and the nature of the the security-focused stories and execute all of them data for which it will be responsible. Given these during testing. factors, it may be apparent that one particular attack vector would be more readily prevalent Story and Task Prioritization than others, and that might influence the Using “Security Debt” security stories and tasks you choose to address The term “security debt” in Agile software develop- first. It does not mean that the others are less ment is used to describe uncompleted tasks that important, but simply that the conditions of your have security relevance. Skipping, postponing, system dictate that these activities will mini- de-prioritizing or otherwise ignoring applicable mize your system’s attack surface versus others security-focused stories or security tasks will build that might be “good to have” but do not have as “debt” that by accumulating will likely leave the immediate an impact on your system’s security application vulnerable. Sometimes this is addressed posture. by performing security sprints that try to clear or reduce this debt, but it is recommended to try to Residual Risk Acceptance avoid building debt in the first place. Unfortunately, It is important to both inform business stakehold- sometimes it is impossible to not build security ers of any known risks left in the application that debt. Prioritization of some kind is necessary in such is approved for release to production and get their cases. In order to accomplish that, take the follow- approval for leaving these risks unresolved. The ing factors into account: sprint review conducted at the end of a given sprint should cover any issues left in the completed sprint. 1. Return on investment: Consider some of the A single release may include a large number of proposed stories and tasks; it will be easy to sprints performed by various teams, and thus there see that they directly influence not only the can be multiple known risks and issues in a release. coding of a system, but its very design. If a Any risk that may impact the business objectives team must concentrate on a select number of must be approved by the respective stakeholders stories and tasks, then the ones in this paper before release.