threat modeling and its usage in mitigating security threats in an application
TRANSCRIPT
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
D E C L A R A T I O N
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: ............................
C E R T I F I C A T E
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
1
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).
2
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
3
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.
4
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.
5
• 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.
6
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
7
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).
8
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.
9
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:
10
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
11
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.
12
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, self-
organization and accountability, a set of engineering best practices that allow for rapid
delivery of high-quality software, and a business approach that aligns development with
customer needs and company goals.
Agile methods break tasks into small increments with minimal planning, and don't
directly involve long-term planning. Iterations are short time frames that typically last to
one to four weeks. Each iteration is worked on by a team through a full software
development cycle. Iteration may not add enough functionality to warrant a market
13
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.
14
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.
15
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.
16
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
17
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.
18
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
19
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.
20
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
21
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
22
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
23
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 lower-
level 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
24
complete classes, polymorphism, exception handling, templates, and it provides more
robust type checking than C does.
4) C#: C# is a general-purpose, object-oriented language and programming
environment developed by Microsoft with syntax similar to C, C++, and Java and
provides extensive tools that aid development on Microsoft platforms.
5) Cobol: Cobol is an English-like programming language that was originally
developed in 1959-1961 for use by the Department of Defense. Cobol is used
primarily for business applications and is still one of the most widely used languages
today. Cobol has been updated over the years to include mathematical functions and
object oriented capabilities. The acronym “Cobol” stands for Common Business-
Oriented Language.
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
25
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 All-
purpose Symbolic Instruction Code. Visual Basic is a high-level, object-oriented,
visual programming version of Basic developed by Microsoft that was originally
designed for creating Windows applications. It has since been extended to support
customization of desktop applications such as Microsoft Office, creation of web
programs, and other applications.
2.4.2 Security Bugs in Construction Phase
A bug is a software security defect that is introduced during software implementation and
can be detected locally through static and manual analysis. The following types of
security bugs (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
26
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.
27
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).
28
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)
29
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
30
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
31
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,
32
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
33
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.
34
The figure taken from (Takao Okubo and Hidehiko 2008) gives a clear picture about the
right place for threat modeling in SDLC.
35
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.
36
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 Threat-
Centric 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.
37
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.
38
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
39
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
40
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-a-
days, it is obligatory to develop security aware applications. Security needs to be
embedded into the system from the early stages of Software Development Life Cycle 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 pass-
through 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
41
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.
42
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
43
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
44
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,
45
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.
46
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.
47
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.
48
• 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
49
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 sub-
goals 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
50
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:
51
• 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.
52
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.
53
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
54
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
55
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.
56
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
57
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
58
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.
59
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
60
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
61
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 e-
commerce 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
62
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
63
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
64
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.
65
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.
66
REFERENCES
Ashbaugh (2009). Security Software Development, CRC Press.
Asoke K Talukder and Manish Chaitanya (2008). “Architecting Secure Software Sys-
tems.” 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/paper-
attacktrees-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 Goal-
Oriented 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.
67
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 and
Countermeasures,” http://msdn.microsoft.com/en-us/library/ms994921.aspx (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
68
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.
69
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”.
70
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 : [email protected]
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).