threat modeling to reduce software security risk
TRANSCRIPT
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