1. Threat Modeling to Reduce
Software Security Security Risk

2. About Security Innovation
• Authority in Software Security
• 10+ years research on software vulnerabilities
• Security testing methodology adopted by SAP,
Symantec, Microsoft and McAfee
• Authors of 18 books
• Helping organizations minimize risk
• Assessment: Show me the gaps
• Education: Guide me to the right decisions
• Standards: Set goals and make it easy and natural
• Tech-enabled services for both breadth and depth
• Gartner MQ Leader for security computer-based training

3. Agenda
Threat Modeling 101
• Threat Modeling Activity Examples
• STRIDE and DREAD threat classification techniques
• Leveraging a Threat Model at every phase of the SDLC

4. Threat
Mitigation
Vulnerability
Attacker
Threat Modeling Overview
Vulnerabilities are
unmitigated threats
Here’s our
opportunity!
• Threat modeling consists of Assets, Threats and Attacks
• Assets are what you want to protect
• Threats live forever; they are the attacker’s goal
• Attacks are how an attacker can realize a threat
• Vulnerabilities are design or implementation errors that allow an attack to succeed
• Very hard to write secure solutions unless you understand your Assets, Threats and Attacks
• If done right, provides more ROI than any other security activity

5. What is Threat Modeling?
• A powerful way to identify potential threats, visualize risk and
understand the security of the software system
• Multi-disciplinary effort in which all team members think about and
address threats
• A way for architects to realize and mitigate design problems
• A road map for developer to write secure code
• A starting point to create robust security minded test plans
• The most reliable way to:
• Understand the security implications of system architecture
• Find business-process and system-level security issues
• Ensure you get the most impact for your security investment
“Experience shows that nearly 50% of security flaws will be discovered from Threat Modeling
because it finds different threats than those found through code review"
-Michael Howard, author of "Writing Secure Code" and Security Program Manager, Microsoft

6. Why Threat Model?
• Creates a common understanding amongst technical and
management stakeholders
• Ensures design and code is written to protect critical assets
• Allows organizations to:
• Make better decisions throughout development
• Prioritize security efforts according to true risk
• Understand your organization’s weaknesses
• Weigh security designs against functional design goals
• Step into the mind of an attacker and identify attack vectors
“To know your enemy, you
must become your Enemy.”
-Sun Tzu

7. Threats Vary by Platform, Technology, Language
• Web, embedded, mobile attacked in different ways
• You cannot implement effective design and coding
countermeasures without knowing these specific attacks
• Adobe Flash vulnerabilities exploited numerous times
• PHP is widely known as being insecure
• Java frameworks littered with security flaws
• Each Technology has different security features and vulnerabilities
• .NET and J2EE protect against buffer overflows; objectiveC does not
• Heartbleed, Shellshock, POODLE, GotoFail, Stuxnet
• All software born exploits

8. A World Without Threat Modeling
• Important assets are left unprotected
• Many assets aren’t even identified
• Team doesn’t understand key threats to the system
• Developers code defensively but leave gaps
• Mitigations are in place but they block the wrong attacks
• Low risk areas are well protected, high risk areas left open
• Testing is conducted with a one-size-fits-all solution
• Reliance on scanning tools and vendors with canned test plans

9. What a Threat Model Isn’t
• A representation of how an attacker approaches a system
• Represents system security, not an attacker model
• A test plan
• Test plans should be based on a TM, but a TM offers more than just test
planning
• A formal proof of system security
• This is not achievable on complex systems
• A design review
• Design review is the next level of action after the Threat Model is
completed

10. Agenda
• Threat Modeling 101
Threat Modeling Activity Examples
• STRIDE and DREAD threat classification techniques
• Leveraging a Threat Model at every phase of the SDLC

11. Threat Modeling in a Nutshell
Analyze
Application
Determin
e Threats
Rank
Threat
s
• Understand architecture and security requirements
• Identify assets and roles
• Build an activity matrix
• Identify threats that put assets at risk
• Define a set of attacks and/or negative scenarios that
could be used to realize threats
• Identify testable conditions each attack requires to be
successful
• Assess probability, harm, priority, and business impact
of each threat
• Devise mitigations

12. Identifying Entry Points, Assets & Roles
• Entry points in an online store application example:
• Front-end web server
• Merchandise database
• Interface with 3rd-party credit card processing system
• Interface with inventory system
• To find assets one needs to think about what the attacker will target
• Customer data
• Checkout cart
• Product information
• Inventory system
• The Web application
• Identify roles Web customer (Authenticated user)
• Site Administrator
• Anonymous user
• 3rd-party payment processing system
• Suppliers

13. Building the Activity Matrix
• The activity matrix shows the interactions between each asset and role in
the target system
• The activity matrix is a set of explicit mappings between roles and asset
• Each <role, asset> pair lists the access types granted to a role for the
asset
• The activity matrix is used in later steps to derive threats to the system
based on improper asset access

14. Building the Activity Matrix: Example
14
Role
Asset Action Anonymous
Authenticated
User
Site Admin
Customer Data Create Always Sometimes 1
Never
Read Never Sometimes 1
Always
Update Never Sometimes 1
Never
Delete Never Sometimes 1
Always
Product Items Create Never Never Always
Read Always Always Always
Update Never Never Always
Delete Never Never Always
Password Create Always Always Never
Read Never Never Never
Update Never Sometimes 2
Sometimes 3
Delete Never Never Never
Sometimes 1
User can modify their own data, but not anybody else's
Sometimes 2
Cannot change username or reset password more than once a day
Sometimes 3
Admins should be able to set temporary password or trigger password reset

15. Building Threat Profile
• Identifying Threats
• CIA on assets
• Attacker steals an asset
• Attacker modifies an asset
• Attacker denies an asset
• Break rules in activity matrix
• Attacker can act with higher privileges
• Classifying Threats
• Is it data tampering? DoS? Other? (more on STRIDE shortly)
• Rating Threats
• What is Impact? Likelihood? (more on DREAD shortly)
• Building Threat Trees
• Threat trees can provide comprehensive details about a threat, describing the
conditions required to realize it

16. Tips for Building the Threat Model
• Arrange a meeting to brainstorm on threats
• Include at least one member from the different groups in the team
• Developer
• Architect
• Tester
• Business representative
• Don’t think too much into solutions or mitigations
• Identify each threat with a unique Threat ID

17. For Each Threat Decide How to Stop It
• Redesign and eliminate
• Use standard threat mitigations
• Accept risk in accordance with your organization’s risk tolerance
Client/UI Threat
#4:
Attacker
Impersonates user
Spoof
authentication
token/transaction
ID
Modify the audit trail so
that it appears that a
different user conducted
the transaction
Bypass the client
application/UI to
create transaction
Attacker discovers
another user’s
credentials
Attempt to intercept
credentials during
their transmission
Attempt to discover
credentials left in
memory
Threat
Action
Sub-Actions

18. Agenda
• Threat Modeling 101
• Threat Modeling Activity Examples
STRIDE and DREAD threat classification techniques
• Leveraging a Threat Model at every phase of the SDLC

19. Vulnerability Classification and Prioritization
• Not all vulnerabilities are equal, so it’s important to have defined criteria for
vulnerability criticality
• Here are the things you can use to get there
• Data asset classification
• DREAD
• Criticality definitions (critical, high, medium, low)
• Combined, it gives you a framework for how to respond to a vulnerability

20. STRIDE: Classifying Threats
20
Name Description
Spoofing Is it something or someone that tricks us to be legitimate and valid?
Tampering with Data Can attackers modify or tamper with legitimate information?
Repudiation Is when a user denies performing a certain action which could be illegal and
harmful?
Information Disclosure Is information disclosed that should not be?
Denial Of Service When a service is brought down intentionally or unintentionally, resulting
in disruptions for legitimate users
Escalation of privilege An unauthorized user gets higher privilege access from the one he was
supposed to have, which might result in access to restricted information, or
might apply dangerous tasks

21. DREAD: Rating Threats
• For each vulnerability, assign a rating (0 to10) for each DREAD category
• The final DREAD rating will be the sum of the ratings
• The higher the DREAD rating, the more serious the vulnerability
• Prioritize vulnerabilities according to their DREAD rating
21
Name Description
Damage Potential How much damage can this threat do to our system?
Reproducibility Is it easy to reproduce?
Exploitability How much effort and experience does it require to be exploited?
Affected Users In case the threat became an attack, how many users can be
affected?
Discoverability How easy is it to discover the vulnerability?

22. Threat Modeling Methodology –
D.R.E.A.D.Rating High (3) Medium (2) Low (1)
Damage
potential
Attacker can subvert security
system, get full trust authorization,
run as admin, upload content
Leaking sensitive information Leaking trivial information
Reproducibility Attack can be reproduced every
time and does not require a timing
window
Attack can be reproduced but
only with timing window and
particular race situation
Attack is difficult to reproduce,
even with knowledge of the
security hole
Exploitability A novice programmer could make
the attack in a short time
A skilled programmer could
make the attack, then repeat
the steps.
Attack requires extremely skilled
person and in-depth knowledge
every time to exploit
Affected users All users, default configuration,
key customers
Some users, non-default
configuration
Small percentage of users,
obscure feature; affects
anonymous users
Discoverability Published information explains the
attack; Vulnerability is in most
commonly used feature
Vulnerability is in seldom-used
part of product
The bug is obscure; unlikely that
users will work out damage
potential
DREAD: Example Ratings

23. Reporting Business Impact
• DREAD can serve as an excellent template for providing insight into the business
impact of a particular bug
• For example - A SQL injection bug:
• Damage potential:
• High; A malicious user can directly access and modify the application database and run
any Oracle commands that are available
• Reproducibility:
• Reproducible under default install
• Exploitability:
• Medium; Requires knowledge of Oracle SQL and the design of the application
• Affected users:
• All users of the application and others whose information is present in the database
• Discoverability:
• This is a standard attack vector for these types of applications
23

24. Prioritizing and Classifying Vulnerabilities
Critical
• Server or client side error
allows remote code execution from anonymous user
• Persistent XSS
allows attacker to propagate a web-mail worm with minor
victim interaction
• Server crash or infinite loop
allows attacker to generate a widespread DoS
• Tampering vulnerability
allows attacker to tamper with critical data
Low
• Server or client side error
allows remote code execution from anonymous user
• Denial of Service error
caused by low resources in victim machine
• Information disclosure of implementation details
allows attacker to create/execute reverse engineering attacks
Medium
• Server or client side error
allows remote code execution from anonymous user
• Information disclosure
allows attackers to gain access to fixed encryption data
such as initialization vectors
• Encryption or hashing using outdated methods
SSL v2, MD4, etc
High
• Reflected cross-site scripting
allows attacker to steal victims’ confidential data (such as
cookies or session ID)
• Server-side error such as excessive resource
consumption
allows attacker to generate a temporary widespread denial
of service attack
• Tampering vulnerability
allows attacker to tamper with highly sensitive data
• Local escalation of privileges
allows a non-admin attacker to gain admin-level privileges

25. Defining Criticality
• Every organization will report criticality
differently
• Consistency is important
• Typical scales include several levels:
• Critical
• High
• Medium
• Low
25

26. Agenda
• Threat Modeling 101
• Threat Modeling Activity Examples
• STRIDE and DREAD threat classification techniques
Leveraging a Threat Model at every phase of the SDLC

27. Leverage Threat Model to Gather Security
Requirements
• Threat modeling is generally a design-phase activity
• However, its not a bad idea to start thinking in terms of threats when gathering
security requirements
• At a high level:
• What should not be allowed to happen?
• What are some critical assets that need to be protected?
• For instance
• Processing credit card data, so we can’t allow it to be stolen
• Will need to generate some requirements around keeping the data safe when
transmitting and we should not be storing it
27

28. Leverage Threat Model at Design
• Shape your application design to meet security objectives
• Build security architecture to protect critical assets
• Decisions made before developing or during architectural or project
revisions
• Capture basic architectural and design assumptions that may raise
security issues
• List features that may increase the attack surface of your application
• Help in defining mitigations to specific threats
28

29. Leveraging Threat Modeling to Code Defensively
• Developers implement the security specifications, referring back to the
threat model to understand the context they operate in.
• Understand which assets need protection
• Understand threats that can be used to compromise an asset
• Understand what types of vulnerabilities could allow attacks through
• Build countermeasures to reduce vulnerabilities in the code
• Overall benefit is developer awareness and prioritization of effort to protect
the most important assets against the most likely attacks
29

30. Leverage Threat Model for Precision
Testing
• Threat model contains attacks that should be attempted
• Also contains vulnerabilities that, if present, would allow an attack to succeed
• Tester can use this information to create a very targeted test plan
• Built the test plan Security testing is the process of validating that security
controls are in place and working appropriately
• Ascertain how the application holds up against the types of attacks envisioned
during the threat modeling exercise
• Threat Model allows testers to focus testing on the most impactful threats and
vulnerabilities
30
Threat model can be used by outside security teams to audit the
code, freeing them from performing up-front analysis work.

31. Threat Model – Summarizing Software or
Enterprise Risk
• Threat Modeling allows you to get ahead of and plan for risk
• If you understand threats and risks before deployment, you can reduce
security impacts to development schedule and cost
• Most solutions make trade offs between security and functionality
• If low priority security concerns are mis-prioritized, you can
negatively impact usefulness and user experience
• If high priority security concerns are mis-prioritized, you can
negatively impact your users and business
• Threat modeling helps you plan and prioritize effectively
31

32. Summary
• It all starts with Threats
• What are the potential threats that could impact each asset?
• Think about CIA on each asset: Confidentiality, Integrity, Availability
• Under what conditions would each attack succeed?
• Threat Models makes EVERY security engineering activity better
• Threats change – update and improve iteratively
• When your security objectives and design changes
• During implementation, testing and deployment

33. How Security Innovation Can Help
• Training
• How to Conduct a Security Threat Model in addition to 100+ other courses
• Computer based and Instructor-led for all major roles, technologies and platforms
• Software and SDLC Assessments
• Standards and Process Improvement
• Application and IT Security Hackathons
• Authentic environments to learn and hone attack and defense skills

34. Thank You!
Related Resource
• A CTO’s Perspective on Software Threat Classification
• https://web.securityinnovation.com/software-threat-classification-
evolution-of-dread
Additional Resources and Guides
• https://www.securityinnovation.com/knowledge-center/reports-guides
Additional Webinar Replays
• https://www.securityinnovation.com/knowledge-center/webinars