MISUSE CASE AND SECURITY REQUIREMENT ANALYSIS FOR AN APPLICATION

Thesis Submitted in partial fulfillment of the requirements for the degree of

MASTER OF TECHNOLOGY in COMPUTER SCIENCE & ENGINEERING - INFORMATION SECURITY

by

VINEET KUMAR MAURYA (07IS11F)

DEPARTMENT OF COMPUTER ENGINEERING NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA SURATHKAL, MANGALORE-575025 June, 2009 Dedicated To

My parents

&

Suraksha Group Members D E C L A R A T I O N

I hereby declare that the Report of the P.G Project Work entitled "MISUSE CASE AND SECURITY REQUIREMENT ANALYSIS FOR AN APPLICATION" which is being submitted to the National Institute of Technology Karnataka, Surathkal, in partial fulfillment of the requirements for the award of the Degree of Master of Technology in Computer Science & Engineering - Information Security in the Department of Computer Engineering, is a bonafide report of the work carried out by me. The material contained in this report has not been submitted to any University or Institution for the award of any degree.

………………………………………………………………………………..

(Register Number, Name & Signature of the Student)

Department of Computer Engineering

Place: NITK, SURATHKAL

Date: ...... C E R T I F I C A T E

This is to certify that the P.G Project Work Report entitled "MISUSE CASE AND SECURITY REQUIREMENT ANALYSIS FOR AN APPLICATION" submitted by Vineet Kumar Maurya (Register Number: 07IS11F), as the record of the work carried out by him, is accepted as the P.G. Project Work Report submission in partial fulfillment of the requirements for the award of the Degree of Master of Technology in Computer Science & Engineering - Information Security in the Department of Computer Engineering.

External Guide Internal Guide

(Name and Signature (Name and Signature with date and seal) with date and seal)

Chairman – DPGC (Signature with Date and Seal) ACKNOWLEDGMENTS

I take this opportunity to express my deepest gratitude and appreciation to all those people who made this project work easier with words of encouragement, motivation, discipline, and faith by offering different places to look forward to expanding my ideas and helped me towards the successful completion of this project work.

First, I would like to express my sincere gratitude to my guide Dr. Asoke K. Talukder, visiting faculty, Department of Computer Engineering, NITK, Surathkal and project coordinator & guide Mr. Alwyn Roshan Pais, Sr. Lecturer, Department of Computer Engineering, National Institute of Technology Karnataka, Surathkal for their motivating suggestions, insightful advice, invaluable guidance, help and support in successful completion of this project and also for constant encouragement and advice throughout my M.Tech programme.

I would like to take this opportunity to express my thanks to the teaching and nonteaching staff of Department of Computer Engineering, NITK for their invaluable help and support in these two years of my study. I am also grateful to Suraksha group members and all my classmates for their help, encouragement and invaluable suggestions.

Finally, I would like to thank all those whose direct and indirect support helped me in completing my project work & thesis in time. ABSTRACT

Security is always considered as Non–functional requirement in traditional Software Development Life Cycle (SDLC) and handled outside of software development environment. In the Next Generation Network (NGN) where all applications will be networked it is compulsory that security should be treated as functional requirement. Misuse case diagram is one approach to solve our purpose. In misuse case diagram mis-actor always posed threat to our application. By doing requirement analysis with the help of misuse case diagram, we can figure out the possible way of threat to our application and can apply remedy action in form of the security use case and security patterns. Misuse cases treat security as a functional requirement. If we encapsulate misuse case diagram in the software development process, security can be embedded from early stage in SDLC process, and we can achieve our goal of developing security aware application.

This project work is an attempt to develop an approach for security requirement analysis of any application using misuse case. Also a tool named “Suraksha” has been developed with this facility to develop misuse case diagram and misuse case template easily.

Keywords – Misuse case, Security requirement analysis, STRIDE, CI5A, Security aware application, Security-aware Software Development Life Cycle, SaSDL.

i CONTENTS

Abstract i

List of Figures iv

Nomenclature v

1. INTRODUCTION ...... 1 1.1 Use Case ...... 2 1.2 Misuse Case ...... 3 1.3 Misuse Case Template ...... 5 1.3.1 Lightweight Misuse Case Description ...... 5 1.3.2 Extensive Misuse Case Description ...... 6 1.4 STRIDE...... 6 1.5 Organization of Thesis ...... 8 2. SOFTWARE DEVELOPMENT LIFE CYCLE ...... 9 2.1 Various SDLC Models...... 9 2.1.1 Waterfall Model ...... 9 2.1.2 Prototyping Model ...... 10 2.1.3 Spiral Model ...... 10 2.1.4 Agile Model ...... 11 2.1.5 Scrum ...... 12 2.1.6 Extreme Programming (XP) ...... 13 2.1.7 Stage-Gate Model ...... 13 2.2 Requirements ...... 15 2.2.1 Functional Requirements ...... 15 2.2.2 Nonfunctional Requirements ...... 15 2.2.3 UML Model for Requirement Elicitation ...... 16 2.3 Design ...... 18 2.3.1 Design Patterns ...... 18 2.3.2 Security Design Patterns ...... 19 2.4 Construction ...... 20

ii 2.4.1 Various Techniques & Languages for Construction ...... 21 2.4.2 Security Bugs in Construction Phase ...... 24 2.5 Testing ...... 26 2.5.1 Testing Techniques ...... 26 2.5.2 Why Security Bugs not Detected ...... 27 2.5.3 Security Testing ...... 28 3. SECURITY-AWARE SOFTWARE DEVELOPMENT LIFE CYCLE (SaSDLC) ...... 32 3.1 Problem Description ...... 32 3.2 SaSDLC Process ...... 32 4. SECURITY REQUIREMENT ELICITATION ...... 38 4.1 Suraksha: Open Source Tool ...... 38 4.1.1 Suraksha: Misuse Case Diagrams ...... 39 4.1.2 Suraksha: Misuse Case Template ...... 44 4.2 Misuse Case and Security Requirement Analysis ...... 49 5. CONCLUSION ...... 52

REFERENCES

iii LIST OF FIGURES

1.1 A simple use case diagram…………………………………………………...3

1.2 Misuse case diagram example illustrating notations and relationships………4

2.1 Prototyping model…………………………………………………………..10

2.2 A typical Spiral model……………………………………………………....11

2.3 Stage-Gate model…………………………………………………………...14

3.1 Assets identification for an application (Suraksha)………………………...34

3.2 An example of Attack Tree with DREAD rating…………………………...35

4.1 Misuse case diagram user interface………………………………………....39

4.2 Property editor for a node in misuse case diagram window………………...40

4.3 Process to open a misuse case diagram window…………………………....43

4.4 Misuse case diagram for e-commerce application using Suraksha…………44

4.5 Textual representation of misuse case- tamper with database (part 1)……...47

4.6 Textual representation of misuse case- tamper with database (part 2)……...48

4.7 Misuse case diagram for e-commerce application analyzed using STRIDE.49

iv NOMENCLATURE/ACRONYMS

Notation Description SDLC Software Development Life Cycle SaSDLC Security- aware Software Development Life Cycle UML Unified Modeling Language XP Extreme programming CC Common Criteria PP Protection Profile TE Target of Evaluation ST Security Target EAL Evaluation Assessment Level DOS Denial of Service LAN Local Area Network XSS Cross-Site Scripting

v 1. INTRODUCTION

In 1968 October NATO Science Committee organized a conference on Software Engineering [1]. To manage the software crisis it was felt that software development should follow some standard engineering principles. In fact, the philosophy of software engineering emerged from this conference. In last forty years different techniques have been proposed to establish software development as a part of mainstream engineering that includes formal techniques of requirement elicitation, design, construction, testing, deployment, and maintenance of software. All these techniques that dealt with software engineering are focused on functional requirements. Functional requirement is defined as “behavior of the software system for desired input”, whereas the nonfunctional requirement relates to “how the system is expected to behave with undesired input or in an unpredicted environment”. Nonfunctional requirements generally were defined as constraints in the system. In software engineering these constraints were generally handled outside of the development life cycle. Constraints were primarily handled by isolation of the constraints or by reducing the effect of the constraints by increasing the magnitude of the function – through external means. Security in software has been defined as non- functional requirement and looked as constraints. Till sometime ago, security for the software system was managed through perimetric security. It was not mandatory that applications should be security aware. That is why security has always been an afterthought. Now-a-days, it is obligatory to develop security aware applications. Security needs to be embedded into the system from the early stages of Software Development Life Cycle (SDLC) and must be considered as functional requirement to develop a security aware application. This can be achieved through Security aware Software Development Life Cycle (SaSDLC) [2]. Misuse case diagram is a main step-stone to achieve the target of development of security aware applications. A main step of SaSDLC process is development of misuse case diagram to collect the possible threats to an application. Here our main concern is misuse case development using Suraksha tool [3] and explain how misuse

1 case diagrams are helpful in security requirement analysis of an application through SaSDLC process. This chapter presents a brief walkthrough of related concepts and approaches for secure application development.

1.1 Use case In software design, a technique known as use cases [4] has gained increasing popularity since it was first proposed by I. Jacobson in 1986. A Use case typically describes some function that the system should be able to perform [5]. Hence, use cases are good for working with so-called functional requirements, but not necessarily with extra-functional ones, such as security [6, 7]. A use case is a structured way to address how a user or other system interacts with a system. In proper words, we can say Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing the system implementation details. A complete set of use cases define all behaviors required of the system, bounding the scope of the system [8]. Use case is now included within UML (Unified Modeling Language). UML is a modeling language that includes graphical notations and diagrams to create an abstract model of a system. These diagrams capture the three important aspects of a system, viz., structure, behavior, and functionality. UML provides total nine different ways of defining a system through nine predefined diagrams. These are: Class diagram, Object diagram, State chart diagram, Activity diagram, Sequence diagram, Collaboration diagram, Use-case diagram, Component diagram, and Deployment diagram. Three kinds of relationships are used to link various nodes of use-case . These are – “include”, “generalization”, and “extends”. An include relationship between two use cases means that one use-case can include and use other use-cases. The sequence of behavior described in the included use case (or sub use case) is included in the sequence of the base (including) use case. The extend relationship between use-cases means that the base use case is extended with additional behavior. It provides a way of capturing a variant to a use case. A generalization relationship between use cases is the same as generalization among classes. It implies that the child use case contains

2 all the attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all relationships of the parent use case. When modeling with use cases, it is common to start with a use case diagram that depicts the actors, use case(s) and interaction(s). The diagram will give both the author and the reader an instant feeling how the user relates to the system. An example of use case diagram is shown in Figure 1.1.

Figure 1.1: A simple use case diagram

1.2 Misuse case Use cases have become popular for determining, communicating, specifying, and documenting functional requirements. However, they are not sufficient to elicitate, communicate and document nonfunctional requirements like security requirements of a system. To define security, we need to understand how someone will misuse the system. To embed security in system design, we first need to capture security requirements. Misuse cases are simple and fine approach to solve the purpose. A misuse case is the inverse of a use case, i.e., a function that the system should not allow. Misuse case was first introduced by Guttorm Sindre and Andreas Opdahl in their paper Eliciting Security Requirements by Misuse Cases [9].

3 According to Sindre and Opdahl “A use case generally describes behavior that the system/entity owner wants it to provide. A misuse case is a special kind of use case, describing behavior that the system/entity owner does not want to occur.” A mis-actor is the inverse of an actor – that one does not want the system to support and initiates misuse cases. A mis-actor can also be defined as a special kind of actor who initiates misuse case.

Figure 1.2: Misuse case diagram example illustrating notations and relationships

To denote a system behavior, effort should be to include both functional and non-functional requirements together. And, to denote this in graphical fashion, use- case and misuse-case should be integrated to define the system. To represent use cases and misuse cases together, these need to be distinguished. Therefore, use-case is black in white and misuse-case is shown in an inverted format – white in black. The actor in use-case is white-hat stick person, a mis-actor is in inverted form black-hat stick person. Misuse case uses the UML notations of arrows and undirected lines between an actor and use case. In addition to standard “include” and “extend” relations, security requirements introduce other relations. They are called “threaten” and “mitigate”. The “threaten” relationship between a misuse case and use case originates

4 from the misuse case targets a use case that a misuse case wants to harm. The “mitigates” relationship originates from a use case (security use case) to misuse case. It characterizes how the security use case is defined as a countermeasure against a misuse case. The example in Figure 1.2 depicts a very simple misuse case that illustrates the various notations and relationships. A five-step approach for determining and specifying security requirements with misuse cases has been proposed by Sindre and Opdahl [9]: · Identify critical assets · Define security goals · Identify threats · Identify and analyze risks · Define security requirements

Ian Alexander made a valuable contribution in the area of misuse cases by giving a practical touch. He applied misuse cases to analyze requirement/design option Trade- Offs in a railway case study [12].

1.3 Misuse case template A misuse case diagram only provides an outline of the requisite system functionality, so the real meaning of a misuse case is usually captured in the associated textual description. Sindre and opdhal have found two useful ways of expressing misuse cases textually [9, 10, 11].

1.3.1 Lightweight Misuse case description The lightweight approach describes misuse within the textual description of a use case. In this approach in a normal use case description, an extra “Threats” slot is inserted. The lightweight option can give a considerable gain in customer and developer understanding of security threats, with very little extra price beyond normal use case description. The extra slot straight away signals that misuse is possible and must be addressed. In fact, for applications where security is essential, it would make good judgment to include a threat slot as standard in the normal use case template. If

5 the misuse case is itself just a twisted variety of a normal application use case, for example, an unwanted but honest error, the threat slot would possibly present enough clarification.

1.3.2 Extensive misuse case description It is a more heavyweight approach, providing the misuse case a complete textual description, with basic and alternative paths, preconditions, triggers, etc. A template for heavyweight approach was defined in [11] and used by Suraksha tool. The heavyweight approach would be more suitable, if the misuse case is an elaborate sequence of steps, with exceptions, alternative paths, preconditions and assumptions.

1.4 STRIDE STRIDE is a methodology for identifying possible threats [13, 14, 15]. It provides a high level classification of threat. This makes it easier to understand what that threat allows an attacker to do and help assigning priority to a threat. It is used by Microsoft for threat modeling of their systems. The STRIDE acronym is formed from the first letter of each of the following categories.

· Spoofing Identity: In a spoofing attack, an adversary impersonates as a different person and pretends to the system as a legitimate user. Spoofing attacks assume that some piece of content or functionality is associated with an identity and that the content is trusted by the target because of this association. Credentials or tokens stored in HTTP cookies, Authentication tokens in the clear on the wire can be used by attacker for spoofing attack. Other examples are IP spoofing, spoofed mail etc. Spoofing attack is mitigated through authentication so that adversaries cannot become any other user or assume the attributes of another user.

· Tampering with Data: In this category of the attack, the attacker's goal is modify the data within the system to perform a malicious action. Example includes SQL injection to modify database data, modifying data on the wire, in transit etc. To disallow tampering; any data to the application or from the

6 application should be secured so that it cannot be altered. The application should validate all data received from the user before storing or using it for any processing. An attacker should not be able to change data delivered to a user. Also, data in the disk and any other storage media needs to be protected. Hashes, digital signatures, Tamper-resistant protocols are other ways to protect data.

· Repudiation: The ability of an adversary to deny performing some malicious activity because the system does not have enough evidence to prove otherwise. A dishonest user may dispute a genuine transaction if there is insufficient auditing or recordkeeping of their activity. For example, a bank customer may say, “The signature on the cheque is forged and the money should be credited in my account!”, and you cannot track his or her activities through the application. In such case it is likely that the transaction will have to be written off as a loss. Therefore, applications need to have audit trails and systems by which the activity of a user can be proven beyond doubt.

· Information Disclosure: The exposure of protected data to a user that is not otherwise allowed access to that data. If it is possible for an attacker to publicly reveal user data, whether anonymously or as an authorized user, there will be an immediate loss of confidence and reputation loss. Also, disclosure of proprietary or secured information may lead to serious financial loss. Examples are reading on the wire, unsecured pages and components, error messages that reveal implementation details etc.. Therefore, applications must include strong controls like encryption, proper authorization to prevent disclosure of information.

· Denial of Service: Denial of Service (DoS) occurs when an adversary can prevent legitimate user from using the normal functionality of the system. Application designers should be aware that their applications may be subject to a denial of service attack. Therefore, countermeasures for such attack should be properly built in the system.

7 · Elevation of Privilege: If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his role to a higher privilege one. All actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality. Also, the privileged access must be for the minimum duration it is necessary [8].

In this literature survey, we have gone through some approaches like Misuse cases, STRIDE, Misuse case template etc. They are helpful in developing security aware applications. But any approach itself is not enough to fulfill all security requirements. A fine combination of these approaches can solve our problem of developing security aware applications. Misuse cases have a big role in security requirement analysis of an application because they treat security as functional requirement. However, there is no fair approach available for security requirement analysis using misuse case. Further regarding the available tool support, open source tools are hardly ever available for misuse case diagram. Development of holistic approach to develop security aware application and an open source tool based on this approach capable of drawing misuse case diagram are the problems which we have focused in this project. How to do security requirement analysis of an application using misuse case is also the main part of our problem.

1.5 Organization of Thesis The whole thesis is organized as follows. Chapter 1 gives introduction about Misuse cases and related concepts. Chapter 2 gives a detail description of the software development life cycle. Various SDLC method and description of each phase with security view are discussed here. Chapter 3 defines the problem and gives an overview of the proposed Security-aware software development life cycle (SaSDLC) process. In Chapter 4 we discuss how misuse cases are helpful in Security requirement analysis of an application using SaSDLC process. The process of misuse case diagram and template development using Suraksha tool is also explained here. Last chapter provides the conclusion of whole work.

8 2. SOFTWARE DEVELOPMENT LIFE CYCLE

In this chapter, a brief introduction to the software development life cycle is given. Along with description of various SDLC methods, descriptions of each phase in SDLC are examined from the security point of view.

2.1 Various SDLC Models The software development life cycle (SDLC) is the complete process of formal, logical steps taken to develop a software Application. The SDLC traditionally comprise of following phases:

• Requirement Elicitation

• Design of the Application • Construction of the Application • Testing of the Application There are many methodologies or models that can be used to guide the software development life cycle either as a core model to the SDLC or as a complementary method. These include:

2.1.1 Waterfall Model Winston Royce introduced the Waterfall model in 1970. It is a popular version of the software development life cycle model for software engineering also known as classic life cycle or linear sequential model. Waterfall model suggests a systematic, sequential approach to software development with distinct goals for each phase of development. The seven waterfall phases are:

a) Requirement Gathering – Collecting the business requirements/needs b) Analysis – Business and Requirement Analysis c) Design – Architecture and application design d) Coding – Development/Construction/Programming e) Testing – Bug fixes, error corrections, quality assurance f) Implementation – Deploying the application into the production environment g) Post Implementation – Maintenance and review.

9 2.1.2 Prototyping Model In this technique, a very basic model of the system is built known as prototype. This prototype is tested, reworked and enhanced till a satisfactory prototype of the system is created. Then prototype is elaborated till the final system is developed.

Figure 2.1: The prototyping model

The prototyping model (Figure 2.1) [16] begins with requirements' gathering. Application developer and customer meet and define objectives for the software, identify known requirements and outline areas where further explanation is compulsory. A "quick design" is prepared, which focuses on a representation of visible aspects of the software to the user (e.g; input approaches and output formats). The quick design leads to the construction of a prototype. The prototype is evaluated by the user and used to refine requirements for the software to be developed. Iteration occurs until prototype can satisfy the requirements of the user, while at the same time enabling the developer to better understand what needs to be done.

2.1.3 The spiral model The spiral model, initially proposed by Boehm [17], is an evolutionary software development model that combines the features of the prototyping model (iterative nature) and the waterfall model (controlled and systematic aspects). The spiral model is intended for big, costly and complicated projects. Using the spiral model, software is developed in a series of incremental releases. In the initial phase, release might be a paper model. In the later phase, more complete versions of the software are created. A spiral model is divided into three to six task regions also known as framework activities. Figure 2.2 show a spiral model [16] with six task regions:

10 · Customer communication—tasks required to establish effective communication between developer and customer. · Planning—tasks required to define resources, timelines, and other project related information. · Risk analysis—tasks required to assess both technical and management risks. · Engineering—tasks required to build one or more representations of the application. · Construction and release—tasks required to construct, test, install, and provide user support. · Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Figure 2.2: A typical spiral model

2.1.4 Agile Model Agile software development [18] refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile

11 methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Agile methods break tasks into small increments with minimal planning, and don't directly involve long-term planning. Iterations are short time frames that typically last to one to four weeks. Each iteration is worked on by a team through a full software development cycle. Iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.

Under the broad term of 'Agile Software Development' there are other approaches such as Extreme Programming, Scrum, Lean Development, and RUP. Each approach has its own ideas, communities and leaders.

2.1.5 Scrum Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. This method has some very key principles.

· Deliver products based on need from high-priority down. · Deliver the absolute minimum that the customer wants. · Eliminate waste from your projects wherever possible. · Deliver projects in short bursts, called iterations.

Scrum is a communication methodology more than a development methodology and because of that, it can be applied to almost any type of project. Scrum consists of the following core believes:

· The customer lists all the features, they want in priority order. · Development efforts are broken into 30 day iterations called sprints.

12 · Scrum teams are multi-functional teams of 5-10 that contain all the facets of the team that is needed to complete the projects.

2.1.6 Extreme Programming (XP) Extreme Programming (XP) is actually a deliberate and disciplined approach to Agile software development. One of the first approaches to gain main-stream success, XP was found to be most successful at smaller companies. XP allows the software developers to confidently respond to changing software requirements, even late in the life cycle.

This methodology additionally focuses on team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple and effective way to enable groupware style development.

XP improves a software project in four essential methods; communication, simplicity, feedback, and courage. XP programmers communicate with their customers and programmers. The design should be simple and clean. They get feedback by testing their software starting on day one and deliver the system to the customers as early as possible and implement changes as suggested.

2.1.7 Stage-Gate Model The Stage-Gate method from Robert G. Cooper [19] is an approach that can be used to make the product development process more effective. It is a blueprint for managing the new product process, from an idea to launching a product, in a number of predetermined stages. Each stage consists of a set of certain cross-functional and parallel activities, which must be successfully completed prior to obtaining management approval to proceed to the next stage of product development. The entrance to each stage is called: a gate. These gates, which are normally meetings, control the process and serve as:

· Quality control · Go / Kill check-points. Readiness-checks, Must-Meet criteria, and Should- Meet criteria. · Marker for action plan for the next phase.

13 Figure 2.3: Stage-Gate Model

Stage-Gate model consists of six stages as shown in Figure 2.3 and explained below:

1) Discovery stage: It contains pre-work designed to discover opportunities and to generate new ideas. 2) Scoping: A quick, preliminary investigation of each project. Provides inexpensive information by desk research to enable narrowing the number of projects. 3) Build the Business Case: A much more detailed investigation by primary marketing and technical research. The business case must include a product definition, a product justification and a project plan. 4) Development: A detailed design and development of the new product, along with some simple product tests. 5) Testing and Validation: Extensive product tests in the marketplace, the lab and the plant. 6) Launch: Beginning of full production, marketing, selling, distribution, quality assurance etc.

14 2.2 Requirements

Requirements are defined during the early stages of a system development as a specification of what should be implemented. They are descriptions of how the system should behave, constraints on the system's operation, or specifications of a system property or attribute. Broadly, we can divide requirements into two parts functional requirements and non functional requirements. They are briefly described in this section. In addition, various UML techniques for requirement elicitation are also discussed.

2.2.1 Functional Requirements The functional requirement can be defined as – “A system or software requirement that specifies a function that a system or software system or its component must be capable of performing. These are requirements that define behavior of the system or the software. The functional requirement also covers the process or transformation that software and hardware components of the system perform on inputs to produce outputs.”[8]

2.2.2 Nonfunctional Requirements Non-functional requirements are requirements, which are not specifically concerned with the functionality of a system. They place restrictions on the product being developed and the development process, and they specify external constraints that the product must meet. Because they are restrictions or constraints on system services, non-functional requirements are often of critical importance, and functional requirements may need to be sacrificed to meet these non-functional constraints.

Non-functional requirements define the overall qualities or attributes of the resulting system. Non-functional requirements include safety, security, usability, reliability and performance requirement. Functional requirements are easy to define and quantify; therefore, easy to test. However, nonfunctional requirements are mostly qualitative – therefore, difficult to test. Because, security is a component of nonfunctional requirement, designers do not think about it during the design and construction process of the system. Security therefore, always remains as an afterthought.

15 2.2.3 UML Model for Requirement Elicitation A requirement is a design feature, property, or behavior of a system. The activity of requirement analysis involves trying to figure out what the users and customers of a software effort want the System to do. A number of UML techniques can come in handy here:

1) Use case diagram shows the functionality provided by a system in terms of actors, actors' goals (represented as use cases), and any dependencies among those use cases. Use cases are useful in capturing and communicating functional requirements, and as such they play a primary role in product definition. Use case diagrams are meant to facilitate the communication with the future users of the system, and with the customer, and are especially helpful to determine the required features the system is to have. Use case diagrams specify desired behavior, but cannot specify how this is to be achieved.

2) Class diagram describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. A class diagram drawn from the conceptual perspective, which can be a good way of building up a rigorous vocabulary of the domain. Classes map out key business concepts, their relationships and the business rules applicable to these, that is, what the system is about.

3) Object diagram shows a complete or partial view of the structure of a modeled system at a specific time. Object diagrams are used to model the static design view of a system just as we do with class diagrams, but from the perspective of real or prototypical instances. This view primarily supports the functional requirements of a system that is, the services the system should provide to its end users.

4) State machine diagram is a standardized notation to describe behavior of many systems, from computer programs to business processes. State machine diagrams are good at describing the behavior of an object across several use cases.

16 5) Activity diagram represents the business and operational step-by-step work flows of components in a system. An activity diagram shows how Software and human activities interact. An activity diagram can show the context for use cases and also the details of how complicated use case works. Activity diagrams are similar to flowcharts, but the principal difference between them is that activity diagram support and encourages parallel behavior.

6) Sequence diagram shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespan of objects relative to those messages. Usually, a sequence diagram captures the behavior of a single use case (scenario). Sequence diagrams should be used to look at the behavior of several objects within a single use case. Sequence diagrams are fine for showing collaborations among the objects.

7) Collaboration diagram models the objects and links that are meaningful within an interaction. It is a type of interaction diagram; emphasize the data links between the various participants in the interaction. The collaboration diagram allows free placement of participants, with links between them to show how the participants connect. It uses numbering to show the sequence of messages. Collaboration diagrams are easier to modify, so they are a good approach for exploring alternatives.

8) Component diagram depicts how the software system is split up into components and shows the dependencies among these components.

9) Deployment diagram serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware. Deployment diagrams show a system's physical layout, revealing which part of software runs on what pieces of hardware. They are very useful in showing what is deployed where, so any nontrivial deployment can make good use of them.

17 2.3 Design After the requirements are identified, possible security threats have been identified, the system needs to be designed in such a way that all the security considerations have been taken into account. Security design patterns help to insert this security consideration in a right way. This section gives an overview of design patterns and security design patterns.

2.3.1 Design Patterns A design pattern is a formal way of documenting successful solutions to problems. The concept of design patterns was introduced by Christopher Alexander and has been adapted for various other disciplines. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are a way to describe some best practices used in designing software applications [20].

Design patterns can be described using a consistent format (template). The template provides a uniform structure to the information thus making design patterns easier to learn, compare, and apply. At the very least, a template should contain:

1) Pattern name: concise and descriptive name. 2) Intent: object of the pattern. (Particular design issue or problem it addresses) 3) Motivation: a scenario that explains a design problem and how the pattern will solve the problem. 4) Applicability: describe situations where the design pattern can be applied. Examples of poor designs that the pattern can. 5) Structure: a graphical representation of the classes used in the pattern. 6) Participants: the classes and/or objects participating in the design pattern and their responsibilities. 7) Collaborations: interfaces between the participants to bring out their responsibilities.

18 8) Consequences: trade-offs and forces that exist within the pattern. How does the pattern support its objectives? 9) Implementation: describing pitfalls, hints, or techniques that user should be aware of, for implementation of the pattern. 10) Sample Code: code fragments in any language illustrating how pattern can be implemented. 11) Known Uses: real world example of the pattern. 12) Related Patterns: design patterns closely related to this and important differences between them.

Design patterns can be classified by based on two criteria’s such as purpose and scope. Purpose reflects what a pattern does. Patterns can have creational, structural, or behavioral purpose. Creational patterns are used to create objects in an application. Structural patterns are used to design the structure of modules (composition of classes or objects) in an application. Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility. [20]

The second criteria called scope, specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Most patterns are in the Object scope. [20]

The reasons for using design patterns are nearly same as using any object oriented techniques. Design patterns support reuse, without constraining implementations to a specific platform or language, and promote efficient use of design time. They can be seen as the design equivalent of modular or object oriented programming. Design patterns provides solutions to general software engineering problems and there is no added cost in creating patterns for every part of a system under development.

2.3.2 Security design patterns Joseph Yoder and Jeffrey Barceló were first to adapt design patterns for information security. It is easy to document what the system is required to do. However, it is quite

19 difficult and sometime impossible to define what a system is not supposed to do. Yoder and Barceló [21] proposed seven security design patterns for information security that were extended to ten [8]. These security patterns are:

1) Single Access Point: Providing a security module and a way to log into the system. This pattern suggests that keep only one way to enter into the system. 2) Check Point: Organizing security checks and their repercussions. Authentication and authorization are two basic entity of this pattern. 3) Roles: Organizing users with similar security privileges. 4) Session: Localizing global information in a multi-user environment. 5) Full View with Errors: Provide a full view to users, showing exceptions when needed. 6) Limited View: Allowing users to only see what they have access to. 7) Secure Access Layer: Integrating application security with low-level security. 8) Least Privilege: Privilege state should be shortest lived state. 9) Journaling: Keep a complete record of usage of resource. 10) Exit Gracefully: Designing systems to fail in a secure manner.

At the end of the design, the attack surface is analyzed. If the attack surface area is high, above process is repeated until the attack surface is reduced to the minimum level.

2.4 Construction The term software construction refers to the creation of working, meaningful software using mostly coding and debugging. Elements of detailed design, unit testing, integration testing etc., also have involvement in construction. Construction is a large part of software development. Depending on the size of the project, construction typically takes 30 to 80 percent of the total time spent on a project, and thus it affects the success of the project. Construction is the central activity in software development, which is guaranteed to be done. Proper requirements analysis and design are required to do construction effectively. System testing is done after construction to verify that construction has been done correctly.

20 2.4.1 Various Techniques & Languages for Construction For software construction, mainly two techniques are used by developers. They are object-oriented programming and procedure oriented programming.

· Object-oriented technique: Object oriented programming has become the latest fashion in software construction. Object oriented technique is an attempt to change software into something where structure exists in a form which can be exploited to solve the problems of software construction. Software is constructed in a component based way, in the same way as mechanical and electrical engineers work. Classes are used to describe an object. Multiple copies of this can then be created in a program. Objects work collectively by activating operations (methods) in each other. Object–oriented programming technique provides increase productivity (due to reusable components), reliability, extensibility (inheritance) and easy maintenance of constructed software. · Procedure oriented technique: Procedural programming refer to a programming paradigm based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself. A procedural programming technique provides a developer a means to define precisely each step in the construction of a software. The developer knows what is to be accomplished and provides through the language step-by-step instructions on how the construction is to be done. Procedure oriented technique has ability to re- use the same code at different places in the program without copying it. Also they have ability to be strongly modular or structured.[22]

Languages for Construction

The programming language in which the application will be implemented is always a main issue in construction. Programming-language choice affects productivity and code quality in several ways. Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages. Languages such as C++, Java, Smalltalk, and Visual Basic have been

21 credited with improving productivity, reliability, simplicity, and comprehensibility over low-level languages such as assembly and C. Moreover, higher-level languages are more expressive than lower-level languages. Below is a short description of the most common languages in use today [23].

1) Assembly Language: Assembly language, or “assembler,” is a kind of low-level language in which each statement corresponds to a single machine instruction. Because the statements use specific machine instructions, an assembly language is specific to a particular processor for example, specific Intel or Motorola CPUs. Assembler is regarded as the second-generation language. Most programmers avoid it, unless they are pushing the limits in execution speed or code size. 2) C: C is a general-purpose, mid-level language that is originally associated with the UNIX operating system. C has some high-level language features, such as structured data, structured control flow, machine independence, and a rich set of operators. It has also been called a “portable assembly language” because it makes extensive use of pointers and addresses, has some low-level constructs such as bit manipulation, and is weakly typed. 3) C++: C++ is an object-oriented language founded on C, was developed at Bell Laboratories in the 1980s. In addition to being compatible with C, C++ provides code complete classes, polymorphism, exception handling, templates, and it provides more robust type checking than C does. 4) C#: C# is a general-purpose, object-oriented language and programming environment developed by Microsoft with syntax similar to C, C++, and Java and provides extensive tools that aid development on Microsoft platforms. 5) Cobol: Cobol is an English-like programming language that was originally developed in 1959-1961 for use by the Department of Defense. Cobol is used primarily for business applications and is still one of the most widely used languages today. Cobol has been updated over the years to include mathematical functions and object oriented capabilities. The acronym “Cobol” stands for Common Business- Oriented Language.

22 6) Fortran: Fortran was the first high-level computer language, introducing the ideas of variables and high-level loops. “Fortran” stands for FORmula TRANslation. Fortran is used mainly in scientific and engineering applications. 7) Java: Java is an object-oriented language with syntax similar to C and C++ that was developed by Sun Microsystems. Java was designed to run on any platform by converting Java source code to byte code, which is then run in each platform within an environment known as a virtual machine. Java is in widespread use for programming Web applications. 8) JavaScript: JavaScript is an interpreted scripting language that is loosely related to Java. It is used primarily for adding simple functions and online applications to web pages. 9) Perl: Perl is a string-handling language that is based on C and several UNIX utilities, created at Jet Propulsion Laboratories. Perl is often used for system administration tasks such as creating build scripts as well as for report generation and processing. The acronym “Perl” stands for Practical Extraction and Report Language. 10) PHP: PHP is an open-source scripting language with a simple syntax similar to Perl, Bourne Shell, JavaScript, and C. PHP runs on all major operating systems to execute server-side interactive functions. It can be embedded in web pages to access and present database information. The acronym “PHP” originally stood for Personal Home Page, but now stands for PHP: Hypertext Preprocessor. 11) Python: Python is an interpreted, interactive, object-oriented language that focuses on working with strings. It is used most commonly for writing scripts and small web applications and also contains some support for creating larger programs. It runs in numerous environments. 12) SQL: SQL is the de facto standard language for querying, updating, and managing relational databases. SQL stands for Structured Query Language. Unlike other languages listed in this section, SQL is a “declarative language” meaning that it does not define a sequence of operations, but rather the result of some operations. 13) Visual Basic: The original version of Basic was a high-level language developed at Dartmouth College in the 1960s. The acronym BASIC stands for Beginner’s

23 All-purpose Symbolic Instruction Code. Visual Basic is a high-level, object- oriented, visual programming version of Basic developed by Microsoft that was originally designed for creating Windows applications. It has since been extended to support customization of desktop applications such as Microsoft Office, creation of web programs, and other applications.

2.4.2 Security Bugs in Construction Phase A bug is a software security defect that is introduced during software implementation and can be detected locally through static and manual analysis. The following types of security bugs [24] are common in construction phase

1) Incorrect or incomplete input validation: Incorrect or incomplete input validation is a common source of security problems. Attacks that take advantage of little to no input validation include SQL injection, HTML injection, cross-site scripting, illegal pointer values and integer overflows. In addition, inadequate input validation can lead to buffer overflows and SQL defects also. Without robust checks all of these types of attacks can cause risks to integrity and confidentiality of an application. One effective approach for input validation is to use a whitelist, which lists all known good inputs that a system is permitted to accept and excludes everything else (including characters used to perform each type of attack). 2) Poor or missing exception handling: Programming language's use exception handling mechanism to deal with unexpected events such a divide-by-zero attempt, violation of memory protection, or a floating-point arithmetic error. Such exceptions could be handled by the code by checking for conditions that can lead to such violations. When such checks are not made, exception handling passes control from the function with that error to a higher execution context in an attempt to recover from that condition. Such exception handling disrupts the normal flow of the code and even causes the program to crash. When the program fails due to some exception, it may leaves behind the temporary files for attacker to dumpster. Attacker can manipulate the program input to make the program crash or malfunction in situation of Poor or missing exception handling.

24 3) Race Conditions: Race conditions can be characterized as scheduling dependencies between multiple threads that are not properly synchronized, causing an undesirable timing of events. An example of a race condition, which is a security threat, is when an exact sequence of events is required but a race occurs and the proper sequence is not ensured by the software program. An example of a race condition attack is the old UNIX login attack. When a new login process was created, there was a brief moment when the new process was running at root mode and hadn’t yet been switched to normal user mode. If an attacker repetitively presses escape key while logging in, there is a small possibility that the change from root to user could be prevented, allowing complete access to the entire system. This depended on whether the escape key processing occurred before or after the switch to normal user mode. Typical places for race condition attacks involve opening a file, validating a file, running a subprogram, checking a password, or verifying a username. Developers can use a number of programming constructs to control the synchronization of threads, such as semaphores, mutexes, and critical sections. 4) Buffer Overflows: Buffer overflows are a favorite exploit for attackers by remotely injecting malicious code into a target application. Buffer overflow problems root cause is that commonly used programming languages such as C and C++ are inherently insecure. In these languages, no runtime bounds checks on an array and pointer references are done, means that a developer must perform the bounds check in their own code or risk encountering problems. Developer must take care not to store more data in the buffer than its size. Buffer overflow problems often remain invisible during standard testing. The important thing to realize about buffer overflows is that any data that happens to be allocated near the buffer can potentially be modified when the overflow occurs. 5) SQL Injection: SQL injection is currently the main attack used by attacker to take benefit of non validated input. Many applications assume a SQL query as a trusted command in their security model. In this case, the defect lies in the software's construction of a dynamic SQL statement based on user input. Developers often attach together SQL commands with user-provided parameters. Attackers take advantage of the fact and embed SQL commands inside these

25 parameters. As a result, the attacker can execute arbitrary SQL queries and/or commands on the database server through the application. This ability enables attackers to exploit SQL queries to circumvent access controls, authentication, and authorization checks. In some instances, SQL queries may allow access to commands at the level of the host operating system. This can be done using stored procedures. 6) Cross-Site Scripting (XSS): An attack in which an attacker embeds malicious scripts in content that will be served to Web browsers. The goal of the attack is for the target software (i.e., the client-side browser) to execute the script with the user's privilege level [25]. 7) Integer overflow: An attack that forces an integer variable to go out of range, leading to unexpected program behavior and possibly execution of malware by the attacker [26].

2.5 Testing Software testing is a critical function in the software development life cycle Software. It is an important means of assessing the software or service to determine its quality. Testing techniques include the process of executing a program or application with the goal of finding software bugs. It can also be stated as the process of validating and verifying that a software program/application/product meets the business and technical requirements that guided its design and development, so that it works as expected and can be implemented with the same characteristics [27].

2.5.1 Testing Techniques Different testing techniques expose different quality aspects of the software. There are two major categories of testing techniques black box testing and white box testing. Others are Grey Box Testing, Acceptance testing, Regression Testing and Non Functional Software Testing.

· White-box testing: Sometimes called glass-box testing also is a test case design method that uses an internal perspective of the system based on internal structure to design test cases. Using white-box testing methods, the software engineer can derive test cases that (1) guarantee that all independent paths within a module

26 have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity.[16] White box testing method includes API testing (Testing of the application using Public and Private APIs.), Code coverage, Fault injection methods, Mutation testing methods and Static testing.

· Black-box testing: Also known as behavioral testing, focuses on the functional requirements of the software. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure. Black-box testing attempts to find errors in the following categories: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external database access, (4) behavior or performance errors, and (5) initialization and termination errors.[16] Black box testing treats the software as a "black box," without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing.

2.5.2 Why Security bugs not detected Security is considered as non-functional requirement in SDLC process and handled outside Development environment. It is difficult to find Bugs In developed software. For example, Buffer overflow problems which occur during construction phase (if bound checking is not done in code) often remain invisible during standard testing. Lack of awareness about security in most developers, unavailability of Proper approach for secure software development are also big reasons why Security bugs generated and remain Undetected. Applying security from starting stages is more costly approach in maximum software development that’s why companies and customer are not concentrating about security issues and security bugs remain undetected.

27 2.5.3 Security Testing Security testing focus on the testing of applications and the hosted environment for potential security bugs that might be exploited by the hackers. This is one of the most important phases in the secure software development. Security testing goal is to ensure that the software being tested is robust and continues to function in an acceptable way even in existence of malicious attacks. Some important security testing methods are described below:

1) Vulnerability Assessment: The process of vulnerability assessment is to conduct various analysis and tests on a particular system to assess presence of security vulnerabilities. This also relates to assessing the current state of the system that includes configuration and patch status of the system. Patch level and configuration can then be mapped straight to some known vulnerabilities. Vulnerability assessment can be grouped into two categories. These are external vulnerability assessment and internal vulnerability assessments. External vulnerability assessment determines the presence of security vulnerability in the system when used from external environments; some external network, or some untrusted environment, especially from Internet. To do this type of assessment, we need to penetrate into the network and the application from outside. Internal vulnerability assessment is conducted from inside of the corporate network, LAN, or the trusted network. It will include vulnerabilities related to application, database, and operating system of network elements.

2) Negative or Non-operational Testing: Non-operational testing is a method of testing the system in which the testing profile does not correspond closely to the expected operational profile. Software exposure patterns during testing are different from the probabilities that similar functional patterns will be followed during production usage. During non-operational testing, operational profiles are not used to select test cases.

3) Penetration Testing: A penetration test is a method of evaluating the security of a computer system or network by simulating an attack from a malicious source. The process involves an active analysis of the system for any potential vulnerabilities

28 that may result from poor or improper system configuration, known and/or unknown hardware or software flaws, or operational weaknesses in a process or technical countermeasures. This analysis is carried out from the position of a potential attacker, and can involve active exploitation of security vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution. Tools like nessus, nmap, tcpdump can be used for this purpose. The intent of a penetration test is to determine feasibility of an attack and the amount of business impact of a successful exploit, if discovered. It is a component of a full security audit.

4) Ethical Hacking: Ethical hacking is the same process of hacking the system but not for malicious purpose. Ethical hacking requires higher level of skill in comparison to penetration tests. Ethical hacking tests both safety and security issues of a program. Large corporations and financial institutes hire people as ethical hacker who at some point in their life were professional hackers. Ethical hackers will use some of the standard tools as mentioned in penetration tests; but mainly they will write proprietary custom tools that will try to hack the system in true sense to discover vulnerabilities.

5) Fuzz Testing: Fuzz testing is a technique of software testing that provides random data ("fuzz") to the inputs of a program. If the program fails (for example, by crashing, or by failing due to built-in code assertions), the defects can be noted. The advantage of fuzz testing is that the test design is simple, and free of preconceptions about system behavior. Fuzz testing has three characteristics[28]: · The input for fuzz test is random. It does not use any model of program behavior, application type, or system description. This is sometimes called black box testing. · Fuzz test reliability criteria are simple. If the application crashes or hangs, it is considered to fail the test, otherwise it passes. · Fuzz testing can be automated to a high degree and results can be compared across applications, operating systems, and vendors.

29 6) Fault Injection: Fault injection methods attempt to cause the execution of seldom used control pathways within a system or use frequently used section of the code in numerous ways. By doing this either a failure will be observed or the system’s fault tolerance mechanism will handle the error. This technique has been in use for testing the dependability of fault-tolerant computers and safety-critical systems. Similar philosophy can be used to test the security and safety of a program. In this approach, faults are injected similar to an attack scenario into the environment. Faults are introduced by design into the application environment during testing to see how the system responds and whether there will be a security violation under this perturbation, if not then the system is considered secure.

7) Common Criteria: Common Criteria (CC) defines a set of IT requirements of known validity, which can be used in establishing security requirements for prospective products and systems. The CC also defines the Protection Profile (PP) construct, which allows prospective consumers or developers to create standardized sets of security requirements, which will meet their needs. The Target of Evaluation (TOE) is that part of the product or system which is subject to evaluation. The TOE security threats, objectives, requirements, and summary specification of security functions and assurance measures together form the primary inputs to the Security Target (ST), which is used by the evaluators as the basis for evaluation. The principal inputs to evaluation are the security target, the set of evidence about the TOE and the TOE itself. The expected result of the evaluation process is a confirmation that the ST is satisfied for the TOE, with one or more reports documenting the evaluation findings. Once a TOE is in operation vulnerabilities may surface, or environmental assumptions may require revision. Reports may then be made to the developer requiring changes to the TOE. The CC details can be found at http://www.commoncriteriaportal.org

8) EAL: Evaluation Assessment Level has 7 levels starting from EAL1 going up to EAL7. A particular level of EAL is assigned to a system following CC security evaluation. Higher the level means higher level of detailed analysis, testing, and documentation. To meet a particular EAL level criteria, the computer system must

30 meet specific assurance requirements. Most of these requirements involve documentation, design, analysis, functional testing, or penetration testing. Above EAL4 increasing application of specialized security engineering techniques is required. TOEs meeting the requirements of these levels of assurance will have been designed and developed with the intent of meeting those requirements. At the top, EAL7level, there are significant limitations on the practicability of meeting the requirements, partly due to substantial cost impact on the developer and evaluator activities, and also because anything other than the simplest of products is likely to be too complex to submit to current state-of-the-art techniques for formal analysis [8].

31 3. SECURITY-AWARE SOFTWARE DEVELOPMENT LIFE CYCLE (SaSDLC)

This chapter gives a detail description of the problem. Also the proposed approach named as Security-aware Software Development Life Cycle (SaSDLC) [2] is explained with all eight steps. SaSDLC is the backbone of the project work.

3.1 Problem description Researchers have given various kinds of approaches for secure application development, for example, Misuse cases, STRIDE, Attack tree, DREAD, security patterns etc. These approaches themselves are not enough to fulfill all security requirements. A fine combination of these approaches can solve our purpose of secure application development. But, the absence of holistic approach brings confusion and ambiguity in combining different approaches. Further Regarding the available tool support, the present situation is not at all encouraging. Even though the combination of all the approaches is promising for secure application development, hardly any tools support all the approaches. Even tools supporting individual techniques are rarely found. Open source tools are hardly ever available for misuse cases. Misuse cases have a big role in security requirement analysis of an application because they treat security as functional requirement. Even so, there is no fair approach available for security requirement analysis using the misuse case. Absence of holistic approach and lack of open source tools are genuine matters of concern for a software designer.

Development of holistic approach to develop security aware application and an open source tool based on this approach capable of drawing misuse case diagram are the problems which we have focused in this project. How to do security requirement analysis of an application using misuse case is also a main part of our problem.

32 3.2 SaSDLC Process Traditionally a software application is constructed keeping functional requirements in mind. Requirements like security are difficult to define from measurable goal point of view. Therefore, it was always considered as nonfunctional requirement in Software Engineering and Software Development Life Cycle (SDLC).

In order to develop security aware applications Security needs to be embedded into the system from the early stages of Software Development Life Cycle (SDLC) and so it should be treated as part of functional requirement. This is achieved through Security-aware Software Development Life Cycle (SaSDLC) [2]. Misuse case treats security as functional requirement and development of misuse case diagram is one of the major steps in SaSDLC process.

Our approach for SaSDLC

Step 1: Functional Requirement analysis

Step 2: Asset Identification

Step 3: Security Requirements analysis using misuse case modeling using STRIDE/CI5A

Step 4: Threat and Attack tree development

Step 5: Classification and rating of threats using DREAD

Step 6: Decide security countermeasures IN-VIVO Vs IN-VITRO

Step 7: Convert Non-functional to functional requirements

Step 8: Repetition of above steps until all the security patterns included.

Step 1– Functional Requirements: This is the traditional way of elicitation of requirement. In this step, functional requirements of the system are analyzed and captured. During this step, Unified Modeling Language (UML) methodology is used [29]. UML diagrams are used to capture the requirements.

33 Step 2 – Identification of Assets: In this step object diagram is an input. Objects are taken one after the other and the criticality of an object is assessed. When an object is found to be valuable to the organization, it is termed as an asset. A brainstorming session is conducted to list all assets; in addition, various existing documents are examined to identify important assets. Assets are then categorized based on their perceived value and impact in case a security attack happens. Security measures depend on states of mobility -- they are either stationary assets or assets in transit [8].

Figure 3.1: Assets identification for an Application (Suraksha)

To evaluate the value of an asset, an object from the object diagram is taken and viewed from different perspectives i.e. service provider, user, and the attacker. From these perspectives, each asset is assigned a value indicating the importance from STRIDE and CI5A perspective. Threats are also identified with respect of CI5A that deals with Confidentiality, Integrity, Availability, Authentication, Authorization, Accounting, and Anonymity. While assets are being identified following tangible and

34 intangible assets like Identity, Financial, Property & life, Reputation, Privacy & regulatory, Availability guarantees, and Regulatory. Valuations of each asset are added and the asset with highest sum is ranked as the most valuable asset. An example of asset identification by using Suraksha is shown in Figure 3.1.

Step 3 – Security Requirements: For each actor in the Use case, one or more misactors are identified using the Misuse Case diagram. STRIDE and CI5A concepts are applied in connection with each action and assets related to it. This yields a list of possible abstract threats.

Figure 3.2: An example of Attack Tree with DREAD rating

35 Step 4 – Threat and Attack Tree: Each abstract threat in the Misuse case diagram is considered as a root node and corresponding attack tree [30, 31, 32] is constructed to understand what are the AND and OR relationship in the threat path (Figure 3.2). Here the user goes through each and every Misuse case; a node in the attack-tree is an actual threat.

Step 5 – Rating of Risks: For each attack type, DREAD [15, 33] is used to rate a threat. This is done by assigning values to each node beginning from leaf nodes using simple formula,

Risk DREAD = (D+ R + E +A + D) / 5

Where,

D = Damage Potential,

R = Reproducibility,

E = Exploitability,

A = Affected Users,

D = Discoverability.

The calculation always produces a number between 0 and 10; the higher the number, higher the risk.

Step 6 – Decision on In-vivo Security versus In-vitro Security: After careful examination of each threat rating using DREAD, a threat is ranked as a high risk or moderate risk or low risk threat. These ratings are compared with value of assets as measured in Step 2. All high value assets must be secured. If it is too expensive to secure an asset in-vivo, in comparison to the cost of the asset, those threats need not be secured in-vitro – a candidate for in-vitro security could be Denial-of-Service attack.

Step 7 – Nonfunctional to Functional Requirement: All these threats that are decided to be protected in-vivo through countermeasures now become candidate for functional requirement for a Security-aware application. In other words, all these

36 countermeasures that need to be included in-vivo will move into the software as functional requirements.

Step 8 – Iterate: In the last step all misuse cases go through above 7 steps. The security design patterns might force revisit of these 7 steps. Also, there might be necessity for some refinements.

37 4. SECURITY REQUIREMENT ELICITATION

This chapter gives description of the open source tool "Suraksha". Here we have given the process of developing misuse case diagram and misuse case template using Suraksha tool. Also the approach for security requirement analysis of an application using misuse case is explained with an e-commerce application example.

4.1 Suraksha: Open Source Tool We have taken the above philosophy of SaSDLC and developed a tool called Suraksha (http://isea.nitk.ac.in/suraksha/) which helps in Security Requirement Analysis through Security Designers’ workbench [3]. Suraksha offers the Asset evaluation, standard Use-case analysis and to depict it graphically. Suraksha provides a simple and efficient GUI to draw Misuse case diagram. Suraksha also offers GUI for the user to document the textual representation of Misuse cases.

Suraksha provides GUI for attack tree analysis as depicted in Figure 3.2. For each abstract threat mentioned in the Misuse case, detailed information about the threat can be obtained by drawing an attack tree corresponding to the threat. User can draw an attack tree easily using this tool starting with an abstract threat as root node. Various paths possible to achieve the goal (root node) are explored. User can draw all possibilities by creating children to a node and connect these children using the AND or the OR component. The AND component is represented by straight line and the OR component is represented using double line arc. User needs to select the required items from panel and can place the items in required position. To facilitate the designer, there are some standard threat models available in the library and can be used by the user. These threat models help to identify various attacks and their relationship. In the real system, these threats need to be mitigated. Also, the impact of these threats needs to be measured. To measure the impact of each threat, DREAD technique is used by Suraksha.

38 4.1.1 Suraksha: Misuse case diagrams Suraksha provides a simple and efficient GUI to draw Misuse case diagram. User can easily add actor node, misactor node, use case node, misuse case node and can easily draw various relationships between them like extend, mitigate, threaten etc by selecting the suitable item from the panel. Use case and Misuse case are combined to define the system. To co-represent Use cases and Misuse cases together, a Use case is black in white and Misuse case is shown in an inverted format – white in black.

· Suraksha: Misuse case Diagram User Interface

This part gives description about functionality of each item in the Misuse case Diagram user interface. The top bar as shown in the Figure 4.1 consists of UML tools corresponding to the misuse case diagram. By moving mouse over node in the bar we can read the tool tips to see what they do.

Figure 4.1: Misuse case diagram user interface

39 1) Selector: The first tool button (with the four “grabbers”) is the “Select” tool. This button is used for selecting particular item in the window. There are three reasons to do that: · to move a node (by dragging it to the new position) · to delete a node or edge (by hitting DELETE, selecting EditĺDelete from the menu) · to change the properties of a node or edge (by right-clicking or double- clicking on it, or by hitting CTRL+ENTER or by selecting EditĺProperties from the menu).

When we edit the properties of a node or edge, a property popup appears. It lists the properties of the objects in a table. Each property has a name and a value. For example, as shown in Figure 4.2, the Note node has a property whose name is “color” and whose value is a color value. When we edit the value field, the value in the diagram is instantly updated.

Figure 4.2: Property editor for a node in Misuse case diagram window

40 2) Actor: In the Unified Modeling Language (UML), an actor is a coherent set of roles that users of use cases play when interacting with the use cases. Actor is represented graphically as a stick person with white head.

3) Misactor: inverse of an actor that initiates misuse cases either intentionally or inadvertently or an actor that one does not want the system to support. Graphically it is represented as black head stick person.

4) Use case: A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. The use case technique is used to capture the functional requirements of a system. Graphically it represented by ellipse with white foreground on which use case name is written in black.

5) Misuse case: inverse of a use case, a function that the system should not allow. In other words, a misuse case in a system is a description of a system’s false behavior as a response to a request that is organized by a misactor. Representation of the misuse case is an inverted format of the use case –white in black.

6) Note: Making note of the functional requirement or any information, this Note node is used. Information can be inserted using the property window by right click on note node or double-click. Color can be also changed by choosing appropriate color from the property window.

7) Association: An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Actors may be connected to use cases only by association. An association between an actor and a use case indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages. Same way association relationship is used between misactor and misuse case. Graphically it is represented by line between appropriate nodes.

41 8) Extends: It is a dependency relationship. It specifies that the target use/misuse case extends the behavior of the source. Graphically it is represented by an arrow line with label “extends” between the appropriate use case/misuse cases.

9) Include: It is also a dependency relationship. It specifies that the source use/misuse case explicitly incorporates the behavior of another use/misuse case at a location specified by the source. It is also represented by an arrow line with label “include” between the appropriate use case/misuse cases.

10) Threaten: The “threaten” relationship between a misuse case and use case originates from the misuse case targets a use case that a misuse case wants to harm. Graphical representation same as include relationship with a label “threaten”.

11) Mitigate: The “mitigates” relationship originates from a use case to misuse case characterizes how security use case is defined as a countermeasure against the misuse case. Graphical representation same as include relationship with a label “mitigate”.

12) Generalization: A generalization is a relationship between a general thing (called the superclass or parent) and a more specific kind of that thing (called the subclass or child). With a generalization relationship from the child to the parent, the child will inherit all the structure and behavior of the parent. The child may even add new structure and behavior, or it may modify the behavior of the parent. Generalization relationship can be used between actor, misactor, use case or misuse case.

13) Note connector: It is used to connect note node with the related node whose information is given in the note.

42 · Drawing a new Misuse case diagram using Suraksha

First open a new misuse case window with File ĺ Designer’s workbench ĺ Misuse Case ĺ Misuse Case Diagram as shown in Figure 4.3.

F i g u r e

7

P r o c Figure 4.3: Process to open a Misuse case diagram window

Misuse case diagram is composed of nodes (actor, misactor, use case etc.) and edges (extend, mitigate etc.). To add a node, first click on the matching UML tool on the top bar, then click anywhere on the diagram to add it. To connect two nodes with an edge, first select an edge tool. Then click on the first node and hold down the left mouse button. Drag the mouse to the appropriate second node and release the mouse button. The edge is inserted between the two nodes. There is one exception: we can insert a “note connector” edge simply by dragging from a “note” node to anywhere on the diagram. An example of misuse case diagram for an e-commerce application drawn using Suraksha Misuse Case Diagram is given in Figure 4.4.

43 Figure 4.4: Misuse case diagram for e-commerce application using Suraksha

When we have done with the misuse case diagram, we can save it with the "FileĺSave", "FileĺSave as" menu option or even by hitting CTRL+S. We can give it any suitable name. The information about the diagram will be stored in specified path with “.swb” extension. We can also export the diagram to PNG or JPEG format with the "FileĺExport Image" menu. Misuse case diagram can also be printed with the "FileĺPrint" menu.

4.1.2 Suraksha: Misuse case Template Suraksha offers user friendly GUI for the user to document the textual representation of misuse cases. Sindre and Opdahl focused on templates for misuse cases in [9]. Suraksha uses the misuse case template suggested by them. Misuse case template is a suggestion for fields that a misuse case description should contain in its finished state. The various fields used in misuse case template description are explained below.

· Name: Name for the misuse case to uniquely identify it.

44 · Summary: Description of the misuse case in one or two sentences. · Author: Author name. · Date: Date when the textual description is written by the author. · Basic path: This field describes the steps that the misuser, use to achieve the goal. This is the most common path followed by the misuser. · Alternative paths: Ways other than basic path to harm the system. · Mitigation points: This field identifies actions at particular steps in a basic or alternative path to prevent and/or detect misuse. There are many possible paths to mitigate misuse. These paths can be described here step by step and each of them may be further described in a separate security use case. As for extension points, the misuse case must eventually have a mitigate relationship to a corresponding security use case. · Extension points: In some cases, a misuse case may be extended with optional paths whose details are described in a separate extension misuse case. This field lists the actions in the main or alternative paths where optional paths may be inserted. The misuse case must have an extend relationship to the misuse case that contains the optional path. · Trigger: Trigger is the condition that initiates the misuse case. For some misuse cases, the trigger is just the predicate true, indicating a permanently present danger. · Assumptions: This field describes the states in the system’s environment that make the misuse case possible. · Preconditions: This field describes the system states that make the misuse case possible. · Mitigation guarantee: This field describes the guaranteed outcome of mitigating a misuse case. If the mitigation points are not yet specified in detail, the mitigation guarantee describes the level of security required from the mitigating security use cases that will be designed later. When the mitigation points in the misuse case have been detailed by security use cases, this field describes the strongest possible security guarantee that can be made, regardless of how the misuse case is mitigated.

45 · Related business rules: This field describes what business rules will be broken by the misuse. Also we have to find out situations where business rules are too weak to initiate misuse. · Potential misuser profile: This field describes about the misuser behavior, role, technical skills etc., for example, some misuse may occur accidentally other are most likely to be performed by intent. Misuser may be an organization person or an outsider and technically skills required for misuse etc. · Stakeholders and threats: This field specifies the major threats for each stakeholder involved in the misuse case. On an abstract level, threats could simply be described textually, e.g., ‘‘the system is unavailable for several hours’’. · Scope: This field indicates whether the proposed system in a misuse case is, e.g., an entire business, a system of both users and computers, or just a software system. · Level: As for regular use cases, misuse cases can be specified at a general or specific abstraction level. This field indicates whether the misuse case is, e.g., a summary, a user goal, or a sub-function.

Misuse case diagram for an e-commerce application is shown in Figure 4.4. Tampering with database is one of the misuse case in this application. To develop textual representation for this, developer should follow the process given below:

· In Suraksha tool first open a new misuse case template window with File ĺ Designer’s workbench ĺ Misuse Case ĺ Misuse case template. · Enter corresponding information against each field in the provided text boxes. This process is a brainstorming session. Developer has to think with respect to each field to fill required information. For example, in Basic path field developer has to describe the most common steps that the misuser use to achieve the goal. In our example misuser goal is to change or delete or reveal

46 Figure 4.5: Textual representation of misuse case: Tamper with database (part1) the database information related to “register account” action (with this action customer register for e-commerce application by giving name, address, phone, email etc.). Attacker can use following path: 1) Attacker supplies some values on a register account form and submits. 2) Attacker alters the submitted URL, introducing a query error, and resubmits. 3) The query fails and the system displays the database error message to the attacker, revealing more about the database structure.

47 Figure 4.6: Textual representation of misuse case: Tamper with database (part2)

4) Attacker alters the query further, for instance, adding a nested query to reveal secret data or update or delete data related to “register account”, and submits. 5) The system executes the altered query, changing the database or revealing content that should have been secret.

The textual representation of the Misuse case “Tamper with database” with all fields is shown in Figure 4.5 & Figure 4.6.

· After completion of giving all the necessary information, developer can save the textual representation using “save” button for future use.

48 4.2 Misuse case and security requirement analysis Misuse case diagram play an important role in security requirement analysis of an application. To do security requirement analysis first we have to identify functional requirements and critical assets (using asset identification process) of the application. In next step use case diagram specifying the functional requirements of the system is developed. For each actor in the use case, one or more misactors are identified; STRIDE and CI5A concepts are applied in connection with each action and assets related to it. Through STRIDE, the possibilities for Spoofing Identity, Tampering with Data, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege are considered; and, through CI5A, Confidentiality, Integrity, Availability, Authentication, Authorization, Accounting, and Anonymity in the given case by misactor are explored.

Figure 4.7: Misuse case diagram for e-commerce application analyzed using STRIDE

49 To understand the concept, we have taken e-commerce application example as shown in Figure 4.7. Register account is one of the actions (use case) that are performed by the customer (Actor). The purpose of “Register account” is customer registration for the e-commerce application to enable him to order goods. Customer register himself by providing information like name, address, email, phone no. etc. Here misactor goal may be to prohibit the customer to use this action. Misactor may also try to modify/delete/steal assets (name, address, email, etc.) related to this action. Both activities make a threat to the use case.

To apply STRIDE misactor will analyze the each possibility one by one. First he will think about threats under Spoofing Identity then Tampering with Data and so on. For “Register account” spoofing Identity is one possible threat. Attacker can use some another person identity and register himself. Then attacker can order goods on behalf of that person. In this case tampering with database (under Tampering with Data) is one more possible threat. Tampering with database allow misactor to change/delete/reveal assets related to register account and thus a threat to use case. The textual description of this misuse case in Figure 4.5 and Figure 4.6 gives a clear picture to developer, how the attack can be performed. Flood system is also another possibility under Denial of service category that prevent legitimate customer from accessing internet service including register account.

STRIDE provides a high level classification of threat. This classification makes it simpler to understand what that threat allows an attacker to do and help assigning priority to a threat. Threat often fits to multiple category of STRIDE. For example, some threats are purely tampering nature; others might enable tampering but result in elevation of privilege. Developer needs to understand the underlying effect (root effect) a threat has on the system when classifying threat using STRIDE Model.

Confidentiality, Integrity, Availability, Authentication, Authorization, Accounting, and Anonymity (CI5A) are main security objectives. To apply CI5A misuser will think in perspective of each security objective for use case and assets related to that. He will try to find out possible misuse cases to target the security objective and in this way he can get threats to use case and related assets. There may

50 be some common threats between threats find out through STRIDE and CI5A. For example “flood system” which is under DOS category in STRIDE is also a threat to Availability. We are using STRIDE and CI5A so that the misuser is focused to a particular category of threats or security objective and thus make the process of identifying threats simpler.

After applying STRIDE and CI5A we get a list of possible abstract threats. Each abstract threat now becomes root of an attack tree and attack tree is developed. For each attack tree DREAD is used to rate the threat. All the threats that filter through the DREAD rating are considered as functional requirement of the security aware application. In other words, all countermeasures that need to be included in- vivo will move into the application as functional requirement.

51 5. CONCLUSION

This project work focuses on usage of the misuse case for security requirement analysis of an application along with a tool to facilitate such activity. We proposed a holistic approach known as Security-aware Software Development life Cycle (SaSDLC) to develop security aware application. Based on the SaSDLC philosophy we have developed an open source tool named “Suraksha”. Suraksha provides a simple and efficient Graphical User Interface (GUI) to draw misuse case diagram. Suraksha also offers user friendly GUI for the developer to document the textual representation of the misuse case. This tool allows a security professional to do security requirement analysis of an application using misuse case in an organized way. Our approach for security requirement analysis usage STRIDE and CI5A concept. Using this approach security professional can easily figure out security threats to the application. As an example we analyzed a part of e-commerce application using this tool.

52 REFERENCE

[1] P. Naur and B. Randell, (Eds.) (1969). “Software Engineering: Report of NATO Software Engineering Conference 1968.” Scientific Affairs Division, NATO, Brussels, Belgium.

[2] Asoke K Talukder, et al. (2009). “Security-aware Software Development Life Cycle (SaSDLC) - Processes and Tools.” Proc., IFIP International Conference on Wireless and Optical Communications Networks, WOCN '09, Cairo, Egypt.

[3] Santhosh Babu G, et al. (2009). “Suraksha: A Security Designers' Workbench.” Proc., Hack.in 2009, IIT Kanpur, 59-66.

[4] Ivar Jacobson, et al. (1992). “Object-Oriented Software Engineering: A Use Ca-se Driven Approach.” Addison-Wesley.

[5] A. Cockburn (2001). “Writing effective use cases.” Addison-Wesley.

[6] C. P. Pfleeger (1997). “Security in Computing.” Prentice-Hall.

[7] Guttorm Sindre and Andreas L Opdahl (2001) “Capturing Security Requiremen-ts by Misuse Cases.” Proc., 14th Norwegian Informatics Conference (NIK'2001), Troms, Norway.

[8] Asoke K Talukder and Manish Chaitanya (2008). “Architecting Secure Software Sys-tems.” Auerbach Publications.

[9] G. Sindre and A.L. Opdahl (2000). “Eliciting Security Requirements by Misuse Cases,” Proc., 37th Conf. Techniques of Object-Oriented Languages and Systems, TOOLS Pacific 2000, 120–131.

[10] Guttorm Sindre, et al. (2002). "Generalization/specialization as a structuring mechanism for misuse cases.” Proc., 2nd Symposium on Requirements Engineering for Information Security.

[11] Guttorm Sindre and Andreas L. Opdahl (2001). “Templates for Misuse Case Description,” Proc., 7 th International Workshop on Requirements

53 Engineering, Foundation for Software Quality (REFSQ'2001), Interlaken, Switzerland.

[12] Ian Alexander (2002). “Initial Industrial Experience of Misuse Cases in Trade- Off Analysis” Proc., IEEE Joint International Conference on Requirements Engineering (RE’02), 61-68.

[13] Shawn Hernan, et al. (2006). “Uncover Security Design Flaws using The STRIDE Approach” http://msdn.microsoft.com/enus/magazine/cc163519.aspx (March 21, 2009).

[14] “The STRIDE Threat Model.” http://msdn.microsoft.com/en- us/library/ms954176.aspx (March 21, 2009).

[15] F. Swiderski and W. Snyder (2004) “Threat Modeling.” Microsoft Press.

[16] Roger S. Pressman (2001) “Software Engineering: A practitioner’s approach.” fifth edition, McGraw-Hill Companies.

[17] Boehm B. (1988). “A Spiral Model for Software Development and Enhancement.” Computer, vol. 21, no. 5, 61–72.

[18] “Agile software development.” http://en.wikipedia.org/wiki/Agile_software_development (June 8, 2009).

[19] Robert G. Cooper (1988). “The Journal of Marketing Management”, Spring 1988.

[20] Erich Gamma, et al. (1995) “Design Patterns: Elements of Reusable Oject- Oriented Software” Addison-Wesley Professional Computing Series.

[21] Joseph W. Yoder and Jeffrey Barcalow (1997). “Architectural Patterns for Enabling Application Security,” Proc., 4th Conference on Patterns Languages of Programs (PLoP '97) Monticello, Illinois.

[22] “Procedural programming”. http://en.wikipedia.org/wiki/Procedural_programming (June 9, 2009).

[23] Steve McConnell (2004). “Code Complete: A Practical Handbook of Software Construction.” second edition, Microsoft press.

54 [24] Julia H. Allen, et al. (2008). “[Software Security Engineering: A Guide for Project Managers.” Addison Wesley Professional.

[25] “Simple Script Injection.” http://capec.mitre.org/data/definitions/63.html (June 10, 2009).

[26] “Forced Integer overflow.” http://capec.mitre.org/data/definitions/92.html (June 10, 2009).

[27] “Software testing.” http://en.wikipedia.org/wiki/Software_testing (June 10, 2009).

[28] “Fuzz Testing of Application Reliability.” http://pages.cs.wisc.edu/~bart/fuzz/ (June 8, 2009).

[29] Rumbaugh J, et al. (1999). “The Unified Modeling Language Reference Manual.” Addison Wesley.

[30] Bruce Schneir (1999). “Modeling Security Threats.” http://www.schneier.com/paper-attacktrees-ddj-ft.html (Feb. 17, 2009).

[31] Fredrik Moberg (2000). "Security Analysis of an Information System using an Attack tree-based Methodology.” Master’s Thesis, Chalmers University of Technology, Goteborg, Sweden.

[32] Mamadou H. Diallo, et al. (2006). “A Comparative Evaluation of Three Approaches to Specifying Security Requirements.” Proc., 12th Working Conference on Requirements Engineering: Foundation for Software Quality, Luxembourg.

[33] J.D. Meier, et al. (2003). “Improving Web Application Security: Threats and Countermeasures,” http://msdn.microsoft.com/en-us/library/ms994921.aspx (June 5, 2009).

55 BIO-DATA

Contact Address: H.No. 157, Ramchandrapura, Chhawani, Kota, Rajasthan. Pin – 324007 E-mail Address: [email protected] Qualification: M.Tech. (Computer Science & Engineering – Information Security)

My Publications

[1] Santhosh Babu G, et al. (2009). “Suraksha: A Security Designers' Workbench.” Proc., Hack.in 2009, IIT Kanpur, 59-66.

[2] Asoke K Talukder, et al. (2009). “Security-aware Software Development Life Cycle (SaSDLC) - Processes and Tools.” Proc., IFIP International Conference on Wireless and Optical Communications Networks, WOCN '09, Cairo, Egypt.

[3] Asoke K Talukder, et al. (2009). “Managing Non-functional Requirements of Scalability and Security in the Grid/Cloud.” communicated to HiPC 2009, International conference on High Performance Computing, Kochi, India.

56