Institutionen för datavetenskap
Department of Computer and Information Science
Final thesis
Secure Scrum During the Development of a
Configuration Tool for Generic Workflow
by
Joel Paulsson
Charlotta Westberg
LIU-IDA/LITH-EX-A--10/052--SE
2010-12-21
Linköping University
Department of Computer and Information Science
Final Thesis
Secure Scrum during the development of a
configuration tool for generic workflow
by
Joel Paulsson, Charlotta Westberg
LIU-IDA/LITH-EX-A--10/052--SE
2010-12-21
Supervisor: Per Flodin
Examiner: Nahid Shemherhi
Abstract
Secure Scrum is a framework that integrates security into Scrum. In this thesis Secure Scrum has been evaluated in the development environment at Medius. An aim for the thesis was to implement a configuration tool for the module Generic Workflow in Medius’ product MediusFlowTM. In order to evaluate Secure Scrum, this framework has been used during the development of the configuration tool. Before this thesis began a configuration tool existed but it was Medius’ wish that this configuration tool was redesigned and rewritten. The requirements for the configuration tool were to meet the functionality with the previous configuration tool and add some new functionality. The new implementation of the configuration tool fulfills these requirements successfully.
The results of the evaluation of Secure Scrum is that the usage of it during development of the configuration tool went smoothly, and the conclusion of this is that Secure Scrum is a flexible framework that was easily adapted to a smaller development team and a project lifetime of a few months.
Acknowledgements
We would like to thank Professor Nahid Shahmehri and David Byers at Linköping University and supervisor Per Flodin at Medius. We also wish to give thanks to opponents Daniel Johansson and Mansoor Munib.
Table of Contents
Abstract ... 11
Introduction ... 1
1.1
Background ... 1
1.1.1
Configuration Tool ... 1
1.1.2
Secure Scrum ... 1
1.2
Purpose and Scope ... 1
1.3
Method ... 2
1.4
Structure ... 2
1.5
Sources ... 3
2
Theory ... 4
2.1
Workflow ... 4
2.2
Generic Workflow ... 4
2.3
Scrum ... 6
2.3.1
Scrum Teams and Their Roles ... 7
2.3.2
Time-‐boxed events ... 7
2.3.3
Artefacts ... 9
2.3.4
The concept of done ... 9
2.4
Secure Scrum ... 10
2.4.1
Changes to the Product Owner Role ... 10
2.4.2
Changes to the Team Role ... 11
2.4.3
Added artefacts ... 12
2.4.4
Changes to ceremonies ... 12
2.5
Security Development Lifecycle ... 13
2.5.1
Training ... 13
2.5.2
Requirements ... 15
2.5.3
Design ... 15
2.5.5
Verification, Release and Response ... 17
2.6
SDL-‐Agile ... 18
2.7
Security ... 19
2.7.1
Risk Analysis ... 19
2.7.2
Abuse/Misuse Cases ... 20
2.7.3
Vulnerabilities ... 20
2.7.4
Testing Security ... 22
3
Potential Approaches ... 24
3.1
Reusing Code or Writing New ... 24
3.1.1
Reusing Code ... 24
3.1.2
Writing New ... 24
3.1.3
Our Decision ... 24
3.2
Comparing SDL or TSP with Secure Scrum ... 24
3.2.1
SDL ... 25
3.2.2
TSP-‐Secure ... 25
3.2.3
Our Decision ... 26
4
Technical Background ... 27
4.1
The Previous Configuration Tool ... 27
4.1.1
Explanation of Terms ... 27
4.1.2
Why A Configuration Tool Is Needed? ... 28
4.2
Model-‐View-‐ViewModel ... 28
4.3
Requirements ... 29
5
Design ... 31
5.1
Scrum ... 31
5.1.1
Changes to Scrum ... 31
5.2
Secure Scrum Study ... 31
5.3
Model-‐View-‐ViewModel ... 33
5.3.1
Model ... 33
5.3.3
ViewModel ... 34
5.4
Threat Analysis ... 34
5.4.1
Threats to the Configuration Tool ... 35
6
Implementation ... 37
6.1
Usage of Scrum and Secure Scrum ... 37
6.1.1
Changes during the thesis ... 37
6.1.2
Daily Scrum ... 37
6.2
Implementing the Configuration Tool and MVVM ... 37
6.2.1
The Model ... 37
6.2.2
The View ... 40
6.2.3
The ViewModel ... 43
7
Results ... 47
7.1
Secure Scrum ... 47
7.2
Development ... 47
8
Evaluation ... 49
8.1
Usability of Secure Scrum ... 49
8.1.1
Within Medius ... 49
8.1.2
Standardized Point of View ... 49
8.2
Comparison between SDL and Secure Scrum ... 50
8.3
Evaluation of us ... 51
8.3.1
Secure Scrum ... 51
8.3.2
Development ... 51
8.4
Of our Solutions ... 52
8.4.1
Secure Scrum ... 52
8.4.2
Unit Tests ... 52
8.4.3
Data Binding ... 53
8.5
Future Work ... 53
8.5.1
Secure Scrum ... 53
8.5.2
Configuration Tool ... 53
9
Conclusions ... 55
Table of Tables
Table 1: Examples of requirements in SDL-‐Agile ... 19
Table 2: Future work on the configuration tool ... 54
Table of Images
Image 1: Illustration of a workflow ... 6Image 2: Illustration of the Scrum lifecycle ... 6
Image 3: The prior configuration tool ... 27
Image 4: Illustration of Model-‐View-‐ViewModel ... 29
Image 5: Sheet for the evaluation of Secure Scrum ... 32
Image 6: The prototype of the configuration tool (the right side-‐panel) ... 34
Image 7: The final view of the configuration tool (the right side-‐panel) ... 48
1 Introduction
This chapter will describe the background, purpose and scope of the thesis. A description of the methods that have been used during the thesis can be found in section 1.3. The structure of the thesis report is described in section 1.4.
1.1 Background
This section describes the background as to why the thesis is necessary, from Medius perspective, the school’s perspective and a general perspective.
1.1.1 Configuration Tool
At the start of this thesis, in July 2010, Medius had a configuration tool for their generic workflows. The configuration tool is used for configuring a document that travels through a workflow. The complexity of the documents that are configurable in the tool has grown since the original tool was developed and requirements of external data sources have been introduced. The internal look of the tool is not modelled in a practical way for reuse and maintainability, and the external look does not match the product in which the tool is integrated. This means that the configuration tool that Medius had at their disposal at the time did not provide sufficient functionality or usability.
1.1.2 Secure Scrum
Secure Scrum is a newly developed process by Linköping University. It is a software development framework that builds upon the Scrum framework, and aims to add security to Scrum. It needs to be evaluated at a company site where it is unlikely that the theoretical version of Scrum is being used.
While Medius do not offer any network connected technology at the time of writing, there are thoughts of bringing the product to the network, which would mean increased security threats, and they would need a process to handle this.
1.2 Purpose and Scope
The purpose of the thesis was as follows:
1. Design a configuration tool for generic workflow. 2. Implement a configuration tool for generic workflow. 3. Use Secure Scrum during the entire development process.
4. Evaluate Secure Scrum from Medius’ point of view and from a typical scenario, and compare it with another secure development process.
The thesis also has a few limitations in order to get a correct time scope.
2
1.3 Method
The method that we chose to use during this thesis has been successfully used by many other thesis workers and therefore we organized our work as is described below.
• Theory Collection
In the first step we read up on theory regarding workflows, generic workflows, Scrum and Secure Scrum. We also read about Security Development Lifecycle and other secure processes. We read up on security, and what kind of threats there may be against a software application. We also read a lot of theory on C# which was the programming language used, as we were both new to it. A lot of technical data about the existing configuration tool was also read up on.
• Possible Solutions
Here, we gathered information about what different methods could be used to solve the thesis’ purpose. We also chose which solutions to use.
• Design and Threat Analysis
Here, a threat analysis was performed on the configuration tool. A design for the configuration tool was created in order to decide what the finished system would look like and what attributes and functions it would contain. Here, we also identified some changes that would need to be made to Scrum before we started to use it.
• Implementation
In this step, we implemented the configuration tool while using Secure Scrum.
• Evaluation
In the last step, the entire work was evaluated, with regards to things that went well and things that could have gone better. We also went through future improvements to both the configuration tool and Secure Scrum.
1.4 Structure
The thesis report is constructed by the following chapters: Chapter 1: Introduction
This chapter introduces the reader to the thesis and to the report. Chapter 2: Theory
This chapter is an overview of the theory needed for the completion of this thesis. Chapter 3: Potential
Chapter 4: Technical Background
This chapter goes through the technical background of the configuration tool. Chapter 5: Design
This chapter explains the work put into designing the tool and creating a threat analysis for it.
Chapter 6: Implementation
This chapter explains the work put into implementing the configuration tool and the use and integration of Secure Scrum into Scrum.
Chapter 7: Results
This chapter describes the results of the implementation of the configuration tool and Secure Scrum
Chapter 8: Evaluation
This chapter evaluates the results and the processes used. It also describes any future work.
Chapter 9: Conclusions
This chapter lists the conclusions that have been made during the thesis.
1.5 Sources
During this thesis, the Vancouver system is used to refer to sources. If there is anything in the text that we think may be interesting to have more information about, but is not within the scope of the thesis, we have included a link in a foot note. Our sources are mainly taken from white pages on the Internet, and from books that were written later than 2002, in order to get the most recent information. We have in many cases supplemented our Internet sources with corresponding information from printed books.
4
2 Theory
This chapter explains the theory behind the main parts of this thesis. This includes explaining workflows, Scrum, Secure Scrum, SDL and security.
2.1 Workflow
To understand what a workflow is there is a need to explain what a business process is. This is because a workflow is when a person is doing defined activities in a business process. A business process is defined as “A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships.” (Workflow Management Coalition, 1999, p. 10). A business process can be exemplified by the administration of a vacation request or by the sending of an invoice. A workflow is the actual instance of a business process. An example that can be given to illustrate this is the workflow of the vacation request. The business process for a vacation request begins with an employee filling out a vacation request document, and then the employee sends the document to the manager by mail. The manager reads the document and either accepts the vacation request or denies it. Finally, the manager mails the document back to the employee. The workflow for a vacation request is when an employee and a manager are doing the activities that are defined in the business process described above.
Today, a lot of the administration of documents is handled automatically by computers. This has changed the definition of a workflow. Today, a workflow is defined as: “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.” (Workflow Management Coalition, 1999, p. 8). The managing and automation of a workflow is done by a workflow management system, which is defined as “A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications.” (Workflow Management Coalition, 1999, p. 9). The vacation request example that we used earlier can be used to illustrate the automation as follows. Luke, who is an employee at a company, opens a vacation request document in the workflow management system and fills in the document. Upon closing the document, the management system automatically sends it to Luke’s manager. The manager is notified by the management system of the existing request and opens the document to accept or deny the vacation request. When the manager closes the document, it is returned to the employee by the management system and the employee is notified that a decision has been taken. (Plesums, 2002)
2.2 Generic Workflow
Workflow management systems are good for managing workflows, though they generally do not support changes in workflows. A change in a workflow can be everything from a small change in the workflow for one customer to a complete
restructure of a workflow to improve efficiency. Because of the lack of support for changes, the only way to deal with a change in a workflow is to go behind the system and edit in a workflow, and doing this makes the system more of a liability than an asset.
The solution to the problem described above is provided by something called a generic workflow process model. This is a flexible way of dealing with both small changes and complete restructures to workflows. A process in generic workflow is the same as a business process, as was described in section 2.1, for example job applications or invoices. Each process includes one or more activities, and each activity is a task that needs to be done. Each activity in the process can be specified with a task, but the activity is not specific for a process. Examples of activities are to create a document or send an e-‐mail. A process can also include sub processes and generic processes. A sub process is a process that is instantiated by another process and a generic process is a process that relates to a family of processes rather than to a specific process. The generic process must have at least one family member where a family member can be either a sub process or an activity. To describe the route between the activities in a process there are so called routing elements. There are elements for an AND-‐split, AND-‐join, OR-‐split, OR-‐join, After, Begin, End. These elements can be used to create a parallel, iterative, sequential, alternative or conditional routings in the process. Image 1 gives an example of elements that have sequential, conditional and parallel routings.
A process model can be described by something called routing diagrams. This is to visually describe the workflow in a process and to get a better overview of the workflow. These diagrams include: activity, sub process, generic process, AND-‐split, AND-‐join, OR-‐split, OR-‐join, After, Begin and End.
To illustrate a generic process, we once again return to the vacation request example that was first mentioned in section 2.1. We will make a few changes as to how the vacation request should be handled in the workflow. Now, a vacation request originating from an employee with employee-‐number between 1 and 1000 may only be accepted by the staff manager. The vacation requests of the employees with employee number above 1000 should be accepted by their unit manager. This means that if Linda, with employee number 456, opens and sends a vacation request it will be sent to the staff manager. If Luke, with employee number 1234, opens and sends a vacation request, the management system will check the generic process for “Unit Managers” where it will find Luke’s unit manager, and then it will forward the vacation request to that manager. Image 1 is an illustration of this example. (Aalst, 2001)
6
Image 1: Illustration of a workflow
2.3 Scrum
Scrum is an agile software development framework where different processes and techniques can be used. Scrum exposes the efficiency of the user’s development practices so that they can be improved upon and provides a framework for complex product development. (Sutherland & Schwaber, 2010) (Schwaber, 2004)
Image 21 shows an illustration of what the Scrum lifecycle looks like. At the beginning, there are a set of Product Backlogs that are split into Sprint Backlogs. During the Sprint of two through four weeks, the Sprint Backlog Items are worked through, and every day there is a Daily Scrum Meeting. The work from every Sprint should result in a potentially shippable product increment. All of these terms are explained in this chapter.
Image 2: Illustration of the Scrum lifecycle
1 Image source: http://www.mountaingoatsoftware.com/scrum/figures 2 https://www.fortify.com/ssa-‐elements/threat-‐intelligence/rats.html
2.3.1 Scrum Teams and Their Roles
There are various roles belonging to the people utilizing Scrum. The Scrum Team consists of everyone that is involved in the project. There are three roles within the Scrum Team: ScrumMaster, Product Owner and the Team. (Sutherland & Schwaber, 2010) (Schwaber, 2004)
ScrumMaster: The ScrumMaster should know everything about Scrum, and is responsible for ensuring that everyone in the Team follows Scrum’s values, practises and rules. The ScrumMaster should help the Scrum Team to do its best in an organizational environment and may make changes in order to achieve this. The ScrumMaster should for example make sure that the Team is not disturbed by employees wanting to get something developed on their own behalf. The term “removing impediments” is used for when the ScrumMaster helps making these changes.
Product Owner: The Product Owner is in charge of the Product Backlog which is explained in section 2.3.3, and there should only be one Product Owner. The Product Owner is the only one that is allowed to prioritise items within the Product Backlog, and is in charge of keeping it visible to everyone so that the Scrum team knows which items are, and are not, being worked on.
Team: During every Sprint, which is explained closer in section 2.3.2, the Teams of developers turn the Product Backlog into shippable functionality. The Team members all need to be able to turn a requirement into a usable product. It is the Team’s sole responsibility to turn the Product Backlog into increments of shippable functionality. A Team usually consist of around seven people. If a Team has fewer members the result will be less interaction and less productivity gain. If there are more members in the Team, too much coordination between the Team members will be necessary, and the complexity this produces is too high for the process.
2.3.2 Time-boxed events
There are time-‐boxed events used within Scrum. These are explained in this section and exist to create regularity within the process. A time-‐boxed event is an event that shall take place within a set amount of time. (Sutherland & Schwaber, 2010) (Schwaber, 2004)
Release Planning Meeting: The release planning meeting is an optional meeting and has the purpose of establishing a plan and goals that the Scrum Teams and the rest of the organisations can understand and communicate. The release planning should answer the questions: “How can we turn the vision into a winning product in best possible way?” and “How can we meet or exceed the desired customer satisfaction and Return or Investment?” The meeting will establish the goal of the release, the major risks and the features and functionality that the release will contain. It should also give a preliminary delivery date and a cost that should hold if
8 there are no changes. The release plan can be changed in accordance with the Sprints.
Sprint: A Sprint is an iteration of at most one month, during which the ScrumMaster ensures that no changes that would affect the Sprint Goal (see Sprint Planning Meeting below for explanation) are made. The Sprint is illustrated by the large circling arrow in Image 2. The Team composition and quality goals remain constant throughout the Sprint. In the beginning of a Sprint there is a Sprint Planning Meeting which is explained below, after this meeting the development work takes place, and at the end there’s the Sprint Review and the Sprint Retrospective, both of which are explained more closely below. As soon as one Sprint has ended a new one begins. A Sprint can be cancelled by the Product Owner, but that is rarely the case due to the short duration of Sprints. One example as to why it would be cancelled is that the Sprint Goal has become obsolete.
Sprint Planning Meeting: A Sprint Planning Meeting is held in the beginning of a Sprint and is time-‐boxed to eight hours for a one month Sprint, and if the Sprint is shorter the planning meeting time should be altered proportionately. There are two parts to the Sprint Planning Meeting, time-‐boxed to four hours each, where the first part addresses the question “What?” and the second part addresses the question “How?”. During the first part of this meeting the Scrum Team works together to select the Product Backlog and a Sprint Goal is created. The Sprint Goal is the objective that shall be met when the Product Backlog has been implemented. During the second part the Team determines how it will turn the Product Backlog that was selected during the first part into a done product increment.
Sprint Review: The Sprint Review meeting is held at the end of a Sprint. Like the Sprint Planning Meeting, it is a time-‐boxed meeting and time is adjusted proportionally for shorter Sprints. The Sprint Review meeting is time-‐boxed to four hours for one month Sprints. During this time, the team present and discuss what has been done during the Sprint with the Product Owner and any other stakeholders that wish to be present. When the functionality has been presented they cooperate in deciding what the team should do during the next Sprint.
Sprint Retrospective: The Sprint Retrospective meeting is held after the Sprint Review meeting at the end of a Sprint. The meeting is time-‐boxed to three hours for a one month Sprint and is adjusted proportionally in case of a shorter Sprint. During this meeting the Scrum Team will revise its development process to make it more effective for the next Sprint. The meeting should identify items that went well during the Sprint and items that could have gone better if they had been done in a different way.
Daily Scrum: The Daily Scrum is time-‐boxed to 15 minutes and takes place every day, as is illustrated in Image 2, during a Sprint. All the Team members shall attend. There are three items that every member of the Team will explain to the others:
1. What he or she has accomplished since the last meeting 2. What he or she is going to do before the next meeting 3. What obstacles are in his or her way
The ScrumMaster is responsible for ensuring that the Team members have this meeting, and the Team is responsible for having it. The Daily Scrum meeting is a key inspect and adapt meeting in the Scrum empirical process. It inspects the progress that has been made towards fulfilling the Sprint Goal that was set during the Sprint Planning Meeting.
2.3.3 Artefacts
There are four fundamental artefacts to Scrum: the Product Backlog, Release Burndown, Sprint Backlog and Sprint Burndown. (Sutherland & Schwaber, 2010) (Schwaber, 2004)
Product Backlog: The requirements of the product that is being developed by the Team(s) are in the Product Backlog. This is never complete, and keeps evolving along with the product and the environment in which it is used. The Product Backlog consists of changes that need to be made to the product for upcoming release and is a list of all features, functions, technologies, enhancements and bug fixes. The Product Backlog is sorted based on priority, and when a new Product Backlog Item (PBI) needs to be chosen it will be chosen from the highest priority. There can always be changes to the Product Backlog. Items can, and will, be added, removed and re-‐prioritized.
Release Burndown: The Release Burndown is a graph that shows the amount of work that remains in a Product Backlog Item. It is kept up to date by the Product Owner.
Sprint Backlog: The Sprint Backlog is a list of tasks that the Team needs to perform in order to turn the Product Backlog it selected into a product increment that is potentially shippable. These tasks are called Sprint Backlog Items (SBI) and have a usual size of one day or less in order for everyone at the Daily Scrum meeting to be able to completely comprehend its progress. An initial list of these tasks is created during the Sprint Planning Meeting and only the Team may change the Sprint Backlog.
Sprint Burndown: The Sprint Burndown is a graph that shows the amount of work that remains in the Sprint Backlog during the Sprint. It is calculated every day through summing the backlog estimates of the Sprint.
2.3.4 The concept of done
Scrum should be used in a way so that there is a new increment of product functionality after every Sprint. This increment must be something that may be shippable in the case the Product Owner chooses to release the functionality immediately. In order to be able to achieve this, the increment must be done. This
10 state can be achieved through ensuring all increments are additive to all prior increments and thoroughly tested in order to ensure that the integration of the increments is successful. It should include all the analysis, design, refactoring, programming, documentation and testing for the increment and all PBIs in the increment. (Sutherland & Schwaber, 2010) (Schwaber, 2004)
2.4 Secure Scrum
Scrum, on its own, does not explicitly address security. It is possible to implement security functional requirements within the limits of the framework, but the security aspects that do not translate directly to functionality are more difficult, and this is where Secure Scrum comes in.
Secure Scrum integrates security with Scrum while keeping the core principles, concepts and practices of Scrum. A few aims that Secure Scrum has are that:
• The impact of security is made visible.
• The lean principles behind Scrum are adhered to and there is a particular focus on eliminating waste, building quality in and respecting people.
• Security is integrated into existing roles, ceremonies, and artefacts to the extent possible.
• New rules and artefacts should feel similar to existing ones and fit into existing activities.
With security, which generally is looked at as a non-‐functional requirement, the concept of done, as explained in section 2.3.4, does not always exist. The security requirements may instead be properties of everything that is developed, or they may be related to the process rather than the product. Some security requirements are negative and tend to live forever which makes them different from normal requirements.
Since the security requirements have business value; they are owned by the Product Owner, but in Scrum, the development process and practices are owned by the ScrumMaster and Team. This means that some changes have to be made to Scrum, or rather, the ownership of certain parts of the process and practices needs to be transferred to the Product Owner, without infringing on the ScrumMaster and the Team. (Shahmehri, 2010)
2.4.1 Changes to the Product Owner Role
The Product Owner gets some new responsibilities with the integration of Secure Scrum. These are:
• Identifying and prioritizing potential security requirements with respect to each other and to PBIs.
• To break down security requirements into PBI-‐sized pieces.
• To quantify the business value of security requirements in such a way that they can be compared to the business value of features.
• To translate negative requirements into positive ones, where possible and appropriate.
• To maintain the Security Backlog and committed security list.
Identifying security requirements: There can be many sources for security requirements, such as customer requirements, certification requirements, standard requirements and etcetera. They are no different from other requirements, but may include requirements on the process and the development practices.
A threat analysis on the PBIs that are the closest to being started on in the Product Backlog is performed by the Product Owner. The Product Owner also needs to maintain an up-‐to-‐date threat analysis for the entire product. Each threat to the product or PBI implies a potential security requirement.
Business value: A security requirement’s business value can directly be estimated, especially when it’s a functional requirement that has come from evaluation of customer needs. There are, however, security requirements that have no business value; the most prominent ones being requirements related to preventing threats. While a business value is absent, there is likely a potential or expected business impact resulting from not satisfying these requirements. The expected impact of a security requirement can therefore be used as its business value, which any risk analysis method can be used to estimate.
Translating negative requirements: If there are any negative requirements these should, to the extent possible, be translated into positive (measurable) ones. This should be done by the Product Owner when there is a reason for selecting a specific translation, otherwise it should be done by the development team who can do it as a part of the Sprint Planning Meeting. As an example, the negative requirement: avoid
SQL injection could be translated into e.g. always use prepared statements for SQL queries.
Threats are originally placed on the Security Backlog (see section 2.4.3) and when they have mitigation strategies these strategies are added to the Product or Security Backlog in place of the original threat. (Shahmehri, 2010)
2.4.2 Changes to the Team Role
The Team gets some new responsibilities with the addition of Secure Scrum. These are:
• To translate negative requirements into positive ones.
• Breaking down security requirements into manageable parts and committing to these items.
• To estimate the impact on team velocity that introducing or changing practices or processes will have.
• Carrying out the work in accordance to practices and processes that the team has committed to.
12 Translating negative requirements: As was described in section 2.4.1, the Product Owner or the Team translates the negative requirements into positive ones. The Team might find more than one translation of a requirement in which case the Product Owner should be notified for prioritizing of the options. (Shahmehri, 2010)
2.4.3 Added artefacts
Two artefacts have been added with the integration of Secure Scrum: the committed security list and the Security Backlog. These are necessary because security requirements often have different character from the normal Product Backlog items, and their business value is estimated in a different way. (Shahmehri, 2010)
Committed security list: The committed security list is where all the security issues that the Team has committed to reside. These security issues (henceforth called items) are long-‐term and lack a concept of done, since all the items not of this type have already been converted into PBIs and SBIs. The list may be altered during the Sprint Planning Meeting, and is consulted during the Sprint Planning Meeting, during the development and during the Sprint Review meeting.
Security backlog: In this backlog all the security issues that the development team has not committed to lie. It may contain items of any character, including items that have not been converted to PBIs or SBIs even if it is possible.
The maintenance of the Security Backlog is kept by the Product Owner, and it is prioritized by the estimated business value. Anyone that finds a security issue may add an item to the list, but the Product Owner is solely responsible for prioritizing the item.
2.4.4 Changes to ceremonies
A few additions need to be made in the ceremonies of Scrum, mainly to allow for the added artefacts to be used. The altered ceremonies are the Sprint Planning Meeting, Daily Scrum and the Sprint Review meeting. (Shahmehri, 2010)
Sprint Planning Meeting: The purpose of the Sprint Planning Meeting is, just as it was explained in section 2.3.2, to determine what the team should commit to in the following Sprint. Secure Scrum only needs minimal changes to the Sprint Planning Meeting. These are:
• Rather than only selecting items from the Product Backlog, they are also selected from the Security Backlog. The Product Owner compares their business values to determine priority.
• Selected negative requirements are converted to positive requirements before any estimation is made.
• Selected items that lack done should be broken down into items that can be
done. This should be done by the Product Owner and the Team before the
• If an item cannot reach the state done and cannot be broken down into items that can be done, the team should estimate the impact this will have on their velocity in the next Sprint. The estimation can also be performed during the Sprint if it is agreed upon by everyone. This is done in order to reduce the risk of over-‐committing on other work.
• To add an item into the committed security list the team must identify tasks to ensure that the entire product will meet any new security requirements. These tasks must be committed to in the next Sprint for the item to be eligible to add to the committed security list.
• Selected items that lack the concept of done are added to the committed security list if the prerequisite tasks have been committed to in the Sprint. All other items are added to the Sprint backlog in the usual fashion.
Daily Scrum: While the Daily Scrum still retains everything as in Scrum it is important that the developers remember to bring up any lack of security know-‐how as an impediment if applicable.
Sprint Review meeting: Any activities in the Sprint Review meeting that have any relation to the Product Backlog are also extended to apply to the committed security list and the Security Backlog. An identification of the issues that have been satisfyingly handled should be handled by the Product Owner. Prioritizing any security issues is discussed with the Team and other stakeholders. Any non-‐relevant security issues should be identified.
The retrospective part of the review meeting consists of the Team assessing how they have worked with security issues, and identifying any improved practices that could be implemented. If any improved practices are found they are added to the Security Backlog for the Product Owner to appraise.
2.5 Security Development Lifecycle
Security Development Lifecycle (SDL) is a process developed by Microsoft that can be used on any software development methodology (i.e. Waterfall, Agile or Spiral). SDL aims to integrate security into every phase of the software development lifecycle, which means that SDL’s final goal is to reduce the severity, and number of vulnerabilities in software. The phases in the development lifecycle, which SDL adds requirements to are: training, requirements, design, implementation, verification, release and response. SDL defines requirements for what has to be done in each phase during a development process and recommendations for what to do during the development. The SDL process is described below, and the tasks that are described are requirements in the SDL process. (Microsoft, 2010)
2.5.1 Training
Before a development team can start using SDL; each person in the team needs appropriate security training. Microsoft also emphasizes on the importance of
14 keeping the security knowledge up to date, and that the development team should attend security classes each year. (Microsoft, 2010)
Basic security training before using SDL should cover these topics: • Secure Design • Threat Modelling • Secure Coding • Security Testing • Privacy
2.5.2 Requirements
A basic aspect of developing secure software is to consider security from the start of the software development. By following SDL’s requirements during this phase, security is considered on a basic level, and the project team considers the costs and risks within the project.
During this phase a security advisor is appointed to the project; this advisor will serve as the first point of contact for security support for the duration of the project. Another thing that should happen during this phase is that a team or an individual that will be responsible for tracking and managing security for the software should be appointed. This team or individual will be responsible for communicating and coordinating the status of security issues during the project.
Once the security requirements are defined, quality gates and bug bars need to be defined. Quality gates and bug bars are used to set the acceptable minimum security and privacy levels on the software. The quality gates are defined by the project team, at each development phase and the quality gates should be approved by the security advisor. A process that describes how to handle and approve exceptions of quality gates and bug bars should be defined. The process should demand approval from both the product team management and the security experts, who are aware of the potential risks with the security exception, so they can make necessary plans for the future to mitigate those risks.
The last step in the requirements phase is mandatory in SDL: the assessment of security and privacy risks. This step will identify which functionality that will need what types of reviews. The assessments should answer questions such as: “which functionality need threat modelling and security design reviews?”, “What is the scope for the fuzz testing?”, “What privacy impact rating will the software have (high, medium, low)?” (Microsoft, 2010)
2.5.3 Design
In SDL, the design specification should describe security and privacy features that the user is directly presented with (i.e. a login screen to access the system). The design specification should also describe how to securely implement all functionality for a feature in the software. Some design requirements are to create security and privacy design specifications, perform a security design review and write a specification of minimal cryptographic requirements. The security design
16 review is done together with the security advisor. If the privacy impact rating, defined in the privacy assessment during the requirements phase (see section 2.5.2), is rated as high for the project a privacy design specification and a privacy design review is mandatory.
The attack surface should be analysed during the design phase, this is done through analysing where attackers can attack the system, and through this, learn what actions need to be taken to reduce the attack surface. For example, some actions may be to restrict access to certain parts of the system or employing layered defence. Microsoft recommends the following as the minimum actions for attack surface reduction.
• Use strong named assemblies and Code Access Security correctly. • Use firewall exceptions with care.
• Design the software to work fully as non-‐administrator.
Before the team can move into the implementation phase the team needs to make threat models of the parts of the software that has been set during security assessment in the requirements phase, see section 2.5.2. Threat modelling is the primary risk analysis that is made during the development phase. Threat modelling is a structured way for the team to think through and document the security risks in the products’ planned environment. The team involved in the threat modelling task should include developers, testers and project managers. The threat models need to contain:
• Data Flow Diagrams • Assets
• Vulnerabilities • Mitigations
The threat model process can be varied. The development team can find the workflow that suits them best as long as the threat models follow the requirements that were defined above. After the threat models are done, they should be reviewed by one member from each group that is involved in the threat modelling process (developers, testers etc.). (Microsoft, 2010)
2.5.4 Implementation
To avoid expensive vulnerabilities and bugs it is important to detect and remove security issues early in the development. The implementation phase in SDL requires that the project team defines best practices that they should follow during the development. SDL has some predefined best practices but it also emphasizes the importance of complementing these with project-‐specific best practices. An example of best practices defined by SDL:
• Use compiler versions (or later) required by SDL.
• Use code analysis tools of versions (or later) required by SDL.
