A Framework for Security Requirements Elicitation830754/FULLTEXT01.pdf · A Framework for Security...

Master Thesis Software Engineering Thesis no: MSE-2012-95 May 2012

School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden

A Framework for Security Requirements Elicitation

Gibrail Islam and Murtaza Ali Qureshi

ii

This thesis is submitted to the School of Engineering at Blekinge Institute of Technology inpartial fulfillment of the requirements for the degree of Master of Science in SoftwareEngineering. The thesis is equivalent to 26 weeks of full time studies.

Contact Information: Authors: Gibrail Islam E-mail: [email protected] Murtaza Ali Qureshi E-mail: [email protected]

University advisor: DR. JÜRGEN BÖRSTLER Department of Software Engineering and Computer Science

School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden

Internet : www.bth.se/com Phone : +46 455 38 50 00 Fax : +46 455 38 50 57

ABSTRACT

Context. Security considerations are typically incorporated in the later stages of development as an afterthought. Security in software system is put under the category of non‐functional requirements by the researchers. Understanding the security needs of a system requires considerable knowledge of assets, data security, integrity, confidentiality and availability of services. Counter measures against software attacks are also a security need of a software system. To incorporate security in the earliest stages, i.e. requirement gathering, helps building secure software systems from the start. For that purpose researchers have proposed different requirements elicitation techniques. These techniques are categorized into formal and informal techniques on the basis of finiteness and clarity in activities of the techniques. Objectives. Limitations of formal methods and lack of systematic approaches in informal elicitation techniques make it difficult to rely on a single technique for security requirements elicitation. Therefore we decided to utilize the strengths of formal and informal technique to mitigate their weaknesses by combining widely used formal and informal security requirements elicitation techniques. The basic idea of our research was to integrate an informal technique with a formal technique and propose a flexible framework with some level of formality in the steps. Methods. We conducted a systematic literature review to see “which are the widely used security requirement elicitation techniques?” as a pre‐study for our thesis? We searched online databases i.e. ISI, IEEE Xplore, ACM, Springer, Inspec and compendeX. We also conducted a literature review for different frameworks that are used in industry, for security requirement elicitation. We conducted an experiment after proposing a security requirements elicitation Framework and compared the result from the Framework with that of CLASP and Misuse cases. Results. Two types of analysis were conducted on results from the experiment: Vulnerability analysis and Requirements analysis with respect to a security baseline. Vulnerability analysis shows that the proposed framework mitigates more vulnerabilities than CLASP and Misuse Cases. Requirements analysis with respect to the security baseline shows that the proposed framework, unlike CLASP and Misuse cases, covers all the security baseline features. Conclusions. The framework we have proposed by combining CLASP, Misuse cases and Secure TROPOS contains the strengths of three security requirements elicitation techniques. To make the proposed framework even more effective, we also included the security requirements categorization by Bogale and Ahmed [11]. The framework is flexible and contains fifteen steps to elicit security requirements. In addition it also allows iterations to improve security in a system.

Keywords: Security Requirement Elicitation Framework, Security Requirement Engineering, Software Security

ii

ACKNOWLEDGEMENTS

We are thankful to Almighty God for giving us courage and strength to complete our thesis within six months of time. We would also like to thank our Parents, Family and Friends for their constant support and prayers. We would like to thank Dr. JÜRGEN BÖRSTLER for helping us throughout the thesis. We are grateful to him for his guidance and never ending willingness to transfer the knowledge he has. In the end we would also like to thank each other for working as a team and solving conflicts during the study with patience.

iii

CONTENTS ABSTRACT ...................................................................................................................................... I

ACKNOWLEDGEMENTS .................................................................................................................. II

CONTENTS .................................................................................................................................... III

1 LIST OF FIGURES ................................................................................................................... VI

2 LIST OF TABLES .................................................................................................................... VII

1 CHAPTER 1 – INTRODUCTION ................................................................................................ 1

1.1 BACKGROUND ........................................................................................................................... 1 1.1.1 Security in software .......................................................................................................... 1 1.1.2 How is security neglected? ................................................................................................ 2 1.1.3 How is security addressed? ............................................................................................... 2 1.1.4 Secure Software Engineering ............................................................................................ 2

1.2 OUR IDEA ................................................................................................................................. 3 1.3 PRE‐STUDY FOR THESIS ............................................................................................................... 4

1.3.1 Selection Criteria for techniques ....................................................................................... 4 1.3.2 Systematic Literature Review for Security Requirement Elicitation Techniques (Pre‐work for Thesis) ....................................................................................................................................... 4

1.3.2.1 Search Strategy ...................................................................................................................... 4 1.3.2.2 Research Questions for SLR .................................................................................................... 5 1.3.2.3 Search Terms .......................................................................................................................... 5 1.3.2.4 Databases and data collection source .................................................................................... 6 1.3.2.5 Inclusion/ Exclusion Criteria ................................................................................................... 7

1.3.2.5.1 Exclusion Criteria ............................................................................................................... 7 1.3.2.6 Kappa Coefficient ................................................................................................................... 7 To increase the level of agreement among the authors, we tried to resolve our conflicts through mutual understanding and discussions between us. ............................................................................................. 8 1.3.2.7 Study Quality Assessment ...................................................................................................... 8 1.3.2.8 Data Extraction Criteria .......................................................................................................... 9 1.3.2.9 Synthesis of Articles ............................................................................................................. 12 1.3.2.10 Conclusion ............................................................................................................................ 13 1.3.2.11 Limitations ............................................................................................................................ 13

1.3.3 Quick comparison of Security Requirement Elicitation techniques ................................. 13 1.3.4 Why did we choose two formal techniques? .................................................................. 15 1.3.5 Why Misuse cases? ......................................................................................................... 15

1.4 AIMS AND OBJECTIVES ............................................................................................................... 16 1.5 RESEARCH QUESTIONS FOR OUR THESIS ........................................................................................ 16 1.6 EXPECTED OUTCOMES ............................................................................................................... 17

2 CHAPTER 2 – ANALYSIS OF AVAILABLE FRAMEWORKS – DO WE REALLY NEED A NEW FRAMEWORK? ............................................................................................................................. 18

2.1 CONCEPT BEHIND SECURITY REQUIREMENT ELICITATION TECHNIQUES ................................................ 18 2.2 SECURITY REQUIREMENT FRAMEWORKS IN INDUSTRY ...................................................................... 19 2.3 LITERATURE REVIEW FOR EXISTING FRAMEWORKS FOR SECURITY REQUIREMENT ELICITATION ................. 20

2.3.1 Search Strategy ............................................................................................................... 20 2.3.2 Research Questions for Literature .................................................................................. 20 2.3.3 Search Terms ................................................................................................................... 20 2.3.4 Databases and data collection source ............................................................................ 21 2.3.5 Inclusion/ Exclusion Criteria ............................................................................................ 21 2.3.6 Search Results ................................................................................................................. 21

2.4 RESULTS AND CONCLUSIONS ...................................................................................................... 22

iv

3 UNDERSTANDING SECURE TROPOS, MISUSE CASES AND CLASP ........................................... 23

3.1 SECURE TROPOS .................................................................................................................... 23 3.2 MISUSE CASE .......................................................................................................................... 27

3.2.1 Misuse Cases Template ................................................................................................... 28 3.3 CLASP ................................................................................................................................... 29 3.4 SUMMARY .............................................................................................................................. 34

4 PROPOSED FRAMEWORK .................................................................................................... 35

4.1 OVERLAPPING ACTIVITIES OF CLASP AND SECURE TROPOS ............................................................ 35 4.2 BEST PRACTICE SELECTION ......................................................................................................... 35 4.3 ACTIVITY SELECTION ................................................................................................................. 36 4.4 ADDITIONAL FIELDS IN MISUSE CASES TEMPLATE ............................................................................ 37 4.5 SEQUENCING THE STEPS ............................................................................................................ 37 4.6 ANALYSIS OF SELECTED STEPS: ACTIVITY REVISIT ............................................................................. 37 4.7 USING SECURITY REQUIREMENT CATEGORIZATION ......................................................................... 38 4.8 PROPOSED FRAMEWORK ........................................................................................................... 38

4.8.1 How to conduct each step of Framework ....................................................................... 38 4.8.1.1 Specify Operational environment ........................................................................................ 39 4.8.1.2 Identify global security policy ............................................................................................... 39 4.8.1.3 Identify resources and trust boundaries .............................................................................. 40 4.8.1.4 Identify user roles and resource capabilities ........................................................................ 40 4.8.1.5 Identify in‐depth user roles, secure capabilities and security constraints for each actor .... 41 4.8.1.6 Identify attack surface .......................................................................................................... 41 4.8.1.7 Research and assess security posture .................................................................................. 42 4.8.1.8 Detail misuse case ................................................................................................................ 42 4.8.1.9 Document security relevant requirements .......................................................................... 43 4.8.1.10 Perform security analysis of system requirements and design. ........................................... 44 4.8.1.11 Update security requirements document ............................................................................ 45 4.8.1.12 Identify resources, entry points, functionalities, assets, services and actors for the system 45 4.8.1.13 Suppose all the threats mentioned in the categorization are true for all resources, entry points, functionalities, assets, services and actors for the system .......................................................... 45 4.8.1.14 Validate threats for each resource, entry point, functionality, asset, service and actors for the system 45 4.8.1.15 Update the document .......................................................................................................... 46

5 EXPERIMENT ....................................................................................................................... 47

5.1 EXPERIMENT DEFINITION ........................................................................................................... 47 5.1.1 Objective ......................................................................................................................... 47 5.1.2 Context ............................................................................................................................ 47 5.1.3 Sample Space .................................................................................................................. 48

5.2 EXPERIMENT PLANNING ............................................................................................................. 48 5.2.1 Purpose ........................................................................................................................... 48 5.2.2 Quality focus ................................................................................................................... 48 5.2.3 Perspective ...................................................................................................................... 48 5.2.4 Context selection ............................................................................................................. 48 5.2.5 Hypothesis formulation ................................................................................................... 48 5.2.6 Variable selection ............................................................................................................ 48 5.2.7 Subject selection ............................................................................................................. 49

5.3 EXPERIMENT DESIGN ................................................................................................................. 49 5.3.1 Design principle ............................................................................................................... 49 5.3.2 Design type ..................................................................................................................... 49 5.3.3 Instrumentation .............................................................................................................. 50 5.3.4 Validity evaluation .......................................................................................................... 50

5.4 EXPERIMENT OPERATION ........................................................................................................... 51 5.4.1 Software System for Experiment ..................................................................................... 51

5.4.1.1 Monolithic Mainframe ......................................................................................................... 51 5.4.1.1.1 Glossary ........................................................................................................................... 51 5.4.1.1.2 System Description .......................................................................................................... 52

v

5.4.2 Experiment execution ..................................................................................................... 52 5.4.2.1 Output during each activity of Framework .......................................................................... 53

5.4.2.1.1 Specify Operational Environment (Implementation scenario) ........................................ 54 5.4.2.1.2 Identify Global Security Policy ......................................................................................... 54 5.4.2.1.3 Identify resources and trust boundaries ......................................................................... 54 5.4.2.1.4 Identify user roles and resource capabilities ................................................................... 56 5.4.2.1.5 Identify in‐depth user roles, secure capabilities and security constraints for each actor 57 5.4.2.1.6 Identify attack surface ..................................................................................................... 57 5.4.2.1.7 Research and assess security posture ............................................................................. 57 5.4.2.1.8 Detail Misuse Case .......................................................................................................... 58 5.4.2.1.9 Document security relevant requirements ..................................................................... 59 5.4.2.1.10 Perform security analysis of system requirements and design...................................... 59 5.4.2.1.11 Update Security Requirements Document: ................................................................... 61 5.4.2.1.12 Identify Resources, Entry Points, Functionalities, Assets, Capabilities, Resources, Services And Actors. ........................................................................................................................... 61 5.4.2.1.13 Suppose All The Threats Mentioned In The Categorization Are True For All Resources, Entry Points, Functionalities, Assets, Services And Actors For The System. ....................................... 62 5.4.2.1.14 Validate threats for each resource, entry point, functionality, asset, service and actors for the system ..................................................................................................................................... 62 5.4.2.1.15 Update Security Requirements Document: ................................................................... 62

6 ANALYSIS AND INTERPRETATION: ........................................................................................ 63

6.1 DATA SET REDUCTION ............................................................................................................... 63 6.2 DESCRIPTIVE STATISTICS ............................................................................................................. 63

6.2.1 Vulnerability Comparison ................................................................................................ 63 6.2.2 Requirement Types with Respect to System’s security baseline ..................................... 65

6.3 RESULTS AND DISCUSSIONS ........................................................................................................ 68 6.4 RETURN OF INVESTMENT FOR EACH TECHNIQUE. ............................................................................. 69 6.5 VALIDITY THREATS .................................................................................................................... 69

6.5.1 Limitations ...................................................................................................................... 70 6.6 ANSWERS TO RESEARCH QUESTIONS ............................................................................................ 71 6.7 CONCLUSION AND LESSON LEARNED ............................................................................................ 72 6.8 FUTURE WORK ........................................................................................................................ 73

7 REFERENCES ........................................................................................................................ 74

8 APPENDIX ........................................................................................................................... 81

8.1 APPENDIX A ......................................................................................................................... 81 8.2 APPENDIX B ......................................................................................................................... 81 8.3 APPENDIX C (THREATS CATEGORIZATION) .................................................................................. 81 8.4 APPENDIX D (CLASP AND FRAMEWORK SECURITY RELEVANT REQUIREMENTS) ................................. 85 8.5 APPENDIX E (CLASP AND FRAMEWORK SECURITY ANALYSIS REQUIREMENTS) .................................. 88 8.6 APPENDIX F (FRAMEWORK’S FINAL UPDATE REQUIREMENTS) ......................................................... 89 8.7 APPENDIX G (MISUSE CASE REQUIREMENTS) ............................................................................. 90 8.8 APPENDIX H (QUESTIONNAIRE) ................................................................................................ 92 8.9 APPENDIX I (FEEDBACK FORM) ................................................................................................ 93 8.10 APPENDIX J MISUSE CASE TEMPLATE ........................................................................................ 95 8.11 APPENDIX K SEQUENCE DIAGRAM SHOWING ACTIVITY FLOW ........................................................ 96 8.12 APPENDIX L USE CASE DIAGRAM FOR MONOLITHIC SYSTEM .......................................................... 97 8.13 APPENDIX M SEARCH STRINGS ..................................................... ERROR! BOOKMARK NOT DEFINED.

vi

1 LIST OF FIGURES Figure 1: Overall Research Overview ____________________________________________ 1 Figure 2: Search Strategy _____________________________________________________ 5 Figure 3: Study Selection Criteria _______________________________________________ 9 Figure 4: Search Strategy ____________________________________________________ 20 Figure 5: Secure TROPOS example _____________________________________________ 27 Figure 6: Misuse Cases example _______________________________________________ 27 Figure 7: Component Architecture Diagram _____________________________________ 55 Figure 8: Threat Tree ________________________________________________________ 61 Figure 9: Percentage comparison with known vulnerabilities ________________________ 64 Figure 10: Authorization requirements _________________________________________ 66 Figure 11: Authentication Requirements ________________________________________ 66 Figure 12: Confidentiality Requirements ________________________________________ 66 Figure 13: Data integrity Requirements _________________________________________ 67 Figure 14: Availability Requirements ___________________________________________ 67 Figure 15: Non Repudiation Requirement _______________________________________ 68 Figure 16: Accountability Requirements ________________________________________ 68 Figure 17: Requirement Analysis w.r.t Security Baseline ____________________________ 69

vii

2 LIST OF TABLES Table 1: Two Phase Inclusion Criteria ____________________________________________ 7 Table 2: Kappa Coefficient ____________________________________________________ 8 Table 3: Relevance of Papers with Research Questions _____________________________ 9 Table 4: Categorization by research methods ____________________________________ 11 Table 5: Data Extraction Criteria _______________________________________________ 11 Table 6: Synthesis of Articles _________________________________________________ 12 Table 7: Star Ratings of Different Security Requirement Elicitation Techniques (reproduced

from Romero‐Mariona et al. [69]). _________________________________________ 13 Table 8: Description for Star Rating (reproduced from Romero‐Mariona et al. [69]). _____ 14 Table 9: Two Phase Inclusion Criteria ___________________________________________ 21 Table 10: Search Result ______________________________________________________ 21 Table 11: Four Phases of Secure TROPOS ________________________________________ 23 Table 12: Implementation Steps of Secure TROPOS _______________________________ 25 Table 13: Misuse Cases Implementation Steps ___________________________________ 28 Table 14: Misuse Case Template ______________________________________________ 28 Table 15: CLASP Views ______________________________________________________ 29 Table 16: CLASP Activities ____________________________________________________ 29 Table 17: CLASP Best Practices ________________________________________________ 33 Table 18: Overlapping Activities of CLASP and Secure TROPOS ______________________ 35 Table 19: Selected Best Practices for CLASP ______________________________________ 36 Table 20: Selected Activities from CLASP ________________________________________ 36 Table 21: Selected Activities from Secure TROPOS ________________________________ 37 Table 22: Additional fields in Misuse Case Template _______________________________ 37 Table 23: Sequence of CLASP Activities _________________________________________ 37 Table 24: Merged activities from techniques _____________________________________ 37 Table 25: Framework Steps __________________________________________________ 38 Table 26: Experiment design type _____________________________________________ 49 Table 27: Activity flow _______________________________________________________ 52 Table 28: Plan for Day1 of Experiment __________________________________________ 52 Table 29: Plan for Day2 of Experiment __________________________________________ 53 Table 30: Security Baseline ___________________________________________________ 54 Table 31: Component Architecture ____________________________________________ 55 Table 32: System resources and capabilities _____________________________________ 56 Table 33: User's capabilities __________________________________________________ 56 Table 34: Application's capabilities ____________________________________________ 56 Table 35: Access method capabilities ___________________________________________ 57 Table 36: Technologies and problems __________________________________________ 58 Table 37: Misuse Case _______________________________________________________ 58 Table 38: Misuse Case _______________________________________________________ 58 Table 39: Correlation Matrix __________________________________________________ 59 Table 40: Threats on Assets __________________________________________________ 60 Table 41: Threats on Capabilities ______________________________________________ 60 Table 42: System's resources/assets ___________________________________________ 62 Table 43: Valid Threats ______________________________________________________ 62 Table 44: Vulnerability and Security requirement comparison _______________________ 64 Table 45: Requirement analysis with respect to Security baseline ____________________ 65

1

1 CHAPTER 1 – INTRODUCTION The purpose of this chapter is to give an introduction about security in software,

the way security is addressed in software and to present an overall idea of our research. We have explained our research plan and the basic idea behind our research in this chapter.

Figure 1: Overall Research Overview

1.1 Background

1.1.1 Security in software As assets got connected to software, security concerns for software grew more

and more. Over the years, the level of threats to software systems has varied depending upon the environments in which software systems are used and the data these software systems process [54,81]. Internet and connectivity was considered as a social and commercial breakthrough but it has increased the opportunities for those who want to electronically exploit others [81]. Software attacks and hacking incidents actuated the software world to concentrate on security of the software produced.

2

Constant and successful attack stories make it clear that yet softwares are developed with vulnerabilities inside [30,90].

1.1.2 How is security neglected? Traditionally, software development is focused on functional requirements of

software system from the start of software development [3,15,64]. Security is incorporated in the later stages of development as an afterthought [41]. Security in software system is put under the category of non‐functional requirements by the researchers [3,16,27] and hence taken as a complimentary feature by software developers [7,15,74]. According to syllabus provided by REQB1 [82] in‐depth security requirements are not focused due to time pressure, exclusive fixation of cost and orientation towards fast results. In addition, functional security features are often confused with actual security needs throughout the system [3]. Understanding security needs of a system requires considerable knowledge of asset, data security, integrity, confidentiality and availability of service [64]. Counter measures against software attacks is also a security need of a software system.

1.1.3 How is security addressed? A number of approaches have evolved to address software security. Following

three major approaches are used to address security in software [30]. 1. Penetrate and Patch 2. Secure Operational Environment 3. Secure Software Engineering In penetrate and patch approach, software product is released in public after

completion. Any vulnerability found is fixed by applying patches. Although it is the most common approach but to apply patch after finding vulnerability is hundred times [10,30,41] more expensive than if it was fixed during development. Most of the time, more vulnerabilities are introduced while applying patches [30,41,86].

Securing operational environment [30,37] relies on the devices external to the software systems such as firewalls and protection mechanisms. It can provide external security to the software but helps very little against design and implementation attacks. Moreover, operational environment security is only possible after launching the operational product [30].

Idea behind secure software engineering is to implement well structured processes and mechanisms from early phases of software development i.e. requirement elicitation [30]. Secure software engineering starts from requirements phase and reflected in all the phases of software development lifecycle [29,69,70,78].

1.1.4 Secure Software Engineering Focus of security requirement engineering is on early stages of software

development lifecycle which proves to be cost effective and brings about robust design [42,54]. In order to gather security requirement of a software system, number of security requirement elicitation techniques are used [69].

Security requirement elicitation techniques are divided into two categories i.e. formal and informal. Formal security requirement elicitation techniques follow a systematic procedure and definite number of steps [35,69]. Besides following the standard steps, there exists a definite order to follow these steps. Lack of flexibility and limitation in defining scope of (formal) security requirement elicitation techniques limits the use and efficiency of technique. Due to limitations in scalability

1 REQB = Requirement Engineering Qualifications Board (REQB), Poland

3

of the method, formal techniques are hard to use for big projects [69]. There are predefined roles and repetition of process in formal techniques to conduct the requirement specification.

On the other hand, informal techniques are more flexible and it becomes easy to define the steps according to the nature of the system under consideration. Despite the flexibility of informal techniques, they lack a systematic approach. Repetition of the process in informal techniques is not easy as compared to formal methods. Since there are no pre‐defined steps in informal security requirement elicitation techniques, most of the software professionals avoid [41] using them. Informal security requirements elicitation techniques lack a proper structure and normally leave few security problems un‐addressed. In addition, particular roles are not defined for the stakeholders in order to conduct the specification [69]. These are some of the main reasons that informal techniques are normally avoided by the security requirement engineers.

Main idea behind security requirement elicitation was to use elicitation methods, which are used to gather functional requirements, for non‐functional requirement (e.g. security) [3]. Since elicitation techniques are focused on functional requirements [2,3,14,23,63], it is difficult to use the same technique for capturing non‐functional requirements. For this purpose, many of the elicitation techniques were extended and were used in an extended form [2,14,23,63] to capture non‐functional requirement (e.g. security). Some researchers have proposed new frameworks and techniques especially for security requirement elicitation [4,48,49,51,92]. Whereas some of the techniques were combined with other elicitation techniques [2,84] to produce better results. All this, ongoing and past, work [3,8,45,46,65,69] is aimed upon developing attack resistant and secure software systems.

1.2 Our Idea Different researchers have rated security requirement elicitation techniques

differently [3,69,85]. This makes it very difficult to compare the results and various ratings of security requirement elicitation techniques. Limitations of formal methods and lack of systematic approaches in informal elicitation techniques makes it difficult to rely on a single technique for security requirement elicitation.

As it is mentioned above, that formal techniques lack flexibility and in‐formal techniques lack systematic approach, we decided to combine the strengths of both formal and informal techniques to mitigate the problems in both techniques, when used separately. The basic idea of our research was to integrate an informal technique with formal technique and propose a flexible framework with some level of formality in the steps. Following were some questions which we needed to answer before we start our research

1. Which informal technique are we going to choose for integration? 2. Which formal techniques are integrate‐able with an informal technique? 3. What is going to be our selection criteria for selecting security requirement

elicitation techniques? 4. Are the frameworks proposed by other researchers not good enough? 5. Do we need another framework? To answer point number 3 above i.e. Selection Criteria, we conducted a literature

review. After deciding a selection criteria (see next section), we conducted a Systematic literature review as a Pre‐study for our research. Following were the aims of our systematic literature review.

4

1. Identify the best informal security requirement elicitation techniques according to the selection criteria.

2. Identify the best formal security requirement elicitation techniques according to the selection criteria.

We also conducted a literature review to identify problems and challenges in available security requirement elicitation frameworks (see Chapter 2).

1.3 Pre‐Study for Thesis 1.3.1 Selection Criteria for techniques

As said earlier, many researchers have compared security requirement elicitation techniques according to their self selected criteria. Each one of them [3,17,18,22,40,41,49,50,69,70‐72,75,85] have rated the techniques differently. Variety of criteria and different ratings hinders the selection of security requirement elicitation techniques. So we conducted a literature review and selected quality criteria for evaluating security requirement elicitation techniques. Our quality criteria were based upon those quality criteria that were common in most of the papers we selected for understanding evaluation [17,41,49,50,69,70‐72,75] of techniques. i.e.

− Easy to Implement: Steps and activities involved in the method are not too complex and can be executed easily [49].

− Flexibility: Technique is modifiable for use [49,75]. − Adaptability: The method can be used in multiple environments [49]. − Learnability: Technique is learnable in definite and acceptable time period

[17,49,72]. − Understandability: Clarity of steps and activities of the technique along with

the capability of technique to understand requirement specification [70,71]. − Scalability: Technique serves for projects of different sizes [49,69,71]. − Visual output: Technique produces understandable graphical output [49].

We shall evaluate security requirement elicitation techniques using above

mentioned criteria.

1.3.2 Systematic Literature Review for Security Requirement Elicitation Techniques (Pre‐work for Thesis)

1.3.2.1 Search Strategy This section is an explanation of search strategy implementation using

Kitchenham Guidelines [43]. 1. We identified keywords and important search terms from research

questions. 2. We also used synonyms of important search terms to improve our

search. 3. We formed search strings by using AND and OR Boolean operators (see

section 1.2.2.3). Our search strategy is partially iterative. It means that while searching Databases,

we changed and refined keywords and search terms to improve our search. We gathered a large set of initial studies after exhausting all the search terms and search strings (mentioned in section 1.2.2.3). It is shown below in figure1.

5

Figure 2: Search Strategy

1.3.2.2 Research Questions for SLR 1. What are the software security requirements elicitation techniques that are

widely used? 2. What are the two widely used techniques for security requirement elicitation

i.e. which satisfies these evaluation criteria (mentioned and explained in section 1.3.1);

− Easy to Implement − Flexibility − Adaptability − Learnability − Understandability − Scalability − Visual output

3. Which informal technique for security requirement elicitation has the highest rating for following evaluation criteria;


These research questions help us in evaluating security requirement elicitation techniques according to above mentioned criteria.

In order to have better understanding of RQ2 i.e. “why did we select two formal techniques”, refer to section 1.3.4.

1.3.2.3 Search Terms To find papers in databases we used two Boolean operators i.e. ‘AND’ & ‘OR’.

Firstly, we search papers with keywords and then we combined the keywords with the Boolean operators to get the desired output.

1. Software Requirements 2. Requirements Elicitation 3. Requirements Elicitation Process 4. Techniques used to elicit Security Requirements 5. Requirements Elicitation Technique

6

6. Formal Requirements Elicitation Methods 7. Requirements Gathering 8. Formal Requirements Elicitation Technique 9. Software requirement elicitation 10. Software requirement elicitation technique 11. Software requirement elicitation methods 12. Formal Elicitation Technique 13. Informal Elicitation Technique 14. Software security 15. Security Requirement Elicitation Technique 16. Software security requirements 17. Software security requirements elicitation 18. Software security requirements formal elicitation technique 19. Software security requirements formal elicitation methods 20. 1 OR 2 OR 3 21. 6 OR 7 OR 8 22. “Formal Elicitation” AND “Elicitation process” AND “Elicitation methods” 23. “Formal Elicitation Technique” AND “Software requirement elicitation” AND

“Software requirement elicitation technique” 24. “Elicitation Methods” AND 5 AND 6 25. “Elicitation Methods” AND 14 26. “Software Security” AND 11 AND 12 27. “Software Security” AND 11AND 13 28. “Software security” AND 15 AND 16 29. 16 AND 17 AND 18 30. “Elicitation Technique” AND 7 AND 8 31. “Elicitation Technique” AND 19 32. (Software Requirements OR Requirements Elicitation OR Requirements

Elicitation Process OR Formal Requirements Elicitation Methods OR Requirements Gathering OR Formal Requirements Elicitation Techniques) AND (Formal Elicitation OR Elicitation Process OR Elicitation Methods OR Formal Elicitation Technique OR Software Requirements Elicitation OR Software Requirement Elicitation Technique) AND (“Software Security” OR Formal Elicitation Technique OR Informal Elicitation Technique OR Security Requirements Elicitation Technique)

1.3.2.4 Databases and data collection source We used BTH Library to search the relevant material. We also searched the

databases using the keywords which were used in the initial search to make sure that there is no Formal or Informal Security Requirement Elicitation Techniques which is left un‐touched. We searched online databases i.e. ISI, IEEE Xplore, ACM, Springer, Inspec and compendeX.

7

1.3.2.5 Inclusion/ Exclusion Criteria In abstract level we selected papers based on their title, abstract, keywords,

language etc to check whether papers are relevant to our field. In detailed level we further analyzed papers whether the detail level information (mentioned in Table 1) exist in the selected papers.

Table 1: Two Phase Inclusion Criteria

Abstract Level

• Papers and journals in English language. • Articles that looked relevant by keywords. • Search for recent papers from last 8‐9 years. • Availability of paper through BTH library. • Papers that are published in journals and conferences are included. • Articles were included with relevance to metadata. • Articles were included with relevance to metadata and Full text. • Articles were included relevance to title and abstract. • Articles were selected related to the software security and formal elicitation techniques. • Articles were selected related to software security and Informal elicitation techniques. • Relationship with RQ (Research Questions): The paper selection was focused on our RQs.

Detailed Level • Articles were selected that compare software requirement elicitation techniques. • Articles were selected that evaluate software requirement elicitation techniques. • Articles were selected based on Evaluation Criteria mentioned in RQ2 and RQ3.

1.3.2.5.1 Exclusion Criteria • There were number of articles and papers which were repeated in number of

databases. We removed duplicates automatically with the help of software called EndNote. Literature with same reference type is taken as a duplicate by EndNote. For example if journal article, author, year, title fields are identical for two or more papers, Endnote will consider such articles as duplicates and keep only one reference for such articles. Other identical articles with difference in reference type, can be removed manually.

• Papers were discarded which did not fulfill the criteria of inclusion. • Studies were excluded if its main focus was not on security requirement

elicitation techniques i.e. some papers focused only on requirement elicitation techniques e.g. brainstorming, interviews etc were excluded.

• Articles were excluded which were not having information about informal and formal security requirement elicitation techniques.

1.3.2.6 Kappa Coefficient We randomly selected 25 studies while applying inclusion criteria to check level

of agreement and disagreement between two authors. To check level of agreement between two authors we used kappa coefficient. The value of kappa coefficient [43] in table is 0.40 which is a fair agreement between authors.

K = P (o) ‐ P (E) 1‐ P (E)

P(o) = Probability of Observed agreement between authors. P(E)= Probability of Expected agreement between authors. N = Number of studies randomly selected K = [‐1, 1] K= 1: Perfect agreement K=0: Agreement is equal to chance

8

K= ‐1: Perfect disagreement. P(o) = (No of studies both researcher says Yes + No of studies both

Researcher says no) / N (In order to calculate observed agreement we calculated number of studies in which both researchers agreed that they must be included and added with the number of studies on which both researchers disagreed. Result of this was divided with number of studies randomly selected i.e. 25 here) P(o) = 11 + 6/ 25 P(E) = [No of Studies Researcher 1 says yes/ N * No of studies

Researcher 2 say yes/ N] + [ No of studies Researcher 1 say No / N * No of Studies Researcher 2 say No / N]

(In order to calculate expected agreement we first calculated number of studies separately in which researcher 1 and 2 agree. Then we divided separately research 1 studies and research 2 studies with the number of studies randomly selected. Then we calculated separate studies in which researcher 1 and 2 disagree. We divided separately Researcher 1 and researcher 2 studies with the number of studies randomly selected.) P(E) = [16/25 * 14/25] + [ 9/25 * 11/ 25]

Table 2: Kappa Coefficient Studies Papers Selected

Randomly P(A) P(E) K

Inclusion Exclusion Criteria

25 0.70 0.50 0.40

To increase the level of agreement among the authors, we tried to resolve our conflicts through mutual understanding and discussions between us.

1.3.2.7 Study Quality Assessment In order to search different relevant articles in the databases, we proposed some

checklist points. A list of papers was selected after applying an inclusion/ exclusion criteria. Information extracted from studies was analyzed on the basis of approach, techniques, methods and results. The main objective was to find answer to our research questions. So the relevancy of problems addressed in the papers was of significant importance.

The search was basically focused on different available security requirement elicitation techniques and their effectiveness of use in different scenarios. Inclusion and Exclusion criteria were also taken into account to search material. In order to find authentic articles, we used checklist points for quality assessment. We applied checklist points by manually by reading the articles. Following are the quality criteria which were taken into consideration:

• The research methodology is understood by the reader. • Limitations of the study are reported.

9

• Primary studies were selected based on empirical evidence i.e. data must be available in qualitative or in quantitative form.

Figure 3: Study Selection Criteria

1.3.2.8 Data Extraction Criteria After the inclusion and exclusion criteria we choose 24 articles

[1,5,6,9,17,19,20,31,32,36,41,49,50,52‐55,57,70‐72,76,78,83] which are more related to our research area with respect to process, techniques, approaches, gap, future work, advantages and disadvantages of security requirements elicitation techniques. Found articles are related to the various important techniques for security requirements engineering. Papers include both formal and informal techniques.

Table 3: Relevance of Papers with Research Questions

Papers Title of the paper Paper related to Research question

[52]

Security Requirements Engineering for software systems: Case studies in support of software engineering

RQ:2

10

[55]

Successful requirement elicitation by combining requirement engineering techniques

RQ:1

[76]

Security Requirements Elicitation Using Method Weaving and Common Criteria

RQ:1, RQ:2

[9]

Injecting security as aspectable NFR into Software Architecture

RQ:2

[32]

Security Requirements Engineering: A Framework for Representation and Analysis

RQ:2

[36]

MOQARE: misuse‐oriented quality requirements engineering

RQ:2

[20]

An Ontological Interface for Software Developers to Select Security Patterns

RQ:2

[54]

A systematic review of security requirements engineering

RQ:1,RQ:2

[53]

Security Requirements Variability for Software Product Lines

RQ:1

[78]

Eliciting Security Requirements by Misuse Cases

RQ:2

[19]

Analysis for Understanding Software Security Requirement Methodologies

RQ:1

[1]

Security Requirements Elicitation Using View Points for Online System

RQ:1

[31]

Security requirements engineering; state of the art and research challenges

RQ:1,RQ:2

[57]

Extending tropos methodology to accommodate security

RQ:2

[83]

Security‐aware Software Development Life Cycle (SDLC)

RQ:2

[17] A comparative Evaluation of three approaches to specifying security Requirements

RQ:3

[41] A Survey on requirements and design methods for secure software development.

RQ:2,RQ:3

[50] Experiences in Eliciting Security Requirements

RQ3

[72] Formality of the security specification process: Benefits Beyond Requirements

RQ2

[49] How to compare the security quality requirements engineering(SQUARE) Method with other Methods

RQ3

[71] Security Requirements Engineering—A survey

RQ2, RQ3

[70] SRRS: A Recommendation System for security Requirements

RQ2,RQ3

[6] Initial Industrial Experience of Misuse Cases in Trade Off Analysis

RQ3

[5] Misuse Cases Help to elicit non functional requirements.

RQ3

Relevant Papers were extracted based on the research questions as shown in the above table. Based on the selected papers above we categorized the papers according to the research methodology used in each paper. One article was found

11

which adopted experiment as a research methodology whereas other articles used case study, survey, Interviews and literature reviews.

Table 4: Categorization by research methods Articles Methodology

[50] Experiment[17][9][36][50][52][54][53][49][5][31][76] Case Study[9][19][55][57][41][72][71][70][78][6] Survey[19][1] Literature Review[54] SLR[55] Interviews[32],[20][31],[83] Others

Following information was recorded for each paper.

Table 5: Data Extraction Criteria Article Title Journal/Conference/Conference ProceedingsDate of Publication Study Context(Academia/Industrial)Research Method(Experiment/Case Study/Survey/Literature Review etc.)External/Internal ValidityRetrieval Search QueryEvaluation/Metrics (RQ2, RQ3)Abstract

Article Title: Relevant titles were selected based on our study. Journal/conference/Conference proceedings: We included papers from Journals,

conferences and conference proceedings. Date of publication: Date of publication was taken into consideration when

selecting the paper. We selected recent papers from past 8‐9 years. Study Context (Academia/Industrial): In our study we considered both academia

and industrial study. Research Method (Experiment/case study/survey/Literature Review etc): Based

on the selected papers above we categorize the papers according to their research methodology.

External/Internal validity: We recorded the validity measures of the results of

each paper. Evaluation/Metrics (RQ2, RQ3): Evaluation criteria are mentioned in research

question 2 and 3. Evaluation criteria (see Section 1.2.1) for the papers evaluating the techniques was recorded and looked into with respect to evaluation criteria mentioned in our research questions.

Abstract: In abstract summary of the paper is presented. Based on the abstract of

the paper we can have a general idea whether the paper is relevant to our study or not.

12

1.3.2.9 Synthesis of Articles In synthesis of articles, we synthesize the articles on the basis of research

methods, and the way the articles are related to our research area of software security requirements. Articles are summarized below to show that what exactly we have found and what is the result of our study regarding our chosen research area for systematic review.

Table 6: Synthesis of Articles Articles Summary Results

[54][78][17][50][71][52] [55][76][9][53][19][1][31]

These papers explain the benefits of applying security in early requirement phase with the help of security requirement elicitation techniques. It results in detecting security vulnerabilities, decrease cost of software maintenance and helps in finding complex components in software architecture. Furthermore we get to know different techniques and the benefits of combined requirement elicitation techniques in different applications from these papers.

By analyzing these articles we understood different security requirement elicitation techniques and their benefits. Secondly we analyze the application of combined requirements engineering techniques for efficient and successful requirements engineering process for real life complex project. We cannot say that one technique is better than the others. There are number of security requirement elicitation techniques which facilitates in detecting different security vulnerabilities.

[41][54][78][70][49][50][72][71][5][6][1][83][57][31]

In these papers, detail analysis is presented of formal and informal approaches. Some of the papers explain threat modeling based on formal and informal elicitation technique. Furthermore it discusses the challenges and benefits of different security elicitation techniques based on evaluation criteria mentioned in RQ2 and RQ3:


Different research methods are used in found articles to elicit security requirements. These papers evaluate different techniques based upon some criteria. We evaluated the techniques on the basis of our own criteria. We came to know that CLASP and Secure TROPOS are widely used techniques in formal techniques. Whereas in informal techniques, Misuse case is mostly understandable and used.

[32],[36],[20],[53] These papers propose a framework for requirement elicitation and analysis. These frameworks were proposed to elicit quality requirement. Applicability of frameworks was checked in industry.

Models are proposed by using some standards to gather requirements in the early stages of the product. It is used as a reference models in decision making. Reason behind analyzing different techniques is to see that which techniques and frameworks are suitable in practical world.

We have narrow down our research area to three research questions, and these

posed research questions are answered in following ways. We searched out in available databases using different search strings and search

criteria to find the techniques to elicit software security requirements which give the answer of the first research question. After reviewing the found research articles we analyzed all techniques to find out widely used formal and informal security requirements elicitation technique on the basis of evaluation criteria mentioned in research questions. We analyzed the widely used technique based on its implementation and application. After the inclusion/exclusion criteria we choose the 24 articles [1,5,6,9,17,19,20,31,32,36,41,49,50,52‐55,57,70‐72,76,78,83].

13

1.3.2.10 Conclusion There are a number of security requirement elicitation techniques. The security

requirement elicitation techniques fall under two categories i.e. formal and informal security requirement elicitation techniques. Formal techniques follow certain methods which are understandable and explainable. After reviewing and analyzing the formal and informal security requirements elicitation techniques we selected two widely used formal techniques (CLASP and Secure TROPOS) and one informal technique(Misuse cases) based on the evaluation criteria. The reason to choose formal security requirements elicitation techniques is that they follow a formal process that includes standard steps to develop security requirements specifications and also there is a defined order in which such standard steps are to be followed, and roles are defined for system’s stakeholders [72]. After reviewing different articles we came to know that CLASP and Secure TROPOS are the most widely used security requirements elicitation techniques in industry and academia on the basis of articles [31,41,57,71,72]. Though the informal technique does not follow any predefined steps, reason to choose the informal technique (Misuse cases) is that it is used to analyze a situation from different aspects and capture security requirements in order to remove threats in early phases of requirements engineering. Misuse cases as a solution for security requirement elicitation is accepted by different researchers because of its simplicity and effectiveness of use. Based on the evaluation criteria we selected informal technique [5,6,31,41,49,50,70,71]. Unfortunately, we did not have access to industry and we had to draw conclusions from published material alone. If we had access to industry, we would be able to gather more evidence for the conclusions drawn from the SLR here.

After reviewing and analyzing the comparison of the formal techniques with the help of literature review, we concluded that CLASP and Secure TROPOS are easy to understand and implement, more scalable and have more usage history for security critical systems.

1.3.2.11 Limitations After reviewing and analyzing all the found articles from available and possible

databases for the systematic review, we found some limitations in our systematic literature review. Some search terms or strings were not working properly to find the articles from databases related to security requirements elicitation. We tried our best to find the articles which are available in last 8‐9 years so that we can find the latest research gaps in this area but yet we may have missed some articles that were not available to us.

1.3.3 Quick comparison of Security Requirement Elicitation techniques

We used researches by different researchers to understand the comparison between different security requirement elicitation techniques in our systematic literature review. Following table is a better and simple example in this regard which gives a quick and brief overview of famous security requirement elicitation techniques.

Table 7: Star Ratings of Different Security Requirement Elicitation Techniques (reproduced

from Romero‐Mariona et al. [69]). Resulting

System Security

Scalability Integration of security

Requirements

Constraint Consideration

Benefits of testing

Other Requirements Integration

14

Misuse cases (Informal) ** * None None *** * Abuser Stories (Informal) * * None I** * None Secure TROPOS (Formal) ** **** **

A** D** ** ***

Security Problem Frames (Informal) ** *** None A**** None None Anti Models (Formal) ** **** None None * None I* (Formal) **** ** *

D**I*** * *

Common Criteria (Formal) **** **** *

D** I* * *

SQUARE (Informal) *** **** None A* * None OCTAVE (Formal) ** **** * None ** None Attack Trees (Informal) * * None D** *** None USer Method (Formal) ** ** *

D**I** None *

CLASP (Formal)

**** **** **

A*D** I* M* **** *

Romero‐Mariona et al. [69] compare 5 informal and 7 formal security

requirement elicitation techniques according to 6 different quality criteria (see Table 3). Their survey explored constraints at later stages of development. These constraints are the factors that can benefit other stages of development. These constraints include Architectural (A), Design (D), Implementation (I) and Maintenance (M). The criteria for star rating is as follows

Table 8: Description for Star Rating (reproduced from Romero‐Mariona et al. [69]). Notation Translated As Description

None Not specified There is no information regarding any aspects/concepts about the question at hand in any of the sources describing the approach.

* Low Aspects/concepts related to the question at hand are suggested (but not in detail) OR there is enough information to suggest that any support would be possible by the approach.

** Moderate Aspects/concepts related to the question at hand are explicitly mentioned in some of the sources describing the approach, but it is not a critical component. Support is described, but no specific measures to operationalize that support are given.

*** Moderate‐High Aspects/concepts related to the question at hand are explicitly mentioned in a majority of the sources describing the approach; they are important aspects to the approach. Support is described and some measures to operationalize that support are described.

**** High Aspects/concepts related to the question at hand are critical to the approach. Support for the specific question is described across the majority of sources describing the approach. There is evident and extensive support for the question at hand, and measures for achieving this support are described.

We can see that Romero‐Mariona et al. [69] rated CLASP and Secure TROPOS higher than other security requirement elicitation techniques. There is another research conducted by Khan and Zulkernine [41] which also draws the same conclusion as Romero‐Mariona et al.[69]. They [41] have compared Secure TROPOS and CLASP with all other formal/Informal techniques and the results were almost similar to that of Romero‐Mariona et al.[69]. Khan and Zulkernine [41] compared different security specification languages according to properties like Security

15

constraints, Easy to implement, Usability (Usage scenarios), low level security requirements and software specification language etc. According to them [41], Secure TROPOS covers all these properties as compared to other specification languages. They [41] have also compared CLASP with SQUARE, Haley, SREP and concluded that CLASP covered most of the properties related to Flexibility, resources, potential attackers, Easy to implement, attackers capabilities and high level security requirements. In another study Romero et.al [70], in their research, conducted comparison of different security requirement elicitation techniques based on the different criteria which also includes Scalability and Understandability. They [70] conducted Survey to conclude their results and used likert scale to rate the technique according to criteria. In their rating matrix, Secure TROPOS and CLASP have highest rating in Scalability whereas for understandability, they have rated CLASP and Secure TROPOS as good [70]. Similar conclusions were drawn by some other [29,85,87] researchers. Better and concise way of presenting the comparison without a lengthy preface, motivated us to refer to a piece of research from Romero‐Mariona et al. [69].

1.3.4 Why did we choose two formal techniques? The reason for choosing two formal techniques i.e. CLASP and Secure TROPOS out

of several formal techniques was that they cover the security aspects of the system not in the requirement phase only but also in the design and the implementation part [41]. So by using these techniques together, we can get useful result, which is more likely to elicit the security requirements, keeping in view, all software development phases. These techniques also consider low and basic level security requirements which include integrity, availability and confidentiality of the system [41]. We ignored others formal techniques because constraints and approaches defined in formal techniques follow strict systematic procedures [41] which are difficult to integrate with other techniques. Integrating two widely used techniques and generalizing their steps is easy as compare to combine more than two techniques which will result in a mess and thus require more knowledge in understanding the notations which might be unfit for our framework analysis [25]. Integrating two widely used techniques can have the benefit of using the different style and meaning of both the methods. Moreover, considering two techniques will provide us with more options and freedom in order to propose a framework.

1.3.5 Why Misuse cases? In addition to our systematic literature review and its results, we would like to

mention some main reason behind selecting Misuse cases as an informal technique for our framework. Misuse cases are used to analyze a situation from different aspects and capture security requirements in order to remove threats in early phases of requirements engineering [68]. Alexander [5] indicated that Misuse cases can be used for capturing non‐functional requirements other than security like reliability, availability and maintainability. This informal (Misuse Cases) method is very useful in analyzing security threats and requirements [78]. Misuse cases as a solution for security requirement elicitation is accepted by different researchers because of its simplicity and effectiveness of use. It has a graphical and a textual form of representation [6,44‐46,65,79,84,89]. In graphical representations, we can use different notations to show the security threats. Textual templates are used to gather detailed use cases descriptions which will benefit the requirement engineers to analyze the system.

16

1.4 Aims and objectives The main aim of this thesis is to propose a concrete, implementable framework

for security requirement elicitation. • To understand common software requirement elicitation mistakes that

cause security problems in a system, at later stages. • Study formal and informal techniques for security requirement

elicitation. • Develop an implementable systematic procedure for security

requirement elicitation by integrating Misuse cases with two widely used formal techniques for security requirement elicitation.

• To evaluate our proposed framework. • Understanding the validity of attack scenarios i.e. there are possibilities

of getting results some of which may not be applicable in case of the system under consideration. In that case we shall have to validate every attack scenario.

1.5 Research Questions for Our thesis We formulated three research questions for our research. The first research

question will be answered by literature review and analysis of available and ongoing research. We shall also conduct an experiment to conclude RQ1. The second and third research questions will be validated through experiments or case studies. For this, we have created two hypothesis null (H0) and alternative (H1) hypothesis in RQ3. We gave special attention to the answer‐ability of each research question. Every research question has an elaboration under the research question which discusses motivation of the research question and in what way the research question is answer‐able.

It should be noted that we used CLASP and Misuse Cases to elicit security requirements (as mentioned in elaboration of RQ1). We did not elicit security requirements from Secure TROPOS because later analysis (see Chapter 3) showed that Secure TROPOS uses strict diagrammatical notations (see Figure 4) which are difficult to integrate with textual form. Moreover most of the steps of Secure TROPOS overlap with some of the activities of CLASP. Therefore, we decided to use CLASP from the formal techniques for comparison.

RQ1. Do formal approaches produce better results when integrated with informal

approach i.e. Misuse case? Elaboration: Generalizing the steps of the two widely used formal security requirement

elicitation techniques CLASP and Secure TROPOS and integrating them with Misuse cases will be the first step to answer RQ1. In a second step we shall conduct an experiment and use CLASP and Misuse cases separately to elicit security requirements. Then we will use our framework to elicit security requirements and compare results of our framework with the result from CLASP and Misuse case respectively. During the comparison, we shall see that which one from CLASP, Misuse and Framework, produces more number of security requirements. • H0: Formal approaches do not produce better results when integrated

with informal approach i.e. Misuse case. • H1: Formal approaches produce better results when integrated with

informal approach i.e. Misuse case.

17

RQ2. What is the practicality of the proposed framework, i.e. up to what extent and for which types of software systems the framework is suitable?

Elaboration: We focus on delivering an implementable system which is useful for software industry. After proposing the framework we need to validate our framework in terms of its implementation. Usability of the outcome will be tested with the help of an experiment or case study defined in Research Methodology section.

RQ3. On what basis and for which type of software systems, is the proposed

framework better than other widely known security requirement elicitation techniques?

Elaboration: We need to compare our framework with several well‐known security requirement elicitation techniques. It will help us in determining if the proposed framework captures more security requirements in number than other security requirement elicitation techniques. By answering this research question we will find out limitations and ranking of our framework as compared to the other security requirement elicitation techniques. • H0: The proposed framework is not better than other security

requirement elicitation techniques. • H1: Proposed framework is significantly better than the other

requirement elicitation techniques.

1.6 Expected Outcomes • A workable model and framework by integrating Secure TROPOS and

CLASP with Misuse cases that can be used for security requirement elicitation of any software system.

• Knowledge about the systems, for which our model is suitable.

18

2 CHAPTER 2 – ANALYSIS OF AVAILABLE FRAMEWORKS – DO WE REALLY NEED A NEW FRAMEWORK? Purpose of this chapter is to discuss the overall concept behind security

requirement elicitation techniques and available frameworks for security requirement elicitation in industry.

This chapter is divided into three main parts, Concept behind Security Requirement Elicitation Techniques, Security Requirement Frameworks in industry and literature review for existing frameworks for security requirement.

Different requirement elicitation techniques and frameworks address security from different angles and perspectives in order to provide maximum benefit to user of the technique or framework. To understand the concept behind the creation of these techniques, we need to look into various definitions of security by researchers and try to establish their relationship with requirement elicitation techniques and frameworks.

2.1 Concept behind Security Requirement Elicitation Techniques Rushby [73] describes the concept of security as something “which must not

happen”. This description of security is quite vague but it is used by Sindre and Opdahl to create an informal security requirement elicitation technique [78]. If we take inverse of this description i.e. what “must happen”, we touch use cases. Use cases technique is a pictorial and textual representation of functional requirements of a software system. In other words a representation of what “must happen” in a software system. Misuse cases is said to be inverse of Use cases [78]. In other words, we can say Misuse cases represent “what must not happen” in a software system. This description of Misuse cases technique is vague and ambiguous which is same as the concept of security described in Rushby’s [73] paper. Misuse cases is an informal security requirement elicitation technique which is an extension of Use case requirement elicitation technique [61]. Input for Misuse cases is at‐least one Use case [46,78,84]. There can be one or many misuse cases for a single use case. Misuse creation depends upon the creativity of the person creating misuse cases [45,65,6,79]. It means that there is no measurement of how many maximum misuse cases can be created for a particular use case. This vague concept of misuse case creation establishes its relationship with Rushby’s [73] description. It may be said that Misuse cases is a realization of what “must not happen” during a software operation.

According to Mouratidis [58], a system’s security requirements are defined by a system’s security constraints. Same concept of security is presented by others [56,59] who define security to as a system’s constraint. This concept of security is seen in i* which is an informal requirement elicitation technique. I* uses the concept of goals, actors and dependencies to gather system’s requirements. The concept of dependencies used in I* can be defined as “obligations [58] on the actors”. I* is used for capturing functional requirements of a system but using the concept of system’s constraint, I* is also used for capturing security requirements [16,23,57]. Tropos, a formal technique for requirement elicitation is based upon I* modeling. Although Tropos was not developed with security on mind [58], set of security constraints was proposed in order to enable Tropos to consider security aspects [23,58,59]. Secure TROPOS, an extension of Tropos methodology, emerge as a formal technique for security requirement elicitation [2,41,59]. Secure TROPOS lacks in clear definition of

19

system assets. Moreover, the idea behind Secure TROPOS methodology does not talk about what system services are being constrained and its effect on system’s functionality [33].

If we look at CLASP, it consists of five views which contain twenty four activities, in total [66]. Each of the twenty four activities of CLASP is further divided [66] into discrete process component and linked to one or more specific project roles. Detail working of CLASP will be explained in an upcoming section (see Chapter 3). CLASP is a formal technique it focuses on removing vulnerabilities in software environment. CLASP emphasizes more on white box testing [29]. Therefore, despite the detail in different views and activities of CLASP, it lacks in determining the types of bugs to be fixed. CLASP activities usually focus on the architectural and the technical weaknesses [29]. These activities ignore the business level threats [29]. CLASP does not have any clear methodology how to realize or understand its activities [29,49,67,87]. Moreover, CLASP lacks tool support [29].

We see that not one description of software security encompasses the whole problem area i.e. security issues in software. It is because of the variety of resources involved in software. Different natures of software systems, type of resources involved, different architectural styles and life cycle models are some of the reasons of varying efficiency of security requirement elicitation techniques and frameworks.

Some researchers confine security to authorization, integrity, confidentiality and availability of services [30,78,81] , whereas some [4,65,92] focus on assets, activities, goals and restrictions. Security requirement elicitation techniques and frameworks are constructed on the concept of security. The way security is presented by predecessors, in research, is reflected later in the realization of the concepts by the successors in the form of methods and techniques. Every requirement elicitation technique and framework is a realization of a concept and the way security is presented by one or more researchers [4,32,33]. It has become clear, after in depth study of security concepts, that a flaw or shortcoming in a concept of security is reflected in the realization of the concept later. It means that if a security concept has flaws, almost same flaws are reflected in realization of the concept whether the concept is realized by the same or different researcher(s).

2.2 Security Requirement Frameworks in Industry While studying existing techniques and frameworks, we saw that frameworks

proposed in academia are seldom used in industry at large. Most organizations have their own set of steps or framework to address security needs of a system. To understand the actual use of security requirement elicitation frameworks in industry, we searched for security requirement frameworks used in software industry. We selected literature available from two organizations i.e. IBM and CISCO. We were surprised to know that these organizations have their own frameworks and set of defined rules to address security in their systems. For example CISCO [39] uses standards like ISO17799 and NISTSP800. CISCO is using integrated approach in which they have integrated standards like ISO17799 and NISTSP800 with different steps and procedures to be able to implement security in all phases of software development. IBM [13] created a framework using the holistic approach to business security. Security framework consists of 5 steps that enable the organization to secure the solutions and the services. Framework used by IBM characterized security requirements with respect to business policies which is again a customized framework.

Frameworks proposed by researchers [4,12,21,24,32,33,38,52,58,77] are based on different research methods. Researchers conducted detail studies in order to

20

address security requirements and to make software work better. There is not much literature available which shows that different frameworks proposed by researchers are actually used in the industry on wide scale.

Before proposing a new framework, it was important to look into the published material regarding different frameworks proposed by researchers. In order to have a clear understanding of the existing frameworks and to know whether we need another framework or not, we conducted a literature review.

2.3 Literature Review for Existing Frameworks for Security Requirement Elicitation

2.3.1 Search Strategy In this section we explain the search strategy for our literature review.

1. We identified keywords and important search terms from research questions.

2. We also used synonyms of important search terms to improve our search.

3. We formed search strings by using AND and OR Boolean operators (see section 2.3.3).

Our search strategy is partially iterative. It means that while searching Databases, we changed and refined keywords and search terms to improve our search. We gathered a large set of initial studies after exhausting all the search terms and search strings (mentioned in section 2.3.3). It is shown below in figure3.

Figure 4: Search Strategy

2.3.2 Research Questions for Literature

RQ1. Which are the available frameworks for security requirement elicitation that came into being by integrating formal and Informal security requirement elicitation techniques?

RQ2. What are the problems in the Resulting frameworks from (RQ1)?

2.3.3 Search Terms • Formal Technique Security Requirement Elicitation Framework • Informal Technique Security Requirement Elicitation Framework • CLASP Security Requirement Elicitation Framework • Misuse Case Security Requirement Elicitation Framework • Secure TROPOS Security Requirement Elicitation Framework • Security requirement elicitation framework • 1 AND 2

21

• 1 OR 2 • Framework for Security Requirement Elicitation • Formal informal techniques frameworks • General framework for formal informal techniques • Secure TROPOS Framework • Misuse case frameworks • Modeling security requirements with misuse cases • Semi formal framework elicitation techniques

2.3.4 Databases and data collection source We used BTH Library to search the relevant material. We also searched the

databases using the keywords which were used in the initial search to make sure that there is no Security Requirement Elicitation Framework which is left un‐touched. We searched online databases like ISI, IEEE Xplore, ACM, Springer, Inspec and compendeX.

2.3.5 Inclusion/ Exclusion Criteria Table 9: Two Phase Inclusion Criteria

Abstract Level

• Papers and journals in English language. • Articles that looked relevant by keywords. • Availability of paper through BTH library. • Papers that are published in journals and conferences are included. • Articles were included with relevance to metadata. • Articles were included with relevance to metadata and Full text. • Articles were included relevance to title and abstract. • Articles were selected related to the software security frameworks. • Relationship with RQ (Research Questions): The paper selection was focused on our RQs.

Detailed Level

• Papers related to Integration of formal and informal security requirement elicitation techniques were included

• Articles were selected that evaluate and discuss problems in security requirement elicitation frameworks.

• We excluded papers which propose a security elicitation framework without integrating formal and informal techniques.

• There were number of articles and papers which were repeated in number of databases. We removed duplicates automatically with the help of software called EndNote.

2.3.6 Search Results Table 10: Search Result

DBs Title,Abstract,fulltext, Metadata, Topic Total Search Result

Google scholar FullText 144983

IEEE Full text and metadata 22,714

ISI Topic 194

ACM Title, abstract, review 9323

Eng. Village All fields 2904

Total All 180,118

Above are the search results from different databases.

22

2.4 Results and Conclusions We would like to mention here that we were not able to find any paper in which

the author(s) have proposed a framework by combining Formal and Informal security requirement elicitation techniques. We found few papers in which author(s) have combined two informal techniques [47,84] but we did not find any paper which combines formal and informal security requirement elicitation technique. As we have mentioned earlier, many frameworks are available [24,33,47,77] for security requirement elicitation. We only looked for the papers in which researchers have combined formal and informal technique i.e. the context and basic idea of our research. After our literature review for frameworks, in which we did not find any helpful material, a question was raised i.e. “May be it is not a good idea to combine formal and informal technique for security requirement elicitation!”

We have to answer the above question in our research (See RQ1). The idea behind our research is to propose a framework by combining formal and informal security requirement elicitation techniques. In this way we can use strengths in formal and informal techniques to mitigate the problems in the usage of both formal and informal techniques.

23

3 UNDERSTANDING SECURE TROPOS, MISUSE CASES AND CLASP In this chapter, we have done implementation analysis of Secure TROPOS, Misuse

case and CLASP. We have list down implementation steps of techniques. There were some steps in these techniques, which needed to be further broken down to understand actual implementation e.g. (see Table 12). Following aspects were considered during implementation analysis of techniques

− ID: An identification number is assigned to identify and differentiate a particular activity.

− Description: Description and title of the activity. − Input: Input and pre‐requirements for the activity. − Participants: People involved in carrying out the activity. − Output: Result of the activity − Purpose: Reason to carry out the activity. − Risk in Omission: Threats if the activity is not carried out.

Analysis and steps extraction was carried out after careful literature review. We combined points mentioned in several papers in tabular form for easy understanding.

3.1 Secure TROPOS Secure TROPOS was initiated as a PhD project in 2000 [61]. Secure TROPOS is

extension of Tropos methodology to model security features throughout the development process. Purpose of this extension is to propose security constraints in a well defined manner. Secure TROPOS methodology was proposed to fulfill the limitations of Tropos [26,62]. Secure TROPOS Process includes early requirement analysis ,late requirement analysis, architectural design and detail design stage. Early Requirement phase starts from actor modeling. Early requirements and late requirements have the same activities like actor modeling, dependency modeling, trust modeling, delegation, security constraint modeling and goal modeling. Difference is that early requirements model the environment of the system whereas late requirements model the system to be [26]. Architectural phase defines the relationships of actors with external actors. Last phase is the detail design phase where the components identified, in the previous phases, are modeled using the agent unified modeling language [26].

Below is the phase wise explanation of Secure TROPOS (see Table 11). In order to have an in depth understanding of Secure TROPOS activities, please refer to Table 12.

Table 11: Four Phases of Secure TROPOS

Phase Phase Description Input Participants Output Purpose Risk in Omission

24

1. Early Requirement analysis stage.

In this stage developers understand the problem by studying the organization environment and their settings. Stakeholders are identified and developers model the stake holders as actors to identify the goals, dependencies between the actors. Actors goals are decompose into more precise goal through goal oriented analysis in order to achieve the goals [59][60].

Organization Environment and their settings.

Stakeholders (Actors), Developers

Output will be organizational model which include the actors, Security entities and the dependencies between them [59][60].

The purpose is to identify the actors, security entities and to understand the problem of the organization [59][60].

Security constraints are identified for the stakeholders who are further analyzed in the later steps. For each actor corresponding secure goals are introduced in order to satisfy them. By omitting this step security constraints will be ignored for each actor and we cannot further analyze the security goals for the corresponding actors [59][60].

2. Late Requirement Analysis Stage

First stage was to analyze the actors. In this stage system is analyzed in operational environment along with the functions and the qualities. In the late requirement stage one or more actors are also introduced because sometimes the existing actors defined in the first stage cannot the satisfy the goals and the dependencies between them [59][60].

Operational environment, System, Early Requirement analysis stage.

Actors, Developers, analyst

System functional and non functional requirement are defined. Furthermore entities are assigned to the actors in order to satisfy the security goals [59][60].

The purpose is to describe the model of the system as an actor which are defined in the previous stage.

Most of the actors defined in the first step could not satisfy their corresponding intentions goals or their relationships between them. By omitting this step we could not add more actors in the system which can lead to failure in satisfying the goals of the system. Secondly we will be unable to define the functional and non functional requirements of the system [59][60].

3. Architectural design Stage

• Definition of the overall organization.

• Identification of the capabilities.

• Identification of agent Types.

In this stage architecture of the system is defined in terms of: • Subsystems. • These subsystems are interconnected through data and dependencies. Furthermore this stage is divided into three steps as listed in steps section. Architecture of the organization is defined by identifying the new actors and corresponding goals are assigned to them. Second step explains the resources or capability needed by the actor to achieve their goals. Third step identify the agent types [59][60].

Actors, Goals, Early Requirement analysis stage.

Architect, Designer, Developer

Set of software agents are identified corresponding to the actors [59][60].

The purpose of this step[59][60]: • Involve new actors that they can interact with the external actors. • Decomposition of the actor so that every actor defined must be analyzed in detail with respect to their goals. • Set of agent types are defined and their corresponding capabilities.

By defining new actors in this stage we define security constraints and when we further decompose actors we identify security sub constraints and their entities. By omitting this step some security constrains and sub constraints will be neglected which can lead the system insecure. Furthermore we cannot move to the next step which is detail design stage [59][60].

25

4. Detail Design Stage.

In this stage architectural component defined in the previous stage are discussed in details in terms of [59][60]: • Inputs • Outputs • Security • Control

Architectural Design Stage, Early requirement analysis, late requirement analysis [59][60].


Capabilities of the software agents are identified and their interaction through the system is modeled. Agents are derived from the actors defined in the previous stage [59][60].

Purpose is to identify the software agent capabilities by introducing the security rules and to further analyze the architectural component [59][60].

In this stage security aspects are taken into account from the previous steps. By omitting this step we cannot trace back to early requirement phase [59][60].

Secure TROPOS is implemented in a number of sequential steps. Input of each

step is dependent upon output of the preceding step. Detail implementation steps of Secure TROPOS are mentioned below in Table 12. Purpose of each step along with the risk if that particular step is omitted, is mentioned. This Table (12) can be used for analysis in the later section in which we are going to propose a framework. We have used ST with a digit, in ID field, in order to be able to uniquely identify activities of Secure TROPOS from activities of other techniques.

Table 12: Implementation Steps of Secure TROPOS

ID Step Description

Input Participants Output Purpose Risk in Omission

ST1 Construction of Security reference diagram

Security Features Stakeholders (Actors), Developers

Security Reference Model/diagram

The security reference modeling involves the identification of security needs of the system‐to‐be, problems related to the security of the system, such as threats and vulnerabilities, and also possible solutions (usually these solutions are identified in terms of a security policy that the organization might have) to the security problems.

We lose track of the security features we have to take care of.

ST2 Modeling Stakeholders along with their goals, dependencies, and security constraints.

Stakeholders, dependencies, security constraints, Security Reference Model

Stakeholders (Actors), Developers, Requirement analyst

(Partial) Stakeholder/Actor diagram

It allows developers to perform an analysis by introducing relationships between stakeholders and security constraints and its context.

We have no idea of the stakeholders and their relationship with each other. We cannot describe the relation between stakeholders and security constraints.

ST3 Analyze In depth each actor’s goals and security constraints imposed to them.

(Partial) Stakeholder/Actor diagram


Detail actor diagram for each actor

Identification of relationships and constraints related to each actor

In‐depth vulnerabilities are neglected

ST4 Introduce Secure entities

Detail actor diagram for each actor


Detail actor diagram for each actor. (Steps 3 and 4 are performed simultaneously)

To help towards the satisfaction of imposed security constraints.

We cannot check if the security goal has been achieved or not

26

ST5 Analysis of system under development within its operational environment along with relevant functions and qualities

Complete actor analysis from step 3 and 4

Actors, Developers, Requirement analyst

System (partial) analysis (diagram)

The system is introduced as one more actors, to which existing actors delegate responsibilities for some of the goals and the dependencies that they cannot satisfy. The delegated dependencies define all the functional and non‐functional requirements of the system.

Relationship between security constraints and operational environment cannot be understood

ST6 Addition of new actors


Architect, Designer, Developer, Requirement Analyst, Actors


To make the system interact with external actors

Development of Secure communication methods between internal and external actors is neglected

ST7 Actor Decomposition

Output from step 6



Each actor is described in detail with respect to their goals and tasks

Goal associated with the actors might be misunderstood

ST8 Identify secure capabilities for each actor

Output from step 7



Capabilities needed by the actors to fulfill their goals are identified

Lose track of resources needed by actors.

ST9 Agent Assignment

Output from step 8


Architectural design

Set of agent types is defined and each agent is assigned one or more capabilities.

In‐ability to define trust between actors

ST10 Specify agent capabilities and interactions taking into account the security aspects derived from previous steps of analysis.

Architecture design


Detail Design Consists of identifying a design that satisfies the security requirements of the system, as well as its functional requirements.

Cannot trace leftover problems

ST11 Validation Detail Design Stakeholders, Architect, Designer, Developer

Final security model

Validate the relationship between threats and security features. To check consistency between different security models.

Lack of consensus among stakeholders. System might not work with some components or other systems.

27

Figure 5: Secure TROPOS example

Figure 4 is an example of Secure TROPOS which shows the security of eSAP

System. eSAP is electronic single assessment process system which is an agent based health and social care for older people. This diagram illustrates modeling stakeholders along with their goals, dependencies and security constraints. As you can see from diagram each node is an actor and the links between each node shows that they are dependent on each other to accomplish goal. For example older person depends upon benefit agency(Actor) so that older person can have financial support. In order to keep their financial information private, older person impose security constraints to the benefit agency. Likewise R&D Agency is dependent upon professional so that they can obtain clinical information to conduct research. As you can see from figure professional imposed a constraint to keep patient anonymity from department of health [59].

3.2 Misuse Case Misuse cases are actions that are performed by actor (Person) in order to harm

system. Purpose of misuse cases elements is to threat use case to hinder them in achieving the goal [6].

Figure 6: Misuse Cases example

Above diagram (Figure 5) is an example which shows use and misuse case of car

security requirements. As it is shown in figure driver the car, lock the car and lock the transmission are use case elements. Where as in the right side of picture steal the

28

car, short the ignition are misuse case elements. In order to mitigate threat (Steal the car) driver must lock the car. To mitigate short the ignition driver must lock the transmission [6].

As discussed earlier, Misuse cases is an informal technique proposed by Sindre and Opdahl. Normally, informal techniques lack definition of discrete and clear number of steps [41]. If we look at the Implementation steps of Misuse cases, we clearly see that there is no pre‐defined end state and creation of Misuse case depends upon the creativity of the person using Misuse cases technique [6,45,65,79]. We have used MC with a digit in ID field, in order to be able to uniquely identify activities of Misuse cases from activities of other techniques.

Table 13: Misuse Cases Implementation Steps

Step Number

Step Description

Input Participants Output Purpose Risk in Omission

MC1

Concentrate on normal actors and use‐cases

Use Cases

Stakeholders, Analyst

Use case with preliminary Identification of weak points

To understand the services user wants. Simple motivation for this step is: if there is nothing to use, there is nothing to misuse.

Misuse case is created on the basis of Use Case. Omitting this step will stop further progress with misuse case technique [80].

MC2

Introduce major Misuse Cases

Output from step 2

Analyst Major Misuse case identification, Misuse case diagram

To express the intentions of mis‐actors who intend to harm the system.

By omitting this step, mis‐user’s intentions towards the system are skipped [80].

MC3

Investigate Potential Relation between Misuse cases and Use cases

Misuse case

Analyst Detail Misuse case

To identify the nature of threat. Many threats to a system can be achieved through normal functionality e.g. Denial of Service

We have no clue of the nature of attacks [80].

3.2.1 Misuse Cases Template Since Misuse cases is an extension of Use case [80], there are common fields

between Use case and Misuse cases templates such as Name, Date, and Author etc. There are some additional fields that are specific for Misuse cases Template. Following are the fields included in Misuse cases template [80].

Table 14: Misuse Case Template

Field DescriptionName Misuse Case Name/TitleSummary Explanation of Misuse caseDate Date of creation of Misuse caseAuthor Creator of Misuse caseBasic Path Steps which a misuser is going to take before reaching the goal Alternative Path Other paths through which the same goal can be reachedCapture Point Options for how misuse can be detected and prevented [61]. Extension Point Optional paths taken by misuseTriggers Condition that can initiate misuse casePre‐conditions This condition describes those states of the system which make misuse

possible Assumptions This condition describes those states of the system’s environment

which make misuse possible Post‐conditions State of the system after successful misuse caseWorst Case Threat Maximum damage possible in case of a successful misuse case.

Optional paths are also included. Prevention guarantee “Prevention Guarantee describes the result that would be obtained by

following the “Basic” or “Alternate” path if the threat were detected and minimum threat mitigation occurs.”[34]

29

Detection guarantee “The “Detection Guarantee” describes the result that would be obtained if the misuse were detected, but not mitigated.”[34]

Related Business Rule “Related Business Rules are use case business rules that are broken by the misuse case”[34]

Potential Misuser Profile Level of skills and intentions of the misuse must be assessed in order to be aware of the severity of threat

Stakeholders The people who have concern about what should not happen in the system

Scope “The scope of modeling, e.g., the entire business or just the planned computerized information system” [80]

Abstraction Level What is the level of abstraction for the misuse case e.g. summary, sub function etc.

Technology and Data Variations

Which various ways and technologies can be used to achieve the misuse

3.3 CLASP CLASP is an application security process which focuses on security throughout

software development life cycle. CLASP has five views (see Table 15), twenty four activities (see Table 16) which are grouped in seven best practices (see Table 17).

Table 15: CLASP Views View DescriptionConcepts View Purpose of this view is to gain an overview of all the CLASP

processes and activities. Special attention is given to all the concepts, activities and processes of CLASP [28,88,66].

Role Based‐View This Section Gives an idea to the project manager how he and his project members will deal or interact with the security problems. Role based also introduces the basic responsibilities for the team members. Role based is used as initial point for the team members in order to address the security of software [88,28,66].

Activity assessment view CLASP Includes 24 activities. It is not necessary to include all of them. In assessment view, those activities are considered which are appropriate for the software and which benefit the cost. Focus of this view is on two things i.e. risks and implementation cost. Those activities which have low risk and high implementation cost may be deleted in this view [28,88,66].

Activity Implementation View CLASP activities are translated into software development processes. Subset of these activities are assessed and accepted in this phase [28,88,66].

Vulnerability View In this view all the security problems are categorized [88,66].

Following twenty four activities [66,88] are performed in CLASP. Some of these

activities can be performed independently whereas to carry out some activities, we need outputs of other activities. We have used CL with a digit, in ID field, in order to be able to uniquely identify activities of CLASP from activities of other techniques. Relative impact of CLASP on several key traditional software engineering activities such as requirements specification is mentioned in Description field. Steps within such activities are not “materially changed” by CLASP [66,88]. Instead, CLASP “recommends extensions to common artifacts and provides implementation guidance for security‐specific content” [66]. Owner in Participant field is the person(s) who initiate and perform the activity. Key contributors provide significant support to the activity.

Table 16: CLASP Activities

Step Number

Step Description Input Participants Output Purpose Risk in Omission

30

CL1

Institute security awareness program (Relative Impact: High)

Trainings, Concepts

Project manager, Team Members

Security awareness

Trainings are conducted in order to ensure that project managers and the whole development team knows about the importance of the security in the software

Team members will not understand the concept and importance of security.

CL2

Monitor Security Metrics (Relative Impact: High)

Organization, Application

Project manager

Critical Vulnerabilities are assessed to know the level of improvement in security.

To identify part of software that requires more attention. By identifying those areas, security can be improved. To identify the frequency of the defects.

By omitting this step there will be no concrete base to measure security effort.

CL3

Specify Operational environment (Relative Impact: Medium)

Operating Environment

Owner : Requirement Specifier, Key Contributor: Architect ,

Operational environment specification

Operation environment is identified in order to assess the security impact. Assumptions can be made in order to identify the operational environment or through the requirements of the systems

By not properly identifying the operational environment we will not be able to communicate to users the impact of security in design decisions.

CL4

Identify global security policy (Relative Impact: Medium)

Organization Requirement specifier

Security business requirements, Comparison of products in organizations in order to capture security posture.

By identifying the global security policy a comparison can be made of the security procedure of the products related to the different organizations. By this we can have a default base line for security business requirements

It might create an hindrance in comparing different security procedure with different organizations

CL5

Identify Resources and trust boundaries. (Relative Impact: Low)

System Owner:Architect , Key contributors: Requirement Specifier

Security requirements

The system is introduced as one more actors, to which existing actors delegate responsibilities for some of the goals and the dependencies that they cannot satisfy. The delegated dependencies define all the functional and non‐functional requirements of the system.

Relationship between security constraints and operational environment cannot be understood

31

CL6

Identify user roles and resource capabilities (Relative Impact: Medium)

System Owner : Architect , Key contributor: Requirement specifier

System roles, resources

System roles and the resources these roles can access are identified.

By not identifying the roles according to the resources available might create hindrance in the protection mechanism on resources. Secondly by not specifying roles according to resources available will create confusion regarding the access control mechanisms.

CL7

Document Security Relevant Requirements (Relative Impact: High)

Application, Security

Owner: Requirement Specifier, Key contributor

Functional and Business requirements for security

Functional Requirements for security are documented

System services for security can be ignored easily.

CL8

Detail Misuse cases (Relative Impact: Low)

System, organization

Owner: Requirements specifier, Key contributors: Stake holders.

Risks are identified which can be communicated to stakeholders

To communicate potential risks to the stakeholder.

Customer will not understand the threats and the risks related to the system.

CL9

Identify Attack Surface (Relative Impact: High)

Application Design

Owner: Designer

Potential entry points for attack.

By identifying the attack surface one can identify the maximum entry points for an attack to the system. This can be measured by identifying the number of inputs to the program.

Failure to consider important entry points. There can be a chance of duplication of work in other activities.

CL10

Apply security principle to design (Relative Impact: High)

Application Owner: Designer

Implementation strategies, Design principles

Determine implementation strategy for security.

Not applying security principles earlier in design phase will result in revisit the design phase in case some security problem arise in the implementation part.

CL11

Research and assess security posture of technology solutions (Relative Impact: High)

Third party components, Technology

Owner: Designer, Key Contributor: Component Vendor

Security Risks in technologies.

It will assess risks in third party components. Determine how effectively a technology reduces risks.

Security problems in third party components can potentially compromise system’s security.

CL12

Annotate class designs with security properties (Relative Impact: Low)

Data fields, Class design

Owner: Designer

Detail explanation of security policies.

Security policies are defined for data fields.

Error in implementing access control policy.

CL13

Specify Database security configuration (Relative Impact: Medium to High)

Database resources

Owner: Database Designer.

Default configuration in order to secure database resources.

Default security configurations are identified for the databases that are associated with implementation. Identify recommended security configuration for database resources for databases that are deployed by a third party.

By omitting this activity will have security Errors in database configuration.

32

CL14

Perform Security analysis of system requirements and design (Relative Impact: High)

System Owner : Security Auditor, Key contributor: Architect and designer

System threats,System risks, Security impact

System risks are analyzed by analyzing the requirements and the design of the system. It identifies the high level system threats which are not properly documented in requirements section. Security impact of non security requirements are assessed in this phase.

System threats and risks will be ignored.

CL15

Integrate security analysis into source management process (Relative Impact: Medium)

Management process

Owner: Integrator.

Regular metrics data, implementation review.

Automatic Metric collection and implementation security level analysis.

Omitting this activity will lead to manual labor which can have negative impact on project scheduling. Implementation reviews can be easily skipped.

CL16

Implement Interface contracts (Relative Impact: High)

Program Interface.

Owner:Implementer.

Reliability Errors are identified.

It is used for validation of inputs. Reliability Errors are identified.

Critical data related to security will be not identified. Input validation will not be complete.

CL17

Implement and elaborate resource policies and security technologies (Relative Impact: Very High)

Specification Owner: Implementer.

Security functionalities

Security Functionalities related to the specification will be implemented by the implementer.

Will increase risks

CL18

Address reported security Issues (Relative Impact: High)

Software Owner: Designer, Key contributor: Fault Reporter

Security Riski .e. to check whether the security risks identified are addressed or not.

It is used to check whether the risks identified in the design phase are addressed properly in implementation phase

Risks not addressed in implementation will lead to more threats in the software.

CL19

Perform Source Level security review Relative Impact:(Very High)

Software, System

Owner: Security Auditor, Key contributors: Implementer, Designer.

Measurement of health of secure software development effort.

Vulnerabilities related to security are identified in implementation.

Those risks which are ignored or skipped in the design phase can be reflected in the implementation phase.

CL20

Identify , implement and perform security Tests Relative Impact:(Medium)

Design review, Operational environment

Owner: Test analysts.

Security Problems, Security Risks.

Security Problems are found which are not identified in the implementation part. Failures can be identified in design, specification and implementation.

Security risks will be reflected in deployment.

CL21

Verify Security attributes of Resources (Relative Impact: Medium).

Software operational environment.

Owner: Tester Confirmation of previously defined security policies.

Confirm previously defined security policies.

Attackers have a direct access to the resources of the software.

CL22

Perform Code Signing (Relative Impact: Low).

Software Owner: Integrator.

Malware are omitted

Provide the stakeholder with a means of validating the origin and integrity of software

Customer may receive illegitimate software with malwares.

33

CL23

Build Operational Guide (Relative Impact: Medium).

Security functionality, Software.

Owner: Integrator, Key Contributors: Designer, Architect, Implementer

Operational security measures document.

Documentation is provided to stakeholder related to operational security measures.

User may install the software without recommended security configurations

CL24

Manage security issue disclosure process (Relative Impact: Low)

Security Researchers

Owner: Project Manager, Key Contributor: Designer

Effective communication.

Communication with customers and security researchers from outside when issues are found in released software.

Damage business reputation

All the 24 activities defined above are grouped in seven best practices in CLASP.

Related activities of CLASP are grouped into seven best practices, 1. Institute awareness program: Purpose of this activity is to educate everyone

involved about security concepts and techniques used in organizations through trainings and accountability.

2. Perform application assessment: The purpose of this practice is to assess the application by identifying security problems and security risks introduced in operational environment.

3. Capture Security Requirements: In order to capture security requirements followings factors must be considered:

• Understand the application in context of usage and attack scenarios.

• Assets are identified in order to find the level of access they provide. • Overall architecture of the application.

4. Implement secure development practices: Goal of this practice is to achieve secure development practices in organization. It guides project team when applying security principles to design and elaborating resource policies.

5. Build vulnerability remediation procedures: Role of this activity is to reduce risks by defining roles, responsibilities, prioritize steps and remediate vulnerabilities.

6. Define and monitor metrics: This practice is critical in analyzing the security posture of an organization, security effort and monitors the overall performance.

7. Publish operational security guidelines: Documentation is provided to stakeholder related to operational security measures. Tasks defined above must be communicated to different researchers.

Following Table is inspired from [28] for better understanding of CLASP best practices.

Table 17: CLASP Best Practices CLASP Best Practices ID CLASP Activities Related Project Roles 1. Institute security

awareness program CL1 Institute security awareness program Project Manager

2. Perform Application Assessment

CL14 Perform Security analysis of system requirements and design

Security Auditor

CL19 Perform Source Level security review Owner: Security Auditor Key Contributor: Implementer, designer

CL20 Identify , implement and perform security Tests

Test analyst

CL21 Verify Security attributes of Resources TesterCL11 Research and assess security posture of

technology solutions Owner: Designer Key Contributor: Component Vendor

3. Capture Security CL4 Identify global security policy Requirement Specifier

34

Requirements CL5 Identify Resources and trust boundaries Owner: Architect Key Contributor: Requirement Specifier

CL6 Identify user roles and resource capabilities

Owner: Architect Key Contributor: Requirement Specifier

CL3 Specify Operational environment Owner: Requirement SpecifierKey Contributor: Architect

CL8 Detail Misuse cases(Relative Impact: Low)

Owner: Requirement SpecifierKey Contributor: Stakeholder

CL9 Identify Attack Surface Designer CL7 Document Security Relevant

Requirements Owner: Requirement SpecifierKey Contributor: Architect

4. Implement Secure development practices

CL10 Apply security principle to design Designer CL12 Annotate class designs with security

properties Designer

CL17 Implement and elaborate resource policies and security technologies

Implementer

CL16 Implement Interface contracts Implementer CL15 Integrate security analysis into source

management process Integrator

CL22 Perform Code Signing Integrator 5. Build vulnerability

remediation procedures CL24 Manage security issue disclosure process Owner: Project manager

Key Contributor: Designer CL18 Address reported security Issues Owner: Designer,

Fault Reporter 6. Define and monitor

metrics CL2 Monitor Security Metrics Project Manager

7. Publish Operational Security guidelines

CL13 Specify Database security configuration Database Designer

CL23 Build Operational Guide Owner: Integrator Key Contributor: Designer, Architect, Implementer

3.4 Summary As far as Secure TROPOS is concerned, it uses strict notations and diagrams which

are really difficult to integrate with textual form of activity description (see Figure 4). The notations like depender, node, constraints, dependee, dependum etc used in Secure TROPOS are extension of Tropos methodology. Without these notations one cannot carry out activities of Secure TROPOS. Focus of Secure TROPOS is to secure the system.

Misuse cases have both textual and pictorial form of representation (see Figure 5). Misuse cases represent attacks on a system. Unlike CLASP and Secure TROPOS, Misuse cases focus on threats to a system.

All the 24 activities of CLASP have textual explanation. It means that activities of CLASP are explained in simple and plain language. CLASP’s activities and best practices focus on securing the system throughout software development lifecycle.

35

4 PROPOSED FRAMEWORK We went through a number of activities for proposing a framework for security

requirement elicitation using CLASP, Secure TROPOS and Misuse cases. All of these activities are mentioned clearly in this chapter. It should be kept in mind that there were many places where we removed some constraints in the activities which were specific for the technique. These constraints were removed to make the activity integrate‐able with other activities. For example: Activities in Secure TROPOS are sequential and Secure TROPOS uses special notations and diagrams for security constraints and requirements which makes integration of Secure TROPOS with any other technique very difficult. We used the basic idea behind such activities and proposed new activities in our framework. We proposed this framework by integrating activities from CLASP, Secure TROPOS and Misuse Cases.

4.1 Overlapping Activities of CLASP and Secure TROPOS We compared activities of CLASP and Secure TROPOS and found similarities in

some of the activities on the basis of concept behind the activities. To check similarities we looked into actual steps of the techniques. As discussed earlier, Secure TROPOS uses graphical notations which are difficult to integrate with techniques having textual form of representation. Therefore we used the basic concept behind Secure TROPOS activities.

Some of activities of CLASP use similar concept as some activities in Secure TROPOS. For example Activity CL3 says that one must specify operational environment in order to assess security impact. Using the same concept ST5 in Secure TROPOS says that “to analyze system one should specify operational environment in which system works”. Same is the case with CL10 and ST6, ST7, ST8 which are related to architectural design. We have listed down the overlapping activities to eliminate repetition of activities (see Table 18). Activities of Secure TROPOS are based upon language notations and diagrams. We have taken the basic idea behind each activity of Secure TROPOS and ignored notations and diagrammatical representations.

Table 18: Overlapping Activities of CLASP and Secure TROPOS

CLASP Activity ID Description

Secure TROPOS Activity ID

Description

CL2 Monitor Security Metrics ST1 Construction of Security reference diagram

CL3 Specify Operational environment ST5

Analysis of system under development within its operational environment along with relevant functions and qualities

CL10 Apply security principle to design

ST6,ST7, ST8,

These activities are performed to produce an architectural design

CL5 Identify Resources and trust boundaries ST9 Agent Assignment


ST10 Specify agent capabilities and interactions taking into account the security aspects derived from previous steps of analysis

CL21 Verify Security attributes of Resources ST11 Validation

4.2 Best Practice Selection Theme of our thesis is to propose a framework, through which you are able to

elicit security requirements. After analyzing CLASP practices we realized that these practices are related to different phases of Software Development Lifecycle such as

36

implementation and testing whereas focus of our research was on requirement elicitation. So we selected two best practices of CLASP that contain the activities related to requirement gathering phase (see Table 19).

Table 19: Selected Best Practices for CLASP

CLASP Best Practices ID CLASP Activities Related Project Roles Perform Application Assessment


Security Auditor

CL19 Perform Source Level security review Owner: Security Auditor Key Contributor: Implementer, designer

CL20 Identify , implement and perform security Tests

Test analyst

CL21 Verify Security attributes of Resources Tester CL11 Research and assess security posture of

technology solutions Owner: Designer Key Contributor: Component Vendor

Capture Security Requirements

CL4 Identify global security policy Requirement Specifier CL5 Identify Resources and trust boundaries Owner: Architect

Key Contributor: Requirement Specifier

CL6 Identify user roles and resource capabilities Owner: Architect Key Contributor: Requirement Specifier

CL3 Specify Operational environment Owner: Requirement SpecifierKey Contributor: Architect

CL8 Detail Misuse cases(Relative Impact: Low)

Owner: Requirement SpecifierKey Contributor: Stakeholder

CL9 Identify Attack Surface Designer CL7 Document Security Relevant Requirements Owner: Requirement Specifier

Key Contributor: Architect

4.3 Activity Selection We further analyzed activities of the two selected best practices and found out

that there are some activities which focus on other than requirement phase of Software Development Lifecycle. We deleted activities which were out of context for us and kept only those which focus on security requirement capturing phase. We then revisited the table in which we listed over lapping activities(see Table 18) and listed down the overlapping activities of CLASP and Secure TROPOS for our finally selected activities. Our final activities are listed below (see Table 20). It should be kept in mind that those activities of CLASP and Secure TROPOS which are related to phases other than requirement elicitation are equally important in order to secure a system but we only focused on the activities that address requirement elicitation to stay in the scope of the thesis.

Activity number CL19, CL20 and CL21 were deleted because they are related to implementation and Testing phases of the Software development Lifecycle.

Table 20: Selected Activities from CLASP CLASP Best Practices

ID CLASP Activities Overlapping activitiesfrom Secure TROPOS

Perform Application Assessment

CL14 Perform Security analysis of system requirements and design ST10

CL11 Research and assess security posture of technology solutions

Capture Security Requirements

CL4 Identify global security policy CL5 Identify Resources and trust boundaries ST9 CL6 Identify user roles and resource capabilities CL3 Specify Operational environment ST5 CL8 Detail Misuse cases

(Relative Impact: Low)

CL9 Identify Attack Surface CL7 Document Security Relevant Requirements

37

Table 21: Selected Activities from Secure TROPOS

Secure TROPOS Activity ID Description ST2 Modeling Stakeholders along with their goals, dependencies, and security constraints. ST3 Analyze In depth each actor’s goals and security constraints imposed to them. ST4 Introduce Secure entities.ST8 Identify secure capabilities for each actor.

4.4 Additional fields in Misuse Cases Template In this step we considered those activities of Secure TROPOS that have no

overlapping with any of the activity of CLASP i.e. ST2, ST3, ST4 and ST8. We intend to make a separate activity using ST3, ST4 and ST8 because they are

related. Purpose of ST2 is to record Stakeholder information along with their goals, dependencies, and security constraints. It seems feasible to add these fields in Misuse Cases Template (see Table14) and record this information in the added fields. So we added three more fields in Misuse cases template i.e. (see Table 21)

Table 22: Additional fields in Misuse Case Template Field DescriptionGoal Which goal of the stakeholder is hinderedDependencies(Relationship): Relationship of Stakeholder with other Stakeholder(s) Security Constraints Information about Security constraints on Stakeholder(s)

4.5 Sequencing the Steps After finalizing the activities that are to be included in the framework, we

sequenced the activities on the basis of what shall be done first (see Table 22). For example: CL14 is dependent upon the output of other activities [66] so it should be kept at last.

Table 23: Sequence of CLASP Activities

ID Activity DescriptionCL3 Specify Operational environmentCL4 Identify global security policyCL5 Identify resources and trust boundariesCL6 Identify user roles and resource capabilitiesCL9 Identify attack surfaceCL11 Research and assess security postureCL8 Detail misuse caseCL7 Document security‐relevant requirementsCL14 Perform security analysis of system requirements and design.

4.6 Analysis of Selected Steps: Activity revisit Sequenced CLASP activities were then merged with the activities of Misuse case

and Secure TROPOS (see Table23).

Table 24: Merged activities from techniques ID Activity DescriptionCL3 Specify Operational environmentCL4 Identify global security policyCL5 Identify resources and trust boundariesCL6 Identify user roles and resource capabilitiesST3, ST4, ST8 Identify in‐depth user roles, secure capabilities and security constraints for each actor CL9 Identify attack surfaceCL11 Research and assess security postureMC1 Concentrate on normal actors and use‐casesMC2 Introduce major Misuse CasesMC3 Investigate Potential Relation between Misuse cases and Use casesCL7 Document security‐relevant requirements

38

CL14 Perform security analysis of system requirements and design.

4.7 Using Security Requirement Categorization When we looked at Misuse Case activities, we still face the problem that “Misuse

creation depends upon the creativity of the person creating Misuse case”. So we decided to use Security Requirement Categorization by Bogale and Ahmed [11] in which they have categorized all the known security requirements and validated their categorization from Swedish Armed Forces (see Appendix C).

In order to make sure that maximum security requirements are captured, we initially assume that all security requirements mentioned in Security Requirement Categorization [11] are true for all identified entry points, functionalities, assets, services and actors. There are going to be many requirements which are not valid for an entry point, functionality, asset, service or actor. We delete invalid requirements one by one for each entry point, functionality, asset, service or actor. The left over security requirements will be valid security requirements for each entry point, functionality, asset, service or actor.

4.8 Proposed Framework Following steps are proposed after analysis of activities mentioned in earlier

sections in this chapter. It should be noted that Detail Misuse Case activity i.e. Step8 and 11 are comprised of three sub‐activities mentioned in Table 13 and Table23.

Table 25: Framework Steps

Step Number Description

Activity ID from CLASP, Secure TROPOS or Misuses Cases

1 Specify Operational environment CL3 2 Identify global security policy CL4 3 Identify resources and trust boundaries CL5 4 Identify user roles and resource capabilities CL6

5 Identify in‐depth user roles, secure capabilities and security constraints for each actor

ST3, ST4, ST8

6 Identify attack surface CL9 7 Research and assess security posture CL11 8 Detail misuse case MC1, MC2, MC3 9 Document security‐relevant requirements CL7 10 Perform security analysis of system requirements and design. CL14 11 Update security requirements document

12 Identify resources, entry points, functionalities, assets, services and actors for the system

13 Suppose all the threats mentioned in the categorization are true for all resources, entry points, functionalities, assets, services and actors for the system

14 Validate threats for each resource, entry point, functionality, asset, service and actors for the system

15 Update the document.

Further analysis of the framework showed that there can be iteration from Step8 to Step15. Step 11 and onwards do not belong to any technique. These steps are included to facilitate the use of Security Categorization (see section 4.7)

4.8.1 How to conduct each step of Framework Most part of the section 4.8.1 contains text from [66] and [88]. Most of the text

written in before mentioned section also belongs to [66] because there were many things which were better explained in original text from [66].

It should be noted that first nine activities are decomposition of the system for “Perform security analysis” activity of the system. We break down the application to

39

understand user roles, entry points, exit points and dataflow in first nine activities of the framework. These activities act as an input for security analysis of system.

4.8.1.1 Specify Operational environment This activity helps the team members in understanding the operational context of

the system. Consideration of operational context facilitates the team in establishing security guidelines and principles [66].

An operational worksheet is provided in Appendix A for this activity. Following important aspects of this activity should also be looked into while performing this activity.

• Identify requirements and assumptions related to individual hosts User rights and authorization related to software system is the focus of this sub‐

activity [66]. Security policies defined by the organization regarding the use of particular software are listed here. Moreover risks related to the platform on which the software is installed must also be highlighted. For example: there may be some components of OS that pose risk to the usage policy of a software.

In addition, all optional functionalities and their impact on security must also be considered in this sub‐activity [66].

• Identify requirements and assumptions related to network architecture Network resources, network topologies, existence and configuration of firewalls

are identified in this sub‐activity. Those things and factors which have any impact (negative or positive), on security, must be taken into account [66].

4.8.1.2 Identify global security policy Baseline security requirements act as a reference for security requirement

specifiers. Organization’s security policies and basic security services are defined in order to have clear understanding of internal security procedures [66]. Sample list of global security requirements is presented in Appendix B.

Every global security requirement should be checked for its applicability in the system. If a requirement is not relevant to the project, it should be explicitly documented. Baseline for global security policy is created for protecting data resources. These resources are further divided into categories or technologies which provide guidance about when to apply these technologies and how to apply them when they are used in a project. Global security policy is valuable since it provides the concrete documentation of internal or external procedures that the documentation team should follow. In large organizations it is useful to have a set of baseline security requirements for different projects which ease the job for requirement specifier in long term and provides a path to compare the security posture of different application in organization.

For each security policy following three checks must be performed [66]. • Is the global requirement already addressed by one or more other system requirements?

• If the global requirement contradicts any explicit or implicit requirement for project.

• The global requirement does not contradict any requirement but has not been addressed yet.

40

4.8.1.3 Identify resources and trust boundaries This activity “provides a structured foundation for understanding the security

requirements of a system” [66]. This activity includes following important sub‐activities.

• Identify network level design Describe network architecture of the system and identify any components that

are located on different logical platform such as client software, middleware and databases. A middleware and a database, which both can possibly live on a separate machine, should be identified as logically separate.

After describing network components and architecture, trust boundaries are identified e.g. firewall and Individual hosts. For example, Client machines on the outside are less trustworthy whereas many multi‐user systems can have multiple trust boundaries internally. "Trust boundaries should be mapped to system roles that can be granted level of trust” [66]. In this activity protection mechanism is identified for resources and data links in the architecture diagram. Moreover, the diagram should be annotated with these mechanisms.

• Identify Data resources Data resources that may be used by a program are identified. In the next activity,

individual capabilities related to each resource are identified e.g. identifying individual database tables, instead of simply the database as a whole. Outcome of this activity should be documented separately to facilitate security analysis. The information may be included into business requirements.

Sample resources include [66]: Databases and database tables Configuration files Cryptographic key stores ACLs (Access control Lists) Registry keys Web pages (static and dynamic) Audit logs Network sockets / network media IPC (Inter Process Communication), Services, and RPC (Remote procedure

call)resources Any other files and directories Any other memory resource

"Network media is a resource of its own” [66]. We need to specify how to protect that data when it traverses the media. All the components connected to the media are also considered such as disks and memories.

4.8.1.4 Identify user roles and resource capabilities Purpose of this activity is to identify system roles and capabilities/resources a

particular role can access. The word capability here means the things user(s) may be able to do. Following main sub‐activities are involved in this activity.

• Identify distinct capabilities “Capabilities are interesting operations on resources that should be mediated via

an authorization/access control mechanism”. Capabilities are set of operations that are applied on resources. Capabilities are defined so that system users can have proper understanding of the system and can perform these operations. To perform

41

these operations different roles are identified on the basis of authorization/Control mechanism. All the access control mechanisms for operations, user rights and authorities are defined in this sub‐activity.

• Map system roles to capabilities System roles and set of capabilities are mapped in this sub‐activity. This step

helps in understanding which set of capabilities are assigned to which users. Most of the time system itself is a set of roles which includes capabilities and can access them. Example of this is client server application.

• Identify Attacker profile (attacker roles and resources) One must have a clear picture of the origin of threat. By knowing the origin of

threat, one can predict the resources attacker may use. Attacker profile must be documented.

Examples of different types of attackers are as follows − Insiders – People from inside the organization or have access to the

infrastructure. − Script Kiddies‐ People who uses software or existing scripts to exploit

weaknesses. − Competitor‐ Who may have a reasonable budget. − Governments‐ May have an extra ordinary budget and resources. − Organized Crime Units‐ Choose few targets for financial gain normally. − Activists‐ who target organizations which are not liked (by community or a

group of people).

4.8.1.5 Identify in‐depth user roles, secure capabilities and security constraints for each actor Each user’s abilities to interact with the system and resources a user can access

are identified. Secure capabilities are separated from insecure capabilities and explicitly mentioned. Security constraints on each actor with their impact are identified. Security constraints are also checked for their successful implementation.

4.8.1.6 Identify attack surface Identify all the entry points to facilitate the analysis. Define all the components

attacker can interact with. Define mechanism through which any one can interact with the system regardless of his/her role in the system. Document all the following [66]

− network ports opened, − places where the file system is touched − any local User Interface elements, − any inter‐procedural communication points − Any public methods that can be called externally while the program is running After identifying entry points, map roles to entry points. Next step is to map

resources to the entry points. In mapping roles all roles that can possibly access entry points are identified. After that document the resources that are accessible from that entry point.

42

4.8.1.7 Research and assess security posture Generally, it is very hard to get technology assessment from vendors because

they are rarely cooperative in this regard. Still, you need to know the risk associated with the software components you are using in your system. Self‐assessment sheet based on interaction with the vendor, which can be filled in by you or the vendor is included in Appendix A. Worksheet is filled by conducting structured interviews with vendors.

Worksheet should be able to answer following points in this activity [66]. • At a high level, what are the trust boundaries, resources, and roles in the

system? • Has an independent assessment been performed by a respected third‐party?

And if so, what business risks did it identify, and what has changed since the assessment?

• What are the security qualifications of the development team? • What are the major areas of risk in the product? • What were the security requirements that were used for development

(implicit and explicit)? In addition to above mentioned points, you must collect data from customers and

user reviews. If possible perform security testing on the component. Above mentioned steps will help you in deciding whether to proceed with the technology or not.

4.8.1.8 Detail misuse case Misuse cases technique is similar to use case except the aim where Misuse case is

“meant to detail common attempted abuses of the system” [66]. Determining Misuse case is a brainstorming activity and there are three good points for structured brain storming [66] i.e.

• The person performing the activity should describe how the attacker will take advantage of a problem using pre‐existing knowledge of common security problems.

• The person, performing the activity shall construct misuse cases for each system resource by brainstorming for each of the basic security services e.g. authentication, confidentiality, access control, integrity, and availability.

• The person, performing the activity shall create misuse cases on the basis of a set of existing use cases to ensure that the first two steps did not overlook any obvious threats.

Misuse cases should be described visually and should be documented. Defense mechanism is identified for every Misuse case. Results are then reviewed with the stakeholders.

A Misuse case is created using following steps • Concentrate on normal actors and use‐cases by preliminary Identification of

weak points in Use cases • Introduce major Misuse Cases to express the intentions of mis‐actors who

intend to harm the system • Investigate Potential Relation between Misuse cases and Use cases to identify

the nature of threat. Many threats to a system can be achieved through exploiting normal functionality e.g. Denial of Service

43

To have a quick understanding of Misuse Cases activities, please refer to Table 13. Misuse Cases template which is necessary for this activity is included in Appendix J

4.8.1.9 Document security relevant requirements All the business level and functionality related security requirements are

documented in this activity. All the requirements must have following basic properties

• Specific: There must be are no ambiguities in the requirement. Consistent terminologies should be used between requirements.

• Measurable: It should be possible to determine whether the requirement has been met, through testing.

• Reasonable: One should conduct some validation to determine whether meeting the requirement is physically possible keeping in mind the project constraints.

• Traceable: Requirements should also be isolated to make them easy to track/validate throughout the development lifecycle.

• Document explicit business requirements Issues must be communicated to customers earlier in order to avoid problems

after deployment as customers are not always aware of the security problems. [66,88]:

• Recommended authentication solutions • Personal data must be kept Private (Privacy Concerns). • Recommended Confidentiality solutions for network traffic. • Confidentiality solutions for long term storage of key data.

• Develop functional security requirements

Specify protection requirements related to the basic security services like • Authorization (access control): What privileges on data should be granted to

the various roles at various times and what measure shall be taken to enforce the policy [66,88].

• Consider operating environment resources which need to be protected — such as administrative privileges on a host machine [66,88].

• Authentication and integrity: How Identity determined to gain of access to a resource? Is, the resource strongly bound to an identity? For example do individual messages need to have their origin identified, or can data be anonymous on communication channels [66]?

• “Confidentiality (including privacy): Confidentiality mechanisms such as encryption are used to enforce authorization. When a resource is exposed to a user, what exactly is exposed: the actual resource or some transformation?” [66]

• Availability: Requirements should take into account how available a resource should be for authorized users [66,88].

• Accountability (Including non repudiation): Log files need to be specified and protected. [66,88].

• Explicitly label requirements that denote dependencies

44

• All external dependencies should be discovered in requirements to reasonable degree [66,88].

• All third‐party components and required functionality in the operational environment specification should be specified [66,88].

• Any requirements denoting external dependencies should be explicitly labeled to facilitate subsequent analysis [66,88] .

• Determine risk mitigations (compensating controls) for each resource

Business level resources are identified that need to be protected — i.e., what are the risks to individual resources and how the risks need to be addressed [66,88].

• Resolve deficiencies and conflicts between requirement sets In order to determine omissions and conflicts, set of requirements are mapped to other sets of requirements [66,88].

4.8.1.10 Perform security analysis of system requirements and design. In order to perform security analysis of a system, following outputs from previous

activities are needed as an input for this activity • “A specification of the operational environment; • A high‐level architectural diagram indicating trust boundaries; • A specification of resources and capabilities on those resources; this may

be incorporated into the requirements; • A specification of system users and a mapping of users to resource

capabilities; this also may be incorporated into the requirements; • An attack surface specification, to whatever degree elaborated; • Data flow diagrams, if available; • An attacker profile (again, this may be part of the requirements); and • Misuse cases, if any.”[66]

Security analysis consists of set of sub‐activities i.e. • Develop an understanding of the system

To develop an understanding of the system before security analysis is important. Documentation shall be reviewed for existing high level system. It is generally best to have a project overview from a customer‐centric perspective on the project. • Determine and Validate security relevant assumptions

Any assumptions that are made about the attacker and environment in which system is deployed should be validated and then incorporated into project documentation [66,88]. • Review Non‐security security requirements

Find out any security implications that are not properly addressed in the security requirements. Also look into requirements that are not explicitly aimed at security. Through data flow diagram we can assess the impact on each security service while tracing resources that are relevant to a requirement [66,88]. • Assess completeness of Security requirements

For each resource and capability, security services must be addressed with security requirements. This is done through a correlation matrix, where requirements are on one axis and security services on capabilities (or resources) are on another axis [66]. Appropriate boxes for each security requirement, where requirements have an impact, are marked in the matrix. This matrix assesses the completeness of requirements, i.e. if the security service is adequately addressed.

45

• Identify Threats on Assets/Capabilities All potential security threats should be identified and documented for each

security service on each capability by iterating through assets and capabilities [66,88]. • Determine level of risks

Decision making process of an attacker can be modeled using threat trees. Look particularly for ways that multiple conditions can be used together to create additional threats [66]. • Determine risk mitigations for each resource

Mitigation steps for each threat indentified in the previous activity should be explicitly mentioned along with any possibility of reproducibility of the particular threat. • Evaluate findings

Security auditor should report any security risks that may not have been adequately addressed in the requirements. Auditor should recommend a preferred strategy for implementing risk mitigation and should discuss any alternatives that could be considered. If any conflicts or omissions are brought to light during requirement review, security auditor should make recommendations that are consistent with project requirements.

4.8.1.11 Update security requirements document Based on the evaluation of findings of Security analysis phase, security

requirement document is updated. All requirements must be mentioned with all the traceability information.

4.8.1.12 Identify resources, entry points, functionalities, assets, services and actors for the system All

• resources, • entry points, • functionalities, • assets, • capabilities, • resources, • services and • actors

shall be explicitly documented

4.8.1.13 Suppose all the threats mentioned in the categorization are true for all resources, entry points, functionalities, assets, services and actors for the system All threats mentioned in security requirements categorization (see Appendix C)

should be supposed true for every point in the list mentioned in last activity.

4.8.1.14 Validate threats for each resource, entry point, functionality, asset, service and actors for the system For each resource, entry point etc. threats which were supposed true are now

validated. For example, threat that is not applicable to a particular resource is omitted for that particular resource. Each threat shall be considered as a Misuse case and documented by filling Misuse case template for each threat separately.

Above mentioned step is performed in iteration until all the threats are adequately validated. Threats that are not omitted in the process will be the valid threats to the system.

46

4.8.1.15 Update the document Security requirements for mitigation of every threat/Misuse case in previous

activity must be documented with traceability information.

47

5 EXPERIMENT We have followed Wohlin et. al [91] guideline for experiment. In this Section, we

have explained the detail description of experiment performed for this research. We have explained Experiment definition, plan, Design and execution of our experiment.

This experiment is performed to measure the applicability of our frameworks. We intend to suggest improvements in the framework on the basis of feedback and results from the experiment.

5.1 Experiment definition 5.1.1 Objective

Objective of this experiment is to check whether by combining formal and informal security requirement elicitation techniques we yield better results than using formal or informal security requirement elicitation technique alone.

5.1.2 Context This experiment was completed in two days and involved six students who were

divided in three groups i.e. two members per group. All six students were software engineering students who have studied requirement engineering course and have at least two years of industrial experience. All six students were supposed to conduct a set of activities in a specific amount of time. These activities were selected from the activities of our framework, CLASP and Misuse case technique. After the experiment, all the six students were asked to fill a feedback form (see Appendix I).

We conducted the experiment with CLASP (a formal technique), Misuse Cases (an informal technique) and Framework. We did not Include Secure TROPOS in the experiment due to three main reasons. 1. Purpose of the experiment was to compare the proposed Framework with a

formal and an Informal technique. CLASP being a formal technique and Misuse Cases being an informal technique, fulfill the purpose of the experiment.

2. Secure TROPOS, as mentioned earlier, has sequential activities which are strictly connected to each other.

3. In addition, many activities of Secure TROPOS focus on phases other than requirement gathering of software development life cycle whereas our focus was only on requirement elicitation.

Therefore we did not include Secure TROPOS in the Experiment. Limited availability of students (subjects) compelled us to select a small system.

We sent two documents i.e. System’s detail description and Activities description to subjects via email two days before conducting the experiment. Purpose to send the document was to give brief overview of activities and software system before experiment. Later we had discussions with our subjects via video conferencing in order to clarify the doubts and questions regarding system and activities.

Keeping in mind the lack of practice of students (subjects) to perform the activities, we conducted one hour pilot exercise before conducting the experiment. Each activity was assigned a specific amount of time.

On first day of experiment i.e. 2012‐March‐29, the students were randomly divided in groups of two to perform the activities. It took total 6 hours to perform first part of the experiment.

48

5.1.3 Sample Space Our sample space consists of software engineering students in BTH.

5.2 Experiment planning 5.2.1 Purpose

Purpose of study is to observe effectiveness of our security requirement elicitation framework with respect to widely used formal and informal security requirement elicitation techniques i.e. CLASP and Misuse Cases.

5.2.2 Quality focus Our study is focused on improving the quality of software by highlighting

importance of security in early phase of software development life cycle.

5.2.3 Perspective This study is beneficial for small and medium size software organizations.

Software companies can benefit from the result of this study. Attacker’s perspective towards software provides detail understanding of vulnerabilities in software. Developing secure software can improve business reputation and public confidence in software.

5.2.4 Context selection Experiment was conducted in controlled environment with the help of six

students who were divided in three groups i.e. two members per group. To perform the experiment we provided detail of a software system and activities of our framework. Software system and its description were selected from paper [66]. We also provided them Misuse case template.

5.2.5 Hypothesis formulation NULL HYPOTHESIS (H0): Formal approaches do not produce better results when integrated with informal approach i.e. Misuse cases. ALTERNATIVE HYPOTHESIS (H1): Formal approaches produce better results when integrated with informal approach i.e. Misuse cases. NULL HYPOTHESIS (H0): The proposed framework is not better than other security requirement elicitation techniques. ALTERNATIVE HYPOTHSIS (H1): Proposed framework is significantly better than the other requirement elicitation techniques.

5.2.6 Variable selection Independent variables in this experiment are as following:

• Framework Activities • Framework Activities Guidelines. • Software System • Misuse case template • Misuse case guidelines. • Clasp Activities • Clasp Guidelines

Dependent Variables in this experiment are as following: • Resources • Trust boundaries

49

• User roles and Resource capabilities • Security Constraint of each actor • Attack Surface • Detail misuse case • Security Requirements • Security Analysis

As shown above; independent variables are the inputs to experiment where as dependent variables are the output of experiment. As experiment is conducted in a controlled environment, dependent variables vary according to inputs of experiment (Independent variables).

5.2.7 Subject selection We selected academic Subjects for our experiment as a population. We have

conducted probability sampling for our experiment. Population was the students who have studied requirement engineering course at BTH and have some industrial experience. Subjects were selected randomly from population. Six students were divided in three groups i.e. two members per group. One Group performed activities of CLASP and the other two groups performed activities of Framework and Misuse cases, respectively.

5.3 Experiment design 5.3.1 Design principle

We have used three basic design principles Randomization, Balancing and Blocking in our experiment.

It was not possible to recruit professionals for this experiment due to time constraints and the availability of professionals. Therefore we decided to include software engineering students that have formal trainings in security requirements engineering and have some industry experience.Randomization is achieved by random selection of software engineering students who have studied requirement engineering Course at BTH. Same number of persons in each group and same amount of total time for each technique justifies balancing i.e. two members per group working for approximately 10 hours. To cover the blocking design principle we made sure that out of three groups, no group should consist of only inexperienced people i.e. one out of two students in each group must have 2‐3 years of industrial experience.

5.3.2 Design type Design type of our experiment is one factor with three treatments.

Table 26: Experiment design type SUBJECT TREATMENT 1 TREATMENT 2 TREATMENT 32 X2 X2 X

According to our Experiment, Treatment 1 is Framework activities, Treatment 2 is CLASP activities and Treatment 3 is Misuse case activities. Factor for the Experiment is Security Requirements.

50

5.3.3 Instrumentation In our experiment we have used objects, guidelines as instrument to monitor and

guide involved participants. Object were

• Documentation of software system on which activities were to be performed

• Misuse cases template. Guidelines were how to perform activities in allocated time.

• Description of each activity of framework, CLASP and Misuse case • At the end of experiment asked them to fill a questionnaire.

Instruments used in our Experiment were: • Students from BTH • Library rooms • Documents of software system • Misuse case template • Guidelines of each activities • Questionnaire • Trainings

Measurement • Number of Security Requirements

5.3.4 Validity evaluation Before performing the experiment we conducted pilot study with two students to

have a basic idea about time to conduct the experiment and feasibility of techniques. During the pilot study, we observed that the participants must have time to understand the tasks and ask questions. Moreover; minimum time to conduct the experiment with a small system is 11 hours. We designed our experiment on the basis of observations during pilot studies.

Before executing the experiment there were two things, we had to take care of two things i.e.

1. In our experiment, framework activities take more time as compared to other techniques. One could argue that since framework is taking more time, so one can elicit more requirements from framework.

2. We are dealing with human beings who have varying level of competencies. So what is the guarantee that people working with framework, CLASP, Misuse Case have the same level of competency to work with requirements? There may be a possibility that people working with CLASP have less understanding than people working with framework. Therefore we are going to get more output from activities of framework.

In order to ensure transparency and justice with all the three methods i.e. Our

Framework, CLASP and Misuse case, we took two steps i.e. 1. Assign same amount of time to the techniques i.e. We assigned the same

amount of total time to all the three methods. It is because by looking 15 activities of framework, one can easily tell that it requires more time whereas CLASP with 10 and Misuse case with three activities would take far less time. Since we are concerned with the number of security requirements and not time so we assign equal amount of time to Framework, CLASP and Misuse case. Each group using one of these methods has equal amount of time to elicit security requirements (See Table 30 and Table 31).

51

2. Combine input from Team1 and Team2 and provide it to Team2 for security analysis using CLASP technique (explained in next section).

5.4 Experiment operation Total subjects on first day of our experiment are six people which are assigned

Treatments. On the first day, experiment was conducted in university (BTH) group rooms

H2016, H206C and H206D on 2012 March 29th. Two person i.e. each group was assigned a separate group room. We provided them description of a software system and activities. One group performed activities of framework and the other groups performed activities related to CLASP and Misuse case. All the groups were given a total time of 5 hours and 15 minutes to perform the activities.

Group performing framework activities were supposed to perform 6 activities. For first 2 hours they performed 4 activities. Duration of first four activities was 30 minutes each. After the lunch break they were suppose to perform remaining two activities. Duration of the remaining two activities was 1 hour.

Group performing CLASP activities, had to perform five activities and the duration was same as for group performing framework activities. Group with Misuse case was given the same amount of time also (See Table 30 and Table 31). We provided them Misuse case template and the description of activities. There were total three activities of Misuse case. Team1’s first task was to understand the case and the activities. Based on their understanding they filled Misuse case template.

On the second day of experiment, we conducted the second part of the experiment with the same six people again. The only difference was that Team2 and Team3 i.e. group working with activities with CLASP and Misuse case were free to iterate and repeat the procedure of the activities they have performed. Whereas Team1 i.e. the group working with framework performed the remaining activities of the framework. On the second day i.e. 2012 March 30th experiment was conducted in university (BTH) group rooms H2016, H206C and H206D. Team1, Team2 and Team3 were sat in different rooms. In order to neutralize the threat of different level of competency of students, we decided to give maximum benefit to CLASP.

We have already discussed that outputs of the activities performed during Day1 of experiment are input for security analysis in CLASP and in framework. So we gave maximum advantage to CLASP by providing output of activities performed by Team1 and Team2, during first day of the experiment, for security analysis in CLASP.

The group working with framework continued with what they got after performing the activities on Day1.

5.4.1 Software System for Experiment Due to limitations in access to industrial resources, we had to select a software

system by using which we can conduct an experiment in a short time. For that purpose, we considered many software systems and choice was difficult. We decided to select a system on which a security study is already conducted which will also help us in comparing our results with the results from the study. We considered an example from [66] i.e.

5.4.1.1 Monolithic Mainframe

5.4.1.1.1 Glossary

52

CICS: Customer Information Control System – A transaction server which runs on IBM mainframe under z/OS. z/OS: 64 bit operating system for mainframe produced by IBM. RAFC: Resource Access Control facility: An IBM software product for system’s security that provides auditing functionality and access control. VSAM: Virtual Storage Access Method: An IBM files disk storage method. 3270 terminals: IBM display devices used to communicate with the mainframe.

5.4.1.1.2 System Description A leading insurance company has applications which process claims by its customers. Application users are customer service representatives who either create or update claims information based on telephone conversations with their customers. All incoming claims are processed by the applications on a single IBM mainframe machine.

Table 27: Activity flow

Step: Description:

1 The user performs an initial logon and is prompted for user ID and password.

2 If the user ID and password are successfully entered, a CICS session with the IBM mainframe is initiated

3 The application user invokes the desired CICS transaction.

4 To obtain authorization to run the transaction, the CICS determines permission for the invoking user

5 The application user (i.e., customer service representative) requests account information for an existing customer

6 The application reads account record(s) for the specified customer. In the process of reading the data, the operating system determines whether the user is permitted to read the relevant VSAM file.

7 If RACF authorizations allow it, the record is returned to the application from VSAM.

8 The customer data is returned to the application user and is displayed on the 3270 terminal

9 The application user enters required information – either creating a new claim or adding further information (as instructed by the customer, specifically relating to the insurance claim).

10 The application updates account record(s) for the specified customer. In the process of updating the data, the operating system determines whether the user is permitted to update the relevant VSAM file.

11 If RACF authorizations allow it, the record is updated in the VSAM file.

12 The application satisfies the request for updating the customer claim data and displays confirmation of the update on the 3270 terminal.

Also see Appendix K and Appendix L to see Sequence diagram and Use Case diagram of the system.

5.4.2 Experiment execution Following activities with the sequence described in Table 30 and Table 31, were

performed by the groups named as Team1 (performing Framework activities), Team2 (CLASP activities) and Team3 (Misuse case activities).

Detail schedule for two days of experiment is provided in Table 30 and Table 31. Duration of experiment during first day was 5 hours and 15 minutes. Activities during second day took 4 hours and 50 minutes of time.

Table 28: Plan for Day1 of Experiment

Duration Duration Pilot Exercise 50 Minutes Pilot Exercise 50 MinutesQuestion and Answers 10 Minutes Question and Answers 10 MinutesTeam1 & Team2

Task Team3 Task Specify Operational Environment 20 Minutes Misuse Case Activity 1 20 MinutesIdentify Global Security Policy 15 Minutes Misuse Case Activity 2 55 Minutes

53

Identify Resources and Trust Boundaries 60 Minutes Misuse Case Activity 3 20 MinutesTotal 155 Minutes Total 155 Minutes

Lunch Break Lunch Break Identify user roles and resource capabilities 20 minutes Fill Misuse case

Template 150 Minutes

Identify in‐depth user roles, secure capabilities and security constraints for each actor (Only performed by Team1)

20 Minutes Total 150 Minutes

Identify attack surface 20 MinutesResearch and assess security posture 30 MinutesDetail misuse case 60 MinutesDocument security relevant requirements 60 minutesTotal 150 Minutes

Table 29: Plan for Day2 of Experiment Team1 Task Duration Team2 Task Duration Team 3 Task Duration

Perform security analysis of system requirements and design.

120 Minutes

Perform security analysis of system requirements and design.

120 Minutes

Iterate all the activities of Misuse Case

160 Minutes

Update security requirements document.

30 Minutes

Update security requirements document.

30 Minutes

Total 150 Minutes

Total 160 Minutes

Total 160 Minutes

Lunch Break Lunch Break Lunch Break

Suppose all the threats mentioned in the categorization are true for all resources, entry points, functionalities, assets, services and actors for the system.

30 min Iterate all or any activity of CLASP

100 Minutes

Iterate all or any activity of Misuse Case

100 Minutes

Validate threats for each resources, entry points, functionalities, assets, services and actors for the system.

70 min

Update the document.

30min Update the document.

30min Update the document.

30min

Fill Questionnaire

10 Minutes

Fill Questionnaire

10 Minutes Fill Questionnaire

10 Minutes

Total 140 Minutes

Total 140 Minutes

Total 140 Minutes

To see Output from Misuse cases technique alone, refer to Appendix G.

5.4.2.1 Output during each activity of Framework We have listed output of the activities, in document, in such a way that this

section covers output from all the techniques.

54

Since first 10 activities of the framework are taken from CLASP (except 5.4.2.1.5) it is useless to repeat the output of 9 activities of CLASP in the document. The reader can assume that the output 5.4.2.1.1 up to 5.4.2.1.10 is same for CLASP and Framework. Final output from CLASP is included in Appendix D and Appendix E whereas output of Misuse Cases is mentioned in Appendix G.

Output mentioned in section 5.4.2.1.11 to 5.4.2.1.15 is the output only from Framework. Final output from Framework alone is mentioned in Appendix F.

5.4.2.1.1 Specify Operational Environment (Implementation scenario) The IT organization of the insurance company develops its own applications in

order to gain an advantage in a highly competitive and quickly changing business environment. The applications in question are developed in COBOL to run under CICS on a z/OS IBM mainframe machine. These custom‐written applications enable the insurance company to respond rapidly to the time‐critical needs of its client. The users utilize 3270 terminals from where they log on directly to CICS.

It should be kept in mind that data on the disc is not encrypted.

5.4.2.1.2 Identify Global Security Policy Customer’s data is valuable to the company so only authorized people should be

able view and edit customer’s data. Security baseline and its description are mentioned in Table 32.

Table 30: Security Baseline Authorization Authorization also called access control. Authorizations are given to users to access the system on the

basis of identity and are generally policy driven. Policies are enforced by access control mechanism to perform operations on resources. Policies depend upon the individual actions performed on resources. For example access control decision is generally taken on the basis of user specific policy.

Authentication Authentication is used to establish identity of communication partners, owner, creator etc of data. Authentication must be performed at login time for network connections but one must also perform ongoing authentications for lifetime of connection. Different categories of authentication are as follows:

Things which are known such as passwords or pass phrases. Things you have such as credit card or RSA Secure ID(Authentication tokens). Things you are such as finger prints, voice print and retinal scans.

Confidentiality Purpose of confidentiality is to keep data secret to all unauthorized parties. Data must be kept secret or encrypted in both ways like when data is being transmitted on a network and when it is being stored, long term or short term.

Integrity Data integrity means to keep the data as in form as it was intended to be. For example in physical link layer on trusted media where error occurs but not related to security errors.

Availability Delay of data can cause the availability problem or if problem is due to maliciously is known as denial of service attack.

Accountability System should log information about the operations performed by the system user in order to review this information when required. System users must be accountable for the actions they perform.

Non repudiation When there is two party communications, either sides can prove to themselves whether data comes from authentic source. Problem occurs when third party involves. For this message can be established from original sender to third parties which is called non repudiatable.

5.4.2.1.3 Identify resources and trust boundaries Trust Boundaries

• User i.e. customer service representative connects to sever through 3270 terminal by entering valid id and password.

55

• User can view customer’s information only if the user has authority to view customer’s information. RACF performs authorization check before letting the user view the information.

• User can update customer’s information only if the user has authority to update customer’s information. RACF performs authorization check before letting the user update the information.

• Authorization is called access control and Authentication is used to establish identity of communication partners. Both authorization and authentication checks are performed by RACF.

• There is no remote access to server. All users access the server through 3270 terminals within system boundary.

• Identify network level design Figure 7: Component Architecture Diagram

Business applications, security system and database are located on one

mainframe server. Mainframe server is accessed by customer service representatives using 3270 terminals. This shows that the system is implemented using star topology.

Table 31: Component Architecture

56

Component Description of Component User The application users are customer service representatives of the insurance company who log on to CICS

running under z/OS on a single IBM mainframe. The users are located within a facility of the organization — i.e., no remote access is required.

Application This is a custom application developed within the organization — i.e., it is not a package application. Data The application data in question is located in VSAM file cluster on the single IBM mainframe machine. Security System

The elements of the security system are:• RACF sign‐on security; • RACF authorization to execute CICS transactions; • RACF authorization to read/update VSAM files data.

• Identify Data resources System’s resources along with the capabilities are mentioned in the table below

(see Table 34). Capabilities are the resources a resources or an actor can access

Table 32: System resources and capabilities Resource Name

Description Capabilities

CICS Customer Information Control System – A transaction server which runs on IBM mainframe under z/OS.

Can access and perform operation on database using VSAM. Communicates with RACF through z/OS.

z/OS 64 bit operating system for mainframe produced by IBM. Controls inter‐process communication on Mainframe i.e. between CICS and RACF.

RAFC Resource Access Control facility: An IBM software product for system’s security that provides auditing functionality and access control.

Performs Authentication and Access Control checks. Keeps log of the activities performed.

VSAM Virtual Storage Access Method: An IBM files disk storage method.

Establishes a mechanism to access data base.

3270 terminal

IBM display devices used to communicate with the mainframe.

N/A

User Customer service representative. Accesses Database and performs operations on database through CICS, using 3270 terminals.

Network Medium

LAN i.e. All stations (3270 terminal) are connected by cable (or wireless) to a central point, such as hub or a switch which is then connected to a Mainframe computer.

Acts as a medium communication medium between 3270 terminal and Mainframe sever.

Customer A person who interacts with the customer service representative over the phone.

They can request creation, search and update, but this task is handled by customer service representative.

5.4.2.1.4 Identify user roles and resource capabilities It should be noted that all communication between 3270 terminal and

mainframe, involves Local Area Network. User (Customer service representative) Resources: 3270 terminals

Table 33: User's capabilities CAPABILITIES RESOURCES INVOLVEDLOGIN AUTHENTICATED BY RACFVALIDATE USER AUTHENTICATED BY APPLICATION AND RACF READ CUSTOMER DATA RACF + VSAMUPDATE CUSTOMER DATA RACF + VSAM

Application (Transaction system) Resources: CICS

Table 34: Application's capabilities CAPABILITIES RESOURCES INVOLVED ACCESS CUSTOMER DATA RACFAUTHENTICATE REQUEST RACFUPDATE CUSTOMER DATA RACF + VSAM

57

RETURN PROCESSED DATA TO 3270 TERMINAL

3270 TERMINAL

Access control method (VSAM)

Table 35: Access method capabilities CAPABILITIES RESOURCES INVOLVEDINITIATED BY CICS RACF, Z/OS, CICS

• Attacker’s Profile Attacker is an insider who has physical access to terminal 3270 and Mainframe.

This insider may be a customer service representative or a person who has a physical access to the infrastructure.

Most probably, the attacker will use brute force technique to enter the system or try to exploit a bad programming practice such as stack/buffer overflow attack.

5.4.2.1.5 Identify in‐depth user roles, secure capabilities and security constraints for each actor

Main role in the system is of the user i.e. Customer service representative. In an ideal condition, a user is checked at three points in the system i.e.

1. At the time of login i.e. Authentication/identity check 2. Attempt to view customer’s data i.e. Authorization check 3. Attempt to update customer’s data i.e. Authorization check

Above mentioned are the security constraints on the user. User’s secure capabilities are • Login, • Access customer’s data, • Update customer’s data • Customer service representative have access to 3270 terminal

User’s insecure capabilities are • Login without authentication • By pass CICS, • By pass RACF and access VSAM, • By pass RACF and access CICS, • Perform operation on VSAM without authentication and authorization

5.4.2.1.6 Identify attack surface Main entry points for an attack are 3270 terminal and physical ports. • Anybody who has physical access to Mainframe can copy data directly from Mainframe since data stored in Mainframe is not encrypted.

• If RACF is somehow by passed, it will be easy to perform operation on the data using VSAM. Entry point in this case will be 3270 terminal.

• Insecure public methods which can be manipulated from 3270 terminals can pose a threat to the system.

Disabling inter‐process communication between CICS and RACF may put the system in danger.

5.4.2.1.7 Research and assess security posture

58

Certain technologies like RACF, CICS, VSAM etc. are used in the system. Issues related to these technologies are gathered from online reviews of people who have been working with these technologies. Issues with these technologies are defined in “ISSUES” Column.

Table 36: Technologies and problems

COMPONENTS ISSUES RACF The standard RACF product includes utilities and commands to handle Most of the situations

which security administrators, auditors, and technical staff are likely to encounter. However, some of these facilities are difficult to use or take too long to consider using them on a daily basis. As a result of this some installations have been forced to develop their own procedures for dealing with these situations and others have been unable to afford the resources to deal with them on a regular basis. Configuration Issues.

Z/OS Neither z/OS nor the MVS family of operating systems provides security as part of the operating system. They rely on External Security Managers (ESMs) to provide security. When the operating system receives a request, that request is diverted by the Security Authorization Facility (SAF) within z/OS to an ESM. SAF directs control to either or both: An ESM such as RACF or ACF2. An organization supplied processing routine.

VSAM Disk Storage Unmanaged disk storage can result in system outages.Cost of managing storage is 4 to 10 times the initial cost of storage acquisition.

CICS CICS has stopped running. There are three main reasons why CICS might unexpectedly stop running: There could be CICS system errors. CICS could be in a wait state. In other words, it could have stalled. A program could be in a tight loop. CICS is running slowly. Main reasons are: System is lightly loaded; a poorly designed transaction could be the cause.

5.4.2.1.8 Detail Misuse Case To see Output from Misuse cases technique alone, refer to Appendix G.

Table 37: Misuse Case Field DescriptionName Login in without valid credentialsSummary By passing security protocolsDate 12‐03‐29Author Farukh & waqasBasic Path 3270 terminal user. send request to CICS.Alternative Path Direct access to CICS without 3270 terminals.Capture Point RACF Extension Point Direct accessTriggers Deactivated RACFPre‐conditions Deactivated RACFAssumptions RACF not working, not authenticating the request.Post‐conditions Access to VSAMWorst Case Threat Data integrity implicationsPrevention guarantee RACF Detection guarantee CICS Related Business Rule Prevent unauthorized accessPotential Misuser Profile Access other than customer representationStakeholders AnalystsScope Planned computerized info systemAbstraction Level Sub functionTechnology and Data Variations

LAN

Goal ValidationDependencies Analysts to customer representationSecurity Constraints Access Grant.

Table 38: Misuse Case

Field Description

59

Name CSR UpdateSummary CSR has negative intentions to update customer data.Date 12‐03‐29Author Pezhman & HassanBasic Path CSR logs into the system and tampers the data.Alternative Path Log into the system in an unauthorized way.Capture Point Data logs.Extension Point N/A Triggers CSR has negative intentions and have access to the systemPre‐conditions CSR is logged inAssumptions N/A Post‐conditions CSR updated customer record wrongly.Worst Case Threat Customer data corruption.Prevention guarantee Get to know people with negative intentions in the organization Detection guarantee Data statistical analysisRelated Business Rule Data integrityPotential Misuser Profile Insider.Stakeholders Customer, OrganizationScope Data Abstraction Level N/A Technology and Data Variations

Buffer overflow, SQL injection

Goal Keep Customer personal information safeDependencies CSR and customerSecurity Constraints Authorized login to system

5.4.2.1.9 Document security relevant requirements See Appendix (D)

5.4.2.1.10 Perform security analysis of system requirements and design • Develop an Understanding Of The System.

System was completely understood through documentation and outputs of previous activities.

• Determine and Validate Security Relevant Assumptions: Business Environment: There is no remote access. Attacker: Attackers are of two types:

• It can be customer service representative. • Someone who has physical access to the system or its components.

• Review Non‐ Security requirements: System has not addressed:

• Data integrity • Availability • Confidentiality • Non repudiation

• Assess Completeness Of Security Requirements: Table 39: Correlation Matrix

Security requirement

ID Authorization Authentication Confidentiality Integrity Availability Accountability Non‐

repudiation Other

1 X 2 X 3 X 4 X 5 X

60

6 X 7 X 8 X 9 X 10 X 11 X12 X 13 X 14 X 15 X 16 X 17 X 18 X 19 X 20 X

TOTAL 5 5 3 4 2 0 0 1

• Identify Threats On Assets/Capabilities. Table 40: Threats on Assets

ASSETS THREATSCICS • Without authentication can create CIC session.

• Denial of service(CICS session) Z/OS • Do not allow communication between RACF and Z/OS.

• Operating system can be out of service. RACF • Out of Service

• Allow unauthorized user and not allow authorized users VSAM • Disk Storage can be corrupted. As there is not backup DB file data can be lost.

• Out of service. 3270 TERMINAL • Misused by CSR.

• Used by unauthorized user. NETWORK As there is no data encryption, data can be modified or read during data transmission.

Table 41: Threats on Capabilities CAPABILITES THREATS

Login Attempts from unauthorized personValidate User • Out of service

• Output of the functionality is modified. Read/Customer data/Update. • Do not allow to read/update customer data.

• Write customer data without authentication Read process data to 3270 terminal Do not allow to return process data to 3270 terminal.

• Determine Level Of Risks

61

Figure 8: Threat Tree

• Determine Risk Mitigations For Each Resource.

Risks mitigation: • User can only initiate CIC session after authentic login from 3270 terminal. • Protect transaction server (There must be limited access). • Limit the maximum number of files or processes that a user is allowed. • VSAM file must be stored as Encrypted form. • All data communications through network must be encrypted.

• Evaluate Findings: All the findings are evaluated and documented as security requirements in the next activity.

5.4.2.1.11 Update Security Requirements Document: See Appendix (E)

5.4.2.1.12 Identify Resources, Entry Points, Functionalities, Assets, Capabilities, Resources, Services And Actors.

62

Table 42: System's resources/assets

RESOURCES FUNCTIONALITIES ASSETS CAPABILITIES ACTORS CICS Authentication Customer Data Login. Customer Service

Representative. Z/OS Execution Application Validate User. Customer. RACF Authorization Read/Customer

data/Update.

VSAM Data update/Read Read process data to 3270 terminal.

3270 TERMINAL Search claims NETWORK Create New Claim

5.4.2.1.13 Suppose All The Threats Mentioned In The Categorization Are True For All Resources, Entry Points, Functionalities, Assets, Services And Actors For The System. As we have discussed earlier that we are using security categorization from [11]

(See Appendix C). In this activity all the threats mention in threat categorization (See Appendix C) were supposed to be true for every entry in Table 44.

5.4.2.1.14 Validate threats for each resource, entry point, functionality, asset, service and actors for the system Table 45 contains the number of the valid threats from threat categorization (See

Appendix C). Table 43: Valid Threats

Asset/Resource Threat Categorization NumberCICS, 3270 TERMINAL 1A, 1BLogin, Data storage, CICS, RACF 1CCustomer DATA, Application 2Network, Data storage 3AMainframe, 3270 terminal, Network 3B, 3CApplication 3D 3270 Terminal, Update/Read 4Customer Data, Read/Update 5A, 5B, 5C, 5DRACF, Log File 63270 Terminal, CICS, RACF 7AMainframe,Network,3270 Terminal, Data storage

8

5.4.2.1.15 Update Security Requirements Document: See Appendix (F)

63

6 ANALYSIS AND INTERPRETATION: Purpose of this chapter is to analyze and interpret the data obtained from

experiment. We extracted information from experiment and deleted redundancies. We analyzed results using Vulnerability Comparison and system security baseline [66,88].

We noticed that the participants of the experiment, especially the group using Framework, were not happy about the short time assigned to the activities. In fact, time pressure was really helpful because in this way we were able to simulate the real world circumstances. The experiment, overall was a success because we simulated the actual circumstances under which security is neglected in industry i.e. Lack of resources or inexperienced people and Tight schedule for completing a product.

6.1 Data set reduction By carefully looking at the activities of the techniques, we see that in Framework,

security requirement document is updated thrice. Whereas there was no restriction for updating the document in Misuse cases and in CLASP. The security requirement document was at least updated twice using CLASP and once using Misuse Cases. During information extraction, we noticed that some security requirements were repeated in CLASP and Framework. For example; a security requirement which was already documented was repeated in second or third updating activity.

We decided to delete repeated security requirements. We achieved that by keeping the former and deleting the latter. It means if a security requirement was written once and it was repeated in next document updating activity, we removed the security requirement from latter updating activity.

6.2 Descriptive statistics 6.2.1 Vulnerability Comparison

As described earlier, Software system used during the experiment was taken from [66]. Few vulnerabilities of the system were also listed with the description of the system in [66]. We listed these vulnerabilities in Table 46 below. There may be other vulnerabilities in the system example (Monolithic Framework) but we have decided to list only those vulnerabilities which were listed in the document [66] from which the software system example was selected.

After removing repetitions in the security requirements for each technique, we compared vulnerabilities covered by techniques with the already known vulnerabilities of the system (see Table 46) to see which of the known vulnerabilities are removed by each technique.

It should be noted that our focus was to elicit security requirements. Therefore we analyzed the data gathered in the context of research. Our focus was not on finding vulnerabilities but security requirements. Security requirements were elicited for the other threats found in Table 45 and the document was updated accordingly by the group using Framework (See Appendix F). In Table 46 we have analyzed our security requirements with respect to known vulnerabilities i.e. whether security requirements elicited by the three techniques mitigate the vulnerabilities or not.

64

Table 44: Vulnerability and Security requirement comparison ID Vulnerabilities Misuse Case CLASP FRAMEWORKV‐1 Using password Systems

“The failure of a password authentication mechanism will almost result in attackers being authorized as valid user.”

V‐2 Allowing password aging.

“As password age, the probability that they are compromised grows.” Note: RACF must be correctly configured to obtain the correct password aging

V‐3 Not allowing password aging.

“As password age, the probability that they are compromised grows.”

V‐4 Storing Passwords in a recoverable format.In that case Users password may be revealed and may be reused elsewhere to impersonate the users in question.” Note: RACF must be correctly configured to obtain the correct password aging

V‐5 Using single factor authentication.

“If the secret in a single factor authentication scheme gets compromised, full authentication is possible.”

V‐6 Failure to protect stored data from modification. “The object could be tampered with.”

V‐7 Buffer Overflow. “Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.” “Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy.” “When the consequence is arbitrary code execution, this can often be used to subvert any other security service.”

V‐8 Failure to check whether privileges were dropped successfully. “If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped.” “If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator.”

V‐9 Trust of system event data.

“If one trusts the system‐event information and executes commands based on it, one could potentially take actions based on a spoofed identity.”

Total 1 3 5

Figure 9: Percentage comparison with known vulnerabilities

65

Final output of requirement elicitation techniques i.e. Framework, CLASP and Misuse case, were number of security requirements. These requirements were elicited in same amount of time but the number of elicited requirements was different for each technique. Not only was the number of elicited requirements different but types of requirement were also different. We analyzed the security requirements elicited by each technique and compared the requirements with 9 known vulnerabilities of the system (see Table 46). Basically the purpose was to see that what percentage of the vulnerabilities is mitigated by each technique.

After analyzing the requirements for vulnerability mitigation, we see that 5 out of total nine vulnerabilities (55%) are mitigated by Framework. Whereas 3 of 9 vulnerabilities (33%) were covered by CLASP and 1 out of 9 (11%) was covered by Misuse case.

6.2.2 Requirement Types with Respect to System’s security baseline

Whenever we talk about security, question which comes to our mind is “what do you want to secure”. For that purpose we look into global security policy of the organization and establish a security baseline (see Table 32).

A security baseline was established for the example software system, before the experiment (see Table 32). Now we need to see what type security baseline features are covered by each technique. We have 7 security baseline features and three techniques i.e. Framework, CLASP and Misuse case. We got number of security requirements from each security requirement elicitation technique. We need to see that which of the technique covers which of the established baseline features in an effective manner.

The graphs below are summarized in the table below

Table 45: Requirement analysis with respect to Security baseline Number of Requirements

Security Baseline Feature

Misuse Case CLASP Framework

Authorization 2 6 7

Authentication 0 5 6

Confidentiality 2 3 7

Data Integrity 0 4 4

Availability 0 1 1

Accountability 0 0 1

Non repudiation 0 0 1

In the graph below, X‐axis shows the three Techniques and Y‐axis shows the

number of requirements elicited from these Techniques. As you can see from Table 45, Framework elicited more number of security requirements in terms of authorization, authentication and confidentiality. Whereas in data integrity, confidentiality and availability CLASP and Framework elicited same number of requirements. In non repudiation and in accountability framework elicited one requirements as compared to others.The requirements which are elicited by Misuse Cases and CLASP are covered by framework also.Framework elicited more number of requirements as compared to CLASP and Misuse cases which are mentioned in Appendix F.We did not find any unique requirement other than the security baseline.

66

Following graph (Figure 10) shows the number authorization Requirement elicited from Misuse case, CLASP and Framework. As shown in graph, Misuse Case elicited 3, CLASP 6 and Framework elicted 7 authorization requirements.

Figure 10: Authorization requirements

The graph below, shows the authentication Requirement elicited from Misuse

case CLASP and Framework As shown in graph (see Figure 11), no requirement was elicited using Misuse case. Whereas with CLASP, 5 and with Framework, 6 authentication requirements were elicted.

Figure 11: Authentication Requirements

Following graph(see Figure 12) shows Confidentiality Requirement elicited using

three secuirty requirement elicitation techniques. Misuse Case elicited 2, CLASP 3 and Framework elicted 7 Confidentiality requirements.

Figure 12: Confidentiality Requirements

67

Following graph(see Figure 13) shows, Data integrity Requirement elicited using the three techniques. None of Data integrity requirement was elicited using Misuse case. 4 Data integrity requirements are elicited using CLASP and Framework.

Figure 13: Data integrity Requirements

Graph below (see Figure 14) shows Availability Requirement elicited using three techniques. As shown in graph (see Figure 14), Misuse Case elicited 0, CLASP 1 and Framework elicted 1 availability requirement. As shown (see Figure 14) CLASP and Framework elicited same number of Availability requirements.

Figure 14: Availability Requirements

Follwing graph (see Figure 15) is the comparison of Non repudiation Requirement

elicited using the three techniques. As shown in graph (see Figure 15), Misuse Case elicited 0, CLASP 0 and Framework elicted 1 Non repudiation Requirement.

68

Figure 15: Non Repudiation Requirement

Next graph (see Figure 16) shows the Accountability Requirement elicited from

using three techniques. As shown in graph (see Figure 16), Misuse Case elicited 0, CLASP 0 and Framework elicted 1 Accountability Requirement.

Figure 16: Accountability Requirements

6.3 Results and Discussions Vulnerability analysis (in Section 6.2.1) shows that Framework mitigate more

number of vulnerabilities than CLASP and Misuse Case. Security requirements elicited by Framework mitigated 55% whereas CLASP and Misuse case mitigated 33% and 11% of the total known vulnerabilities in our software system.

Requirement analysis with respect to security baseline shows that CLASP does not elicit any requirement for Accountability and Availability security baseline features. For Confidentiality, number of requirements elicited using CLASP is far less than the number of security requirements elicited by Framework. For Data integrity, number of security requirements by CLASP and Framework is same.

We can see from Table 44 and Figure 17 that Misuse cases has poor performance both in vulnerability analysis and requirement analysis with respect to security baseline. Major reason of poor performance from Misuse case is because it merely depends upon the creativity of the person creating a Misuse case.

69

Figure 17: Requirement Analysis w.r.t Security Baseline

There is no absolute measure for creativity. Since Misuse case depends upon

creativity of the person executing the technique, we are not sure about the results we got from Misuse case alone. We can say that the group had a low level of creativity skills but in the end we were supposed to extract results from what we actually got. So the result showed that Misuse case did not perform better than CLASP and Framework.

CLASP on the other hand has definite number of steps and pre‐defined guidelines which gives a better opportunity to exploit and discover issues. We saw that using the security requirement categorization [11] raised the security requirement elicitation graph significantly for Framework.

6.4 Return of investment for each technique. This section is based upon the observations during the experiment. Result may or

may not differ if circumstances are changed. We conducted the experiment using three techniques i.e. Misuse Cases (informal

technique), CLASP (formal technique) and Framework. Output of the experiment was three sets of security requirements i.e. from Misuse Cases, from CLASP and from Framework. If we initially suppose that time invested in each of the technique is directly proportional to the output, it would simply mean that the more time spent on a technique leads to increase in number of security requirements. We have already mentioned in section 5.3.4 that we assigned same amount of time to all the three techniques. Results show that in same amount of time Framework elicits more security requirements than Misuse Cases and CLASP. Therefore Framework has more Return of Investment than Misuse Cases and CLASP.

6.5 Validity Threats • Conducting an experiment with small sample space i.e. Six students may be a question mark on our results. We can suppose that we get same result with large sample space but we cannot be sure about it. Result inferred is based upon the conditions under which we conducted the experiment.

70

• Results and conclusions mentioned in the document are based on one software system. We can only assume that the conclusion from a large scale experiment will be same as conclusions drawn in this study but we are not sure about it. Results are based on the experiment and the system we selected for the experiment. Although the software system for the experiment was selected randomly, still we do not have large evidence to support our results.

• We proposed the Framework by integrating one informal technique with two formal techniques. We also combined security requirement categorization (see Appendix C) with our framework. Security requirement categorization was devised for Misuse Cases technique by Bogale and Ahmed [11]. Therefore we can say that Misuse Cases have a large contribution in our Framework. Three more fields were also added to Misuse Cases (See Appendix J). Using selected activities from CLASP and Secure TROPOS and combining those with Misuse Cases added strength to our Framework but we are not sure about which technique actually attributed to better results from Framework. At the moment we can only make suppositions about this threat because analyzing each technique’s contribution to the Framework requires in‐depth analysis which becomes out of scope for our thesis.

6.5.1 Limitations • Lack of resources to conduct the experiment i.e. we were not able to find any industrial contact to conduct the experiment. Our experiment required software analysts from industry. Response from industries was not positive because software organizations have their own ongoing projects therefore it was not possible to engage someone from industry.

• If we have more time, we should choose more complex method i.e. more steps in the framework. Just using more time with a simple method will not improve the number of problems found. We had to select the method depending on several issues e.g. available time.

• We have few Data points in our experiment. Few data points may affect generalization of results. As mentioned earlier, our results and conclusions are inferred from one system which was randomly selected.

• Our framework is work intensive and we can see from the experiment that its activities need time to execute. This un‐addressed issue can be a limitation of the study. Our motive in the study was to find more number of security requirements than a formal or informal technique. Reducing activities of framework would simply be at the cost of security requirements. Making a less work intensive Framework and testing its applicability becomes out of scope for us in the present study.

71

6.6 Answers to Research Questions Our first research question was: RQ1. Do formal approaches produce better results when integrated with

informal approach i.e. Misuse case? • H0: Formal approaches do not produce better results when integrated

with informal approach i.e. Misuse case. • H1: Formal approaches produce better results when integrated with

informal approach i.e. Misuse case. Our Framework was proposed by combining CLASP, Misuse case and Secure

TROPOS. Our results show that, our Framework produce better result than CLASP and Misuse case. Since our Framework elicits more number of security requirements than a formal and an Informal technique, we can say that if we combine formal and Informal security requirement elicitation technique, we can yield better results. In other words, we can say that by combining strengths of formal and informal techniques, we can mitigate their weaknesses. For example, a formal technique is flexible but has definite number of steps whereas on the other hand informal techniques lack proper structure but have flexibility. Therefore, by combining formal and informal techniques we can produce better results. This proves hypothesis H1 true for RQ1 (under given circumstances).

Our second research question was: RQ2. What is the practicality of the proposed framework, i.e. up to what

extent and for which types of software systems the framework is suitable?

At this point, we would like to mention again that our scope was limited to requirement elicitation. So we are to see the practicality and workability of our framework in the said context. Of course we do not have measurement scale for the practicality and workability of our framework but the visual analysis we have from the data we see that it works pretty well than CLASP and Misuse case. CLASP, a widely used formal technique and Misuse case, a well known informal technique were tested on a software system along with our framework. We saw that our framework not only elicits more number of security requirements but cover more vulnerabilities in the system. Moreover our framework covered all the security baseline features of the software system (see Table 47).

We can answer the first part of research question RQ2 here by saying that our framework is more workable and practical than CLASP (a formal technique) and Misuse case (an informal technique) in terms of security requirement elicitation and in vulnerabilities mitigation. Moreover we gathered feedback from students to know the usability of the framework (see Appendix I). Feedback showed that, while performing the activities of the Framework, participants analyzed the system from different aspects which are usually are not considered in software development. Moreover, use of the framework improves the user’s knowledge about software security and software attack scenarios.

Unfortunately, it was not possible for us to answer the second part of the RQ2 i.e. “for which types of software systems the framework is suitable?” We did not have the time and resources to conduct experiment on more than one software system so it pointless to argue on relationship of the framework with nature of software

72

systems. We cannot make certain claims about nature of software system unless our framework is tested on different systems.

RQ3. On what basis and for which type of software systems, is the proposed

framework better than other widely known security requirement elicitation techniques? • H0: The proposed framework is not better than other security

requirement elicitation techniques. • H1: Proposed framework is significantly better than the other

requirement elicitation techniques.

Answer to first part of RQ3 i.e. “on what basis, the framework is better than CLASP and Misuse Case”, is:

• Framework shows better performance than a widely used formal and informal technique in terms of eliciting more number of security requirements.

• Framework covers the security baseline requirements defined by the organization.

• Framework takes into account, those perspectives of software system which are not touched in CLASP and Misuse Case e.g. Threats related to Functionalities and physical integrity of hardware and software. Feedback from participants of the experiment shows that this framework helps in analyzing a system from different aspects which are usually not considered in software development (see Appendix I).

• Framework provides an option to iterate through some important activities by which security requirements can be rechecked and refined.

• Framework activities breakdown the system into little details and help build security in the form of requirement elicitation.

As far as second part is concerned, we have already answered that in RQ2.

6.7 Conclusion and Lesson Learned Security requirement elicitation helps focus security in software system. We have

mentioned before that cost related to fixing security problem is much more than the cost of security requirement elicitation in earliest phase of software development. The framework we have proposed by combining CLASP, Misuse case and Secure TROPOS contains the strength of three security requirement elicitation techniques. To make the framework more effective, we also included security requirement categorization by Bogale and Ahmed [11]. Including security requirement categorization was really useful because it helped in eliciting more security requirements (see Appendix F).

If we take a quick overview of the Framework, we see that the Framework is proposed by combining CLASP, Secure TROPOS, Misuse Cases and Security requirement categorization. Framework consists of fifteen activities. First 10 activities are taken from CLASP and Secure TROPOS. Since Secure TROPOS follows complex graphical notations (as mentioned earlier), we only used the basic idea behind the activities from Secure TROPOS. Most of the activities of Secure TROPOS were similar in concept to the activities in CLASP (see Table 18 and Table 20). For any overlapping activity between CLASP and Secure TROPOS, that was selected from CLASP or Secure TROPOS, we used the textual description of the activity from CLASP to describe the activity. CLASP, having textual form of activity description, was easy to integrate as compared to Secure TROPOS. We not only used all the activities of Misuse Cases in the Framework but we also used Security Requirement categorization which was

73

proposed [11] specifically for Misuse Cases. Therefore we can say all the three techniques had equal contribution in proposing our Framework.

The framework is flexible and contains definite number of steps to elicit security requirements. In addition it also allows iterations to improve security in a system. This research was an attempt to provide a flexible framework for security requirement elicitation. We achieved that by mitigating the weaknesses in formal and informal security requirement elicitation techniques by combing them. In the questionnaire, which was filled by the participants of the experiment, the participants agreed that using this framework improved their knowledge about importance of security in software systems.

During this research we learned and discovered that there are many security

requirement elicitation techniques proposed by researchers but almost none of them are used in industry on a large scale. Most of the big brand names like IBM and CISCO have their own, customized, set of steps to ensure security in their product. It is worth noting that these “customized set of steps to ensure security” also reflect organizational structure. Academic research in this field is not used in industry at large scale. Reason behind not including research outputs in security requirement engineering field is that small organizations do not have resources for that. Big organizations have developed their own customized procedures over time to handle security in their product and it is costly to switch to anything new suddenly. Therefore it is unfortunate that academic research in this field is not given attention as it deserves.

It is clear that not every software development organization gives desired attention to security in software and hacking incidents around the world are the evidence to our argument. That means, the organizations that produce vulnerable software do not have any formal procedures to view security as a major concern in a software system. To make such an organization refer to the academic research in this regard, we suggest creating a demand for secure software development.

Social awareness about software security is very important because it will create a demand for secure software systems. Since software has a major role to play in our lives today, we suggest that Software vendors, Customers and Researchers must understand the importance of security in software systems. Demand for systems which are secure from customer’s and vendor’s perspective will automatically force both big and small organizations to refer to academic research in software security, especially security requirements elicitation. This may also help to bridge the gap between academia and industry in the field of security requirement engineering.

6.8 Future Work In our framework we have focused on Requirement phase of Software

Development Lifecycle. We considered only those activities of CLASP and Secure TROPOS which were related to Requirement elicitation. In future, one can add more activities to the framework that are related to other software development Life cycle Phases. This will help to invoke security in all phases of development lifecycle.

We have tested our Framework for one software system. For future work one can check the practicality of framework for different systems. In this procedure improvements in our framework can be suggested.

74

7 REFERENCES [1] Agarwal, A. and Gupta, D. Security Requirements Elicitation Using View Points for

Online System, in Emerging Trends in Engineering & Technology, International Conference on, Los Alamitos, CA, USA, 2008, vol. 0, pp. 1238‐1243.

[2] Ahmed, N. and Matulevičius, R. Towards Transformation Guidelines from Secure

Tropos to Misuse Cases (Position Paper), 2011. [3] Allen, J., Barnum, S., Ellison, R., McGraw, G., and Mead, N. Software security

engineering: a guide for project managers. Addison‐Wesley Professional, 2008. [4] Alberts, C.J., Behrens, S.G., Pethia, R.D., and Wilson, W.R. Operationally critical

threat, asset, and vulnerability evaluation (OCTAVE) framework, Version 1.0, 1999. [5] Alexander, I. Misuse cases help to elicit non‐functional requirements. Computing &

Control Engineering Journal ,2003, vol. 14, no. 1, pp. 40‐45. [6] Alexander, I. Initial industrial experience of misuse cases in trade‐off analysis. In

Proceeding IEEE Joint International Conference Requirements Engineering(2002),pp‐61‐68.

[7] Alhazmi, O.H., Malaiya, Y.K., and Ray, I. Measuring, analyzing and predicting security

vulnerabilities in software systems, Computers & Security,2007, vol. 26, no. 3, pp. 219–228.

[8] Babar, M.A and Zhang, He. Systematic literature reviews in software engineering:

Preliminary results from interviews with researchers, in 3rd International Symposium on Empirical Software Engineering and Measurement. ESEM , 2009, pp. 346‐355.

[9] Bagheri, H. Injecting security as aspectable NFR into Software Architecture, in Asia‐

Pacific Software Engineering Conference, Los Alamitos, CA, USA, 2007, vol. 0, pp. 310‐317.

[10] Boehm, B.W. and Papaccio, P.N. Understanding and controlling software costs,

Software Engineering, IEEE Transactions on, 1988, vol. 14, no. 10, pp. 1462–1477. [11] Bogale, H., Ahmed, Z. “A FRAMEWORK FOR SECURITY REQUIREMENTS: SECURITY

REQUIREMENTS CATEGORIZATION AND MISUSE CASES,”BTH, Thesis doc, September, 2011.

[12] Brown, A.W. and Wallnau, K.C. A framework for evaluating software technology,

Software, IEEE, 1996, vol. 13, no. 5, pp. 39–49. [13] Buecker, A., Borrett, M., Lorenz, C., Powers, C.Introducing the IBM Security

Frameworks and IBM Security Blueprint to Realize Business‐Driven Security.Redbooks.2010.

[14] Castro, J., Kolp, M., and Mylopoulos, J. A requirements‐driven development methodology, in Advanced Information Systems Engineering, 2001, pp. 108–123.

75

[15] Chung, L. Dealing with security requirements during the development of information systems, in Advanced Information Systems Engineering, 1993, pp. 234–251.

[16] Chung, L. and do Prado Leite, J. On non‐functional requirements in software

engineering, Conceptual modeling: Foundations and applications, 2009, pp. 363–379.

[17] Diallo, M.H., Romero‐Mariona, J., Sim, S.E., and Richardson, D.J. A comparative

evaluation of three approaches to specifying security requirements, in 12th Working Conference on Requirements Engineering: Foundation for Software Quality, Luxembourg, 2006.

[18] Davey, B. and Cope, C. Requirements Elicitation‐ What’s Missing?, Issues in

Informing Science & Information Technology, 2008 , vol. 5, pp. 543–551. [19] Du, J., Yang, Y., and Wang, Q. An Analysis for Understanding Software Security

Requirement Methodologies, in Secure System Integration and Reliability Improvement, Los Alamitos, CA, USA, 2009, vol. 0, pp. 141‐149

[20] El Khoury, P., Mokhtari, A., Coquery, E., Hacid, M.S, “An Ontological Interface for Software Developers to Select Security Patterns,” in Database and Expert Systems Application, 2008. DEXA ’08. 19th International Workshop on, 2008, pp. 297 –301.

[21] Elahi, G., Yu, E., and Zannone, N. A vulnerability‐centric requirements engineering framework: analyzing security attacks, countermeasures, and requirements based on vulnerabilities, Requirements engineering, 2010, vol. 15, no. 1, pp. 41–62.

[22] Fabian, B., Gürses, S., Heisel, M., Santen, T., and Schmidt, H. A comparison of security requirements engineering methods, Requirements engineering, 2010 , vol. 15, no. 1, pp. 7–40.

[23] Fuxman, A., Kazhamiakin, R., Pistore, M., and Roveri, M. Formal Tropos: language and semantics, University of Trento and IRST, 2003.

[24] Garcia Alcazar, E. and Monzón, A. A process framework for requirements analysis

and specification, in Requirements Engineering. Proceedings. 4th International Conference on, 2000, pp. 27–35.

[25] Gargantini,A., Riccobene,E , and Scandurra ,P. Integrating formal methods with model‐driven engineering, in Software Engineering Advances. ICSEA’09. Fourth International Conference on,2009, pp. 86–92.

[26] Giorgini, P., Mouratidis, H., and Zannone, N. Modelling security and trust with secure tropos, Integrating Security and Software Engineering: Advances and Future Vision, 2006, pp. 160–189.

[27] Glinz, M. On non‐functional requirements, in Requirements Engineering Conference. RE’07. 15th IEEE International, 2007, pp. 21–26.

[28] Graham, D. Introduction to the CLASP Process, Build Security In,Secure Software,Inc. 2006.

76

[29] Gregoire, J., Buyens, K., De Win, B., Scandariato, R.,and Joosen, W.2007. On the Secure Software Development Process: CLASP and SDL Compared. In SESS ’07:Proceedings of the Third International Workshop on Software Engineering for Secure Systems(Minneapolis, MN,2007),pp.1.

[30] Hadavi, M.A., Sangchi, H., Hamishagi, V., and Shirazi, H. Software security; a

vulnerability activity revisit, in Availability, Reliability and Security. ARES 08. Third International Conference on, 2008, pp. 866–872.

[31] Hadavi, M., Hamishagi, V., and Sangchi, H. Security Requirements Engineering; State

of the Art and Research Challenges, Proceedings of the International MultiConference of Engineers and Computer Scientists,2008, vol. 1, pp. 19–21.

[32] Haley, C., Laney, R., Moffett, J., and Nuseibeh, B. Security Requirements Engineering: A Framework for Representation and Analysis, IEEE Transactions on Software Engineering, 2008 , vol. 34, no. 1, pp. 133‐153.

[33] Haley, C.B., Moffett, J.D., Laney, R., and Nuseibeh, B. A framework for security

requirements engineering, in Proceedings of the 2006 international workshop on Software engineering for secure systems, 2006, pp. 35–42.

[34] Hartong, M., Goel, R., and Wijesekera, D. Meta‐models for misuse cases, in

Proceedings of the 5th Annual Workshop on Cyber Security and Information Intelligence Research: Cyber Security and Information Intelligence Challenges and Strategies, 2009, p. 33.

[35] Hassan, R., Eltoweissy, M., Bohner, S., and El‐Kassas, S. Formal analysis and design for engineering security automated derivation of formal software security specifications from goal‐oriented security requirements, Software, IET, 2010, vol. 4, no. 2, pp. 149–160.

[36] Herrmann, A. and Paech, B. MOQARE: misuse‐oriented quality requirements engineering, Requirements Engineering, 2007,vol. 13, no. 1, pp. 73‐86.

[37] Howard, M. and LeBlanc, D. S. T. B. Online, and S. B. O. (Firme), Writing secure code,

vol. 2. Microsoft press, 2003. [38] Husnain, M., Waseem, M., and Ghayyur,S. An Interrogative Review of Requirement

Engineering Frameworks, International Journalof Reviews in Computing(IJRIC). 2009. [39] Integrated Security Architectural Framework.CISCO.White Paper.2006.

[40] Irvine, C.E. and Nguyen, T.D. Use of Evaluation Criteria in Security Education. NAVAL

POSTGRADUATE SCHOOL MONTEREY CA, 2008.

[41] Khan, M.U.A. and Zulkernine, M. A Survey on Requirements and Design Methods for Secure Software Development, Technical Report No. 2009 – 562 , School of Computing, Queen’s University, Kingston, Ontario, Canada, August 2009.

[42] Kim, J., Kim, M., and Park, S. Goal and scenario based domain requirements analysis

environment, Journal of Systems and Software, 2006, vol. 79, no. 7, pp. 926–938.

77

[43] Kitchenham, B. Procedures for Perfoming Systematic Review, Joint Technical Report, Software Engineering Group, Department of Computer Science Keele University, United Kingdom and Empirical Software Engineering, National ICT Australia Ltd.:Australia,2004.

[44] Kruchten, P. The Rational Unified Process – an Introduction, Addison‐Wesley.2000.

[45] Kulak, D., and Guiney, E. Use Cases: Requirements in Context, ACM Press.2000

[46] Matulevicius, R., Mayer, N., and Heymans, P. Alignment of misuse cases with security risk management, ARES 2008 ‐ 3rd International Conference on Availability, Security, and Reliability, Proceedings, 2008 , pp. 1397‐1404.

[47] McUmber, W.E. and Cheng, B.H.C. A general framework for formalizing UML with formal languages, in Proceedings of the 23rd international conference on Software engineering, 2001, pp. 433–442.

[48] Mead, N.R. and Stehney, T. Security quality requirements engineering (SQUARE)

methodology, vol. 30. ACM, 2005. [49] Mead, N.R. How to compare the Security Quality Requirements Engineering

(SQUARE) method with other methods, DTIC Document, 2007. [50] Mead, N.R. Experiences in eliciting security requirements,” DTIC Document, 2006.

[51] Mead, N.R. Requirements engineering for survivable systems, 2003.

[52] Mead, N.R. and Hough, E.D. Security Requirements Engineering for Software

Systems: Case Studies in Support of Software Engineering Education, in Software Engineering Education and Training, Conference on, Los Alamitos, CA, USA, 2006, vol. 0, pp. 149‐158.

[53] Mellado, D., Eduardo Fernández‐Medina, Mario Piattini. Security Requirements

Variability for Software Product Lines, in Availability, Reliability and security. ARES 08. Third International Conference on, 2008, pp. 1413‐1420.

[54] Mellado, D., Blanco, C., Sánchez, L.E., and Fernández‐Medina, E. A systematic review of security requirements engineering, Computer Standards & Interfaces, 2010 , vol. 32, no. 4, pp. 153–165.

[55] Mishra, D., Mishra, A., and Yazici, A.Successful requirement elicitation by combining requirement engineering techniques, in Applications of Digital Information and Web Technologies. ICADIWT. First International Conference on the, 2008, pp. 258‐263.

[56] Moffett, J.D., Haley, C.B., and Nuseibeh, B. Core security requirements artefacts, Department of Computing, The Open University, Milton Keynes, UK, Technical Report, 2004 , vol. 23.

[57] Mouratidis, H. Extending TROPOS Methodology to Accommodate Security. Progress Report, Computer Science Department, University of Sheffield, October 2002.

78

[58] Mouratidis, H., Giorgini, P., and Manson, G. Integrating security and systems engineering: Towards the modelling of secure information systems, in Advanced Information Systems Engineering, 2003, p. 1031–1031.

[59] Mouratidis, H. and Giorgini, P. Secure tropos: A security‐oriented extension of the

tropos methodology, International Journal of Software Engineering and Knowledge Engineering, vol. 17, no. 2, 2007 , pp. 285–309.

[60] Mouratidis, H. Secure Tropos: An agent oriented software engineering methodology

for the development of health and social care information systems, International Journal of Computer Science and Security (IJCSS), 2009, vol. 154, no. 3, p. 241.

[61] Mouratidis, H. A Security Oriented Approach in the Development of Multiagent

Systems: Applied to the Management of the Health and Social Care Needs of Older People in England , 2004, PhD Thesis, University of Sheffield.

[62] Mouratidis, H. Secure Software Systems Engineering: The Secure Tropos Approach,

Journal of Software, 2011 , vol. 6, no. 3, pp. 331–339. [63] Mylopoulos, J., Fuxman, A., and Giorgini, P. From entities and relationships to social

actors and dependencies, in Proceedings of the 19th international conference on Conceptual modeling, 2000, pp. 27–36.

[64] Nuseibeh, B. and Easterbrook, S. Requirements engineering: a roadmap, in Proceedings of the Conference on the Future of Software Engineering, 2000, pp. 35–46.

[65] Okubo, T.,Taguchi, K., and Yoshioka, N. Misuse cases + assets + security goals, Proceedings ‐ 12th IEEE International Conference on Computational Science and Engineering, CSE 2009, pp. 424‐429.

[66] OWASP CLASP. CLASP Concepts View, CLASP v1.2, March, 2006.

http://www.lulu.com/items/volume_62/1401000/1401307/3/print/OWASP_CLASP_v1.2_for_print_LULU.pdf

[67] Pandey, S., Mustafa, K., and Rehman, S. CLASP and SDL Revisited, in Proceedings

Second International Conference on Information Processing, 2008, p. 343. [68] Pauli,J. J. and Xu,D. Misuse case‐based design and analysis of secure software

architecture, in Information Technology: Coding and Computing. ITCC 2005. International Conference on, vol. 2, pp. 398–403.

[69] Romero‐Mariona, J., Ziv, H., and Richardson, D.J . Formality of the Security Specification Process: Benefits Beyond Requirements. Hawaii International Conference on System Sciences (Los Alamitos, CA, USA, 2010), 1‐6.

[70] Romero‐Mariona, J., Ziv, H., and Richardson, D.J. SRRS: a recommendation system

for security requirements, in Proceedings of the 2008 international workshop on Recommendation systems for software engineering, 2008, pp. 50–52.

[71] Romero‐Mariona, J., Ziv, H., and Richardson, D. Security Requirements Engineering:

A Survey, Technical Report UCI‐ISR‐08‐2. University of California, Irvine, 2008.

79

[72] Romero‐Mariona, J., Ziv, H., and Richardson, D.J., “Formality of the Security Specification Process: Benefits Beyond Requirements,” in System Sciences (HICSS), 2010 43rd Hawaii International Conference on, 2010, pp. 1 –6.

[73] Rushby, J. Security requirements specifications: How and what, in Symposium on

Requirements Engineering for Information Security (SREIS), 2001, vol. 441.

[74] Ryan, A.J. An approach to qunantitative non‐functional requirements in software development, in Systems engineering–a key to competitive advantage for all industries: proceedings of the 2nd European Systems Engineering Conference (EUSEC 2000), Munich, September 13th‐15th, 2000, p. 73.

[75] Sadiq, M. and Shahid, M. Elicitation and Prioritization of Software Requirements,

International Journal of Recent Trends in Engineering, 2009 , vol. 2, no. 3. [76] Saeki, M. and koKaiya, H. Security Requirements Elicitation Using Method Weaving

and Common Criteria. Japan 2010. [77] Salini, P. and Kanmani, S. A model based security requirements engineering

framework applied for online trading system, in 2011 International Conference on Recent Trends in Information Technology (ICRTIT 2011), Piscataway, NJ, USA, 2011, p. 1195–202.

[78] Sindre, G., and Opdahl, A.L. Eliciting security requirements with misuse cases, Requirements Engineering, Jan,2005, pp. 34‐44.

[79] Sindre, G.,and Opdahl, A.L. Capturing Security Requirements through Misuse Cases. 13th International Working Conference on Requirements Engineering: Foundation for Software Quality.2007.

[80] Sindre, G. and Opdahl, A.L. Templates for misuse case description, in Proc. Seventh

International Workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’2001), 2001.

[81] Su, X., Bolzoni, D., Van Eck, P., and Wieringa, R. A business goal driven approach for understanding and specifying information security requirements, Arxiv preprint cs/0603129, 2006.

[82] Syllabus Version 1.2 .REQB®Certified Professional for Requirements Engineering,Foundation Level,2008.

[83] Talukder, A.K., Maurya, V.K., G, S.B., Ebenezer, J., V, M.S., KP, J., Samanta, S., and P, A.R. Security‐aware Software Development Life Cycle (SaSDLC) ‐ Processes and tools, in IFIP International Conference on Wireless and Optical Communications Networks, Cairo, Egypt, 2009, pp. 1‐5.

[84] Tndel, I., Jensen, J., and Rstad, L. Combining misuse cases with attack trees and security activity models, in Availability, Reliability, and Security, 2010. ARES’10 International Conference on, 2010, pp. 438–445.

80

[85] Tondel, I.A., Jaatun, M.G., and Meland, P.H. Security requirements for the rest of us: A survey, IEEE SOFTWARE, 2008, pp. 20–27, .

[86] Viega, J. and McGraw, G. Building secure software: how to avoid security problems the right way. Addison‐Wesley Professional, 2001.

[87] Viega,J.. Building security requirements with CLASP, in ACM SIGSOFT Software

Engineering Notes, 2005, vol. 30, pp. 1–7.

[88] Viega, J. The CLASP Application Security Process, Secure Software, Inc.,CLASP v1.0 ,june, 2005.

[89] Whittle, J., Wijesekera, D.,and Hartong, M. Executable misuse cases for modeling security concerns. In ICSE ’08: Proceedings of the 30th international conference on Software engineering,2008, pp.121‐130.

[90] Wilander, J. and Gustavsson, J. Security requirements–A field study of current practice, in Symposium on Requirement Engineering for Information Security (SREIS’2005), Paris, France, 2005.

[91] Wohlin, C., Runeson, P., and Höst, M. Experimentation in Software Engineering: An Introduction, 1st ed. Springer, 1999.

[92] Yoshioka, N., Washizaki, H., and Maruyama, K. A survey on security patterns, Progress in Informatics,2008, vol. 5, no. 5, pp. 35–47.

81

8 APPENDIX

8.1 APPENDIX A F4: System Resources Below table shows the resources used by system internally or exports and different measures are taken to promote security goals. Resource Security Measures Authentication:

Confidentiality: Data integrity: Access Control: Non‐repudiation: Accountability:

Authentication:Confidentiality: Data integrity: Access Control: Non‐repudiation: Accountability:

8.2 APPENDIX B CLASP Resources D discusses the core security service. These are the fundamental security goals which needs to be addressed effectively for resources in a system. Authorization Authorization also called access control. Authorizations are given to users to access the system on the basis

of identity and are generally policy driven. Policies are enforced by access control mechanism to perform operations on resources. Policies depend upon the individual actions performed on resources. For example access control decision is generally taken on the basis of user specific policy.

Authentication Authentication is used to establish identity of communication partners, owner, creator etc of data. Authentication must be performed at login time for network connections but one must also perform ongoing authentications for lifetime of connection. Different categories of authentication are as follows: Things which are known such as passwords or pass phrases. Things you have such as credit card or RSA Secure ID(Authentication tokens). Things you are such as finger prints, voice print and retinal scans.

Confidentiality Purpose of confidentiality is to keep data secret to all unauthorized parties. Data must be kept secret or encrypted in both ways like when data is being transmitted on a network and when it is being stored, long term or short term.

Integrity Data integrity means to keep the data as in form as it was intended to be. Clasp treats data integrity as subset of authentication. There are cases where it can be taken as separate service as authentication. For example in physical link layer on trusted media where error occurs but not related to security errors.

Availability Delay of data can cause the availability problem or if problem is due to maliciously is known as denial of service attack.

Accountability System should log information about the operations performed by the system user in order to review this information when required. System users must be accountable for the actions they perform.

Non repudiation

When there is two party communications, either sides can prove to themselves whether data comes from authentic source. Problem occurs when third party involves. For this message can be established from original sender to third parties which is called non repudiatable.

8.3 APPENDIX C (Threats Categorization) Categories Description Examples Power Statements Power Misuse Case1. Access control Steal Information a. Identification Requirements (D. G. Firesmith, 2003)

Identification requirements is any security requirement that specifies the extent to which a business, application, component or centre shall identify externals before interacting with them (D. G. Firesmith, 2003)

The application shall identify all of its client applications before allowing them to use its capabilities

An “unauthorized agent” attempts to intrude into the “system/ application/ centre” without a valid identity.

82

b. Authentication Requirements (D. G. Firesmith, 2003)

Authentication requirements is any security requirement that specifies the extent to which a business, application, component, or center shall verify the identity of its externals before interacting with them (D. G. Firesmith, 2003)

The application shall verify the identity of all of its users before allowing them to use its capabilities

An “unauthorized agent” attempts to intrude into the “system/ application/ centre” without a verified identity

c. Authorization Requirements (D. G. Firesmith, 2003)

An authorization requirement is any security requirement that specifies the access and usage privilege of authenticated users and client applications (D. G. Firesmith, 2003)

The application shall allow each customer to obtain access to all of his or her own personal account information.

An “unauthorized agent” attempts to gain access to the restricted data/ services, specific application, component capabilities or any confidential information of the “system/ application/ centre” without proper authorization

2. Immunity Requirements (D. G. Firesmith, 2003)

An immunity requirements is any security requirement that specifies the extent to which an application or component shall protect itself from infection by unauthorized undesirable programs (D. G. Firesmith, 2003)

The application shall protect itself from infection by scanning all entered or downloaded data and software for unknown computer viruses, worms, Trojan horses and other similar harmful programs (D. G. Firesmith, 2003)

An “unauthorized agent” attempts to infect the data or software of the “system/ application/ centre”

Infect the system (one way can be to use undesirable program)

3. Integrity Requirements

Corrupt a data

a. Data Integrity (D. G. Firesmith, 2003)(Donald G Firesmith, 2005)

An integrity requirement is the kind of security requirement that specifies the extent to which the hardware, software or data components, or communications are secured from intentional corruption (e.g., via unauthorized creation, modification, deletion or replay ) (Donald G Firesmith, 2005)

The application shall prevent the unauthorized corruption of data collected from customers and other external users (D. G. Firesmith, 2003)

An “unauthorized agent” attempts to create unauthorized corruption to the data or communication of the “system/ application/ centre”

b. Hardware Integrity (Donald G Firesmith, 2005)

The application shall prevent the unauthorized corruption of attached hardware

c. Personal Integrity (Communications) (D. G. Firesmith, 2003)(Donald G Firesmith, 2005)

The application shall prevent the unauthorized corruption of emails that it sends to customers and other external users (D. G. Firesmith, 2003)

83

The application shall prevent the unauthorized corruption of all communications passing through networks that are external to any protected data centers (D. G. Firesmith, 2003)

d. Software Integrity (Donald G Firesmith, 2005)

The application shall prevent the unauthorized corruption of the software

4. Non‐repudiation and Accountability Requirements (D. G. Firesmith, 2003)

A non‐repudiation requirement is any security requirement that specifies the extent to which a business, application or component shall prevent a party to one of its interactions from denying having participated in all or part of the interaction (D. G. Firesmith, 2003)

The application shall make and store tamper proof records of the following information about each order received from a customer and each invoice sent to a customer (D. G. Firesmith, 2003)

An “agent” intentionally tries to tamper the records of interactions (message, transactions etc) of the “system/ application/ centre”

To deny usage/to deny action (this can be done by delete the data used as a proof or Create similar proof

5 Privacy Requirements

Get privilege/disclosure of information

a. Anonymity (D. G. Firesmith, 2003)

A privacy requirement is any security requirement that specifies the extent to which a business, application, component or center shall keep its sensitive data and communications private from unauthorized individuals and programs (D. G. Firesmith, 2003)

The application shall not store any personal information about the users (D. G. Firesmith, 2003)

An “unauthorized agent” attempts to gain access to any data or communication of the “system/ application/ centre”

b. Communications (D. G. Firesmith, 2003)

The application shall not allow unauthorized individuals or programs access to any communications (D. G. Firesmith, 2003)

c. Data Storage (D. G. Firesmith, 2003)

The application shall not allow unauthorized individuals or programs access to any stored data (D. G. Firesmith, 2003)

Confidentiality

The application shall provide access to confidential data only to the authorized users who have the privilege

84

6 Security Auditing Requirements (D. G. Firesmith, 2003)

A security auditing requirement is any security requirement that specifies the extent to which a business, application, component, or center shall enable security personnel to audit the status and use of its security mechanisms (D. G. Firesmith, 2003)

The application shall collect, organize, summarize, and regularly report the status of its security mechanisms including access control, immunity, privacy and intrusion detection.

An “agent maliciously attempts to attack or tamper the auditing process of the “system’s/ application’s/ centre’s” status and security mechanism

Steal the audit status (to mitigate this one we should use some kind of law that governs the security personnel’s)

7. Survivability and Availability Requirements (D. G. Firesmith, 2003)

A survivability requirement is any security requirement that specifies the extent to which an application or center shall survive the intentional loss or destruction of a component (D. G. Firesmith, 2003). Ensuring timely and reliable access to and use of information. [common criteria][federal standards]

The application shall not have a single point of failure (D. G. Firesmith, 2003). The application shall be accessible to the authorized user.

An “unauthorized agent” intentionally destroys a “system’s / application’s/ centre’s” component to create its failure or to hamper its legitimate user to access the "system”.

Denial of service

8. Physical Protection Requirements (D. G. Firesmith, 2003)

A physical protection requirement is any security requirement that specifies the extent to which an application or center shall protect itself from physical assault (D. G. Firesmith, 2003)

The data center shall protect its hardware components from physical damage, destruction, theft or surreptitious replacement (D. G. Firesmith, 2003)

An “agent” tries to intentionally damage or harm physically the hardware or components or personnel of the “system/ application/ centre”

Physically assault

9. System Maintenance Security Requirements (D. G. Firesmith, 2003)

A system maintenance security requirement is any security requirement that specifies the extent to which an application, component, or center shall prevent authorized modifications from accidentally defeating its security mechanisms (D. G. Firesmith, 2003)

The application shall not violate its security requirements as a result of the upgrading of a data, hardware or software component (D. G. Firesmith, 2003)

An “agent” (authorized or accidental) attempts to violate the security requirements during the usage phase (upgrading/ replacement/ removal of data, hardware or software component) of the “system/ application/ centre”.

Fail secure (the Upgrading of data, software, hardware)(the system should preserve its secured state)

10. Attack/ Harm Detection Requirements (Donald G Firesmith, 2004)/ Intrusion Detection requirements (D. G. Firesmith, 2003)

An Attack/harm or intrusion detection requirement is any security requirement that specifies the extent to which an application or component shall detect and record attempted access or modification by unauthorized individuals (D. G. Firesmith, 2003)

Attempt possibilities to intrude

a. Availability requirements

Any security requirement that is related to malicious harm (Donald G Firesmith, 2004)(Information & Systems, 1999)

The system shall detect the presence of at least 99.9% of denial of service attacks

85

b. Confidentiality Requirements

The system shall prevent the corruption of confidential data by at least 99% of the attacks that last no longer than 1 hour and are made by attackers with profile X

c. Integrity Requirements

Upon detection of corrupted data, the system shall notify the security engineer within 5 seconds at least 99.99% of the time

d. Non‐repudiation Requirements

The system shall use virus definitions and a virus scan engine that have been updated within the previous 24 hours, if such an update exists.

Note : Requirements are prioritized according to scale high priority, medium priority and low priority as shown below:

8.4 APPENDIX D (CLASP and Framework Security Relevant Requirements)

Note : Requirements are prioritized according to scale high priority, medium priority and low priority as shown below: Priority Scale( 1: High , 2: Medium , 3: Low) ID 1IDENTIFIER MF_R001TITLE No Remote accessed to SystemREQUIREMENT System shall work within organization. RATIONALE System cannot be access remotely.RESTRICTION Only CSR (Customer service representative) can access

system. DEPENDENCIES NAType Authorization Requirement.Actor 3270 TerminalPriority 1 ID 2IDENTIFIER MF_R002TITLE Time CriticalREQUIREMENT System shall display correct result within 5 seconds of

making the request to the system. RATIONALE Customer service representative must respond to customer

in effective manner. RESTRICTION In order to update, create or search data customer has to call

CSR. DEPENDENCIES 4Type Data Integrity Requirement,Actor 3270 TerminalPriority 1 ID 3IDENTIFIER MF_R003TITLE Unauthorized accessREQUIREMENT There shall be no access to data without authorization. RATIONALE No customer can have direct access to data. RESTRICTION Only CSR can access the data.DEPENDENCIES 5

86

Type Authorization Requirement.Actor 3270 TerminalPriority 1 ID 4IDENTIFIER MF_R004TITLE Availability of systemREQUIREMENT System shall be available all the time and it should be fault

tolerant. RATIONALE Customer service representative must respond to customer

when needed. RESTRICTION Only CSR have access to system.DEPENDENCIES 2Type Availability Requirement.Actor 3270 TerminalPriority 2 ID 5IDENTIFIER MF_R005TITLE Valid credentialsREQUIREMENT Customers’ representative shall use login and a password to

access the system. RATIONALE In order to maintain security, CSR must use username and

password to initiate CICS. RESTRICTION Only CSR can have directly access to system. DEPENDENCIES 3,9Type Authentication Requirement.Actor 3270 TerminalPriority 2 ID 6IDENTIFIER MF_R006TITLE CICS accessibleREQUIREMENT CICS Shall only be accessible through 3270 terminal RATIONALE CSR can initiate CICS through 3270 terminal. RESTRICTION Only CSR can initiate the CICS through 3270 terminal. DEPENDENCIES 1Type Authorization RequirementActor 3270 TerminalPriority 2 ID 7IDENTIFIER MF_R007TITLE RACF AuthorizationREQUIREMENT Returned to application and displayed on the screen only if

RACF authorization allows. RATIONALE RACF checks whether the user is permitted to read the

relevant file. RESTRICTION Only RACF system can give dataset and transaction

permissions. DEPENDENCIES Authorization RequirementType Security RequirementActor 3270 TerminalPriority 2 ID 8IDENTIFIER MF_R008TITLE Update InformationREQUIREMENT Application user can create new claim or can update

information. RATIONALE Application must update data for specified customer. RESTRICTION IF RACF allows it, record is updated in VSAM file.

87

DEPENDENCIES 5Type Data integrityActor 3270 TerminalPriority 3 ID 9IDENTIFIER MF_R009TITLE Login attemptsREQUIREMENT System shall not support more than 3 login attempts(in case

of login failures). RATIONALE Because of improved security we wish to have 3 login

attempts after that system would not be available. RESTRICTION System should not support more than 3 login attempts. DEPENDENCIES 5Type Authentication Requirement.Actor 3270 TerminalPriority 1 ID 10IDENTIFIER MF_R010TITLE Communication FailureREQUIREMENT Roll back shall be supported in case of communication failure

during transaction. RATIONALE To restore the data to its previous state. RESTRICTION NADEPENDENCIES NAType Data integrity Requirement.Actor 3270 TerminalPriority 1 ID 11IDENTIFIER MF_R011TITLE 64 bit operating systemREQUIREMENT Main frame should run under 64 bit operating system. RATIONALE Our security framework support 64 bit operating system

RESTRICTION This case only support 64 bit operating system. DEPENDENCIES NAType System RequirementActor 3270 TerminalPriority 3 ID 12IDENTIFIER MF_R012TITLE Extra ports closedREQUIREMENT All ports except ports connecting 3270 terminal shall be

closed. RATIONALE Close entry points to restrict any direct interaction with data.RESTRICTION AND RISKS System shall only be accessible from 3270 terminal DEPENDENCIES NAType Confidentiality Requirement.Actor 3270 terminalPriority 1 ID 13IDENTIFIER MF_R013TITLE VSAM FileREQUIREMENT CICS can only access VSAM file after authenticating the user

from RACF. RATIONALE Restrict un‐authorized access to data RESTRICTION AND RISKS Customer data can only be accessed by authorized customer

service representatives DEPENDENCIES 7,6Type Authentication Requirement Actor CICSPriority 1

88

ID 14IDENTIFIER MF_R014TITLE Public MethodsREQUIREMENT Public method shall be declared as few as possible. RATIONALE Follow secure coding standards.RESTRICTION AND RISKS Un‐authorized access i.e. using public methods to enter the

system is not allowed. DEPENDENCIES 5Type Authorization Requirement , Authentication Actor UserPriority 1

8.5 APPENDIX E (CLASP and Framework Security Analysis Requirements)

Note: Requirement number 15 is of framework only. ID 15IDENTIFIER MF_R015TITLE CIC SessionREQUIREMENT User can only initiate CIC session after authentic login. RATIONALE To protect customer dataRESTRICTION AND RISKS Only CSR can login the systemDEPENDENCIES 9Type AuthenticationActor 3270 terminalPriority 1 ID 16IDENTIFIER MF_R016TITLE Files and processesREQUIREMENT There should be a limit to the maximum number of files and

processes that a user is allowed. RATIONALE CSR is not allowed keep the system’s resources unnecessarily

busy. RESTRICTION AND RISKS Only CSR can access the system file.DEPENDENCIES 3Type AvailabilityActor 3270 terminalPriority 2 ID 17IDENTIFIER MF_R017TITLE Encrypted Data.REQUIREMENT Data must be stored in Encrypted form. RATIONALE In order to protect data, it must be stored in encrypted form.RESTRICTION AND RISKS Only CSR can access the systemDEPENDENCIES 18Type Confidentiality Requirement.Actor 3270 terminal.Priority 2 ID 18IDENTIFIER MF_R018TITLE Data communicationREQUIREMENT All data communication through network must be encrypted.RATIONALE In order to protect data, communication through network

must be encrypted. RESTRICTION AND RISKS IBM Main FrameDEPENDENCIES 17Type Confidentiality RequirementActor 3270 Terminal

89

Priority 2 ID 19IDENTIFIER MF_R019TITLE Physical access to mainframe.REQUIREMENT There should be no physical access to mainframe, network

and 3270 terminal by any unauthorized person. RATIONALE Only authorized person can access to system. RESTRICTION AND RISKS Only CSR can login the systemDEPENDENCIES 3Type Authorization RequirementActor 3270 terminal.Priority 2 ID 20IDENTIFIER MF_R020TITLE Coding guidelines.REQUIREMENT Proper coding guidelines must be followed to prevent attacks

like buffer overflow and SQL injection. RATIONALE Avoid programming vulnerabilitiesRESTRICTION AND RISKS Only CSR can execute the application DEPENDENCIES NAType Data integrity Requirement.Actor 3270 terminalPriority 3

8.6 APPENDIX F (Framework’s final update Requirements) ID 21IDENTIFIER MF_R021TITLE Access application system file.REQUIREMENT User must not be allowed to access application system file.RATIONALE Attacker cannot corrupt or manipulate application/system

files. RESTRICTION AND RISKS Only CSR can access the system file.DEPENDENCIES 3Type Authorization requirementActor 3270 terminalPriority 1 ID 22IDENTIFIER MF_R022TITLE Software InstallationREQUIREMENT Any Type of software installation shall be strictly restricted.RATIONALE Software installation must be restricted to avoid malware

installation. RESTRICTION AND RISKS IBM Main FrameDEPENDENCIES 23Type Confidentiality Requirement.Actor 3270 TerminalPriority 2 ID 23IDENTIFIER MF_R023TITLE Download dataREQUIREMENT Application should not allow download, copy any kind of

data. RATIONALE Company policyRESTRICTION AND RISKS Only can CSR can login the systemDEPENDENCIES 22Type Confidentiality Requirement.Actor 3270 terminal.Priority 2

90

ID 24IDENTIFIER MF_R024TITLE Access to any communicationREQUIREMENT Application shall not allow access to any communication RATIONALE Attacker must not be able to modify any files or messages

during communication. RESTRICTION AND RISKS Only CSR can execute the application DEPENDENCIES NAType NON repudiationActor 3270 terminalPriority 2 ID 25IDENTIFIER MF_R025TITLE RACF Log FilesREQUIREMENT No access shall be allowed to RACF LOG files. RATIONALE Operation log shows detail of the transactions so that a

problem can be traced back. RESTRICTION AND RISKS CSR must not have any access to RACF log files. DEPENDENCIES 3Type Accountability.Actor 3270 Terminal.Priority 1 ID 26IDENTIFIER MF_R026TITLE Intrusion detection mechanismREQUIREMENT Intrusion detection mechanism shall be implemented at all

entry points and communication points. RATIONALE Intrusion detection mechanism shall be implemented at all

entry points and communication points to protect customer data.

RESTRICTION AND RISKS Ports are blocked.DEPENDENCIES 19Type Confidentiality Requirement.Actor 3270 TerminalPriority 1 ID 27IDENTIFIER MF_R027TITLE Failure of a system componentREQUIREMENT If any component of the system fails or stops responding,

system must not allow operations until system starts functioning normally

RATIONALE Failure of any component can make system vulnerable RESTRICTION AND RISKS There must not be any direct access to data DEPENDENCIES 19Type Confidentiality Requirement.Actor 3270 TerminalPriority 1

8.7 APPENDIX G (Misuse Case Requirements) ID M1IDENTIFIER MC_R001TITLE Encrypted Data.REQUIREMENT Data must be stored in Encrypted form. RATIONALE In order to protect data, it must be stored in encrypted form.RESTRICTION AND RISKS Only CSR can access the systemDEPENDENCIES 18Type Confidentiality.Actor 3270 terminal.Priority 2 ID M2

91

IDENTIFIER MC_R002TITLE No Remote access to SystemREQUIREMENT System shall work within organization. RATIONALE System cannot be access remotely.

RESTRICTION AND RISKS Only CSR (Customer service representative) can access system.

DEPENDENCIES NAType Authorization Requirement.Actor 3270 TerminalPriority 1 ID M3IDENTIFIER MF_R003TITLE Extra ports closedREQUIREMENT All ports except ports connecting 3270 terminal shall be

closed. RATIONALE Close entry points to restrict any direct interaction with data.RESTRICTION AND RISKS System shall only be accessible from 3270 terminal DEPENDENCIES NAType Confidentiality Requirement.Actor 3270 terminalPriority 1 ID 4IDENTIFIER MF_R004TITLE No direct access to VSAMREQUIREMENT CICS can only access VSAM file after authenticating the user

from RACF. RATIONALE Restrict un‐authorized access to data RESTRICTION AND RISKS Customer data can only be accessed by authorized customer

service representatives DEPENDENCIES NAType Authorization

92

8.8 APPENDIX H (Questionnaire)

93

8.9 APPENDIX I (Feedback Form) Do you have any experience in working/eliciting security requirements for software?

Response Chart Frequency

Yes

60%

No

40%

Total responses: 6

Have you ever used or have any knowledge about any technique for security requirement elicitation?


Yes

17%

No

83%

Total responses: 6

Was the information provided about the software system enough to understand the system?


Yes

67%

No

33%

Total responses: 6

What was the level of understanding of the activities from the material provided on the scale of 1 to 5( 1 is very easy and 5 is very difficult)?


1

0%

2

33%

3

17%

4

17%

94


5

33%

Total responses: 6

Edit this item» What was the level of application of the activities from the material provided on the scale of 1 to 5 (1 is very easy and 5 is very difficult)?


1

0%

2

17%

3

67%

4

17%

5

0%

Total responses: 6

Do you think that the time to perform these activities for provided software system was enough?


Yes

67%

No

33%

Total responses:6

Do you think that if you perform these activities again, you can produce better results?


Yes

50%

No

50%

Total responses:6

Do you think that during these activities you analyzed the system from different aspects which are usually are not considered in software development?


95


Yes

67%

No

33% Total Response 6

This Experiment improved your knowledge about software security and software attack scenarios?


Yes

67%

No

33%

Total responses:6

8.10 APPENDIX J Misuse Case Template Field DescriptionName Misuse Case Name/TitleSummary Explanation of Misuse caseDate Date of creation of Misuse caseAuthor Creator of Misuse caseBasic Path Steps which a misuser is going to take before reaching the goal Alternative Path Other paths through which the same goal can be reached Capture Point Options for how misuse can be detected and prevented [61]. Extension Point Optional paths taken by misuseTriggers Condition that can initiate misuse casePre‐conditions This condition describes those states of the system which make misuse

possible Assumptions This condition describes those states of the system’s environment

which make misuse possible Post‐conditions State of the system after successful misuse caseWorst Case Threat Maximum damage possible in case of a successful misuse case.

Optional paths are also included. Prevention guarantee “Prevention Guarantee describes the result that would be obtained by

following the “Basic” or “Alternate” path if the threat were detected and minimum threat mitigation occurs.”[34]

Detection guarantee “The “Detection Guarantee” describes the result that would be obtained if the misuse were detected, but not mitigated.”[34]

Related Business Rule “Related Business Rules are use case business rules that are broken by the misuse case”[34]

Potential Misuser Profile Level of skills and intentions of the misuse must be assessed in order to be aware of the severity of threat

Stakeholders The people who have concern about what should not happen in the system

Scope “The scope of modeling, e.g., the entire business or just the planned computerized information system” [80]

Abstraction Level What is the level of abstraction for the misuse case e.g. summary, sub function etc.

Technology and Data Variations Which various ways and technologies can be used to achieve the misuse

Goal Which goal of the stakeholder is hinderedDependencies(Relationship) Relationship of Stakeholder with other Stakeholder(s) Security Constraints Information about Security constraints on Stakeholder(s)

96

8.11 APPENDIX K Sequence Diagram Showing Activity Flow

97

8.12 APPENDIX L Use Case Diagram for Monolithic System

System

Log In

3270 Terminal

Authentication(RACF)

ApplicationRequest to Execute Application Validate User

Customer Data

Request for customer data

CheckAuthorization(RACF)

Whether the user is permitted to read the relevant file

Update customerdata

CheckAuthorization(RACF)

Determine whether the user is permitted to update file

If RACF allows it,record is updated in VSAM File

If RACF allow it, record is returned to application

from VSAM file

Update Data on the 3270 terminal

To update customer data

DatabaseUpdation(File)

View Data from VASM

Date post:	25-Aug-2018
Category:	Documents
Upload:	dangdan
View:	226 times
Download:	0 times