Threat Modeling is a great way to analyze security early in software development by structuring possible attacks, bad actors and countermeasures over a broad view of the targeted system. This talk will describe basic components of a threat model and how to use them effectively. Threat Intelligence is where you gather knowledge about the environment and business assets to determine what are the actual threats. But how do you reconcile that with the current architecture in a useful manner? The toolkit presented in this talk will enable you to systematically structure related information using graphical notations such as flow diagram and attack tree. In case you are wondering where to start in your organization, a quick lightweight risk rating methodology will also be proposed. And in the end, you’ll see how we can all tie those together and get threat modeling to a point where it’s an efficient application security activity for communication. Doing this will prevent security reviews from missing important things even when chaos prevails during the realization of a project. Modeling concepts will be demonstrated with an actual IoT device used as example.
https://www.owasp.org/index.php/Quebec_City
https://twitter.com/jonathanmarcil
2. Sommaire
• Qui suis-je?
• Qu’est-ce que la Sécurité Applicative?
• Qu’est-ce que la Modélisation de Menaces?
• Modèles existants
• Toolkit component: Simplified Risk Rating
• Toolkit component: Attack Tree
• Toolkit component: Data Flow Diagram
• Conclusion et Ouverture
3. Qui suis-je?
• You may remember me from such things as..
– OWASP Montreal, Chapter Leader 2013-2015
– NorthSec, Challenge designer 2012-2014
– HackFest, Animation CTF 2005,2015
4. Qui suis-je?
• You may remember me from such things as..
– OWASP Montréal, Chapter Leader 2013-2015
– NorthSec, Challenge designer 2012-2014
– HackFest, Animation CTF 2005,2016
• Now living in beautiful Irvine, California
• Application Security at Blizzard Entertainment
5. Ma définition de la Sécurité Applicative
• Un mélange de
– Un livre: Building Security In
– Un standard: ISO/IEC 27034 Application Security
– Une direction: Trustworthy Computing, Microsoft
• Security Development Lifecycle
– Un désordre collaboratif: Wikipedia
• Se résume à
– Cycle de vie et activités
7. La Modélisation de Menaces
• Une activité de Sécurité Applicative
pour une analyse de la sécurité lors du
développement logiciel
• Structurer systématiquement
–Attaques
–Agents de menace
–Contre-mesures
8. Threat Intelligence
• Is not threat modeling
– It’s half of it!
• Threat actors
– And what they have to gain
• Knowledge base of threats
– Modeling is a methodology
9. 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
10. 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
11. Previously at OWASP Québec
9 mai 2017
La modélisation des menaces – Vincent Goulet
15. 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
• That’s it you now have risk rating
16. 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
47. Toolkit Component: DFD Diagram
• Data Flow Diagram
–Actually, not!
• Connection Flow Diagram
–Limit amount of visuals
–Focus on attack surface/vectors
48. 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
49. 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 won’t blame anyone using a cylinder instead
• Red dotted line for boundary
• 100% compatible with Microsoft SDL notation
61. 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
65. .
REVISED
2/23/2017
THREAT MODEL DIAGRAM
IoT
DRAWN BY
jonathan.marcil@owasp.org
VERSION
0.2
User
Internet
Cloud
Integration
Web Site
PHP
Social networks,
weather data, etc.
Broadcast
UPnP?
Cloud
API
Node.js
HTTPS
Browser
Send command
Mobile
App
My Script
Python MySQL
database
HTTP
IoT
Device
Local
API
HTTP
HTTPS
Periodically HTTP GET
to the API and receive a
commands to execute
There's no
authentication!
66. Security Controls Checklist
.
REVISED
2/23/2017
THREAT MODEL DIAGRAM
IoT
DRAWN BY
jonathan.marcil@owasp.org
VERSION
0.2
User
Internet
Cloud
Integration
Web Site
PHP
Social networks,
weather data, etc.
Broadcast
UPnP?
Cloud
API
Node.js
HTTPS
1 IoT device read only
Browser
Send command
Utilization of proper framework ORM2
Mobile
App
My Script
Python MySQL
database
HTTP
IoT
Device
Local
API
HTTP
HTTPS
3 Add Authentication and HTTPS
2
1
3
3
Periodically HTTP GET
to the API and receive a
commands to execute
There's no
authentication!
67. Conclusion
• Si vous avez besoin de vérifier la sécurité d’un système
complexe, le diagramme de flux est votre outil
• Vous pouvez utiliser ce que vous avez appris pour
guider d’autres activités de sécurité applicative
• Si vous tentez l’expérience durant une réunion et que
les gens finissent par clarifier et/ou améliorer le
système alors que vous ne dites rien; alors bravo, vous
avez gagné à la modélisation de menaces!
68. 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
71. Merci à
• OWASP Québec
• OWASP Montréal
• OWASP Orange County
• Département de Security chez Blizzard
• Vous!
@jonathanmarcil
jonathan.marcil@owasp.org
Notes de l'éditeur
Pour ceux qui pensait qu’animé un CTF c’était nouveau en 2016…. 2005:
https://web.archive.org/web/20051001072018/http://hackfest.centinel.org:80/francais/
Sources in order: Gary McGraw, Luc Poulin, Bill Gates and 175 random people that know better.
And I’m still not sure if it’s lifecycle or life cycle
And Threat Modeling is one of the arrows!
Can also be used to reach a maturity level in security, even if you don’t have any formal processes it works just fine.
Discrimination by algorithm: I’ve searched for “famous models”.
Picture under CC Attribution 2.0 https://creativecommons.org/licenses/by/2.0/
Source/credits https://www.flickr.com/photos/rustedhammer/2298322271
Did you know that most of OWASP documentation is too CC too?
https://www.schneier.com/academic/archives/1999/12/attack_trees.html (yup, it’s from 1999!)
You need to erase a lot because of refactoring/normalization of the tree.
Yeah Randomware, it’s like ransomware but it just make your file goes random
http://plantuml.com/
The tool is as great as the web site is ugly.