This document provides an overview of threat modeling practices and tools. It begins with an introduction that defines threat modeling and outlines its benefits. It then covers threat modeling basics like principles, approaches and reasons it is avoided. The main threat modeling process is described, including creating diagrams, identifying threats and planning mitigations. Popular threat modeling tools and a demo are discussed. Standard mitigation techniques and a sample threat model appendix are also included.
5. Application Security Problems
Customer does not know what security
he needs
Different groups think of security in
different terms
Blind security controls applying
The area of security changes in time
Most decisions are made ad-hoc
What we have to understand?
Information Value
Attackers Interest
Events and causes
5
10. Overview
What is Threat Modeling?
Threat modeling is a repeatable process that helps
you find and mitigate all of the threats to your
product.
Why Threat Modeling?
Security design flaws are prevalent
Fixing design flaws is costly
Find problems when there is time to fix them
Threat modeling is one of the most effective security
assessments
Know your enemies and their tactic
10
11. Benefits of Threat Modeling
Contributes to the risk management process because
threats to software and infrastructure are risks to the
user and environment deploying the software.
Uncovers threats to the system before the system is
committed to code.
Revalidates the architecture and design by having the
development team go over the design again.
Forces development staff to look at the design from a
different viewpoint that of security and privacy. To
understand the most at-risk components, development
staff focuses on components with a high attack
probability.
Helps clarify the selection of appropriate
countermeasures for the application and environment.
Helps guide the code review process.
Guides the penetration testing process.
11
12. Threat Modeling Principles
Occurs early in the project lifecycle
Iterative process
Should be updated for evolving threats
about every six months
Process output – documented Threat
Model
12
13. Top 5 Reasons Why Threat Modeling Is Avoided
Time
Over Confidence
Cost
Underestimation
Procrastination
13
18. Define Use Scenarios
Determine which key threat
scenarios are within scope
Consider the insider-threat
scenario should
Other common, but not securityrelated scenarios
18
19. Gather a List of External Dependencies
Application is not self-sufficient
Consider the default system-hardening configuration
19
20. Security Assumption and External Security Notes
Security assumptions about the environment in
which the application resides
External Security Notes - for Users and other
application designers
20
22. What Is DFDs?
A Data Flow Diagram (DFD) is a
graphical representation of how data
enters, leaves, and traverses your
component
It is not a Class Diagram or Flow
Chart!
Shows all data sources and
destinations
Shows all relevant processes that
data goes through
Good DFDs are critical to the process
This point can’t be emphasised
enough!
Building DFDs == understanding the
system
Analysing DFDs == understanding
the threats
22
23. Data Flow Diagram Symbols
External
Entity
Data Store
Complex-Process
Dataflow
Process
Privilege
Boundary
23
24. Privilege Boundaries
Boundary between DFD elements with different privilege levels
Machine boundary (data from the other machine could be anonymous)
Integrity boundary (Low Medium trust)
Process boundary (e.g.; User process SYSTEM process)
Kernel User mode
24
25. DFD Levels
Context Diagram - very high-level; entire component / product / system
Level 0 Diagram - high level; single feature / scenario
Level 1 Diagram - low level; detailed sub-components of features
Level n Diagram - when is enough?
25
26. Context Diagram
View files and
Logging Data
Response
Web Shop
(3.0)
Users (1.0)
Request
Admin (3.0)
Apply Settings
26
27. Level 0 Diagram
1
1
Web Config
(3.1)
Web Pages
(3.2)
Read Data
Read Data
Request
Customers
(1.0)
Response
Admin (3.0)
1
Create, Read,
Update, Delete
Insert, Update
Web
Server
(3.3)
Create,
Update
Read
Order
Processing
(3.4)
Read
Membership
Service
(3.5)
Insert,
Update
Read
Membership
Data (3.6)
1
27
30. Threat Trees
A graphical representation of
security-relevant pre-conditions in a
system
Based on hardware fault trees
There are many “threat tree
patterns”
30
31. Threat Tree Pattern Example
Spoofing
An Interactor
or Process
Obtain legitimate credentials
Leverage insufficient
authentication
Falsify Credentials
No Authentication System
Week change
management
Equivalence
Predictable
Credentials
Non-secure
Channel
Week transit
Guessed
Downgrade
Authentication
Secure Channel
Week storage
Null Credentials
Server
Client
KDC
Tampering
Threats
against Auth
Process
Information
Disclosure
against data
flows
Tampering
against data
flows
31
33. Threat Rating According to DREAD
Rating
Damage potential
Reproducibility
Exploitability
Affected users
Discoverability
High(3)
The attacker can:
subvert the security
system;
get full trust
authorization;
run as administrator;
upload content.
The attack can be reproduced
every time and does
not require a timing
window.
A novice programmer could
make the attack in a short
time.
All users, default
configuration,
key customers
The vulnerability is found
in the most commonly used
feature and is very
noticeable.
Medium(2)
Low(1)
Leaking sensitive information
Leaking trivial information
The attack can be
reproduced, but
only with a timing window
and a particular race
situation.
The attack is very difficult to
reproduce, even with knowledge
of the security hole.
A skilled programmer could make
the attack, then repeat the steps.
The attack requires an extremely
skilled person and in-depth
knowledge every time to exploit.
Some users, non-default
configuration
Very small percentage of users,
obscure feature; affects
anonymous users
The vulnerability is in a
seldom-used part of the
product, and only a few
users should come across it.
It would take some thinking
to see malicious use.
The bug is obscure, and it is
unlikely that users will work
out damage potential.
33
36. Mitigation Technique Based on STRIDE
Threat
Spoofing
Property
Authentication
Definition
Impersonating
something or
someone else.
Example
Pretending to be any of Billg , microsoft.com or
ntdll.dll
Tampering
Integrity
Modifying data or code
Modifying a DLL on disk or DVD, or a packet as
it traverses the LAN.
Repudiation
Non-repudiation
Claiming to have not
performed an action.
“I didn’t send that email,” “I didn’t modify that
file,” “I certainly didn’t visit that web site,
dear!”
web site.
Deny or degrade
Crashing Windows or a web site, sending a
service to users
Availability
Allowing someone to read the Windows
source code; publishing a list of customers to a
authorized to see it
Denial of Service
Confidentiality
Exposing information
to someone not
Information Disclosure
packet and absorbing seconds of CPU time, or
routing packets into a black hole.
Elevation of Privilege
Authorization
Gain capabilities
without proper
authorization
Allowing a remote internet user to run
commands is the classic example, but going
from a limited user to admin is also EoP
.
36
37. Standard Mitigations
Spoofing
Authentication
Tampering
Integrity
Repudiation
Non Repudiation
Information Disclosure
Confidentiality
Denial of Service
Availability
Elevation of privilege
Authorization
To authenticate principals:
Basic authentication
Digest authentication
Cookie authentication
Windows authentication (NTLM)
Kerberos authentication
PKI systems such as SSL/TLS
and certificates
IPSec
Digitally signed packets
To authenticate code or data:
Digital signatures
Message authentication codes
Hashes
Windows Vista Mandatory Integrity Controls
ACLs
Digital signatures
Message Authentication Codes
Strong Authentication
Secure logging and auditing
Digital Signatures
Secure time stamps
Trusted third parties
Encryption
ACLS
ACLs
Filtering
Quotas
Authorization
High availability designs
ACLs
Group or role membership
Privilege ownership
Permissions
Input validation
37
40. Summary
Structured approach to security
Address the top threats
Treat threat modeling as an iterative process
Dynamic item that changes over time
Help manage and communicate security risks across your team
Using a Threat Model to Aid Code Review
Using a Threat Model to Aid Testing
40
42. TAM Security Artifacts
Data access control matrix
Component access control matrix
Subject-object matrix
Data Flow
Call Flow
Trust Flow
Attack Surface
Focused reports
42
43. SDL Threat Modeling Tool Beta
Structured analysis
Automated guidance and feedback in drawing threat diagrams
Guided analysis of threats and mitigations based on the STRIDE
taxonomy
Integration with bug-and issue-tracking systems like Visual
Studio Team Foundation Server
Reporting capabilities: Security activities and testing in the
verification phase
Is a core element of the SDL
43
46. Rank Your Threats by Risk
Address the highest-risk items first
Risk level 1 or 2 threats must always be remedied during the development
phase
Risk level 3 threats should be fixed before the product becomes a release
candidate
Risk level 3 threats should be fixed before the product becomes a release
candidate
Risk level 4 threats should be fixed if time permits
46
47. Spoofing
Spoofing
Server
Pose as specific
principals when
using security
protocol
Risk Level 2
Pose as random
principals when
using security
protocol
Risk Level 3
Client
Present bogus
relied-upon trust
decision UI used
in common
scenarios
Risk Level 2
Present bogus
trust decision UI
used in common
scenarios
Risk Level 3
Present bogus
UI to aids other
attacks
Risk Level 4
47
50. Denial of Service
Denial of
Service
Server
Anonymous
Client
Authenticated
Local
Risk Level 2
Remote
Permanent DoS
Risk Level 2
Temporary DoS
with amplification
Risk Level 2
No user
Interaction
Risk Level 1
Temporary DoS
Risk Level 3
Authenticated
Risk Level 2
Iser Interaction
Risk Level 2
50
51. Elevation of Privileges
Elevation of
Privilege
Server
Local
Authenticated
Risk Level 2
Client
Remote
Local
Risk Level 2
Remote
Anonymous
Risk Level 1
No user
Interaction
Risk Level 1
Authenticated
Risk Level 2
Iser Interaction
Risk Level 2
51
52. References
Basic Terminology http://msdn.microsoft.com/en-us/library/aa302419.aspx#c03618429_005
Security Developer Center: Threat Modeling http://msdn2.microsoft.com/en-us/security/aa570411.aspx
Classification of Security Attacks http://homepages.uel.ac.uk/u0305518/classification_of%20security_attacks.htm
Approaches to Threat Modeling http://en.wikipedia.org/wiki/Threat_model
Threat Modeling http://msdn.microsoft.com/en-us/library/aa302419.aspx
Uncover Security Design Flaws Using The STRIDE Approach http://msdn.microsoft.com/enus/magazine/cc163519.aspx
Security Threats http://technet.microsoft.com/en-us/library/cc723507.aspx
Server and Domain Isolation Using IPsec and Group Policy
http://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/ipsecapd.mspx
Security Briefs http://msdn.microsoft.com/en-us/magazine/dd148644.aspx
Security Developer Center: Threat Modeling — Video Tutorials http://msdn2.microsoft.com/en
us/security/aa570414.aspx
OWASP — Threat Risk Modeling http://www.owasp.org/index.php/Threat_Risk_Modeling
patterns & practices — Threat Modeling Web Applications http://msdn2.microsoft.com/enus/library/ms978516.aspx
Peter Torr's blog: High-Level Threat Modeling Process
http://weblogs.asp.net/ptorr/archive/2005/02/08/368881.aspx
The STRIDE Threat Model http://msdn2.microsoft.com/en-us/library/ms954176.aspx
Microsoft Application Threat Modeling Blog http://blogs.msdn.com/threatmodeling/
52
53. References
Template Sample: Web Application Threat Model http://msdn.microsoft.com/en-us/library/ms978534.aspx
Application Threat Modeling http://www.owasp.org/index.php/Application_Threat_Modeling
Threat Modeling Terms and How To Use Them http://blogs.msdn.com/jmeier/archive/2005/10/10/threat-modelingterms-and-how-to-use-them.aspx
Threat_M odeling_Lab_01 .90.docx
SimpleModel.atmx
53
2. One of the problems in designing secure software is that different groups think of security in different terms. Software developers think of security primarily in terms of code quality while network administrators think of firewalls, incident response, and system management. Of course, all of these things are important in building secure systems. But maybe the single biggest problem is a lack of security success criteria. If we want to avoid security failures, it means we have to have some idea of what security success looks like. 3.To secure an application or a system without spending excessive time and effort we are tempted to blindly apply security controls that have already been extensively used in practice. However, without understanding security requirements common security controls can not provide adequate protection within the specific context.4. A development process must also change5.We have to understand:- the real value of information resources that we need to protect- if an attacker has an interest to compromise our system what are the events and causes that will have an unwelcome consequence upon our system
Once the application has been decomposed into its components, threats identified, and mitigations applied, the final step is to validate.The validation task includes the following:Check whether the Data Flow Diagrams match the final code. If the design has been modified since creating the DFDs, they need to be updated accordingly.Verify whether STRIDE threat types have been identified for each component of the DFD, especially those that touch a trust boundary.Check whether proper mitigations have been applied to the threats identified.Check that all the above tasks have been accomplished before shipping.
Since threat modeling is an iterative process, it is possible to keep repeating the various tasks and updating the threat model until the product is finally shipped.For this reason, it’s extremely important to know when the threat modeling process can be considered complete. Validating the following helps you determine when to stop:DFDs match frozen code.Threats have been identified and mitigations applied to each component in the DFD.The mitigations are validated by QA by testing whether the application is still vulnerable to the threats for which the mitigations are in place.When the threat model has been reviewed and approved by an external security expertSummary: Threat modeling allows you to apply a structured approach to security and to address the top threats that have the greatest potential impact to your application first. This chapter helps you to decompose your Web application to identify and rate the threats that are most likely to impact your system. The chapter presents a six-step threat modeling process.While you can mitigate the risk of an attack, you do not mitigate or eliminate the actual threat. Threats still exist regardless of the security actions you take and the countermeasures you apply. The reality in the security world is that you acknowledge the presence of threats and you manage your risks. Threat modeling can help you manage and communicate security risks across your team.Treat threat modeling as an iterative process. Your threat model should be a dynamic item that changes over time to cater to new types of threats and attacks as they are discovered. It should also be capable of adapting to follow the natural evolution of your application as it is enhanced and modified to accommodate changing business requirements.Threat modeling is critically important to helping build secure software because it is the cornerstone to understanding how your product could be attacked and how to defend it. The process is also a great way to determine the overall security health of a software development team because security-savvy teams are more in tune with the threats to their code and, therefore, tend to build better threat models.By following the updated threat-modeling process, you can systematically uncover threats to the application, rank the risk of each threat, and determine appropriate mitigations. Threat modeling can also help you perform code reviews and build penetration tests.Using a Threat Model to Aid Code ReviewOne of the deliverables from the threat-modeling process is a list of entry points to the system. This is really what the context diagram shows. If you look at the context diagram main entry points to the system. When it comes to reviewing the code for security bugs, it's imperative that you review all code that is remotely and anonymously accessible before reviewing other code. Simply look at the data flow diagram to determine which elements are accessible in this manner.Using a Threat Model to Aid TestingAs we have mentioned, specific threat types (spoofing and tampering, for example) have specific mitigation techniques. These techniques can also be attacked. Determine how best to build attacks or perform penetration testing by looking at the relevant threats' tree patterns, and considering the leaf nodes of each tree. These leaf nodes can give you not only design insight but also attack insight.There's a couple of interesting points here:Assets tend to be very much a point of confusion. It's tough to put boundaries here. For example, show me which pages or components you don't want to protect. Do you really have a page or component you don't care about? Is it an asset or not? This is why we moved to identifying security objectives in our threat modeling approach. This was a lot more tangible. Using security objectives also allowed us to incorporate assets without pinning your threat modeling success to you being able to identify your assets. However, assets do have their place. I think they're best use is to identify priorities and values. Do you care more about your shed or your garage? Your garage or your house. OK, let's start w/your house and prioritize there ... Attacks tend to be the domain of subject matter experts. We don't expect typical practitioners to know the realm of attack possibilities. That's why we try to provide a picklist where possible. Vulnerabilities are your most valuable fallout of your threat modeling exercise. While threats help you see what's within the realm of possibility and to prioritize, vulnerabilities are a clear cut action item. You can use a list of vulnerabilities to drive action. Given enough relevant info, a developer can analyze and address a vulnerability from their code's perspective. Testers can scope their work testing that the developer addressed the vulnerability. Countermeasures could also be called mitigations. You mitigate a risk, not a threat though. You can counter an attack. At the end of the day, we went with countermeasures because enough customers liked the idea of being empowered to defend their code against evil doers as well as non-malicous threats. Put it another way, countermeasures resonated with practitioners. Threats are particularly interesting. You can slide and dice them many ways. You can also choose classes of threats. For example you may view threats strictly as those with business impact. I think it helps to broaden, yet scope this to negative impact against the confidentiality, integrity, or availability (CIA) of your information system
TAM Overview – Asset centric toolMicrosoft Threat Analysis & Modeling tool allows non-security subject matter experts to enter already known information including business requirements and application architecture which is then used to produce a feature-rich threat model. Along with automatically identifying threats, the tool can produce valuable security artifacts such as:- Data access control matrix- Component access control matrix- Subject-object matrix- Data Flow- Call Flow- Trust Flow- Attack Surface- Focused reports
SDL Threat Modeling Tool Beta – Software centric tool The Microsoft SDL Threat Modeling Tool Beta allows for structured analysis, proactive mitigation and tracking of potential security and privacy issues in new and existing applications. Microsoft developed the tool and we use it internally on many of our products. This tool offers a threat modeling methodology that any software architect can lead effectively — in contrast with other processes, which are more expert-dependent. A few quick notes about the features: · Automated guidance and feedback in drawing threat diagrams· Guided analysis of threats and mitigations based on the STRIDE taxonomy· Integration with bug-and issue-tracking systems like Visual Studio Team Foundation ServerThe Microsoft SDL Threat Modeling Tool is a core element of the SDL. The tool is part of the design phase of the SDL and allows software architects to identify and mitigate potential security issues early, when they are relatively easy and cost-effective to resolve.The Microsoft SDL Threat Modeling Tool enables software architects to do the following:Communicate about the security design of their systemsAnalyze those designs for potential security issues using a proven methodologySuggest and manage mitigations for security issuesCapabilities and InnovationsInnovative features in the Microsoft SDL Threat Modeling Tool 3.0 include: Automation: Guidance and feedback in drawing threat diagramsSTRIDE Framework: Guided analysis of threats and mitigationsIntegration: Issue-tracking systemsReporting capabilities: Security activities and testing in the verification phaseA Unique MethodologyThe Microsoft SDL Threat Modeling Tool differs from other tools and approaches in two key areas:Centered on softwareMany threat modeling approaches center on assets or attackers. In contrast, the Microsoft Security Development Lifecycle’s (SDL) approach to threat modeling is centered on the software. This new tool builds on activities that all software developers and architects are familiar with – such as drawing pictures for their software architecture.Focused on design analysisThe term “threat modeling” can refer to either requirements elicitation techniques or design analysis. Sometimes, it refers to a complex blend of the two. The Microsoft SDL approach to threat modeling is a focused design analysis technique.As threat modeling matures as a discipline, there's no single 'right' way to do it. Both the TAM tool and the SDL tool address specific needs. The SDL tool is intended to be software centric, while TAM is asset centric. It's great to be in a situation where we can really distinguish between these and make tools which are focused on the needs of the different customer groups.
Note that there are no risk rankings for repudiation threats. The threats remain unranked for various reasonsmost notably because Microsoft has issued no security bulletins relating to repudiation. In general, the feeling is that any such errors follow the tampering risk rankings. By the end of the risk-identification stage, you should have ranked your threats by risk, from high to low. Obviously, you should address the highest-risk items first. Risk level 1 or 2 threats must always be remedied during the development phase. Risk level 3 threats should be fixed before the product becomes a release candidate, and risk level 4 threats should be fixed if time permits.