SensePost Threat Modelling

Metricon 6, a Usenix Workshop
SensePostThreat Modeling

Agenda
Introduction
What is TM
Why TM
Our goals with CTM
Methodology
Entities & Mapping
Modeling
Risk Calculation & Permutations
Analysis
Scenario Modeling
Brief Comparisons

Dominic White
@singe
http://singe.za.net/
Work:
Research:
MSc in Security
Interests in Privacy, Defensive Tech & Security Management
About Me

Introduction
What is TM
Why TM
Design Goals
1

A model in science is a physical, mathematical, or logical representation of a systemof entities, phenomena, or processes.
Basically a model is a simplified abstract view of the complex reality
Breadth over depth
Represents criteria specific to analysis
What is Modeling?

A threat model is:
“A systematic, non-provable, internally consistent method of modeling a system, enumerating risks against it, and prioritising them.”
Systematic
Non-Provable
Internally Consistent
System Model
Risk Enumeration
Prioritisation
What is Threat Modeling?

Escaping the Detail Trade Off

Usual Drivers of Controls
Audit reports
Prioritises: financial systems, audit house priorities, auditor skills, rotation plan, known systems
Vendor marketing
Prioritises: new problems, overinflated problems, product as solution
New Attacks
Prioritises: popular vulnerability research, complex attacks
Individual Experience
Prioritises: past experience, new systems, individual motives
Why Threat Model?

Threat Modeling provides:
All (most) information security risks
systematic enumeration of risks
Prioritisation of risks
puts known risks in their place & compares new risks
Justification
no appeal to expert authority
Decision Making
scenario modeling to test decisions
Education
Can involve whole team
Why Threat Model?

Developed for consultative role
i.e. likely not the person making the changes
Focus is on:
Providing decision making information
Rapid initial model creation
Hybrid approach
Bit of all the others
Some parts we just threw out
Highly flexible
Initially, due to uncertainty, increasingly less so
Detailed & aggregated results
Includes test plan for verification
SensePost CTM Design Goals

Methodology
Entities & Mappings
2.1

Entity Overview
Locations
Controls
Users
enforceable trust
Interfaces
method of system access
asset value
Attacks
likelihood
Damage
Tests
certainty
relevance

Represent the trust (controls) of a location
Interfaces are exposed at locations
Users are present at locations
Three types:
Physical
Data centers, Head Office, Remote Sites
Network
Internet, DMZ, Server Network, User Network
Logical / Functional (new)
Represent controls within authorisation levels
Administrative, authenticated, unauthenticated access
Locations

Enforceable trust of user group
i.e. contractual or controlled trust, not gut feel
Users are mapped to locations
Interfaces are exposed to users via locations
Example general groups:
Anonymous
unidentified or unauthenticated users
External Users
suppliers, contractors
Internal Employees
application users, administrators, call center
Users

Methods of interacting with a system or asset
They are things an attacker could compromise
Exposes the value of asset
Interfaces to the same system have a consistent value
Value can be set to existing system criticality ratings
Types
Physical
Console Access, Hardware
Network
Remote Desktop, SSH, NTP
Functional (new)
Represent access to data & functionality within an authorisation role
Administrative Access, Approve Transaction
Interfaces

Users are present at certain locations
Many to Many mapping
Both are a representation of controls
“Company founder in the mission impossible room”
vs..
“Unknown Outsider on the Internet”
Location type mappings
Physical – users who can be physically present
Network – users who can access the network
Logical – users who have been granted, or have authorisation
MappingUsers to Locations

Interfaces are present at certain locations
Many to Many mapping
Constraints
Physical interfaces only mapped to physical locations
Physical Server in Data Centre A
Technical interfaces only mapped to network locations
Remote Desktop in Internal Network
Functionality interfaces only to functional locations
Execute Trade in Broken Role
MappingInterfaces to Locations

Attacks
An attack in performed on an interface to expose some of its value
Likelihood is based on factors specific to the attack
Excludes trust of users, or controls in place
General likelihood defined per attack, but made specific when mapped
Popularity, easy of discovery/exploitation, prevalence (DREAD)
Initial work into using external attack metrics
VERIS – best mapping, sometimes non-discreet
CWE – too detailed, vulns specific, no “abuse of privilege”
STRIDE – not specific enough
Impact is the worst case scenario
Defines how much of interface value would be affected (damage)
Originally named “risks”

Attacks are performed against interfaces
Many to one mapping
Likelihood & Impact made specific per mapping
System CIA should be considered e.g. theft of e-mail may be more damaging to the CEO than the gardener
“Could this attack lead to a full compromise of the system?”
Examples
Physical theft of the Physical Server
Password Bruteforce against Outlook Web Access Web Front-End
Abuse of Privilege of the Administrator Role
MappingAttacks to Interfaces

Validate permutations of threat vector combinations
Can be any type of test that provides more information
Technical test, research, policy work
Different tests provide a different level of certainty
Proved  Disproved
Can be granularly mapped
Against a specific entity or combination of entities
Tests

Methodology
Modeling
How-to
System Template
Guidelines
2.2

Data Gathering
Collect as much information about the environment as you can. Network diagrams, key system documentation, existing risk/criticality analysis, past audit reports
Interview
Ideally, find a tech generalist with a good overview, then get specific, large company’s knowledge is more distributed
Look to validate statements across interviews
Get multiple “views” on criticality
Testing
Light testing to validate claims e.g. basic network footprintingor application use
Passive collection
Look for problems that should come out in the TM e.g. if they have regular & damaging virus outbreaks and the TM disagrees …
ModelingA How-To

System Template<Name> |<Description>
AA
Authentication Source
Authorization
Integration
Source
Destination
Criticality
Include overall rating, individual ratings & reasons
Confidentiality
Integrity
Availability
Possession
Authenticity
Utility
Locations
Physical
Network
Functional (controls)
Interfaces
Include number & locations
Physical
Network
Functional (access)
Users
Include number & locations
Admins
Users
Support

Identify unique entitiesfrom completed system templates and general documentation – reconcile if differences
Identify shared infrastructure & create new systems for them
Map users & interfaces to locations
Linked systems
An application's functional interfaces should be mapped to its infrastructure’s functional locations
For integrated systems, map functional interfaces to locations depending on access (push vs.. pull vs.. full)
Process

Keep everything equally specific
Summarise when no meaningful security difference
Don’t create interfaces per-system for shared infrastructure
Don’t represent risks more than once
e.g. Don’t map two interfaces to the same system to the same location unless they are different “paths” e.g. administrator access implies “normal” access
Avoid catch-all systems such as “user’s computers” rather model them as interfaces to relevant areas
2-tier vs.. 3-tier applications have different access from the application to the DB & vice-versa
Modeling Gotchas

Methodology
Calculations & Permutations
2.3

Entity Relationship
present at
available at
performed at
performed on
performed by

Permutations
Administrators
Exchange MAPI
Head Office
Remote MAPI
Exploit
Anonymous

Understand concepts in relation to each other
Discrete
Individually necessary
Collectively sufficient
risk = threat x vulnerability x impact
Disclaimer: Σ – The International Sign for “Stop Reading Here”
Risk Equation

The tool gives us the following inputs
User Trust
Location Trust (controls)
Interface Value
Attack Likelihood
Attack Impact
But, complete freedom in defining how they are mashed up
Input Values

risk = threat x vulnerability x impact
likelihood = threat x vulnerability
risk = likelihood x impact
Likelihood

risk = applied likelihood + value at risk
applied likelihood =
attack likelihood (reduced by)
user trust + location trust
value at risk =
value of asset (reduced by)
amount of asset exposed by attack
Risk Equation Used

[6 minus] – Ratings are out of 5 & denote a positive trust value, we want the “distrust” value
[multiply 0.2] – We want the trust & impact to moderate the likelihood & value
[divide by 2] – We take an average of user & location trust (equally weighted)
Risk Equation

Methodology
Analysis
2.4

Takes every permutation & provides analysis graphs & a risk curve
Provides three things
Risk Curve
One view to rule them all
Analysis Graphs
Slice & Dice
Detailed risk searching/pivot table
Zoom
Threat Model Dashboard

Challenge was to provide management view
Single number loses too much context
Frequency graph of number of “risks” per severity level
Risk Curve

“Digital” version of risk curve, with ability to show risks per entity type
Can view per “perspective”
physical, technical, functional
Can zoom into showing only risks relating to a specific system
Can look at “pivot” risks, i.e. attacks available to someone once they have compromised a system
Analysis Graphs

Analysis Graphs ExampleAll Perspectives, by Attack

Analysis Graphs ExampleAll Perspectives, by Interfaces

Analysis Graphs ExampleAll Perspectives, by Users

Analysis Graphs ExampleAll Perspectives, by Locations

Analysis Graphs ExampleTechnical Perspectives, by Attack

Analysis Graphs ExampleFunctional attacks from Active Directory

Methodology
Scenario Modeling
2.5

Area Under Review

Risk Frequency

Cumulative Risk per Location

Cumulative Risk per Threat

Suggested Change

Resulting Risk Frequency

Resulting Risk per Location

Recommended Change

Resulting Risk Frequency

Tool re-write - aiming for
cross platform
enforcing certain design constraints e.g. physical <-> physical mappings only
macro’ing time consuming tasks
Adding population size
Permutations favour specificity e.g. if you define multiple user groups for one application & not another, the first app has more risks
Refining the risk equation
Equal consideration of user & location trust may need refining
Normalise across physical, network & functional “views”
Refining modeling bounding as results are tested
Future Work

Questions?
http://www.sensepost.com/blog/
The End

http://www.sensepost.com	1982
http://sensepost.com	103
http://research.sensepost.com	22
http://www.sensepost.co.za	9
http://www.hackrack.com	4
http://localhost:5000	4
http://translate.googleusercontent.com	3
http://sensepost.co.za	2
http://localhost	2
http://webcache.googleusercontent.com	1
http://www.hackrack.co.za	1
http://ns2.sensepost.com	1

SensePost Threat Modelling

by SensePost on Aug 10, 2011

Accessibility

Categories

Upload Details

Usage Rights

12 Embeds 2,134

Statistics

SensePost Threat Modelling Presentation Transcript