• No results found

The following diagram (Figure 4.16) illustrates the integration process by the Scrum Team when using the security poker technique. The Scrum Team can use security poker to deal with misuse case artefacts. Furthermore, it can be used in risk identification (Risk ID) and threat analysis (Thread A.) and UMLsec security requirements. The Security Owner can specify the related Security Backlog of the system in order to produce the refined Product Backlog with the Product Owner.

Figure 4.16 is an illustration of the proposed extended Scrum framework. The artefacts include misuse case artefacts and Risk Identification and Threat Analysis, however, as part of the extension of the Scrum framework in this study the artefacts also include UMLsec stereotypes (profile). The techniques used in the extended Scrum framework include the two aforementioned security poker games Risk Poker and Protection Poker, these are in addition to the use of white boards and story and security cards.

All of these tools are used for security requirements consideration prior to the next stage which is the modelling and prioritising of security requirements which is achieved through the addition of UMLsec to model security requirements and facilitated by the proposed role, namely Security Owner role, as part of extending the Scrum framework. During the product development stage which includes the Product Backlog, the Security Backlog and the Sprint Backlog which can be managed with the assistance of the Security Owner role, as an additional extension to the Scrum framework, there is facilitation of these artefacts by the Security Owner through liaising with the Product Owner and the Scrum team.

150

Figure 4.16: Security Owner and UMLsec Profile in the Scrum Framework. Misuse Cases

artefacts

Risk ID & Threat A.

Risk Poker

Protection Poker

Sprint Backlog Story cards & Security cards Product Backlog Security Owner Security Backlog Product Owner White board Scrum Team Refined UMLsec stereotypes (Profile)

UMLsec security requirements modelling and prioritizing Security Poker

151

4.13 Chapter Summary

Towards illustrating the objectives of the study which include to extend the Scrum framework through including a Security Owner and UMLsec, this chapter has introduced the framework for integrating the Security Owner role and UMLsec in the Scrum. The framework is designed to achieve the objective of the study which is to improve the security requirements throughout the modelling and development processes. The framework demonstrated how the Security Owner can assist team members to consider security requirements through their coordinating role which was specified as the first objective of the research. The role of the Security Owner, their responsibility and authority has been discussed. Specifically, the chapter has discussed how the Security Owner deals with security requirements of the proposed system, misuse cases and security story cards in order to prioritise these items in a proposed artefact 'Security Backlog' and integration with the Product Backlog to produce the refined Product Backlog with the Product Owner.

One of the objectives of the study is to include a Security Owner role, and it has been important here to show how that role fits into the processes and functions of the Scrum framework, and where and how the role can facilitate and improve the consideration of security requirements. This chapter has discussed how the misuse cases can be used in Scrum in addition to how the Security Owner can identify misuse cases within the Scrum framework. In reference to the third objective of the study which is to investigate the suitability of UMLsec for modelling security requirements Moreover, it has explained how the analysis of the security requirements for UMLsec is prioritised based on the results of the Scrum team's Security Poker. The chapter presented the Security Owner role to facilitate the work with the security requirements, the Security Backlog as an artefact for

152

security items, and the work of the adoption of UMLsec in agile methods, ending with the proposed integration framework.

As an extension of what has been mentioned in the previous chapter (Chapter 3) about the research methods used (experimentation and questionnaires) to support the proposed adoption of UMLsec and Security Owner role in agile processes, in this research, the next chapter (Chapter 5) in accordance with the fourth objective of the study, will present the experiments to be conducted and the subsequent questionnaires in detail in order to assess the effect of the inclusion of a Security Owner role and UMLsec.

153

CHAPTER FIVE

EVALUATION EXPERIMENTS

Objectives

 To validate the approach of the study through experimentation  Illustrating the related Training Course.

 Piloting of experiments  Training of participants

154

5. Evaluation Experiments

5.1Introduction

This chapter presents the experiments which are used to determine the validity of the hypotheses of the study identified in chapter one as follows:

H1. The introduction of a Security Owner role helps the Scrum team in terms of effectiveness when considering and managing security requirements (when using UMLsec)

H2. The Security Owner role helps to identify security requirements

H3. The Security Owner role will help team members with UMLsec in terms of team working

H4. The Security Owner role will help team members to prioritise security requirements using UMLsec

H5. UMLsec is an appropriate tool for modelling security requirements (when facilitated by a Security Owner)

H6. Scrum as an agile process remains agile when UMLsec is used when / if facilitated by a Security Owner

This is achieved through experimentation using a scenario of the Scrum agile development method both with and without the inclusion of the proposed Security Owner role and UMLsec. In order to test these hypotheses two different types of experiment are conducted, one with and one without Security Owner and UMLsec. The reason for two types of experiment is that the experiment which does not include UMLsec and the Security Owner will act as the control experiment. The results of each experiment are derived from questioning participants upon completion about their

155

experience and the results from the two different groups are used to confirm the hypotheses. Results from the experiment with UMLsec and the Security Owner and the results from the control experiment without, through comparison will increase the validity of the experimentation.

To ensure that the participants understood the Scrum procedure that was used in the experiment and the procedure of the experiment itself a training session was session was conducted. This training session included software development and agile development methods, knowledge of modelling using UMLsec.

In order to ensure that the training was effective in informing the participants about the procedure of the experiments and to ensure that the design of the experiment did not include any barriers or misunderstanding or that the participants faced difficulties, a pilot study of the experiments was carried out.

5.1.1 Aims of The Experimentation

The aims of the experimentation are to allow the participants to take part in modelling security requirements, within the Scrum development framework, to determine if the inclusion of UMLsec facilitated by the presence of a Security Owner would have an effect on the identification, consideration, management and modelling of security requirements in an agile method. These aims are towards answering the research questions of this study which include whether or not the introduction of UMLsec and the Security Owner role will extend and improve agile methods, specifically Scrum, in terms of considering and managing security requirements, whether the Security Owner will help Scrum team members in relation to security requirements and whether Scrum as an agile method remains agile. Therefore, the experiments are designed to validate the

156

approach of the study, to include UMLsec and a Security Owner, to improve security requirements consideration and modelling in Scrum towards validating the hypotheses of the study as mentioned in the above.