THREAT MODELING AND ITS
USAGE IN MITIGATING SECURITY
THREATS IN AN APPLICATION
Thesis
Submitted in partial fulfillment of the requirements for the degree of

MASTER OF TECHNOLOGY in
COMPUTER SCIENCE & ENGINEERING - INFORMATION
SECURITY
by

EBENEZER JANGAM
(07IS02F)

DEPARTMENT OF COMPUTER ENGINEERING
NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA
SURATHKAL, MANGALORE-575025
JULY, 2009

Dedicated
To
My Family, Brothers
&
Suraksha Group Members

DECLARATION

I hereby declare that the Report of the P.G Project Work entitled "THREAT
MODELING AND ITS USAGE IN MITIGATING SECURITY THREATS IN
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: ............................

CERTIFICATE

This is to certify that the P.G Project Work Report entitled " THREAT
MODELING AND ITS USAGE IN MITIGATING SECURITY THREATS IN
AN APPLICATION" submitted by Ebenezer Jangam (Register Number:07IS02F), 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 would like to thank ALMIGHTY GOD for granting me the required grace to complete the project and the course.
I would like to express my sincere gratitude to my guide and coordinator Mr. Alwyn
Roshan Pais, Sr. Lecturer, Department of Computer Engineering, National Institute of Technology Karnataka, Surathkal for his constant encouragement, motivation, help, support and insightful advices throughout the course.
I would like to express my gratefulness to my guide Dr. Asoke K. Talukder,
Visiting faculty, Department of Computer Engineering, NITK, Surathkal for his insightful advice and invaluable guidance without which it would be extremely difficult to successfully complete this project.
I would like to take this opportunity to thank Mr. Vinay Kumar, Head of the
Department, Department of Computer Engineering, NITK, Surathkal for his constant support throughout the course.
I would like to thank Department of Information Technology, Government of
India for offering Information Security course in MTech and for providing all the required facilities under ISEA Project.
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 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
In this insecure world, building a secure application is not feasible until and unless we understand all the potential threats against it. Threat modeling is a technique that can be used to identify, explain and record all threats from every possible source which could attack the system. Threat Modeling is a method which can help in identifying both strengths and weaknesses of a system and can serve as a basis for investigating potential threats and vulnerabilities so that secure system development will be possible. This thesis focuses on mitigation of security threats using threat modeling using a hybrid approach. An open source tool to support various techniques for threat modeling is also introduced.

Key Words: Threat modeling, Threat mitigation, Open Source, Software
Development Lifecycle (SDLC), Threat tree, DREAD

CONTENTS
1. INTRODUCTION.................................................................................................. 1
1.1 Introduction ..................................................................................................... 1
1.2 Threat modeling .............................................................................................. 3
1.3 Threat classification ........................................................................................ 4
1.4 Misuse cases enhance threat modeling............................................................ 4
1.5 DREAD ........................................................................................................... 6
1.6 UML and DFD ................................................................................................ 7
1.7 Organization of the 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................................................................................................ 11
2.1.4 Agile Model ................................................................................................ 12
2.1.5 Scrum .......................................................................................................... 13
2.1.6 Extreme Programming (XP) ....................................................................... 13
2.1.7 Stage-Gate Model ....................................................................................... 14

2.2 Requirements ................................................................................................ 16
2.2.1 Functional Requirements ............................................................................ 16
2.2.2 Nonfunctional Requirements....................................................................... 16
2.2.3 UML Model for Requirement Elicitation ..................................................... 17

2.3 Design ........................................................................................................... 19
2.3.1 Design Patterns ........................................................................................... 19
2.3.2 Security Design Patterns ............................................................................. 21

2.4 Construction ................................................................................................. 21
2.4.1 Various Techniques & Languages for Construction ................................... 22
2.4.2 Security Bugs in Construction Phase .......................................................... 25

2.5 Testing .......................................................................................................... 28
2.5.1 Testing Techniques ..................................................................................... 28
2.5.2 Why Security Bugs not Detected ................................................................ 29

2.5.3 Security Testing .......................................................................................... 29

2.6 Threat modeling and SDLC ......................................................................... 33
3. PROBLEM STATEMENT ................................................................................. 34
4. THREAT MODELING PROCESS: A HYBRID APPROACH ...................... 35
4.1 Introduction ................................................................................................... 35
4.2 Benefits of Threat Modeling ......................................................................... 36
4.3 Outline of the Process ................................................................................... 36
4.4 Functional Requirements & Security Policy ................................................. 37
4.5 Asset Identification & Prioritization ............................................................. 39
4.6 Threat Identification ...................................................................................... 40
4.7 Threat Rating &Prioritization........................................................................ 44
4.8 Threat Mitigation........................................................................................... 45
5. MITIGATION OF SECURITY THREATS ..................................................... 46
5.1 Introduction ................................................................................................... 46
5.2 Threat rating and prioritization ..................................................................... 47
5.3 Threat mitigation process .............................................................................. 51
5.4 Threat mitigation strategies ........................................................................... 52
5.5 Security Design patterns ............................................................................... 54
5.6 Penetration Testing ........................................................................................ 56
5.7 Targeted Code Review .................................................................................. 57
6. SURAKSHA : OPEN SOURCE TOOL SUPPORT ......................................... 58
7. CONCLUSION AND FUTURE WORK ........................................................... 64
REFERENCES

NOMENCLATURE/ACRONYMS
Notation Description
SDLC

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

CHAPTER 1

INTRODUCTION

1.1 INTRODUCTION
On 2 November 1988, an internet worm capable of exploiting vulnerabilities in the
UNIX operating system was released by a 22-year old Cornell university student by name
Robert Morris. In those days, people relied on network security to prevent attacks. Their opinion was that if a firewall with a sophisticated application proxy is installed, it is suffice to protect the whole network. Unfortunately the worm launched at that time exploited a buffer overrun. It is estimated that it infected 10 percent of the internet. With the outbreak of this attack and the various attacks over the years, it became evident that conventional firewalls and proxies are incapable of addressing the security vulnerability present in the application.
Twenty years on, the scale of the malware problem has grown enormously with the growth of Internet and telecommunication and it became the most disconcerting problem.
Today’s internet attacks are organized and designed to steal information and resources from consumers and corporations. As a result, valuable assets of the consumers and corporations are no longer secure. Now, the web became the primary means for the cybercriminals to infect computers, because many organizations have already secured their email gateways. As a consequence, cybercriminals are planting malicious code on innocent websites. This code is capable of infecting all the visiting computers. Hence it is apparent that this crisis can be addressed only by developing a secure application so that the cybercriminal can no longer plant a malicious code. Hence, security of the application needs to be focused right from the beginning of the software development lifecycle
(SDLC).

1

Once upon a time, delegates of the NATO Science Committee Conference organized in 1968 October, were concerned about software crisis at that time (Naur and
Randell 1969). But the crisis was addressed through various Software Engineering techniques proposed in the last forty years .But now we are experiencing Software
Security Crisis with the revolution in the field of Internet and Telecommunication. This crisis is due to the fact that security is considered as non functional requirement and hence focused at the end of design phase or in the implementation phase. Much later, security threats might be discovered or actually faced, and expensive additional protections and measures might be added. These would be relatively expensive, because of the design constraints and the limited options available at this stage. Also, these protections may not seamlessly and effectively integrate into the system, and maintenance of these systems would become difficult after several such upgrades. In order to avert the crisis, it is strongly recommended to make security as a functional requirement. As a functional requirement, security needs to be addressed from the very beginning of the software development lifecycle.
Even if we consider the Next Generation Internet (NGI), all applications are networked; and, these applications are accessible by everybody – legitimate users and hackers alike. NGI applications will be even mobile; therefore, an application needs to be security aware so that it can protect itself from security threats. Again this demands the development of secure application (Asoke K Talukder et al. 2009).
From all the views presented above, it is clear that the problem can be addressed through Secure Software Development Lifecycle (SSDLC). A vital part of this Lifecycle is Threat Modeling. Threat modeling is a process that helps us to identify, analyze, document, and possibly rate system’s vulnerabilities. Threat modeling allows system designers to prioritize and implement countermeasures to security threats in a logical order based on risk. This demands understanding of the system’s assets, architecture, protocols, and implementation

2

Developing software is most of the time a race against the clock, where people involved in this process struggle most likely with the implementation of the requirements rather than solving security issues. Threat modeling saw day light as a way of providing a structure to the design phase by using threat models for the application. It’s a way to help out developers in order to put their attention towards different security threats their application is facing. Threat models also give the team a better understanding of the application and they could help to discover bugs. It’s a pro-active security based analysis of an application and is crucial part of design process (Michael and Leblanc 2003).
After a diligent review of literature, some of the important issues are presented in the following sections.

1.2 MISUSE CASES ENHANCE THREAT MODELING
Threat Modeling became prevalent with the efforts of Microsoft [6, 7].They proposed various techniques, processes and tools in support of threat modeling. Key aspect in threat modeling is looking at the system from the perspective of an attacker. It is highly recommended by many researchers to focus on security from the early stages of software development cycle (Takao Okubo and Hidehiko 2008). The same is true with threat modeling. In the requirement analysis phase itself it is recommended to focus on security.
The approach which is very useful to document the view of an attacker in requirement analysis phase is misuse case or abuse case approach. It would be profitable to use misuse cases to capture the abstract threats in requirement analysis phase itself. An important conclusion is usage of misuse cases in requirement analysis phase enhances threat modeling by giving more insight in to the list of possible threats. Threat modeling can be enhanced using misuse cases. Threat modeling is done more from the architecture level whereas misuse case modeling is more granular and is associated with individual functionalities depicted by use cases. This helps developers to focus on writing secure code and testers on testing individual functionalities for vulnerabilities.
Security use cases (Donald Firesmith 2003) can be used to specify requirements that the system shall successfully protect itself from its relevant security threats while misuse cases are suitable for analyzing and specifying security threats.
3

1.3 APPROACHES FOR THREAT MODELING
Next concept to explore is alternative threat modeling approaches. There are at least three general approaches to threat modeling:
Attacker-Centric
Attacker-centric threat modeling starts with an attacker, and evaluates their goals, and how they might achieve them. Attacker's motivations are often considered and given importance than any other factor. This approach usually starts from either entry points or assets. Software-Centric
Software-centric threat modeling is also called as 'system-centric' or '’design-centric’ or
'architecture-centric' .It starts from the design of the system, and attempts to step through a model of the system, looking for types of attacks against each element of the model.
This approach is used in threat modeling in Microsoft's Security Development Lifecycle
(SDL).
Asset-Centric
Asset-centric threat modeling involves starting from assets entrusted to a system, such as a collection of sensitive personal information. There are various kinds of assets and these assets are crucial in this approach.
However, it is recommended to use combination of these strategies to perform an effective threat modeling.

1.4 UML AND DFD
1.4.1 UML
Various diagrams of UML are explored from the perspective of security and threat modeling and some of the important inferences are:
• Class diagram describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. This is very useful to identify the assets.
• Object diagram shows a complete or partial view of the structure of a modeled system at a specific time. This is crucial to identify assets in a system.
4

• State machine diagram standardized notation to describe many systems, from computer programs to business processes.
• Activity diagram represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
In other words activity diagram is capable of presenting both data flow and control flow in one diagram. This characteristic feature is useful to get entry points and trust boundaries by concentrating on data flow.
• 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. Researchers proposed new techniques for threat model driven threat modeling using sequence diagram (Linzhang Wang 2007).
• Collaboration diagram models the objects and links that are meaningful within an interaction – it shows the roles in the interaction. A classifier role describes an object and an association role describes a role link within collaboration. Assets can be identified.
• Component diagram depicts how the software system is split up into components and shows the dependencies among these components. Threats to each component when taken individually can be listed by using this diagram.
• Deployment diagram serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware. Overall threats to the system from the architectural point of view can be easily determined using this diagram.
Different diagrams are useful for different purposes. Activity diagrams, Sequence diagrams, Collaboration diagrams, and Component diagrams are examined and reviewed to ensure separation of concerns. Following the identification of assets, the Collaboration and Deployment Diagrams are designed. Here it is decided how the system is going to be deployed – it is going to be one single system deployed on a Cluster, Grid, or Cloud.

5

1.4.2 DFD
The DFDs will allow us to gain a better understanding of the application by providing a visual representation of how the application processes data. The focus of the DFDs is on how data moves through the application and what happens to the data as it moves. DFDs are hierarchical in structure, so they can be used to decompose the application into subsystems and lower-level subsystems. The high level DFD will allow us to clarify the scope of the application being modeled. The lower level iterations will allow us to focus on the specific processes involved when processing specific data.
Researchers proposed techniques to represent a DFD in UML [Zrnec et al. 2000 )
.DFD is related to structured programming whereas UML is object oriented. Most of the threat modeling approaches uses DFD whereas some techniques for using different UML diagrams in threat modeling are also proposed.

1.5 DREAD
The DREAD methodology is another tool proposed by Microsoft (OWASP 2001) to determine possible threats and its impact. This acronym is also formed from the first letter of each category.
DREAD modeling not only tries to identify a threat, but it also influences the thinking behind setting the risk rating, and is also used directly to mitigate the risks (Asoke K Talukder and
Manish Chaitanya 2008). Security comes with a cost; the cost is in terms of cash, programming resource, time, and inconvenience to users. Therefore, based on this rating it can be decided whether we would like to implement this security feature or let it pass. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.
Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS
+ DISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk. Here are some examples of how to quantify the DREAD categories.
Damage Potential: If a threat exploit occurs in reality, how much damage will it cause?
•

0 = Nothing

•

5 = Individual user data is compromised or affected.

•

10 = Complete system or data destruction
6

Reproducibility: How easy is it to reproduce the threat exploit?
•

0 = Very hard or impossible, even for administrators of the application.

•

5 = One or two steps required, may need to be an authorized user.

•

10 = Just a web browser and the address bar is sufficient, without authentication.

Exploitability: What tool is needed to exploit this threat?
•

0 = Advanced programming and networking knowledge, with custom or advanced attack tools. •

5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools. •

10 = Just a web browser

Affected Users: How many users will be affected?
•

0 = None

•

5 = Some users, but not all

•

10 = All users

Discoverability: How easy is it to discover this threat?
•

0 = Very hard to impossible; requires source code or administrative access.

•

5 = Can figure it out by guessing or by monitoring network traces.

•

9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.

•

10 = The information is visible in the web browser address bar or in a form.

When performing a security review of an existing application, by normal convention
“Discoverability” is set to 10; because, it is assumed that threat issues will always be discovered.

1.6 AVAILABLE OPEN SOURCE TOOL SUPPORT
Regarding the available tool support, the present situation is not at all encouraging.
Misuse cases modeling tool is not available and a few tools only support attack tree.
Open source tools are hardly ever available for attack trees and misuse cases (Santhosh
Babu G et al. 2009).

7

1.7 ORGANIZATION OF THE THESIS
An important feature related to threat modeling is that it allows system designers to prioritize and implement countermeasures to security threats in a logical order based on risk. This step is very crucial because the success of the whole threat modeling process depends on a few decisions that were made at this point. Certain decisions like whether neglect or consider the threat, whether mitigate or eliminate the threat etc will have a great impact. That is why taking right decision based on various factors like cost, corporate policy, and current situation is a key for threat modeling to be successful.
Hence in this thesis, the main focus is upon threat modeling and the mitigation of security threats using threat modeling. Besides giving the process of threat modeling, the issues pertaining to the alleviation of security threats using threat modeling are well addressed. Moreover, an open source tool which supports various techniques useful for threat modeling is also introduced.
The organization of the thesis is as follows. Chapter two gives an outline of Security
Development Lifecycle (SDLC) and its relation with threat modeling. Next chapter consists of problem statement which is presented after a diligent survey. Chapter four presents the threat modeling process in clear. This is followed by chapter five in which a clear picture of threat mitigation using threat modeling is presented. Chapter six introduces an open source tool for research community which supports various techniques for threat modeling. Seventh chapter concludes the thesis by giving a future scope. 8

CHAPTER 2

SOFTWARE DEVELOPMENT LIFE CYCLE

2.1 INTRODUCTION
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.2 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:

9

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.
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) (Roger 2001) 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

10

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 (Boehm B 1988), 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 (Roger 2001) with six task regions:
•

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.

11

Figure 2.2: A typical spiral model
2.1.4 Agile Model
Agile software development (Agile 2009) 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 methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, selforganization 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

12

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.

•

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.

13

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 (Robert G 1988) 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.

14

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.

15

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.”(Donald
Firesmith 2003)
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

16

requirement, designers do not think about it during the design and construction process of the system. Security therefore, always remains as an afterthought.
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.

17

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.
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

18

what pieces of hardware. They are very useful in showing what is deployed where, so any nontrivial deployment can make good use of them.

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 (Erich Gamma 1995).
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.

19

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.
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. (Erich Gamma 1995)
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. (Erich Gamma
1995)
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
20

provide 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 difficult and sometime impossible to define what a system is not supposed to do. Yoder and Barceló (Joseph and Jeffrey 1995) proposed seven security design patterns for information security that were extended to ten (Donald Firesmith 2003). 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
21

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.
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

22

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.(Procedural programming wikipedia 2009)
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 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 lowerlevel languages. Below is a short description of the most common languages in use today
(Steve McConnell 2004).
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

23

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 BusinessOriented Language.
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

24

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 Allpurpose 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 (Julia H. Allen 2008) 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

25

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.
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.

26

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 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 (Simple Script Injection 2009).
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
(Forced Integer overflow 2009).

27

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 (Software testing wikipedia 2009).
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 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.(Roger 2001)
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)
28

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.(Roger 2001)
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.
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
29

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 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

30

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(Fuzz testing 2008):
•

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.

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,
31

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 particular EAL level criteria, the computer system must 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
32

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 (Donald Firesmith 2003).

2.6 SDLC AND THREAT MODELING
Next aspect is to find the right place for Threat Modeling in SDLC. Although it is logical to place either in requirements analysis or design phase, it is preferable to place it in design phase.

Figure 2.4 Threat modeling in SDLC
This is due to the fact that the architectural design can be obtained only in design phase.
But by the time design phase begins, threat modeling already began informally because we are using misuse cases in requirement analysis phase itself to identify various threats.

33

The figure taken from (Takao Okubo and Hidehiko 2008) gives a clear picture about the right place for threat modeling in SDLC.

34

CHAPTER 3

PROBLEM STATEMENT
From the review of literature, it is evident that the misuse cases enhance the threat modeling. Some researchers have proposed methods to use misuse cases for threat modeling (Damodaran 2006). This kind of threat models cannot capture certain kinds of threats related to the deployment of the application. Also the process is cumbersome to apply. In this thesis a hybrid approach for the process of threat modeling is explained.
Second issue to be addressed is that although many researchers focused on the process of threat modeling, much focus was not laid upon the mitigation of threats using threat modeling. Hence the focus of this thesis is more on this concept.
Finally, there is lack of open source tool support for the techniques that support threat modeling. In order to address this shortcoming, an open source tool is needed for research community. 35

CHAPTER 4

PROCESS OF THREAT MODELING:

A HYBRID APPROACH

4.1. INTRODUCTION
Even though the main objective of threat modeling remains the same, there is a huge variance in the process of threat modeling. Some researchers divided the whole process into five steps whereas some divided it into seven steps and there are no standards regarding this issue. Moreover, diverse approaches can be used for threat modeling.
These approaches are already introduced in chapter 1. Although various approaches like asset-centric, attacker-centric and software-centric were proposed, the Microsoft threat modeling approach is prevalent.
Attacker-Centric threat modeling focuses on the identification of all possible access points to the system and the possible adversary aims. A threat analyst employing ThreatCentric or system-centric approach focuses on capturing system design and deployment flaws which can translate into vulnerabilities. Asset-centric approach focuses on assets and their security. Good threat visualization (representation) must capture both system specific attributes and attacker time specific details (Drake and Maybin 2008) .Hence a good threat modeling process should be the combination of these approaches. Hybrid approach is combination of two or more approaches or strategies. This chapter presents a process for threat modeling based on hybrid approach which makes use of misuse cases for the enhancement of threat modeling.
The organization of the chapter is as follows. After presenting the benefits of threat modeling, the process of threat modeling is briefly described. Each step in the process is further explained in the subsequent sections.
36

4.2. BENEFITS OF THREAT MODELING
Threat modeling provides different benefits to the project stakeholders depending on their role and responsibility. The people who are benefited from the threat modeling are:
•

Architects

•

Developers

•

Security Testers

•

Project Managers

•

Business Managers

•

Information Risk Officers

The outcome of threat modeling proved to be very useful in following ways.
•

The threat modeling outcome will be the basis for design decisions and documents. •

It will be used in the implementation phase .It is recommended for the programmer to read the document before writing code.

•

Using threat modeling, the developer can understand why the designer told him to use a certain technology.

When we begin to have a global view, the following advantages can be resulted from threat modeling.
•

In order to manage all risks efficiently, threat modeling is useful.

•

Security budget can be optimally utilized with the help of threat modeling.

•

Strengths and Weakness of a system can be characterized.

•

Flaws can be found earlier than technical testing.

•

Rather than performing penetration testing for all cases, targeted penetration testing can be performed.

•

Only code targeted by threat modeling can be reviewed rather than reviewing all code. 37

4.3. OUTINE OF THREAT MODELING PROCESS
Threat modeling process can be summarized in the following five steps. Initially, functional requirements of the system are captured using use cases. Also issues like security policy of the organization, security budget, etc are considered. In the second step, assets are identified using various means and critical assets are recognized by prioritizing the list of assets. Next step is to identify all different kinds of possible threats.
After listing all possible threats it is necessary to exploit each threat further to identify vulnerabilities. In the final step, mitigation procedure is presented.
1. Functional Requirements & Security Objectives
2. Asset Identification & Prioritization
3. Threat Identification
4. Threat Rating &Prioritization
5. Threat Mitigation
In this hybrid approach, the assets are identified and prioritized. Critical assets are secured by viewing them from the perspectives of different kinds of adversaries.
Moreover, the overall view of the system is considered in identifying different kinds of threats. 4.4. FUNCTIONAL REQUIREMENTS & SECURITY OBJECTIVES
The functional requirement is 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”.
A business expectation or requirement that is dependent on a security process is called a security objective. Security policy is a definition of what it means to be secure for a system, organization or other entity. For systems, the security policy addresses constraints on functions and flow among them, constraints on access by external systems and adversaries including programs and access to data by people. It is a good practice to estimate the budget reasonable to be spent on security of the application.
Most commonly use cases are used to capture the functional requirements of a system. A use case defines a goal-oriented set of interactions between external actors and the system
38

under consideration. Actors are parties outside the system that interact with the system.
An actor may be a class of users, roles users can play, or other systems. The actor may either receive assistance from the system or give assistance to the system. Use cases can capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.

Figure 4.1: Use case diagram
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. Non-functional requirements include safety, security, usability, reliability and performance requirement Until sometime ago, security for a software
39

system was managed through peremetric security. It was not mandatory that applications should be security aware. That is why security has always been an afterthought. Now-adays, 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 to develop a security aware application. Hence, security should be considered as functional requirement (Santhosh Babu G et al. 2009).
Example of e-commerce application
As an example, we have presented the e-commerce application that was used by Sindre and Opdahl (Guttorm Sindre and Andreas L Opdahl 2001) throughout this thesis. Two actors considered in this example are operator and customer. Operator or administrator has responsibility to maintain the system. Customer is authorized person to browse catalog and order goods. Crook is a malicious user who always tries to exploit the vulnerabilities of the system. Various actions that can be performed by a crook are Denial of service, Spoofing identity and Information disclosure.

4.5. ASSET IDENTIFICATION & PRIORITIZATION
Assets are the reason threats exist; an adversary’s goal is to gain access to an asset. The security team needs to identify which assets need to be protected from an unauthorized user. Assets can be either physical or abstract, i.e. employee safety, company’s reputation etc. Assets can interact with other assets and, because of this, they can act as a passthrough point for an adversary.
Assets are also identified along with their associated risks. We followed the procedure explained in (Martin and Tondel 2008) to identify and prioritize assets. As a first step, a brainstorming session is conducted and all the valuable assets are listed. Next step is to examine various existing documents for other important assets. Once all the assets are listed, the assets are categorized and prioritized with respect to security. To perform this, an asset is taken and viewed from different perspectives i.e. customer, administrator and attacker. From each perspective, each asset gets assigned a number indicating the importance of confidentiality, integrity or availability for this asset. All the

40

priorities of each asset are added and the asset with lowest sum is ranked as highest priority asset.

4.6. THREAT IDENTIFICATION
The second step, determining threats, is certainly the most challenging aspect of threat modeling. After the previous steps have been completed, it is time to think about the specific threats to the system. Threats may come from either inside or outside the system—from authorized users or from unauthorized users who masquerade as valid users or find ways to bypass security mechanisms. Threats can also come from human errors. The goal of this step is to identify threats to the system using the information gathered so far. A threat is the adversary’s goal, or what an adversary might try to do to a system (F. Swiderski and W. Snyder 2004). Sometimes a threat is also described as the capability of an adversary to attack a system. In the context of threat modeling, the first definition is more suitable. it is often to start threat modeling with a list of known threats and vulnerabilities found in similar systems. Although working backward from known vulnerabilities typically yields common threats, system-specific threats require deeper analysis of the unique qualities of the system being modeled. The best method for threat enumeration is to step through each of the system’s assets, reviewing a list of attack goals for each asset. Assets and threats are closely correlated. A threat cannot exist without a target asset. Threats are typically prevented by applying some sort of protection to assets.
The process of correlating threats to an asset involves creation of adversary hypotheses.
In threat modeling, a system model shows all security critical entities such as assets, access points, and communication channels. Threats can be identified by going through each of these security critical entities and creating threat hypotheses that violate confidentiality, integrity, or availability of the entity. The output of threat identification process is a threat profile for a system, describing all the potential attacks, each of which needs to be mitigated or accepted.

The following are the different ways to collect

different kinds of threats.

41

4.6.1. Brainstorming & Misuse case modeling
Brainstorming is an essential but not sufficient for identifying threats for the application.
A set of use cases specifying functional requirements are available along with other crucial information like critical assets, constraints etc. Based on this available information and old documents, an experienced team consisting of people from different backgrounds can sit together to conduct brainstorming session. The key aspect is to think in the perspective of an adversary trying to acquire critical assets. For each action specified in the use case, this process is repeated. As a result of this session, a list of threats corresponding to each action will be listed and represented in the form of misuse case diagram. These use case and misuse case diagrams are represented together.
Misuse case diagram corresponding to above use case can be as shown in the Figure 4.2.
A threat model cannot be created by simply brainstorming an adversary’s possible intentions. This approach is not systematic and is likely to leave large portions of the attack space uninvestigated. An attacker only has to find one security flaw to compromise the whole system (Suvda et al. 2005). Thus, it is important to be systematic during the threat modeling process to ensure that as many possible threats and vulnerabilities are discovered by the developers, not the attackers.
4.6.2. Threats from application overview
Unless the application overview or holistic view is considered, it is difficult to figure out complete list of threats for an application. End-to-End deployment scenario can be used to illustrate the application overview. The process was explained by Microsoft in
(Microsoft 2005).UML Deployment diagram can be used to identify threats related to application overview.
4.6.3. Threats derived from decomposition of the application
Threat modeling should be done on the whole system to enable a "Holistic (global) view" of the system but it must also be done on specific modules as well. That is where decomposition of the application plays a key role.
Access points are what the attacker is going to use to gain access to the assets. Examples of access points are open sockets, RPC interfaces, configuration files, hardware ports, and
42

file system read/write. Related to access points, it is also important to determine the trust boundaries in the system. A trust boundary is a boundary across which there is a varied level of trust. For example, the network may form a trust boundary, as anyone can gain access to the Internet, but not everyone should have access to the enterprise system.

Figure 4.2: Use and Misuse cases.
.
Related to trust boundaries are trust levels. Trust levels indicate how much trust is required to access a portion of the system. For instance, if a user is an administrator, they are trusted to do more than normal users
4.6.4. Insider threat
In recent years, there have been increasing numbers of incidents of damage committed by insiders - individuals who were, or previously had been, authorized to use the information
43

systems they eventually employ to perpetrate harm. Insiders pose substantial security threat to any application by virtue of their knowledge of, and access to, employer systems and/or databases. Thus, some analysis on abuse of privileges by insiders can yield a lot of threat and vulnerability information. Threat modeling should consider the insider threats as a serious issue and all the corresponding threats should be recorded.
4.6.5. Miscellaneous threats and Classification of all threats
The output of threat identification process is a threat profile for a system, describing all the potential attacks, each of which needs to be mitigated or accepted. In general, threats can be classified into six classes based on their effect (F. Swiderski and W. Snyder 2004):
•

Spoofing refers to usage of someone else’s credentials to gain access to otherwise inaccessible assets. All the attacks in which someone uses someone else identity in the

system come under this category.
•

Tampering refers to concept of altering data to mount an attack. All the attacks in which someone changes some information without permission fall into this category.

•

Repudiation occurs when a user denies performing an action, but the target of the action has no way to prove otherwise. All the attacks in which someone denies a transaction that was performed are mapped into this category. For example, someone denying a purchase order after receiving the merchandise and denying the payment is classified as repudiation.

•

Information disclosure refers to disclosure of information to a user who does not have permission to see it. All the attacks in which someone gets to see information she has no right to access can be termed as information disclosure.

•

Denial of service- Reducing the ability of valid users to access resources. All the attacks in which someone breaks the system and prevent it from working normally and supplying the service it should fall into this category. The fact that the system does not work can serve for the interest of the attacker (or the one who sent him).There a numerous ways to implement such an attack.

•

Elevation of privilege occurs when an unprivileged user gains privileged status. All the attacks in which someone enhances their capabilities by raising their privileges fall into this category. Example is when the attacker manages to get administrative rights.

When identifying a threat, it is helpful to think of various attacks in terms of the above classification. On the other hand, security threats are breaches of confidentiality,
44

integrity, or availability. Thus, threats could also be classified by these properties. This classification is useful in security requirements when deciding on a mitigation mechanism of a specific threat. For example, unauthorized modification of data en route to component B from component A poses a tampering threat which violates the integrity property. To mitigate this threat, it might make sense to apply integrity mechanism such as Secure Hashing Algorithm-1 (SHA-1) on the data being transferred.

4.7. THREAT EXPLOITATION, RATING AND PRIORITIZATION
The main tool useful for exploiting a threat is an attack tree. Attack trees (the term is introduced by Schneier in (Bruce Schneier 2005)) form a convenient way to systematically categorize the different ways in which a system can be attacked. The graphical, structured tree notation is appealing to practitioners, yet also seems promising for tool builders attempting to partially automate the threat analysis process. As such, attack trees may turn out to be of interest to the security community at large as a standard notation for threat analysis documents.
An attack tree is a tree in which the nodes represent attacks. The root node of the tree is the global goal of an attacker. Children of a node are refinements of this goal, and leafs therefore represent attacks that can no longer be refined. A refinement can be conjunctive
(aggregation) or disjunctive (choice).The above figure shows exploitation of the threat known as intrusion into an account.
Since it may not be feasible to eliminate all actual threats, it is important to acknowledge their presence and prioritize their associated risks in order to identify those that are most crucial for the system being developed. For this purpose there are different kinds of criteria. One among them is DREAD from Microsoft and the other one is the product of probability of occurrence of a threat and its impact. Thus in this step, each threat is exploited using an attack tree and the list of attacks are prioritized using a rating mechanism. 45

4.8. THREAT MITIGATION
Once the prioritized list of threats is available, each threat needs to be managed using one of the threat management techniques. This decision is also based on various other factors like security budget, current situation, security objectives and business goals etc. Main focus is on the targeted asset value and cost to mitigate the threat. If it is more costly to implement the countermeasure than the original cost of the targeted asset, the better way is to neglect the threat. Hence there are many trade-offs we need to consider before taking a crucial decision in this step.
The last two steps in this threat modeling process are well explained in the next chapter.

46

CHAPTER 5

MITIGATION OF SECURITY THREATS

5.1 INTRODUCTION
The main focus of the thesis is usage of threat modeling to mitigate security threats. In the previous chapter, a five step hybrid approach for threat modeling was outlined. The emphasis of this chapter is on the last two steps of the process i.e. threat exploitation, rating & prioritization and threat mitigation.
Identifying threats is only part of creating the system’s threat profile. Threats must also be analyzed to determine whether the system is susceptible to them. Using attack trees is one way to accomplish this. To illustrate this process, consider the case in which an attacker wishes to decrypt a message traveling from machine A to machine B. At this point, the analyst must brainstorm to figure out all avenues the attacker may pursue in order to achieve this goal. These avenues become nodes under the original goal and become goals themselves that can be evaluated the same way. Attack trees cannot replace threat modeling process but enhance the threat modeling process. When defining a threat model, designers should be concerned not only with defining what attacks they are concerned with, but also those that are not a high priority. Risk assessment is performed to map each threat either into a mitigation mechanism or an assumption that it is not worth worrying about. At this point, the security requirements for the system can be defined. Another step in analyzing the threats is to determine the risk of the threat and the threat’s conditions or child nodes by using the DREAD model. When using the DREAD model, a threat modeling team calculates security risks as an average of numeric values assigned to each of five categories.
•

Damage potential – Ranks the extent of damage that occurs if vulnerability is exploited.

47

•

Reproducibility – Ranks how often an attempt at exploiting vulnerability really works.

•

Exploitability – Assigns a number to the effort required to exploit the vulnerability. In addition, exploitability considers preconditions such as whether the user must be authenticated. •

Affected users – A value characterizing the number of installed instances of the system that would be affected if an exploit became widely available.

•

Discoverability – Measures the likelihood that, if unpatched, vulnerability will be found by external security researchers, hackers, and the like.

Use a scale of 1-10 to rate each category, where 1 is the least probability of occurrence and the least damage potential. Add the rating of each category and divide the total by five to get an overall risk rating for each threat. The result can further be divided into three sections to generate a High, Medium or Low risk rating.
Threat modeling is a technique that can be used to identify, explain and record all threats from every possible source which could attack the system. This will focus the attention on the serious threats that threaten the environment and the system, rather than looking for all general possible ways or all weaknesses in the system. After defining the threat model of the application system, means of mitigating them could be designed. The threats, threat tree, vulnerabilities and mitigations are compiled into a threat modeling document that describes the threat profile of the system. The threat modeling document can be used in the design process as a security design specification and in the testing process to identify the vulnerable areas of the system.

5.2 THREAT EXPLOITATION, RATING AND PRIORITIZATION
5.2.1 Threat exploitation using attack trees and attack patterns
Attack patterns are often used for testing purposes and are very important for ensuring that potential vulnerabilities are prevented (Sean and Amit 2007). The attack patterns themselves can be used to highlight areas which need to be considered for security hardening in a software application. They also provide, either physically or in reference, the common solution pattern for preventing the attack. Such a practice can be termed

48

defensive coding patterns. Attack patterns define a series of repeatable steps that can be applied to simulate an attack against the security of a system.
An attack tree is a way of collecting and documenting the potential attacks on a system in a structured and hierarchical manner (Jide and Casey 2005). The tree structure gives a descriptive breakdown of various attacks that the attacker uses to compromise the system. Developers can make tradeoffs during implementation and architects or developer leads can evaluate the security cost of alternative approaches. While several approaches can be used in practice, the accepted method is to identify goals and subgoals of an attack, as well as what must be done so that the attack succeeds.
Attack patterns are a formalized approach to capturing attack information. These patterns help to identify common attack techniques. Attack patterns are generic representations of commonly occurring attacks that can occur in a variety of different contexts. The pattern defines the goal of the attack as well as the conditions that must exist for the attack to occur, the steps that are required to perform the attack, and the results of the attack.
Attack patterns focus on attack techniques, whereas STRIDE-based approaches focus on the goals of the attacker.
An attack tree provides a method for representing attacks (and similar vulnerabilities) on a system in the structure of a tree. The goal of the tree is the root node. The leaf nodes represent different paths to achieve the goal. Each of these assets can be modeled as an attack tree resulting in an attack forest (Drake and Maybin 2008). The root of each tree in the attack forest constitutes an event that can potentially damage the enterprise system and its related resource’s confidentiality, integrity, and availability.
5.2.2 Threat rating
Two aspects of identified threats may be captured in the threat model, namely impact and probability. The impact of a threat is a measure of the consequences of its realization in the event of a compromise or an attack. The probability represents the likelihood that some vulnerability will be exploited to realize the threat. Quantitative metrics such as severity (product of impact and probability), as well as qualitative indices such as claims

49

based on expert knowledge and experience, can be used to prioritize the identified threats. Risk = Probability of Occurrence x Business Impact

Figure 5.1: Relation between DREAD and risk
There are a number of ways, both qualitative and quantitative, to apply this formula. One way is DREAD which is a collection of five areas with which to assess both probability of occurrence (PO) and business impact (BI). The above figure taken from (Takao Okubo and
Hidehiko 2008) gives a clear idea about the relationship between DREAD and general definition of risk.

•

Damage Potential: Defines the amount of potential damage that an attack may cause if successfully executed.

•

Reproducibility: Defines the ease in which the attack can be executed and repeated. •

Exploitability: Defines the skill level and resources required to successfully execute an attack.

•

Affected Users: Defines the number of valid user entities affected if the attack is successfully executed.

•

Discoverability: Defines how quickly and easily an occurrence of an attack can be identified. After this rating, the list of threats can be divided into 4 groups:

50

•

Critical

•

Important

•

Moderate

•

Low

5.2.3 Calculation of risk appetite and prioritization
Mitigating all threats and vulnerabilities assuming they can be identified, can be very expensive both in monetary and human resources. In some cases, the current system architecture may make mitigation impossible without a complete re-design. It is at this point that the evaluation of the risk appetite of the client comes into the picture. Although there are many factors to consider, the following are some of the considerations for determining risk appetite are:
•

The value of the asset being evaluated: For example, a million-dollar solution that mitigates a threat to a database containing a list of baseball cards does not make good business sense; while the same mitigation for a database that contains critical information for a patented medication is certainly reasonable.

•

The cost of mitigation compared to the potential loss if an attack is successful: This is very similar to the previous consideration although it approaches the question from a return on investment perspective. If the potential loss is reasonably less than the cost of mitigation then it may be worth taking on the risk rather than mitigating the threat.

•

The likelihood of an attack: If executing a threat requires a high level of expertise and a large investment in materials, it may be worth taking on this risk.

•

DREAD priority ratings: A low DREAD rating indicates that the risk for an attack is fairly low and may be worth accepting.

Since it may not be feasible to eliminate all actual threats, it is important to acknowledge their presence and prioritize their associated risks in order to identify those that are most crucial for the system being developed.

51

5.3 THREAT MITIGATION PROCESS
A good risk management procedure for threat modeling has been proposed in (Suvda et al. 2005). This procedure aims at balancing what is possible (in terms of countermeasures) against what is acceptable (in terms of risk and cost).
Despite the best efforts of security researchers, it is impossible to guarantee 100% security. However, we can work toward 100% risk acceptance. A good security system strikes a balance between what is possible and what is acceptable via the risk management process. Risk management consists of risk assessment, risk reduction, and risk acceptance. To assess the risk of identified threats, the threats must be prioritized.
The simplest way to prioritize threats is by using two factors: damage and likelihood.
Threats can be addressed starting at the top of the list. There are four possible ways to manage a risk (Ebenezer et al. 2005):
Accept the risk - The risk is so low and so costly to mitigate that it is worth accepting.
Transfer the risk - Transfer the risk to somebody else through warnings etc.
Remove the risk - Remove the system feature associated with the risk if the feature is not worth the risk.
Mitigate the risk - Reduce the risk with countermeasures.
The threats selected for mitigation must be addressed by some countermeasure. Designers should ensure that security does not become more expensive than it is worth. Security measures should be employed only up to the point where the cost to implement them does not exceed the expected risk. Failure to make this judgment correctly can easily lead to a situation where no risk is judged acceptable, and thus no acceptable system can be designed. Severity/Cost Assessment: It is very easy to go overboard when designing countermeasures against identified threats. Effort may be put into addressing a threat that may as well have low severity. Even if the severity of a threat is considered high, the costs of the countermeasure must be factored into the solution design decision, else the solution may not be cost-effective.

52

Threat Mitigation: After due analysis, a management strategy must be developed. Threats and vulnerabilities can be accepted, transferred or mitigated as described in (Suvda et al.
2005). For the threats that must be mitigated, alternative countermeasures are to be considered and their effectiveness evaluated using refinements, correlations, and the semantics of inverse contributions.Mitigations should be chosen according to the appropriate technology.Resolution should be decided according to risk level and cost of mitigations. 5.4 THREAT MITIGATION STRATEGIES
Risk mitigation represents the process of developing a strategy to deal with risk
(Ashbaugh 2009). There are four primary strategies for mitigating risk: assumption, avoidance, limitation and transference. All of these strategies are not available in all situations. These strategies often involve trade-offs that may not be acceptable to management. Other strategies may not be possible due to the resources required in order to pursue the particular mitigation strategy.
5.4.1 Risk Assumption
The first threat management strategy is threat assumption. When we are ready to face the consequences of a threat, this strategy is chosen. True self-insurance is an example of risk assumption. With risk assumption, an organization assumes the responsibility for the risk, and accepts any consequences associated with the threat action. In some instances, such as with projects for government agencies, in particular with Department of Defense, risk assumption may not be possible strategy, particularly for high and moderate risks.
However, for many other organizations, risk assumption is a valid strategy.
Other organizations may decide to assume risk because the cost of the potential safeguards or controls necessary to reduce a risk may be more costly than the magnitude of impact caused by a threat action.
Some organizations may decide to assume risk simply because they can afford the potential loss associated with the risk. Many organizations choose to assume the potential risk associated with those risks rated low on a scale of high, medium and low. This is due
53

to various reasons like lack of resources to eliminate or reduce all risk, the cost to eliminate the risk is greater than the magnitude of risk, or the potential drawbacks associated with the elimination of risk.
5.4.2 Risk Transference
Issuing warning to the users is an act of threat transference. Threat transference is the strategy of transferring the responsibility for the impact associated with a risk to another organization. Insurance is a prime example of risk transference. Most organizations deal with environmental threats or natural threats by purchasing insurance to cover the physical losses associated with these threats.
Another method of risk transference that is seeing increased use in the IT field is the use of managed services. Managed services are a process whereby organizations turn over the day-to-day management responsibilities for a particular system to another organization.
Managed services are popular for numerous different IT services including but not limited to:
•

Intrusion detection and intrusion prevention services

•

Data backup and storage

•

E-mail services

•

Network management

•

Communications

Organizations utilizing managed services often do so to gain improved efficiencies, reduced costs, or simply to obtain expertise that the current organization doesn’t have.
Managed services can provide cost-effective and efficient solutions for software development programs.
Organizations can also choose to internally transfer the risk to other departments within the organization

54

5.4.3 Risk Avoidance or Removal
This strategy aims at elimination the threat completely. Although this strategy is often the most secure strategy, it may be only possible through the deployment of additional controls and safeguards that may cost more than the assets they protect.
For example when dealing with the threats related to national security or when dealing with risks that may cause significant bodily harm or even death, there may be no alternative other than to completely eliminate the risk. Software that controls or assists in controlling the following actions are some examples.
•

Air traffic control

•

Guidance systems for missiles

•

Municipal water supplies and dams

•

Autopilots for ships or aircraft

•

Railroad routing and switching

5.4.4 Risk Mitigation or Limitation
Mitigation techniques can be chosen according to the classification of attacks based on
STRIDE. If the attack appears to be in spoofing category, appropriate authentication mechanism need to be implemented. Another precaution that can be taken is not storing secrets. If the attack belongs to tampering category, appropriate authorization mechanism need to be implemented. Moreover, other choices like hashes, digital signatures and tamper-resistant protocols are also available.
This strategy aims at controlling or limiting the risk due to threats. The following guidelines are applied according to this strategy.
•

The cost of countermeasures should be never greater than the amount of damage that can be applied to the asset.

•

The earlier in the software development life cycle that the additional countermeasures can be applied, the cheaper those safeguards will cost to implement. 55

Example Let’s say that a threat model for an electronic voting system has been defined.
We will examine how one specific threat can be mapped to a security requirement. The threat in question is “Attacker uses DoS attacks to reduce availability of the system”. The attack tree reveals that this threat can be realized by either flooding the network interface or filling up the available disk space by writing spurious data to the audit log files (Suvda et al. 2005).
During the risk assessment, we calculate the risk of the threat in several categories. For each category, assign a risk value from 1 to 10 calculated as a multiple of criticality by likelihood. Number of affected users

10

Damage potential

6

Level of skills needed

6

Cost of attack

8

Reproducibility

8

Discoverability

10

Total Risk

8
Table

We decide to mitigate this threat because the total risk factor is fairly high. The requirement for mitigating this threat could be: “The system shall not allow any user to successfully use DoS attack to reduce availability of the system”.
To satisfy this requirement, the following mitigation measures are proposed: a) Use a firewall to drop certain IP packets; b) Restrict resources used by anonymous users.
Finding the countermeasures can be made easy if we categorize the threats according to
STRIDE .Countermeasures can be obtained depending on the category of the threat. If the threat belongs to the spoofing category, suitable authentication mechanism is the countermeasure. Once countermeasures are known, still there are some more factors to be taken under consideration before taking the final decision. The crucial issues are the kind
56

of application under development, cost of mitigation, cost of asset to be protected, potential loss, likelihood of an attack etc. Suitable strategy is chosen to mitigate the risk due to the threat.
The following diagram gives the relationship among assets, threats, vulnerabilities and countermeasures. Figure 5.2: Relationship among assets, threats, vulnerabilities and countermeasures

5.5 SECURITY DESIGN PATTERNS
Once all the threat modeling process is completed, and the secure design is proposed, it is recommended to validate the design using the security design patterns. Only if the design satisfies all the ten security design patterns stated in section 2.3.2, the design is said to be completed. These security design patterns provide an opportunity to check the design once again so that all important security factors are taken into consideration.

5.6 TARGETED PENETRATION TESTING
Specific threat types have specific mitigation techniques. By looking at the relevant threats’ tree patterns and considering the leaf nodes of each tree, attacks can be framed
57

for penetration testing. Thus, threat modeling can help the testing team to develop methodical penetration tests that target high risk threats. Rather than performing penetration testing for all cases, targeted penetration testing can be performed.
In penetration test we try to penetrate into the system by breaking the security of the system (Asoke K Talukder and Manish Chaitanya 2008). As the words suggest you attempt to penetrate into the network, system, and possibly program. Penetration test also helps understand the peripheral security of an organization. It helps assess vulnerabilities of a security deployment. Penetration test mainly looks at the network security. Having said that, penetration test can also look at authentication and authorization vulnerabilities.
The effectiveness of penetration test is believed to be as good as that of the team that performs the analysis. Tools like nessus, nmap, tcpdump can help during this test. There are different tools to perform different kinds of tests.

5.7 TARGETED CODE REVIEW AND SAFE PROGRAMMING
One of the deliverables from the threat modeling process is the list of entry points to the system. These entry points are recognized and code review is done to ensure that the inside attacker or outside attacker can’t use these entry points. Only code targeted by threat modeling can be reviewed rather than reviewing all code.
It is sometime difficult to define how safety is different from security. Security is defined as protection from external threats and safety as protection from threats within (Asoke K
Talukder and Manish Chaitanya 2008). In security programming we are protecting our assets from external threats; whereas, in safe programming we protect our assets from internal threats. Here, internal means within the program, operating system, or the computer. In safe programming we ensure that our program is safe and there is no security bugs that can be exploited by someone and use our program to reach someone else’s asset.

58

CHAPTER 6

SURAKSHA: AN OPEN SOURCE TOOL SUPPORT

6.1 INTRODUCTION
In Information Security Lab at National Institute of Technology Karnataka , Surathkal, we have developed the Open Source Security Designers’ Workbench tool named
Suraksha. The tool is freely downloadable from isea.nitk.ac.in/suraksha/. Suraksha supports various important features like assets identification and prioritization, Textual representation of Misuse cases using Misuse case template, Co-representing Use and
Misuse Cases, attack tree development, DREAD Rating, Support for security patterns etc.
Suraksha offers support for asset identification and prioritization as represented in
Figure.1. Assets are classified into two categories based on the mobility. They are static assets and assets in transit (Asoke K Talukder and Manish Chaitanya 2008). Suraksha facilitates user to list all the valuable assets. It promotes not only listing valuable assets but also prioritizing assets based on the values assigned by the user. User needs to enter values for Confidentiality, Integrity and Availability from the perspective of stakeholder and attacker. User need to choose one from three numbers 1, 2 and 3 provided using drop down box. Value 1 denotes high priority indicating that the importance of confidentiality, integrity or availability for the corresponding asset is more. If user didn’t select any value, default value is taken as 4.Once the assignment of all values is finished, the sum of all values for each asset is calculated. The lesser is the value of sum for an asset, the higher is the priority given to the asset.
Suraksha provides a simple and efficient GUI to draw Misuse case diagram as shown in Figure 2. User can easily add actor node, misactor node, use case node, misuse case

59

node and can easily draw various relationship between them like extend, mitigate,

Figure 6.1: Attack tree for Intrude into Customer Account in e-commerce application

threaten etc by selecting suitable item from the panel. To represent a system behavior, attempt should be to include both functional and non-functional requirements together.
And, to represent this in graphical fashion, Use case and Misuse case should be combined to define the system. To represent Use cases and Misuse cases together, these need to be differentiated. Therefore, Use case is black in white and Misuse case is shown in an inverted format – white in black. Suraksha provides attractive GUI to draw Use cases and
Misuse cases and to co-represent them. Within a short time interval, user can draw
Misuse cases and Use cases easily using this tool. The size of the diagram can be adjusted as required. In the example presented in figure 3.2, operator and customer are actors and

60

their corresponding permitted actions are shown. Crook is also represented along with some of the possible malicious actions.
Suraksha offers user friendly GUI for the user to document the textual representation of
Misuse cases. User can enter corresponding information against each field in the provided text boxes. After completion of giving all the necessary information, user can save the textual representation.

Figure 6.2: Attack tree with DREAD Rating for Intrude into Customer Account in ecommerce application
Suraksha provides attractive GUI for attack tree development as depicted in Figure 4. For each abstract threat mentioned in 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 abstract threat as root node. Various paths
61

possible to achieve the goal (root node) are explored. User can easily draw all possibilities by creating children to a node and connect these children using AND or OR component. AND component is represented by straight line and OR component is represented using double line arc. User just need to select the required items from panel and can place the items in required position. To facilitate the designer, there are some standards 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 real system these threats need to be mitigated. Also, the impact of these threats needs to be measured.

Figure 6.3: Annotated attack tree
To measure the impact of each threat, Suraksha uses DREAD methodology. When a node in an attack tree is selected and right clicked, there is provision for the user to enter suitable values for Damage Potential, Reproducibility, Exploitability, Affected Users and
Discoverability. By selecting proper radio button, user can choose either 0 or 5 or

62

10.After completion of giving information, risk associated with corresponding node is calculated automatically based on the formula mentioned below.
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, the more serious the risk. The corresponding snapshot with DREAD rating for the attack tree is shown in Figure 6.2.
Suraksha provides unique provision to work with misuse cases and attack trees. For each misaction in lightweight Misuse case, an attack tree with misaction as root node can be created. It facilitates the user to think of various ways of performing the attack in the perspective of a hacker. Depending on rating and values obtained for different threats using attack trees, threats are filtered and corresponding extensive Misuse case diagram can be generated. Thus this tool reaps the benefits of using attack trees and Misuse cases together. This extensive Misuse case diagram can be saved and forms an excellent input for threat modeling.
Finally, it is very important to provide formal documentation for various problems along with their solutions. The purpose of this documentation is to use these solutions again when the same problems are encountered in future. For recurring problems this approach is very useful. Suraksha offers vital support for security designers to solve recurring problems using security patterns. A documented pattern contains details about the problem that the pattern addresses, the context in which this pattern should be used, the solution etc

63

Figure 6.4: Attack library
Suraksha offers an attack library consisting of various common attacks and description about each one of them. In addition to the description of the attack, vulnerabilities that cause the attack are also available. Countermeasures are suggested for each attack depending on the corresponding vulnerabilities.
As attack list is not closed, new attacks keep coming day by day. Hence there is a provision to add new attack to the library. Modifying the description of an attack, renaming an attack and deleting an attack are possible.

64

CHAPTER 7

CONCLUSION AND FUTURE SCOPE
Threat modeling plays a crucial role in mitigating security threats and thereby facilitating the development of secure applications. These secure applications can prevent the malicious activities of the cybercriminals who are taking advantage of vulnerabilities in an application. This thesis provided a hybrid process for threat modeling using misuse cases, attack trees, DREAD etc. However the main focus of the thesis is on threat exploitation, prioritization and mitigation. An open source tool suraksha which supports techniques used for threat modeling is also introduced.
At present, open source tool with all features required for threat modeling is not available. It would be a great contribution to the field of security if researchers develop an open source tool for threat modeling with automation wherever possible.

65

REFERENCES
Ashbaugh (2009). Security Software Development, CRC Press.
Asoke K Talukder and Manish Chaitanya (2008). “Architecting Secure Software Systems.” Auerbach Publications.
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.
Bruce Schneir (1999). “Modeling Security Threats.” http://www.schneier.com/paperattacktrees-ddj-ft.html (Feb. 17, 2009).
Boehm B. (1988). “A Spiral Model for Software Development and Enhancement.”
Computer, vol. 21, no. 5, 61–72.
Damodaran(2006).”Secure software development using use cases and misuse cases”,
Issues in Information Systems, Volume VII, No.1, 2006.
Donald Firesmith: "Security Use Cases", in Journal of Object Technology, vol. 2, no. 3, pp. 53-64, May-June 2003.[Online].
Drake and Maybin (2008). “Threat Modeling Revisited: Improving Expressiveness of
Attack”, Second UKSIM European Symposium on Computer Modeling and Simulation.
Ebenezer, Sam and Lawrence (2005). “Security threat modeling and analysis: A GoalOriented approach”.
Erich Gamma (1995) “Design Patterns: Elements of Reusable Oject-Oriented Software”
Addison-Wesley Professional Computing Series.
Fredrik Moberg (2000). "Security Analysis of an Information System using an Attack tree-based Methodology.” Master’s Thesis, Chalmers University of Technology,
Goteborg, Sweden.
F. Swiderski and W. Snyder (2004). “Threat Modeling.” Microsoft Press.

66

Guttorm Sindre and Andreas L Opdahl (2001) “Capturing Security Requiremen-ts by
Misuse Cases.” Proc., 14th Norwegian Informatics Conference (NIK'2001), Troms,
Norway.
Guttorm Sindre and Andreas L. Opdahl (2001). “Templates for Misuse Case
Description,” Proc., 7 th International Workshop on Requirements Engineering,
Foundation for Software Quality (REFSQ'2001), Interlaken, Switzerland.
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.
Jide and Casey (2005). “Information Security Attack Tree Modeling”.
Julia H. Allen (2008). “Software Security Engineering: A Guide for Project Managers.”
Addison Wesley Professional.
J.D.

Meier

(2003).

“Improving

Web

Application

Security:

Threats

Countermeasures,” http://msdn.microsoft.com/en-us/library/ms994921.aspx

and

(June 5,

2009).
Linzhang Wang, Eric Wong and Dianxiang Xu (2007). “A Threat Model Driven
Approach for Security Testing.” Proc., Third International Workshop on Software
Engineering for Secure Systems (SESS'07).
Martin Gilje Jaatun and Inger Anne Tondel, ”Covering Your Assets in Software
Engineering,” in Proc. 3rd International Conference on Availability, Reliability and
Security (ARES’08), Barcelona , Spain, Mar. 2008, pp.1172–1179.
Mamadou H. Diallo Jose Romero-Mariona, Susan Elliott Sim and Debra J. Richardson (2006).
“A Comparative Evaluation of Three Approaches to Specifying Security Requirements.”
Proc., 12th Working Conference on Requirements Engineering: Foundation for Software
Quality, Luxembourg

67

Michael Howard and David E. Leblanc (2003).”Writing Secure Code: Practical Strategies
And Proven Techniques For Building Secure Applications In A Networked World.”
Microsoft Press.
Microsoft (2005).“Threat Modeling Web Applications.” http://msdn.microsoft.com/en-us/library/ms978516.aspx (May 2005).
Microsoft.

“The

STRIDE

Threat

Model.”

http://msdn.microsoft.com/en-

us/library/ms954176.aspx (March 21, 2009).
Naur and B. Randell, (Eds.) (1969). “Software Engineering: Report of NATO Software
Engineering Conference 1968.” Scientific Affairs Division, NATO, Brussels, Belgium.
OWASP “Application Threat Modeling.” http://www.owasp.org/.
Robert G. Cooper (1988). “The Journal of Marketing Management”, spring 1988.
Roger S. Pressman (2001). “Software Engineering: A practitioner’s approach.” fifth edition, McGraw-Hill Companies.
Rumbaugh J (1999). “The Unified Modeling Language Reference Manual.” Addison
Wesley.
Santhosh Babu G, et al. (2009). “Suraksha: A Security Designers' Workbench.” Proc.,
Hack.in 2009, IIT Kanpur, 59-66.
Sean Barnum and Amit Sethi (2007). “Attack Patterns as a Knowledge Source for building Secure Software”, CIGITAL, INC.
Steve McConnell (2004). “Code Complete: A Practical Handbook of Software
Construction.” second edition, Microsoft press.
Suvda Myagmar, Adam and William “Threat Modeling as a Basis for Security
Requirements”. In Proc., Symposium on Requirements Engineering for Information
Security (SREIS’05),Paris, France, Aug. 2005.

68

Takao Okubo and Hidehiko Tanaka, “Identifying

Security Aspects in Early

Development Stages,” in Proc. 3rd International Conference on Availability, Reliability and Security (ARES’08), Barcelona , Spain, Mar. 2008, pp. 1148–1155.
Wikipedia.“Agile software development.” http://en.wikipedia.org/wiki/Agile_software_development (June 8, 2009).
Wikipedia. “Procedural programming”. http://en.wikipedia.org/wiki/Procedural_programming (June 9, 2009).
Zrnec , Marko Bajec and Marjan Krisper (2000). “Enterprise modeling with UML”.

69

BIO-DATA

Contact Address: S/o J.N.P Asirvadam,
B.S.N.L Telephone Exchange Quarters,
Kovur, Nellore, Andhra Pradesh.
Pin: 524137
E-mail

: ebenezer.jangam@gmail.com

Qualification

: B.Tech (Computer Science & Information Technology)

LIST OF PUBLICATIONS
1. Suraksha: A Security Designers' Workbench, Proceedings of Hack.in 2009, IIT
Kanpur, March 17-19, 2009, India. (With Asoke K Talukder, Alwyn Roshan Pais,
Santhosh Babu G, Vineet Kumar Maurya and Muni Sekhar V)
2.Security-aware Software Development Life Cycle (SaSDLC) - Processes and
Tools, WOCN 2009, Egypt ,April 28-30, 2009.(With Asoke K Talukder, Alwyn R Pais,
Vineet Kumar Maurya, Santhosh Babu G, Muni Sekhar V, Jevitha K P and Saurabh
Samanta)
3.Managing Non-functional Requirements of Scalability and Security in the
Grid/Cloud. communicated to HiPC 2009, International conference on High
Performance Computing, Kochi, India(With Asoke K Talukder, Alwyn R Pais, Santhosh
Babu G, Prahlad H A, Vineet Kumar Maurya and Muni Sekhar V).

70