RE: Threat Modeling

["Mark Curphey" <mark () curphey com>]

I know a lot about CRAMM from former work days, you can figure that out ;-)

CRAMM is a general / generic Risk Assessment tool for information securtity.
What I was looking for / referring to is a tool or technology that can help
with application specific threat modeling. By that I think the basic concept
is similar but following a structured methodology to decompose an
application, understand the points of attack, application profile (history
of vulns / issues, implications of technoogy etc) and ensure that adequate
countermeasures are in the place.

Here is the section on Threat Modeling from the OWASP Testing Guide (minus
images)

Threat Modeling
Threat modeling has become a popular technique to help system designers
think about the security threats that their systems will face. It enables
them to develop mitigation strategies for the potential vulnerabilities.
Threat modeling helps people focus their inevitably limited resources and
attention on the parts of the system that most require it, thus taking a
pragmatic approach. 

Threat models should be created as early as possible in the software
development life cycle, and should be revisited as the application evolves
and development progresses.
Despite its name, that has now become endemic in the industry thanks to the
Writing Secure Code book (Mike Howard and David LeBlanc), threat modeling is
really a traditional Risk Assessment for applications. Threat modeling is an
essential practice, and it is recommended that all applications have a
threat model developed and documented.
To develop a threat model, we recommend taking a simple approach that
follows the NIST 800-30   standard for risk assessment. This approach
involves defining the assets, understanding the vulnerabilities (technical,
operational and management), and examining the threats. 

§       Decompose Application
§       Define Assets
§       Explore Potential Vulnerabilities
§       Explore Potential Threats
§       Create Mitigation Strategies

Decomposing the Application
Without understanding how the application works, it is impossible to
understand all of the potential ways an attacker is going to break it.
Therefore, it is recommended to decompose the application into its core
components in order to understand exactly how it works. 
Experience has shown that the Unified Modeling Language (or UML) can be an
exceptionally useful tool to help visually model applications. UML was
developed as a modeling language to create unambiguous models of software.
It has developed into a universally adopted way to model various things,
from a business process to a workflow.
UML defines various ways to develop models, and while all maybe useful, the
most commonly used models are Use Cases, Sequence Diagrams and Component
Models. Detailed models may involve state transition and others such as
collaboration models for authorization systems.
The models will develop and evolve as understanding about the application
increases. Do not become fixated on creating perfectly accurate models. As
the models are developed, list the issues as they become obvious for
examination in the vulnerability and threat phases. 

 
Figure 1
Figure 1 above is a UML Use Case diagram. This diagram would typically be
supported by textual descriptions of the Use Cases that explain exactly how
each user interaction occurs. Use Cases are important to help understand
which application functions are available to the user. 

 
Figure 2
Figure 2 is a UML sequence diagram. Sequence diagrams trace the data flow
between system components. They are particularly useful for examining
component to component communications and understanding the message
transformations that occur at each component. The above diagram could be a
simple model of a user logging in, where the user passes a username and
password to the web server that forwards the request to the application
server. The application server then processes the variables and passes them
to the database query that compares the username and password to those
stored in the database, and message 5 returns a boolean answer. Message 6
then generates a cookie that is passed to the browser in message 7 if the
login was successful. 

Sequence diagrams are extremely useful to identify questions about security
issues. For example, is there transport security for message 2? Is message 3
created with a prepared statement?

Defining and Classifying Assets
Assets are the things that an attacker wants to either steal or change, and
that the application needs to protect. After successfully decomposing the
application, the next step is to define the assets. Assets are classed as
either physical or intangible. 

Physical assets are usually fairly easy to define as they can be held -
items such as web servers, computers, buildings, web pages, source code, and
so on. Intangible assets include intellectual property, accounting assets
such as "good will", and electronic organizational records such as customer
records.
The international standard ISO 17799 requires organizations wishing ISO
17799 compliance to establish an asset classification regime. Asset
classification is used to break data down into types of data and data sets
which have different protection requirements. For example, the password
table in a database should be protected differently than the web page color
preferences table.
A matrix or list should be created, consisting of assets that have been
discovered along with their likely protection and retention requirements.
Explore Potential Vulnerabilities
Vulnerabilities can be organized into three primary groups:
§       Technical
§       Management
§       Operational
While other areas of this testing framework will create tests specifically
aimed at extracting these vulnerabilities (particularly technical
vulnerabilities), it is useful to explore them during the development of a
threat model. Many issues will become obvious before the traditional testing
takes place. A list of potential vulnerabilities should be created by
looking at the data flow and state transitions of each asset and its
operational environment.
Technical vulnerabilities may include issues such as a lack of encryption
between the data flow end points, or no input validation. 

Management issues might include a lack of policy or standards for components
developed in specific languages, or a lack of configuration guidelines for a
database server. 
Operational vulnerabilities may include issues such as having no defined
process to review audit logging information, or the change control
procedures for component updates. 
All of the potential vulnerabilities that affect each asset should be
grouped and listed. 

Explore Potential Threats
A threat is a potential malicious event to the system. By systematically
exploring attackers' motives, it is possible to devise a threat matrix
outlining which threats affect which assets. The important thing to note
when devising a threat matrix is the concept of prevalence. It is easy to
dream up potential threats that could occur if the moon lined up with the
stars. However, the likelihood of this event occurring may be very small
When developing threats we suggest always asking the questions:

§       What would an attacker do? 
§       How would they do it?
§       How hard would it be to do that?
§       What is the likelihood of this happening?

Create Mitigation Strategies
Mitigation strategies should be created after gaining a solid understanding
of the application's architecture, and creating lists of system assets,
potential vulnerabilities, and possible threats. The chosen risk handling
tactic for each threat should be added to the software design to mitigate,
accept or transfer the risk. 
A Note about Threat Modeling Techniques
Part 2 of the OWASP Testing Guide (the "How To" text) will outline a
specific Threat Modeling technique. There is no right or wrong way to
develop threat models, and several techniques have evolved. A model that is
worth exploring is OCTAVE from Carnegie Mellon
(http://www.cert.org/octave/).
The primary issue with OCTAVE is its use of likelihood = 1, or "all risks
are equally risky". This does not meet AS 4360 requirements and many other
risk assessment methodologies, so OCTAVE's otherwise excellent material
should be evaluated in light of this issue. 

-----Original Message-----
From: aporia () tiscali co uk [mailto:aporia () tiscali co uk] 
Sent: Thursday, May 20, 2004 12:22 PM
Cc: webappsec () securityfocus com
Subject: RE: Threat Modeling

I've been looking for a free set of threat models, too - no luck, though
- would be interested to know if you are successful.

_However_ I can recommend a software product called CRAMM.  I don't know if
you've used it, but basically it's a tool developed by HMG in Cheltenham.
 The great thing about it, and the reason it costs 4,000 GBP is that it
contains a database of over 3000 threats, vulnerabilities and
countermeasures.

It also follows a specific methodology (Crown Copyright), and is aligned to
BS7799.

Unfortunately, the cost is a significant barrier to using it.  What about
just buying the BS7799 (about 150 GBP) and ISO TR 13335: Guidelines for
Management of IT Security (GMIT)? A reasonable starter pack.  This isn't fee
either, unfortunately.  But it is American.

---------------
Ian Ristic [ivanr () webkreator com]

> Any links to any free threat modeling tools out there ?

   Does anyone know what happened to the threat modeling tool
   Microsoft announced in late 2003?

--
ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web
applications ]

__________________________________________________
Broadband from an unbeatable £15.99!

http://www.tiscali.co.uk/products/broadband/home.html?code=SM-NL-11AM