Threat modeling

Introduction
The term Threat Modeling has become quite popular in recent years.
Microsoft has published a book about its process and includes Threat Modeling as
a key activity in its Secure Software Development Life Cycle (S-SDLC).
A threat model is essentially a structured representation of everything
information that affects the security of an application. In itself, it is a view of the application
and its environment through the "glasses" of security.
Threat modeling is a process to capture, organize, and analyze all of this
information. It allows making informed decisions about security risks in the
applications. In addition to producing a model, efforts for threat modeling
they typically also produce a prioritized list of security improvements in the requirements,
design and implementation of applications.

Objectives of Threat Modeling

Threat modeling is a procedure to optimize security of the
red/applications/Internet by identifying objectives and vulnerabilities, and then
define the countermeasures to prevent or mitigate the effects of threats to the system.
A threat is a potential undesirable or real event that can be malicious (such as a
DoS attack) or accidental (failure in a storage device). The modeling of
threats is a planned activity for the identification and evaluation of threats
and vulnerabilities in applications.

Threat Modeling throughout the Life Cycle

Threat modeling is best applied continuously throughout a project.
software development. The process is essentially the same but at different levels of
abstraction, although the information becomes more and more granular throughout the cycle of
life. Ideally, a high-level threat model should be defined in the phase of
planning, and then refined throughout the life cycle. As more
details to the system, they are created and exposed to new attack vectors. The process of
Risk modeling in progress must examine, diagnose, and address these threats.
Refining the system for the new threats it will be exposed to is part of
natural of the process. For example, when selecting a particular technology, such as Java for
For example, we must take responsibility for identifying the new threats that are created.
for that choice. Even the implementation options, such as the use of expressions
Regulations for a validation introduce new potential threats to address.

Threat Modeling - Generic Steps

For there to be a threat to an application, there must be a combination where
the probability and the impact together are sufficiently significant to make
something about it. Below is a draft of a generic methodology for
threat modeling
Scope of the evaluation
System modeling
Threat identification
Vulnerability identification
Examination of the threat history
Assessment of the impact on the business

Development of a response plan against security threats

To understand if an application is secure enough or not, one must look for
combinations of these ingredients that lead to real threats. The
The true trick for threat modeling is not to waste time on the threats.
that are too implausible or too inconsequential. Caution should be exercised with
the threat modeling processes that are inefficient due to the reduction of
search space; of the possible threats to eliminate that are very unlikely;
or those that have a minimal impact.
There is no 'correct' way to evaluate the search space of possibilities.
threats. But there are 'wrong' ways. The attempt to evaluate all possible
combinations of threat agents, attacks, vulnerabilities, and impact, is a
waste of time and effort. There are many automated tools that take this
approach: the collection of a large amount of data and the production of thousands of possibilities
threats. Generally, it is more productive to focus on the search for threats with
high probability and high impact.
The basic threat modeling process consists of the following generic steps.
The process of exploring the search space is iterative and constantly refined.
based on what they have done so far. Thus, for example, starting with all
Possible vulnerabilities tend to be useless, as most of them are not exploitable.
by the threat agents, protected by a countermeasure or not leading to one.
direct consequence. Therefore, in general, it is better to start with the factors that make
the difference.
Scope of the evaluation: the first step is always to understand what is at stake. The
identification of tangible assets, such as databases or confidential files or
sensible, usually it is easy. The understanding of the capabilities provided by the
application and the assessment of these is more difficult. Less concrete things, such as the
reputation and commercial renown are the hardest to measure, but they are often the
more critical.
Identify threat agents and potential attacks: a fundamental part of modeling
of threats is a characterization of the different groups of people that could be
capable of attacking the application. These groups must include internal and external elements,
and the execution of both, unintentional errors and malicious attacks.
Understand existing countermeasures: the model must include existing countermeasures.
Identify exploitable vulnerabilities: once you have an understanding of the
security in the application, then the new vulnerabilities can be analyzed. The
search is for vulnerabilities related to possible attacks and the
negative consequences that have been identified.
Identify priority risks: prioritization is everything in threat modeling already
that there are always many risks that simply do not deserve any attention. For each
threat, a probability and impact factor must be estimated to determine the risk
general or the level of severity.
Identifying countermeasures to reduce the threat: the last step involves
identify the countermeasures to reduce the risk to acceptable levels.

Benefits
If done correctly, threat modeling provides a clear 'line of sight' through
from a project that justifies security efforts. Threat modeling allows
that security decisions are made rationally, with all the information about
the table. The alternative consists of making instinctive safety decisions without support. The
the threat modeling process naturally produces a security argument that
it can be used to explain and defend the security of an application. An argument for
insurance begins with some high-level exposures, and justifies them either with
subexposures or evidence.

Application of threat modeling

Introduction
Threat modeling is an approach to the security analysis of an application.
It is a structured approach that allows for the identification, quantification, and management of risks.
security associated with an application. Threat modeling is not an approach
for code review, but rather to complement that review. The inclusion of
threat models in the SDLC can help ensure that applications are being
developing with security built in from the start.
This combined with the documentation produced as part of the modeling process of
threats, can give the reviewer a greater understanding of the system; it allows him to see where
there are the entry points and the associated threats with each of these points. The
the concept of threat modeling is not new, but a change has occurred
mindset in recent years. Modern threat modeling looks at the system from
the perspective of a potential attacker, as opposed to the point of view of the defender.
Microsoft has been a strong advocate of the process over the last few years. They have
threat modeling made a central component in their SDLC, which they claim
What is one of the reasons for the increased security of its products in recent times?
years.
When source code analysis is performed outside the SDLC on certain applications
existing, the results of threat modeling help in the reduction of the
complexity of code analysis, promoting an initial in-depth approach
versus the scope of the first approach. Instead of reviewing the entire source code with the same
focus, priority can be given to the review of the security code of the components,
whose threat modeling has classified as high-risk threats.

Steps of threat modeling

The threat modeling process can be broken down into 3 high-level steps:
Step 1 - Decompose the application: the first step in the modeling process
threats focus on deepening the knowledge of the application and determining how
interacts with external entities. This implies the creation of use cases to understand
how to use the application, identifying entry points to see where a
A potential attacker could interact with the application and the identification of assets. For
example: items/areas that the attacker would be interested in and the identification of the levels of
trust that the rights of access that the application will grant to the
external entities. This information is recorded in the document "Threat Model" and
It is also used to create data flow diagrams (DFDs) for the application.
DFDs show the different paths through the system, highlighting the boundaries.
of privileges.
Step 2 - Determine and prioritize threats: the identification of critical threats is
It is carried out with a threat categorization methodology. A can be used.
threat categorization as STRIDE (Spoofing, Tampering, Repudiation, Information)
Disclosure, Denial of Service, Privilege Escalation
application security (Application Security Framework, ASF for its acronym in English)
that defines the categories of threats such as auditing and logging, authentication,
authorization, configuration management, protection of data stored and in transit,
data validation and exception management.
The objective of threat categorization is to help identify both those of the attacker.
(STRIDE) as well as from the defender's point of view (ASF). The DFDs
produced in step 1 help to identify potential threat targets from the
attacker's perspective, such as data sources, processes, data flows, and interaction
with the users. These threats can later be identified as the roots
threat trees; there is one tree for each threat objective. From the point of
defensive view, the ASF categorization helps to identify threats such as
weaknesses in security controls for this type of threats. Lists of threats
common examples can help in the identification of this type of threat. The
use and abuse cases can illustrate how measures can be omitted
existing protections, or when there is a lack of that protection. The determination of
security risk for each threat can be determined using a model of
risks based on values like DREAD (Damage, Reproducibility, Exploitability, Affected)
users, Discoverability (its acronym in English) or a less qualitative risk model
subjective based on general risk factors (for example, probability and impact).
Step 3 - Determine countermeasures and mitigations: the lack of protection against a
threat could indicate a vulnerability whose exposure to risk could be mitigated with the
application of a countermeasure. Such measures can be identified using lists of
mapping threats-countermeasures. Once a risk classification corresponds
With the threats, it is possible to classify the threats from highest to lowest risk, and provide
priority to mitigation efforts, how to respond to such threats by applying the
identified measures. The risk mitigation strategy may involve the assessment
from those threats ranging from the impact on the business they pose, to the reduction of
risk. Other options could include taking on the risk, assuming that the impact on the
the business is acceptable due to compensatory controls, reporting the threat to the
user, mitigating the risk it represents through the application of a control or,
least preferred option, which is to do nothing.
Each of the previous steps must be documented to know how they are carried out.
end. The resulting document is the threat model for the application. In this guide
An example will be used to help explain the concepts behind modeling.
threats. The same example will be used throughout each of the 3 steps as a
help for learning. The example that will be used is a library website of a
university. Each of the steps in the threat modeling process is described
in detail below.

Decompose the Application

The objective of this step is to gain an understanding of the application and how it interacts with
external entities. This objective is achieved through the collection and documentation of
information. The process of collecting information is carried out using a
clearly defined structure, which ensures that the correct information is collected. This
structure also defines how information should be documented for
produce the threat model.

Threat modeling information

The first element of the threat model is the information related to the model.
of threat. This must include the following:
Application name
Application version
a high-level description of the application
Document owner: the owner of the threat modeling document
Participants: the participants involved in the threat modeling process for
this application
Reviewer: the reviewer(s) of threat modeling

Threat modeling

Version of the
1.0
application

The university library's website is the first implementation.

from a website to offer to librarians and library users
(students and university staff), online services.
Since it is the first implementation of the website, the functionality will be
limited. There will be 3 users of the application:

Description Students
Personal
Librarians
Staff and students will be able to log in to search for books and the
staff can request books. Librarians will be able to enter,
add books, add users and search for books.

Owner of the Name and surname of the responsible person

document

Participants Name of the project participants

Reviewer Name and surname of the reviewer

External dependencies
External dependencies are elements outside the application code that can
posing a threat to the application. These elements are still often within the
control of the organization, but possibly not under the control of the development team. The
The first area to observe when investigating external dependencies is how it will be
implement the application in a production environment, and what are the requirements regarding
this. This implies observing how the application is or is not intended to be executed. By
For example, if it is expected that the application will run on a server that has
strengthened with the organization's standard and it is expected to be placed
Behind a firewall, this information must be documented in the dependencies section.
externally. External dependencies must be documented as follows:

ID: a unique identifier assigned to the external dependency.

a textual description of the external dependency.

Entry points
The entry points define the interfaces through which potential attackers
they can interact with the application or feed it with data. So that a potential attacker
to attack an application, there must be entry points. The entry points of a
Applications can overlap, for example, each web page in a web application.
they can contain multiple entry points. The entry points must be documented
in the following way:
ID: a unique identifier assigned to the entry point. This will be used for cross-referencing.
reference the entry point to the threats or vulnerabilities that are identified. In the
In the case of the layer entry points, a greater-less notation should be used.
Name: descriptive name that identifies the entry point and its purpose.
Description: a textual description that details the interaction or process that occurs in
the entry point.
Confidence levels: access level required at the documented entry point. They will be
cross-references with the confidence levels defined later.

Assets
The system must have something that interests the attacker; these elements/areas of interest are
they are essentially the targets of a threat.
to say, are the reason why threats will exist. Assets can be both physical
as logicals (abstract). For example, an asset of an application could be a list of
customers and their personal information, this is a physical asset. An abstract asset could be the
reputation of an organization. These assets are documented in the model of
threats in the following way:
ID: a unique identifier is assigned to identify each asset. This will be used to
cross-reference the asset with the threats or vulnerabilities that are identified.
Name: descriptive name that clearly identifies the asset.
a textual description of what the asset is and what needs to be protected.
Confidence levels: the level of access required to access the entry point is
Document here. These will be cross-references with the defined confidence levels.
in the next step.

Confidence levels
The levels of trust represent the access rights that the application will have.
grant to external entities. The levels of trust have a cross-reference with
the entry points and assets. This allows us to define access rights or privileges
required at each entry point, and those necessary to interact with each asset. The
levels of trust are documented in the threat model as follows:
ID: unique number assigned to each level of trust. This is used for cross-referencing.
of the level of confidence with entry points and assets.
Name: descriptive name that allows identifying the external entities to which it is assigned
has granted this level of trust.
Description: textual description of the level of confidence that details the external entity that
has granted the level of trust.

Data Flow Diagram (DFD)

All the collected information allows for accurate modeling of the application through the use
data flow diagrams (DFDs). The DFD will provide a better understanding of
the application, providing a visual representation of how the application processes the
Data. The focus of the DFD is on how data moves through the application and the
what happens to the data as they move. The DFDs are hierarchical structures,
so they can be used to decompose the application into subsystems and subsystems
of lower level. The high level of the DFD will clarify the scope of the application that
is modeling. Low-level iterations will allow focusing on the processes
involved in the processing of specific data. There are a number of symbols that are
used in DFD for threat modeling.