 |
Security threat modeling, or threat
modeling, is a process of assessing and documenting a
system’s security risks. Security threat modeling
enables you to understand a system’s threat profile by
examining it through the eyes of your potential foes.
With techniques such as entry point identification,
privilege boundaries and threat trees, you can identify
strategies to mitigate potential threats to your system.
Your security threat modeling efforts also enable your
team to justify security features within a system, or
security practices for using the system, to protect your
corporate assets.
|
|
There are five aspects to security
threat modeling:
- Identify threats. The first thing
to do is to identify assets of interest, you first
model the system either with
data flow diagrams
(DFDs) or UML
deployment diagrams. From these diagrams, you
can identify entry points to your system such as
data sources, application programming interfaces
(APIs), Web services and the user interface itself.
Because an adversary gains access to your system via
entry points, they are your starting points for
understanding potential threats. To help identify
security threats you should add “privilege
boundaries” with dotted lines onto your diagrams.
Figure 1 depicts an example
deployment diagram used to explain the boundaries
applicable to
testing a relational database. A
privilege boundary separates processes, entities,
nodes and other elements that have different trust
levels. Wherever aspects of your system cross a
privilege boundary, security problems can arise. For
example, your system’s ordering module interacts
with the payment processing module. Anybody
can place an order, but only manager-level employees
can credit a customer’s account when he or she
returns a product. At the boundary between the two
modules, someone could use functionality within the
order module to obtain an illicit credit.
- Understand the threat(s). To
understand the potential threats at an entry point,
you must identify any security-critical activities
that occur and imagine what an adversary might do to
attack or misuse your system. Ask yourself questions
such as “How could the adversary use an asset to
modify control of the system, retrieve restricted
information, manipulate information within the
system, cause the system to fail or be unusable, or
gain additional rights. In this way, you can
determine the chances of the adversary accessing the
asset without being audited, skipping any access
control checks, or appearing to be another user.
To understand the threat posed by the interface
between the order and payment processing modules,
you would identify and then work through potential
security scenarios. For example, an adversary who
makes a purchase using a stolen credit card and then
tries to get either a cash refund or a refund to
another card when he returns the purchase.
- Categorize the threats. To
categorize security threats, consider the
STRIDE (Spoofing, Tampering, Repudiation,
Information disclosure, Denial of Service, and
Elevation of privilege) approach. Classifying a
threat is the first step toward effective
mitigation. For example, if you know that there is a
risk that someone could order products from your
company but then repudiate receiving the shipment,
you should ensure that you accurately identify the
purchaser and then log all critical events during
the delivery process.
- Identify mitigation strategies. To
determine how to mitigate a threat, you can create a
diagram called a threat tree. At the root of the
tree is the threat itself, and its children (or
leaves) are the conditions that must be true for the
adversary to realize that threat. Conditions may in
turn have subconditions. For example, under the
condition that an adversary makes an illicit
payment. The fact that the person uses a stolen
credit card or a stolen debit/check card is a
subcondition. For each of the leaf conditions, you
must identify potential mitigation strategies; in
this case, to verify the credit card using the XYZ
verification package and the debit card with the
issuing financial institution itself. Every path
through the threat tree that does not end in a
mitigation strategy is a system vulnerability.
-
Test. Your threat
model becomes a plan for penetration testing.
Penetration testing investigates threats by directly
attacking a system, in an informed or uninformed
manner. Informed penetration tests are effectively
white-box tests that reflect knowledge of the
system’s internal design , whereas uninformed tests
are black box in nature.
|
 |
Figure 1. A UML
deployment diagram with
threat/privilege boundaries.
|
|
|
This book is very accessible, presenting the complex
subject of modeling secure systems in a manner that
everyone can understand. The material is supported by
three running case studies that are used to explore the
various aspects of security threat modeling. These case
studies, with full security threat models, are also
presented in the appendix—not only can you see the
solutions evolve throughout each chapter, you also get
each solution in its entirety. If security concerns are
an important issue for your project team, this is the
book for you. |
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
