Threat Modeling to Reduce

Software Security Security Risk

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

Agenda

Threat Modeling 101

• Threat Modeling Activity Examples

• STRIDE and DREAD threat classification techniques

• Leveraging a Threat Model at every phase of the SDLC

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

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

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

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

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

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

Agenda

• Threat Modeling 101

Threat Modeling Activity Examples

• STRIDE and DREAD threat classification techniques

• Leveraging a Threat Model at every phase of the SDLC

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

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

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

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

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

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

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

Agenda

• Threat Modeling 101

• Threat Modeling Activity Examples

STRIDE and DREAD threat classification techniques

• Leveraging a Threat Model at every phase of the SDLC

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

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

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?

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

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

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

Defining Criticality

• Every organization will report criticality differently

• Consistency is important

• Typical scales include several levels:

• Critical

• High

• Medium

• Low

25

Agenda

• Threat Modeling 101

• Threat Modeling Activity Examples

• STRIDE and DREAD threat classification techniques

Leveraging a Threat Model at every phase of the SDLC

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

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

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

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.

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

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

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

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