Check the appropriate Fortnight

submission number
3

Fortnight Submission

Fortnight Duration

February, 23, 2015 to March, 6, 2015

Report Type

Self Study
Tool

Mini Project

Threats and Risk Assessment

Students Details:
Details
Name
Reg. No.
Programme

and

Semester
Mobile No.
Email
Social

Student 1
Bharat Arya
14IS05F

Student 2
Sumit Saurabh
14IS22F

M.Tech(CSE-IS) II

M.Tech(CSE-IS) II

8147299721
developer.bharatarya@gmail

8123996816
ssaurabh262@gmail.co

.com

m
in.linkedin.com/in/learn

Networking

sumit

IDs
Signature and Date

Check your Evaluator Name

Usha D
Evaluator:

Manoj V.

Thomas
Marimuthu C
Joseph

Signature and Date

Anitha Kumari
S Raghavan

Christina Terese

Title

Page 2

Table of Contents
Table of Contents...........................................................................................................................ii
Abstract *........................................................................................................................................1
Members Contributions *.............................................................................................................2
1. Introduction *...........................................................................................................................3
1.1
1.2

Definition...................................................................................................................................3
Types of threats..........................................................................................................................4

2. Threat assessment and modelling...........................................................................................5

2.1

Approaches to Threat modeling..................................................................................................5

3. Creating a threat model...........................................................................................................6

3.1
3.2
3.3
3.4
3.5
3.6

Identify Security Objectives.......................................................................................................7

Application Overview.................................................................................................................8
Decompose Application..............................................................................................................8
Identify Threats..........................................................................................................................9
Rate the Threats........................................................................................................................10
Thread Rating Table..................................................................................................................11

4. Risk Analysis..........................................................................................................................13
4.1

Risk Analysis Steps..................................................................................................................14

5. Generic Risk Model...............................................................................................................16

5.1 Countermeasure Identification........................................................................................................17
5.2 Mitigation Strategies.......................................................................................................................17
5.3
STRIDE....................................................................................................................................18

6. Risk Management *...............................................................................................................19

7. Learning Outcomes................................................................................................................21
8. Case Study *...........................................................................................................................21
8.1

Analysis....................................................................................................................................21

Summary *....................................................................................................................................25
References *..................................................................................................................................25

Risk and Threat Assessment, Analysis

Page 1

Abstract *
Information systems have long been at some risk from malicious actions or inadvertent user errors
and from natural and man-made disasters. In recent years, systems have become more susceptible to
these threats because computers have become more interconnected and, thus, more interdependent
and accessible to a larger number of individuals. In addition, the number of individuals with
computer skills is increasing, and intrusion, or hacking, techniques are becoming more widely
known via the Internet and other media. In this digital era, as organizations use automated
information technology systems to process their information for better support of their missions,
threat and risk management plays a critical role in protecting an organizations information assets,
and therefore its mission, from IT-related risk. An effective threat and risk management process is
an important component of a successful IT security program. The principal goal of an organizations
risk management process should be to protect the organization and its ability to perform their
mission, not just its IT assets. Prior to claiming the security of a system, it is important to identify
the threats to the system in question. Enumerating the threats to a system helps system
architects develop realistic and meaningful security requirements.
In this self-study we attempt to study various aspects of threat and risk assessment and
there analysis.

Risk and Threat Assessment, Analysis

Page 2

Members Contributions *
Bharat Arya:
Introduction, Threats and its analysis, creating threat model.
Sumit Saurabh:
Introduction to risks, risk management and analysis, Stride.
We tried to distribute the work in such a way that both will get basic of the topic as well as detailed
understanding of selected subparts. Case study was jointly done by both members.

Risk and Threat Assessment, Analysis

Page 3

1. Introduction *
We use the term risk in everyday speech, but a whole science has grown up around the
identification, analysis and management of risks. Application security has become a major concern
in recent years. Hackers are using new techniques to gain access to sensitive data, disable
applications and administrator other malicious activities aimed at the software application. The need
to secure an application is imperative for use in todays world. Until recently, application security
was an afterthought; developers were typically focused on functionality and features, waiting to
implement security at the end of development. This approach to application security has proven to
be disastrous; many vulnerabilities have gone undetected allowing applications to be attacked and
damaged. This raises the following questions: How can application security become an integral part
of the development process? How can an application design team discover and avoid vulnerabilities
in their application? There are three measures that can help discovering and avoiding security
vulnerabilities:
Have many experts contribute and share their knowledge
Make expert knowledge about typical vulnerabilities available to developers and
Make system-specific knowledge available to persons searching for vulnerabilities.
At the application layer, security means being aware of how our code uses information and ensuring
that it does so safely and responsibly. For example, it is an organizations responsibility to:
Keep users personal data safe from prying eyes. Store the data in a secure way, and
ensure that our software collects only the information that it requires.
Treat untrusted files and data with care. If our software accesses the Internet or reads
files that might have previously been sent to someone over the Internet, our software must
properly validate the data. If it does not, it might inadvertently provide a vector for attackers
to access other personal data that may be stored on the users computer or other mobile
device.
Protect data in transit. If our software transmits personal information over the Internet, we
must do so in a safe and secure fashion to prevent unauthorized access to or modification of
the data while in transit.
Verify the authenticity of data where possible. If our software provides access to or works
with signed data, it should verify those signatures to ensure that the data has not been
tampered with.
Vulnerabilities and threats need to be taken into account very carefully. Threat modeling allows us
to apply a structured approach to security and to address the top threats that have the greatest
potential impact to our application first. This self-study helps us to decompose our Web application
to identify and rate the threats that are most likely to impact our system.
1.1 Definition
Vulnerability is the intersection of three elements: a system susceptibility or flaw, attacker
access to the flaw, and attacker capability to exploit the flaw. To exploit a vulnerability, an attacker
must have at least one applicable tool or technique that can connect to a system weakness. In this
frame, vulnerability is also known as the attack surface. Vulnerability management is the cyclical

Risk and Threat Assessment, Analysis

Page 4

practice of identifying, classifying, remediating, and mitigating vulnerabilities. This practice

generally refers to software vulnerabilities in computing systems.
In computer security a threat is a possible danger that might exploit a vulnerability to breach
security and thus cause possible harm. A threat can be either "intentional" (i.e., intelligent; e.g., an
individual cracker or a criminal organization) or "accidental" (e.g., the possibility of a computer
malfunctioning, or the possibility of a natural disaster such as an earthquake, a fire, or a tornado) or
otherwise a circumstance, capability, action, or event.
A risk is the potential that a given threat will exploit vulnerabilities of an asset or group of
assets and thereby cause harm to the organization. It is measured in terms of a combination of the
probability of occurrence of an event and its consequence. Information technology risk, or IT risk,
IT-related risk, is any risk related to information technology. While information has long been
appreciated as a valuable and important asset, the rise of the knowledge economy has led to
organizations becoming increasingly dependent on information, information processing and
especially IT. Various events or incidents that compromise IT in some way can therefore cause
adverse impacts on the organization's business processes or mission, ranging from inconsequential
to catastrophic in scale.

Asset. A resource of value, such as the data in a database or on the file system. A system
resource.
Threat. A potential occurrence, malicious or otherwise, that might damage or compromise
our assets.
Vulnerability. A weakness in some aspect or feature of a system that makes a threat
possible. Vulnerabilities might exist at the network, host, or application levels.
Attack (or exploit). An action taken by someone or something that harms an asset. This
could be someone following through on a threat or exploiting a vulnerability.
Countermeasure. A safeguard that addresses a threat and mitigates risk.
1.2 Types of threats

There are several types of threats to consider, including threats to data, service availability, and
system integrity.
1.2.1

Threats to Data

An attacker can modify data. This includes:

Data used internally by the program (such as inter-process messages)
Data acted on by the program (such as numbers on which the program does a statistical
analysis or an audio track that the program filters)
Data stored on disk to which the program gives access.
Similarly, an attacker can compromise data and obtain access to secrets.
An attacker can modify or compromise data directly by telling the program to modify or return
data that it shouldnt have modified or returned. However, an attacker can also modify or
compromise data indirectly by using our program to take control of the computer.
Further, direct modifications often lead to further access that can allow additional indirect
modifications. For example, an attacker might modify internal program data directly, then use that
modified data to inject arbitrary code that adds a new admin user to the systems password database.
1.2.2

Threats to Service Availability

An attack designed to reduce service availability is called a denial of service attack. These
attacks can cause an app or daemon to stop functioning, or make a server so busy that legitimate
users cant get access to it.
An attacker can perform a denial of service attack in many ways:

Risk and Threat Assessment, Analysis

Page 5

Attacking bugs in the networking stack

Open connections to the daemon, start sending a request, then continue sending it very slowly
Convince thousands of people to voluntarily attack our server.
Open millions of connections to the daemon from a botnet.
When a denial of service attack is carried out by a large number of machines, it is called a
distributed denial of service attack, or DDoS.
1.2.3

Attacks on System Integrity

Attacks on system integrity build upon other attacks to modify the system in such a way that it
can no longer be trusted. If an attacker can find a security flaw in our code, the attacker might be
able to:
Execute malicious code, especially with administrator or root access. The attacker might
cause our code to execute the attackers code by exploiting a buffer overflow or by code
insertion in a URL command, for example. If our code is a daemon running with
administrative privileges, the attackers code will be privileged as well. Once an attacker has
administrative control of a computer, any efforts to mitigate threats become futile.
Impersonate a user or server. The attacker might be able to guess or obtain a valid
username and password and therefore authenticate as an authorized user. Similarly, a
spoofed server might be able to convince a client app that it is a legitimate server, then get
the client to give it data or get the user to provide secrets, such as passwords. Finally, a
spoofed server might be able to convince a nave user that the server is legitimate. For
example, a user might not examine the window containing a web page sufficiently to notice
that the lock icon (or other indicator of a secure site) is missing. Using such a malicious
website to obtain user data is called phishing.
Repudiate an action. A malicious user might modify our software in such a way that allows
him or her to deny performing an operation (such as using a specific credit card number).
There are a number of techniques we can use to ensure nonrepudiation, such as code
signature verification, data integrity checks, and so on.

2. Threat assessment and modelling

Threat modeling is an approach for analyzing the security of an application. Its a structured
approach that enables us to identify, quantify and address the security risks associated with an
application. Threat modeling is not an approach to reviewing code, but it does complement the
security code review process. The inclusion of threat modeling in the SDLC can help to ensure that
applications are being developed with security built in from the very beginning. This, combined
with the documentation produced as part of the threat modeling process, can give the reviewer a
greater understanding of the system. This allows the reviewer to see where the entry points to the
application are and the associated threats with each entry point.
To create a threat model, a systematic approach is required. One approach is to use data
flow. By using the data flow approach, the threat modeling team is able to systematically follow the
flow of data throughout the system identifying the key processes and the threats to those processes.
The data flow approach uses three main steps: view the system as an adversary, characterize the
system and determine the threats. The threat modeling process outlined below is adapted from these
references

Risk and Threat Assessment, Analysis

Page 6

2.1 Approaches to Threat modeling

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, for example, "The NSA wants to
read this email," or "Jon wants to copy this DVD and share it with his friends." This approach
usually starts from either entry points or assets.
Software-centric
Software-centric threat modeling (also called 'system-centric,' 'design-centric,' or 'architecturecentric') 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.
Asset-centric
Asset-centric threat modeling involves starting from assets entrusted to a system, such as a
collection of sensitive personal information

3. Creating a threat model

The threat model for an application or other software system should be a high-level data-flow model
that diagrams every spot in which information moves into or out of our code or between major arts
of our code. At a high level, it should include these pieces:

The types of data application will work with

The situations in which application must deal with untrusted data

The types of data transport application uses

Ways that an attacker could exploit a piece of software that does what application does

Strategies for mitigating each of those types of exploits

For the purposes of this analysis, we should consider only theoretical categories of attack, not actual
specific attacks. For example, a word processor could be compromised if it mishandles a corrupted
file in such a way that allows an attacker to inject code. It is not important whether our specific code
has specific bugs that make this possible.
Some potential attack targets might include program input or output, stored data, and the programs
operating environment.

Program input. If an attacker can cause a buffer overflow, they might be able to run their
own code or otherwise compromise the users data or system.

Risk and Threat Assessment, Analysis

Page 7

Program output (either to the user or to another software module). The attacker might be
able to gain access to private information stored on the system, or to read and modify the
information being passed between modules (a man-in-the-middle attack).

Data stored on the system (either permanently, as in a database, or temporarily, as in a

global variable). This data could potentially be stolen and sent to an attacker, modified by an
attacker, or otherwise compromised.

Program environment. A programs execution environment includes its open file

descriptors, environment variables, Mach ports, preference files, and so on.

The threat risk modeling process has five steps, enumerated below and shown graphically in Figure
They are:
1)
2)
3)
4)
5)

Identify Security Objectives

Application overview
Decompose it
Identify Threats
Identify Vulnerabilities

Figure 1: Steps
3.1 Identify Security Objectives
The business (or project management) leadership, in concert with the software development and
quality assurance teams, all need to understand the security objectives. To facilitate this, start by
breaking down the applications security objectives into the following categories:

Identity: Does the application protect user identity from abuse? Are there adequate controls
in place to ensure evidence of identity (as required for many banking applications?)

Financial: Assess the level of risk the organization is prepared to absorb in remediation, as a
potential financial loss. For example, forum software may have a lower estimated financial risk
than an Internet banking application.

Reputation: Quantify or estimate of the loss of reputation derived from the application
being misused or successfully attacked.

Privacy and Regulatory: To what extent will the application have to protect user data?
Forum software by its nature is public, but a tax preparation application is subject to tax
regulations and privacy legislation requirements in most countries.

Risk and Threat Assessment, Analysis

Page 8

Availability Guarantees: Is the application required to be available per a Service Level

Agreement (SLA) or similar guarantee? Is it a nationally protected infrastructure? To what level
will the application have to be available? High availability techniques are significantly more
expensive, so applying the correct controls up front will save a great deal of time, resources, and
money.

This is by no means an exhaustive list, but it gives an idea of some of the business risk decisions
leading into selecting and building security controls.
Other sources of risk guidance come from:

Laws (such as privacy or finance laws)

Regulations (such as banking or e-commerce regulations)

Standards (such as ISO 17799)

Legal Agreements (such as payment card industry standards or merchant agreements)

Corporate Information Security Policy

3.2 Application Overview

Once the security objectives have been defined, analyze the application design to identify
the components, data flows, and trust boundaries.
Do this by surveying the applications architecture and design documentation. In particular, look for
UML component diagrams. Such high level component diagrams are generally sufficient to
understand how and why data flows to various places. For example, data movement across a trust
boundary (such as from the Internet to the web tier, or from the business logic to the database
server), needs to be carefully analyzed, whereas data that flows within the same trust level does not
need as much scrutiny.

Risk and Threat Assessment, Analysis

Page 9

3.3 Decompose Application

Once the application architecture is understood then decompose it further, to identify the features
and modules with a security impact that need to be evaluated. For example, when investigating the
authentication module, it is necessary to understand how data enters the module, how the module
validates and processes the data, where the data flows, how the data is stored, and what fundamental
decisions and assumptions are made by the module.
During this step, we perform the following tasks:

Identify trust boundaries.

Identify data flow.

Identify entry points.

Identify privileged code.

3.4 Identify Threats

It is impossible to write down unknown threats, but it is likewise unlikely that new malware will be
created to exploit new vulnerabilities within custom systems. Therefore, concentrate on known
risks, which can be easily demonstrated using tools or techniques from Bugtraq.
Microsoft suggests two different approaches for writing up threats. One is a threat graph, as shown
in Figure 2, and the other is a structured list.

Risk and Threat Assessment, Analysis

Page 10

Figure 2
Typically, a threat graph imparts more information quickly but it takes longer to construct, while a
structured list is easier to create but it will take longer for the threat impacts to become obvious.
1. Attacker may be able to read other users messages
2. User may not have logged off on a shared PC
3. Data validation may allow SQL injection
4. Implement data validation
5. Authorization may fail, allowing unauthorized access
6. Implement authorization checks
7. Browser cache may contain contents of message
8. Implement anti-caching directive in HTTP headers
9. If eavesdropping risk is high, use SSL
Note that it takes a motivated attacker to exploit a threat; they generally want something from our
application or to obviate controls. To understand the relevant threats, use the following categories to
understand who might attack the application:

Accidental Discovery: An ordinary user stumbles across a functional mistake in our

application, just using a web browser, and gains access to privileged information or
functionality.

Automated Malware: Programs or scripts, which are searching for known vulnerabilities,
and then report them back to a central collection site.

The Curious Attacker: a security researcher or ordinary user, who notices something
wrong with the application, and decides to pursue further.

Risk and Threat Assessment, Analysis

Page 11

Script Kiddies: Common renegades, seeking to compromise or deface applications for

collateral gain, notoriety, or a political agenda, perhaps using the attack categories described in
the OWASP Web Application Penetration Checklist.

The Motivated Attacker: Potentially, a disgruntled staff member with inside knowledge or
a paid professional attacker.

Organized Crime: Criminals seeking high stake pawets, such as cracking e-commerce or
corporate banking applications, for financial gain.

It is vital to understand the level of attacker we are defending against. For example, a motivated
attacker, who understands our internal processes is often more dangerous than script kiddies.
3.5 Rate the Threats
At this stage in the process, we have a list of threats that apply to our particular application
scenario. In the final step of the process, we rate threats based on the risks they pose. This allows us
to address the threats that present the most risk first, and then resolve the other threats. In fact, it
may not be economically viable to address all of the identified threats, and we may decide to ignore
some because of the chance of them occurring is small and the damage that would result if they did
is minimal.
Risk = Probability * Damage Potential
This formula indicates that the risk posed by a particular threat is equal to the probability of the
threat occurring multiplied by the damage potential, which indicates the consequences to our system
if an attack were to occur.
We can use a 110 scale for probability where 1 represents a threat that is very unlikely to
occur and 10 represents a near certainty. Similarly, we can use a 110 scale for damage potential
where 1 indicates minimal damage and 10 represents a catastrophe. Using this approach, the risk
posed by a threat with a low likelihood of occurring but with high damage potential is equal to the
risk posed by a threat with limited damage potential but that is extremely likely to occur.
For example, if Probability=10 and Damage Potential=1, then Risk = 10 * 1 = 10.
If Probability=1 and Damage Potential=10, then Risk = 1 * 10 = 10.
This approach results in a scale of 1100, and we can divide the scale into three bands to generate a
High, Medium, or Low risk rating.
We can use a simple High, Medium, or Low scale to prioritize threats. If a threat is rated as
High, it poses a significant risk to our application and needs to be addressed as soon as possible.
Medium threats need to be addressed, but with less urgency. We may decide to ignore low threats
depending upon how much effort and cost is required to address the threat.

Risk and Threat Assessment, Analysis

3.5.1

Page 12

DREAD

The problem with a simplistic rating system is that team members usually will not agree on ratings.
To help solve this, add new dimensions that help determine what the impact of a security threat
really means. At Microsoft, the DREAD model is used to help calculate risk. By using the DREAD
model, we arrive at the risk rating for a given threat by asking the following questions:

Damage potential: How great is the damage if the vulnerability is exploited?

Reproducibility: How easy is it to reproduce the attack?

Exploitability: How easy is it to launch an attack?

Affected users: As a rough percentage, how many users are affected?

Discoverability: How easy is it to find the vulnerability?

We can use above items to rate each threat. We can also extend the above questions to meet our
needs. For example, we could add a question about potential reputation damage:
Reputation: How high are the stakes? Is there a risk to reputation, which could lead to the loss of
customer trust?
Ratings do not have to use a large scale because this makes it difficult to rate threats consistently
alongside one another. We can use a simple scheme such as High (1), Medium (2), and Low (3).
When we clearly define what each value represents for our rating system, it helps avoids confusion.
Table 3.1 shows a typical example of a rating table that can be used by team members when
prioritizing threats.
3.6 Thread Rating Table
Damage Potential

If a threat exploit occurs, how much damage will be caused?

0 = Nothing

5 = Individual user data is compromised or affected.

10 = Complete system or data destruction

Risk and Threat Assessment, Analysis

Page 13

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

Risk and Threat Assessment, Analysis

Page 14

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

After we ask the above questions, count the values (13) for a given threat. The result can fall in the
range of 515. Then we can treat threats with overall ratings of 1215 as High risk, 811 as
Medium risk, and 57 as Low risk.
For example, consider the two threats described earlier:

Attacker obtains authentication credentials by monitoring the network.

SQL commands injected into application.

Once we have obtained the risk rating, we update the documented threats and add the discovered
rating level, which is high for both of the above threats. Table 3.1 shows an example.

Table 3.1 Threat 1

Threat Description

Attacker obtains authentication credentials by monitoring the network

Threat target

Web application user authentication process

Risk rating

High

Attack techniques

Use of network monitoring software

Countermeasures

Use SSL to provide encrypted channel

Risk and Threat Assessment, Analysis

Page 15

4. Risk Analysis
Risk can be thought of as the chance of adverse consequences or loss occurring. Generally, risks can
be identified and the likelihood of them occurring assessed.
The main technique for a qualitative analysis of risk is to construct a likelihoodimpact matrix in
which the likelihood and impact of each risk event are assessed against a defined scale and then
plotted on a two-dimensional grid. The position on the grid represents the relative significance of
each risk. The simplest matrix is formed by classifying both likelihood and impact as either high or
low, which leads to a 2 by 2 grid. This basic classification of a high or low value leads to the
following rank order for tackling risks:
1. High-impact, high-likelihood risks
2. High-impact, low-likelihood risks
3. Low-impact, high-likelihood risks.

Low-impact, low-likelihood risks are probably not worth expending much effort on. We can then
look at these high-impact or high-likelihood risks one by one to determine whether there are ways
either to reduce the impact if the risk occurs or to reduce the likelihood of the risk occurring, or
both. Conducting a risk analysis is an important part of protecting your information asset
Discovering vulnerabilities is important, but being able to estimate the associated risk to the
business is just as important. It is possible to estimate the severity of all of the risks to the business
and make an informed decision about what to do about those risks. Having a system in place for

Risk and Threat Assessment, Analysis

Page 16

rating risks will save time and eliminate arguing about priorities. This system will help to ensure
that the business doesn't get distracted by minor risks while ignoring more serious risks that are less
well understood.
Ideally there would be a universal risk rating system that would accurately estimate all risks for all
organizations. But a vulnerability that is critical to one organization may not be very important to
another. So a basic framework is presented here that should be customized for the particular
organization.

4.1 Risk Analysis Steps

There are many different approaches to risk analysis. The general approach presented here is
based on these standard methodologies and is customized for application security. Let's start with
the standard risk model: Risk = Likelihood * Impact (This is explained in the section 5)
Step 1: Identifying a Risk
The first step is to identify a security risk that needs to be rated. The tester needs to gather
information about the threat agent involved the attack that will be used, the vulnerability involved,
and the impact of a successful exploit on the business. There may be multiple possible groups of
attackers, or even multiple possible business impacts. In general, it's best to err on the side of
caution by using the worst-case option, as that will result in the highest overall risk.
Step 2: Factors for Estimating Likelihood
Once the tester has identified a potential risk and wants to figure out how serious it is, the
first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely
this particular vulnerability is to be uncovered and exploited by an attacker. It is not necessary to be
over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high
is sufficient. Note that each factor has a set of options, and each option has a likelihood rating from
0 to 9 associated with it. These numbers will be used later to estimate the overall likelihood.
Step 3: Factors for Estimating Impact
When considering the impact of a successful attack, it's important to realize that there are
two kinds of impacts. The first is the "technical impact" on the application, the data it uses, and the
functions it provides. The other is the "business impact" on the business and company operating the
application. Ultimately, the business impact is more important. However, you may not have access
to all the information required to figure out the business consequences of a successful exploit. In
this case, providing as much detail about the technical risk will enable the appropriate business
representative to make a decision about the business risk.
Step 4: Determining the Severity of the Risk
In this step the likelihood estimate and the impact estimate are put together to calculate an
overall severity for this risk. This is done by figuring out whether the likelihood is low, medium, or
high and then do the same for impact. The 0 to 9 scale is split into three parts:

Risk and Threat Assessment, Analysis

Page 17

Likelihood and Impact Levels

0 to <3

LOW

3 to <6

MEDIUM

6 to 9

HIGH

Step 5: Customizing the Risk Rating Model

After the risks to the application have been classified there will be a prioritized list of what
to fix. As a general rule, the most severe risks should be fixed first. It simply doesn't help the overall
risk profile to fix less important risks, even if they're easy or cheap to fix. Remember that not all
risks are worth fixing, and some loss is not only expected, but justifiable based upon the cost of
fixing the issue. For example, if it would cost $100,000 to implement controls to stem $2,000 of
fraud per year, it would take 50 years return on investment to stamp out the loss. But remember
there may be reputation damage from the fraud that could cost the organization much more.
Step 6: Customizing the Risk Rating Model
Having a risk ranking framework that is customizable for a business is critical for adoption.
A tailored model is much more likely to produce results that match people's perceptions about what
is a serious risk. A lot of time can be wasted arguing about the risk ratings if they are not supported
by a model like this. There are several ways to tailor this model for the organization.

5. Generic Risk Model

A more generic risk model takes into consideration the Likelihood (e.g. probability of an
attack) and the Impact (e.g. damage potential):
Risk = Likelihood x Impact
The likelihood or probability is defined by the ease of exploitation, which mainly depends
on the type of threat and the system characteristics, and by the possibility to realize a threat, which
is determined by the existence of an appropriate countermeasure.
The following is a set of considerations for determining ease of exploitation:
1. Can an attacker exploit this remotely?
2. Does the attacker need to be authenticated?
3. Can the exploit be automated?
The impact mainly depends on the damage potential and the extent of the impact, such as the
number of components that are affected by a threat.
Examples to determine the damage potential are:

Risk and Threat Assessment, Analysis

Page 18

1. Can an attacker completely take over and manipulate the system?

2. Can an attacker gain administration access to the system?
3. Can an attacker crash the system?
4. Can the attacker obtain access to sensitive information such as secrets, PII
Examples to determine the number of components that are affected by a threat:
1. How many data sources and systems can be impacted?
2. How deep into the infrastructure can the threat agent go?
These examples help in the calculation of the overall risk values by assigning qualitative values
such as High, Medium and Low to Likelihood and Impact factors. In this case, using qualitative
values, rather than numeric ones like in the case of the DREAD model, help avoid the ranking
becoming overly subjective.

5.1 Countermeasure Identification

The purpose of the countermeasure identification is to determine if there is some kind of
protective measure (e.g. security control, policy measures) in place that can prevent each threat
previously identified via threat analysis from being realized. Vulnerabilities are then those threats
that have no countermeasures. Since each of these threats has been categorized either with STRIDE
or ASF, it is possible to find appropriate countermeasures in the application within the given
category. Provided below is a brief and limited checklist which is by no means an exhaustive list for
identifying countermeasures for specific threats. Once threats and corresponding countermeasures
are identified it is possible to derive a threat profile with the following criteria:
1. Non mitigated threats: Threats which have no countermeasures and represent vulnerabilities
that can be fully exploited and cause an impact
2. Partially mitigated threats: Threats partially mitigated by one or more countermeasures
which represent vulnerabilities that can only partially be exploited and cause a limited
impact
3. Fully mitigated threats: These threats have appropriate countermeasures in place and do not
expose vulnerability and cause impact

5.2 Mitigation Strategies

The objective of risk management is to reduce the impact that the exploitation of a threat can
have to the application. This can be done by responding to a threat with a risk mitigation strategy. In
general there are five options to mitigate threats
1. Do nothing: this implies hoping for the best

Risk and Threat Assessment, Analysis

Page 19

2. Inform about the risk: e.g. warning user population about the risk
3. Mitigate the risk: e.g. by putting countermeasures in place
4. Accept the risk: e.g. after evaluating the impact of the exploitation (business impact)
5. Transfer the risk: e.g. through contractual agreements and insurance
6. Terminate the risk: e.g. shutdown, turn-off, unplug or decommission the asset
The decision of which strategy is most appropriate depends on the impact an exploitation of
a threat can have, the likelihood of its occurrence, and the costs for transferring (i.e. costs for
insurance) or avoiding (i.e. costs or losses due redesign) it. That is, such decision is based on the
risk a threat poses to the system. Therefore, the chosen strategy does not mitigate the threat itself
but the risk it poses to the system. Ultimately the overall risk has to take into account the business
impact, since this is a critical factor for the business risk management strategy. One strategy could
be to fix only the vulnerabilities for which the cost to fix is less than the potential business impact
derived by the exploitation of the vulnerability. Another strategy could be to accept the risk when
the loss of some security controls (e.g. Confidentiality, Integrity, and Availability) implies a small
degradation of the service, and not a loss of a critical business function. In some cases, transfer of
the risk to another service provider might also be an option.
1

STRIDE

STRIDE is a system developed by Microsoft for thinking about computer security threats. It
provides a mnemonic for security threats in six categories.
The threat categories are:
Spoofing of user identity
Tampering
Repudiation
Information disclosure (privacy breach or data leak)
Denial of service (D.o.S)
Elevation of privilege
The STRIDE name comes from the initials of the six threat categories listed. It was initially
proposed for threat modelling, but is now used more broadly.

Spoofing. Spoofing is attempting to gain access to a system by using a false identity. This
can be accomplished using stolen user credentials or a false IP address. After the attacker
successfully gains access as a legitimate user or host, elevation of privileges or abuse using
authorization can begin.

Tampering. Tampering is the unauthorized modification of data, for example as it flows

over a network between two computers.

Repudiation. Repudiation is the ability of users (legitimate or otherwise) to deny that they
performed specific actions or transactions. Without adequate auditing, repudiation attacks
are difficult to prove.

Risk and Threat Assessment, Analysis

Page 20

Information disclosure. Information disclosure is the unwanted exposure of private data.

For example, a user views the contents of a table or file he or she is not authorized to open,
or monitors data passed in plaintext over a network. Some examples of information
disclosure vulnerabilities include the use of hidden form fields, comments embedded in Web
pages that contain database connection strings and connection details, and weak exception
handling that can lead to internal system level details being revealed to the client. Any of
this information can be very useful to the attacker.

Denial of service. Denial of service is the process of making a system or application

unavailable. For example, a denial of service attack might be accomplished by bombarding a
server with requests to consume all available system resources or by passing it malformed
input data that can crash an application process.

Elevation of privilege. Elevation of privilege occurs when a user with limited privileges
assumes the identity of a privileged user to gain privileged access to an application. For
example, an attacker with limited privileges might elevate his or her privilege level to
compromise and take control of a highly privileged and trusted process or account.

Table: STRIDE Threats and Countermeasures

Threat

Countermeasures

Spoofing user identity

Use strong authentication.

Do not store secrets (for example, passwords) in plaintext.
Do not pass credentials in plaintext over the wire.
Protect authentication cookies with Secure Sockets Layer (SSL).

Tampering with data

Use data hashing and signing.

Use digital signatures.
Use strong authorization.
Use tamper-resistant protocols across communication links.
Secure communication links with protocols that provide message

Risk and Threat Assessment, Analysis

Page 21

integrity.
Repudiation

Create secure audit trails.

Use digital signatures.

Information disclosure

Use strong authorization.

Use strong encryption.
Secure communication links with protocols that provide message
confidentiality.
Do not store secrets (for example, passwords) in plaintext.

Denial of service

Use resource and bandwidth throttling techniques.

Validate and filter input.

Elevation of privilege

Follow the principle of least privilege and use least privileged service
accounts to run processes and access resources.

6. Risk Management *
Risk management is the act of implementing security safeguards and controls. It also entails
monitoring for changes and responding with enhanced strategies. The security rule addresses the
ongoing management of risks in several areas:

Security measures implemented to comply with standards and implementation specifications

adopted must be reviewed and modified as needed to continue provision of reasonable and
appropriate protection of electronic protected health information.

Implement procedures to regularly review records of information system activity, such as

audit logs, access reports, and security incident tracking reports

Perform a periodic technical and nontechnical evaluation, based initially upon the standards
and implemented under this rule and subsequently, in response to environmental or operational
changes affecting the security of electronic protected health information that establishes the extent
to which an entitys security policies and procedures meet the requirements of this subpart.
The success of the risk management process depends heavily on the commitment of those involved
with safeguarding an application or system to implement the approved control recommendations.
Therefore, it is strongly suggested that some type of follow-up be scheduled around two to three
months after the final risk analysis report is delivered and signed. The purpose of the follow-up is to
verify progress on risk reduction and maintain open communications when obstacles are
encountered.

Risk and Threat Assessment, Analysis

Page 22

Risk analysis and risk management are ongoing processes. A Security Life Cycle Approach, has a
diagram that illustrates this ongoing risk management process, as illustrated in figure

7. Learning Outcomes
We learned following from the security perspective:
Various types of threats, vulnerabilities and risks
Threat modeling
Risk analysis
Risk management
Security principles for managing threats and risks
Mitigating procedures
This self-study gave us a healthy information about various security principles and techniques
followed to encounter threats and risk in digital world

8. Case Study *
A sample version of the e-commerce application is taken as case study. This version allows
users to browse through a catalogue and add products to a cart. The current sample also allows the
creation, update and deletion of the different products with the restriction that only the user
Administrator is allowed to do these actions. An analysis was made to choose the framework for

Risk and Threat Assessment, Analysis

Page 23

developing e-commerce applications and the .Net MVC (Model-View-Controller) framework was
chosen. When using the MVC framework methodology, the application is divided into three
different components: the models, the views and the controllers. The models are the part of the
application that allows maintaining a state which is linked to a database. The views are used to
display the applications user interface. The controllers are used to handle the interaction with the
end user. While the views are used to display information, the controller is used to handle what is
shown in the views. One of the main reasons that the .Net MVC framework methodology was
chosen is because it helps develop a secure application taking into account the different threats that
were found in the threat modeling process and implement the security constraints that were
introduced in the modeling stages. MVC allows the developer to use different syntaxes to indicate
which code will be executed only and which code will be executed and the results shown. The use
of these different syntaxes helps protect the site against cross-site scripting and HTML injection
attacks. Embedded into MVC, there is an Account Controller class which allows developers include
authentication in their application. MVC also allows the creation of usernames and roles through the
ASP.Net website administration tool. By assigning different roles to the users, the developer can
restrict the access to certain parts of the application, for example in this case, only the users who
have administrative roles are allowed to create, update or delete the products through the website.
To ensure that the information transmitted in the webpage uses a secure channel, the developer can
make use of the syntax.
8.1 Analysis
In this first stage, the organizational setting is studied and the different actors, goals and
dependencies are identified.
The different actors that have been defined for this model are:
Customer: Person who will make his purchase in the online store.
Online Store Administrator: Person that will be in charge of the stores management.
Provider: A wholesale that will provide the products for the online store.
Employee: Person who will take care of the online sales (dispatch, place orders) and
verify customers identity.
Post office: Facility authorized to deliver the products to the customers.
Payment processing agency: Agency that will take care of the payment processing.
The result of the systems analysis in this stage is the Security Enhanced Actor Diagram and the
corresponding Security Enhanced Goals Diagrams.
Security Enhanced Actor Diagram
The following security enhanced actor diagram depicts each actor with their goals, soft goals,
security constraints and the dependencies that they have with each other.
Customer: The actor Customers main goal is Buy Handmade Products. For this, he depends on
the online store, so the actor Online Store becomes the dependee and the actor Customer the
depender. At the same time, the security constraint Protect Customers Identity is imposed by the
actor Customer in this relationship.

Risk and Threat Assessment, Analysis

Page 24

Online Store Administrator: The actor Online Store Administrators main goals are: Sell the
products, manage the stock, and obtain the products. To fulfill the goal Sell the products and
Manage the stock, this actor (depender) depends on the actor Online Store (dependee) and to
fulfill the goal Obtain the products it depends on the actor Provider (dependee).
Online Store: The actor Online Stores goals are: Place Order, Dispatch Products, and
Troubleshoot Customers issues. To fulfill the goals Place the order, Dispatch the products, and
Troubleshoot Customers issues, this actor (depender) will depend on the actor Employee
(dependee).The security constraint Keep Customers Info Safe is introduced in the dependency link
for achieving the Place order and Dispatch products goals.
Provider: The actor Providers main goal is commercialize the products. For this, actor Provider
(depender) depends on the actor Online Store (dependee). This actor uses the resource Handmade
products for which he depends on the actor Manufacturers (dependee).
Employee: The actor Employees main goal is verify Customers identity. For this, it (depender)
depends on the actor Payment Processing Agency (dependee).
Payment Processing Agency: The goal of the actor Payment Processing Agency is Process the
payment. This depender depends on the actor Customer (dependee) who is going to provide with
all the necessary information to be validated. The security constraint Keep Customers
information secure is introduced in the relationship
Customer: For the goal Process Payment to be achieved by the actor Payment Processing
Agency, the task that the actor Customer is going to perform is Enter information. Similarly, for
the soft goal Become a popular store to be achieved by the actor Online Store, this actor is going
to have to perform the task Give positive feedback.
Employee: The actor Employee is going to help the actor Online Store achieve its goal Dispatch
Order by performing the tasks Check Order and Verify Identity. The Actor Online Store also
depends on this actor to achieve the goal Place Order. For this, the tasks that the actor Employee
is going to perform are Verify Products and Retrieve Order. One last goal that this actor is going
to help achieve is Troubleshoot Customers issues. This goal is going to be achieved by
performing the task Retrieve Order. The security constraint Keep Customers info safe imposed
by the actor Customer is also shown in this diagram.
Manufacturer: The actor Manufacturer is only involved in providing the resource Handmade
Products.

Risk and Threat Assessment, Analysis

Page 25

Test Case 1: Data Modification through SQL Injection Precondition: The attacker tries to gain
access to the database in order to modify the information in the tables by injecting SQL queries
through input fields. System expected security reaction: The system should not allow the attacker
obtain any information that could help him gain information about the database. Every input field
should be validated and good programming techniques should be used. Discussion: The attacker
will try to find if the website has any vulnerable input fields that can provide information about the
kind of database that is being used as well as the database configuration and design. Once this
vulnerability has been identified, the attacker injects SQL sentences with malicious purposes. Test
case result: In the first model, this kind of threat was not considered; therefore, it is possible for the
attacker to find input fields that allow him inject SQL sentences. In the second model, after doing
the threat modeling of the system, this threat was identified. The system developer used
programming techniques that dont allow inject SQL sentences in the forms. Every input field is
also validated.
Test Case 2: Denial of service Precondition: The attacker tries to make the website unavailable by
performing a DoS attack. System expected security reaction: The system should be able to detect
that someone is trying to perform a DoS attack. A notification should be sent by the system
whenever a DoS attack has been detected. Discussion: The attacker can maliciously cause the
system to become unavailable by performing a DoS Attack. The attacker can use numerous
methods, i.e., he can send a number of SYN requests to the system and cause a SYN flood. The
system should be designed and configured in such a way whereby it can detect this kind of attacks.
Network configurations play an important role to mitigate this threat, for example, the existence of
firewalls that can help detect and block this kind of threats as well as send a notification
Test case result: In this model, this threat was identified and the actor System Developer was
introduced. One of the main goals of this actor is to configure the system in a way that it is
protected from attackers. To achieve this goal, this actor is going to check the network configuration
and also make sure that there are not any open back doors through which the attacker can access the
system

Risk and Threat Assessment, Analysis

Page 26

Test Case 3: Fraudulent Transaction: Precondition: The attacker will try to make a fraudulent
transaction by using stolen login information and by performing a force brute attack to obtain the
password. System expected security reaction: The system should use a secure connection when
sending personal information to third parties. The system should be able to recognize when an
attacker is trying to log in using a stolen identity. The system must enforce the customer to set a
strong password.
Discussion: Attackers have found different ways to make fraudulent transactions. One of them is the
use of a stolen identity. It is easy for an attacker to obtain login information if the information that is
sent through the web is not sent through a secure connection. Attackers also use force brute attacks
to find passwords and gain access to accounts. The system should be able to provide a secure
environment to the customer. The system is usually in danger of this kind of attack at the time the
customer is going to perform the payment. A way to mitigate this is to use a secure channel to send
the information to a third party. The system developer should make sure that the third party who is
going to be in charge of processing the payment also provides the highest level of security.
Test case result: The first model is designed keeping in mind that the customers information should
be kept private all the time, therefore a secure channel is always used. As for making sure that the
third party provides the same level of security, it is uncertain. In the second model, one of the goals
of the actor System Developer is to make sure that the third party provides a high level of security,
wherefore, this threat is mitigated.
When developing the application, the use of the attribute that the MVC framework provides, helps
ensure that the information entered by the user is sent through a secure channel. The use of this
secure protocol, which encrypts the information with two keys, prevents attackers from intercepting
the information that is transmitted through the web. The use of the ASP .Net Web Site
Administration tool to administrate the different accounts also helps increase the level of security of
the application. For example, when creating a new account, a function enforces users to create a
password that contains at least 6 characters. The capability to allow the assignation of roles to
different users helps the developer restrict the access to certain parts of the application. By
integrating threat modeling in the development process, different risks are mitigated in the early
stages of the development as well as in the late stages, being it is the development of the application
itself. The developer keeps in mind the different threats that need to be mitigated when choosing
what framework to use in the development. These comparisons have helped to have a clearer picture
of how integrating threat modeling in the Secure Agent-Oriented Software Development
methodology Secure Tropos, increases the security level of the resulting application. This is
achieved by adding actors, security constraints and tasks that help mitigate the different risks and
vulnerabilities that put in danger the security of a system.

Summary *
Threat modeling is applied not only applied to web applications but also to embedded systems,
cloud applications, wireless sensor networks, network tools etc. for threat evaluation and risk
analysis along with mitigation suggestions to them. Threat modeling for a application takes a lot of
brainstorming sessions to collect all information of the assets, trust boundaries and threat profiles
possible on the assets. The approach of Microsoft is followed by most of the application developing
companies and is the most acceptable one. Along with threat evaluation, it takes care of business
aspects of a software in a stipulated time period. This is a software centric approach. Currently
software centric approach dominates over the other two. However it is beneficial to use the
combined approach. Whenever it comes to industries, a hybrid approach with a report generation
capability is hoped to get preferred. The model allows security decisions to be made rationally, with
all the information on the table. The alternative is to make on the fly security decisions with no
support which definitely harms performance and security of the system. The threat and risk

Risk and Threat Assessment, Analysis

Page 27

modeling process naturally produces an assurance argument that can be used to explain and defend
the security of a system.

References *
[1]
[2]
[3]
[4]
[5]

B. Mains. (2010, September) Introduction to ASP .NET MVC 2.0. [Online]. Available:
http://dotnetslackers.com/articles/aspnet/Introduction-to-ASP-NET-MVC-2-0.aspx.
Y. Lee, J. Lee and Z. Lee, Integrating Software Lifecycle Process Standards with
Security Engineering, Computers & Security, vol. 21, no. 4, pp. 345-355, Aug. 2002
http://en.wikipedia.org/wiki/Risk
Redmond A: Microsoft (2010). Microsoft Security Development Lifecycle Version 5.0.
OWASP. (2006). OWASP CLASP (Comprehensive, lightweight application security
process) Project. Retrieved August 20, 2009,[Online] Available: http://www.owasp.org