Threat Modeling Toolkit

by Jonathan Marcil
February 2017
Summary
Whos that guy?
What is Application Security?
What is Threat Modeling?
Existing models
Toolkit component: Simplified Risk Rating
Toolkit component: Attack Tree
Toolkit component: Data Flow Diagram
Whats next?
Who am I?
Yet another funny French Canadian
Former chapter leader of OWASP Montreal

Now living in beautiful Irvine, California

Sr. Application Security Engineer in the video
game industry at Blizzard Entertainment
My Background
Application Security since 8 years
Professional IT/dev since 16 years
Passion for hacking since 19 years
Paranoid about threats since all my life
My definition of Application Security
Mix of
A book: Building Security In
A standard: ISO/IEC 27034 Application Security
A direction: Trustworthy Computing, Microsoft
Security Development Lifecycle
A collaborative mess: Wikipedia

All boils down to one thing

Lifecycle and activities
My definition of Application Security
What is Threat Modeling?
Application Security activity to analyze
security in software development

Systematically structure
Attacks
Bad Actors
Countermeasures
Threat Intelligence
Is not threat modeling
Its half of it!

Threat actors
And what they have to gain

Knowledge base of threats

Modeling is a methodology
Threat Modeling: For who? And why?
Common method for
Security practitioners
Software engineers
Design Review
Clarify what the system is for reviewers
Highlight ameliorations or requirements

Help to catch important things despite the chaos

Modeling must be collaborative
Communication is key in a project

If you do it alone in a corner

You are doing it wrong!

You can still start the modeling alone and then

review the model with stakeholders
Existing Models
Existing Model:
Architecture Risk Assessment
Just Good Enough Risk Rating (JGERR)
Brook Schoenfield, Intel
Just Good Enough Risk Rating
Required documents
Risk rating spreadsheet with formulas
Architecture diagram
Data flow diagram
Data sensitivity rating
[]
Existing Model:
Architectural Risk Analysis
Building Security In
Gary McGraw, Cigital
Existing Model:
Security Development Lifecycle
SDL Team, Microsoft
STRIDE
Spoofing identity, Tampering with data,
Repudiation, Nonrepudiation, Information
disclosure, Denial of service, Elevation of privilege
Threat Modeling Tool
Visio Windows App
Toolkit Components
This is what you came for!
At slide #20, not bad..
Toolkit component:
Simplified Risk Rating
Risk = Exposure * Impact
Impact = [LOW, MED, HIGH]
Exposure = [INTERNET, DMZ, INTRANET]

Just ask people to rate [1,2,3] for each

Multiply, adjust result 1 and note why
Thats it you now have risk rating
Toolkit Component: Attack Tree
Organize the Threat Intelligence

Simple tree
Root node is goal
Leaf nodes are ways to reach it
Other nodes are sub-goals

Can be flexible
And logic gates
Attack Tree: Open Safe
Attack Tree: IoT
Lets take an example of a device I have home
Whiteboard!
Trick on drawing: code it instead!
PlantUML
@startuml agent "Make my life miserable" as life
skinparam monochrome true agent "Randomware" as ransomware
agent "Invade my privacy" as privacy
agent "Mass mining" as mine agent "Mess with the lights" as mess
agent "Mass scan" as scan
agent "DDoS" as ddos life --> ransomware
agent "Control many devices \n(Botnet)" as botnet life --> privacy
mine --> botnet life --> mess
scan --> botnet
ddos --> botnet agent "View my habits" as habits
agent "Spy me live" as spy
agent "Use legit command" as legitcmd privacy --> habits
agent "Exploit device flaws" as flaws privacy --> spy
agent "Obtain device access" as access
botnet --> legitcmd agent "Steal cloud data" as data
botnet --> flaws habits --> data
botnet --> access spy --> data
data ---> cloud
agent "Get WiFi LAN access" as wifi
agent "Get Physical access" as phys agent "Sniff network" as sniff
agent "Place Factory Backdoor" as factory habits ---> sniff
agent "Hack cloud server" as cloud spy ---> sniff
access --> wifi access --> sniff
access --> phys sniff --> wifi
access --> factory sniff --> phys
access --> cloud
@enduml
PlantUML!

habits ---> access

spy ---> access
Toolkit Component: DFD Diagram
Data Flow Diagram
Actually, not!
Connection Flow Diagram
Limit amount of visuals
Focus on attack surface/vectors
Toolkit Component: DFD diagram
Provide a security oriented view of the
system
Representation of the comprehension
It will evolve with understanding or
design/architecture changes!

Not an architecture document

Focus on details relevant to security
Omit what might be important for engineers
Flow Diagram Basic Set
Square for actor
Circle for process
Double circle for multiple processes
Arrow for connection flow direction
Double line for data store
I wont blame anyone using a cylinder instead
Red dotted line for boundary

100% compatible with Microsoft SDL notation

Flow Diagram: IoT
Flow Diagram Extended Set
Tech stack label on circle
Sticky notes
Table of security controls/mitigations
Include label numbers to place on the graph for positioning

Anything you want!

Cloud for abstraction
Colors/circles for logical links or special meaning
Just keep it visually pleasing and as minimalist as possible
Conclusion
If you need to review the security of a complex
system, the connection flow diagram is your tool

You can use what you learned to align activities

If you try it in a meeting and people end up

clarifying and/or improve the system while you
say nothing, you won at threat modeling, bravo!
Unified Threat Modeling
Link Attack tree to Flow diagram
Security controls are the way of mitigating the sub-
goals and prevent exploitation

Link Flow diagram to Security testing

Identify and direct tests to components

Create Abuse cases and feed the Attack tree

To be sure we have all threat actors
Unified Threat Modeling
Attack
Tree

Abuse Flow
Case Diagram

Lessons Security
Learned Testing
Thanks to
OWASP Orange County
Security Org at Blizzard
You!

@jonathanmarcil
jonathan.marcil@owasp.org