Threat Modeling Toolkit by Jonathan Marcil OWASP Montreal May 2017

Summary • Who’s that guy again? • What is Application Security? • What is Threat Modeling? • Existing models • Toolkit component: Simplified Risk Rating • Toolkit component: Attack Tree • Toolkit component: Data Flow Diagram • What’s next?

Who am I? • You may remember me from such things as.. – OWASP Montreal, Chapter Leader 2013-2015 – NorthSec, Challenge designer 2012-2014 – LAN ETS, Founder 2002-2008 • Now living in beautiful Irvine, California • Application Security at Blizzard Entertainment

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 – It’s 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

Fresh wisdom: Adam Shostack

Fresh wisdom Four questions for threat modeling: • What are you working on? • What can go wrong? • What do to about it? • Did you do an acceptable job at it?

Fresh wisdom for pentesting You can map threat classification models with the types of tools you are using that might help for completeness of your tool selection As you nmap, tcpdump, lsof, strace of a system you're making a model of a system in your head. Why not white board it?

Fresh wisdom Make sure everyone is thinking about the same thing. Whiteboard helps with that. Don't use a monolithic process, use blocks of different tools that you mix together as you use / need them. Threat modeling is not one single skill. It's multiples techniques (DFD, stride) & knowledge repertoire (tools, books).

Toolkit Components • This is what you came for! – At slide #15, 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 • That’s 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 • Let’s take an example of a device

Whiteboard!

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

No content

Trick on drawing: code it instead! • PlantUML @startuml skinparam monochrome true agent "Mass mining" as mine agent "Mass scan" as scan agent "DDoS" as ddos agent "Control many devices \n(Botnet)" as botnet mine --> botnet scan --> botnet ddos --> botnet agent "Use legit command" as legitcmd agent "Exploit device flaws" as flaws agent "Obtain device access" as access botnet --> legitcmd botnet --> flaws botnet --> access agent "Get WiFi LAN access" as wifi agent "Get Physical access" as phys agent "Place Factory Backdoor" as factory agent "Hack cloud server" as cloud access --> wifi access --> phys access --> factory access --> cloud agent "Make my life miserable" as life agent "Randomware" as ransomware agent "Invade my privacy" as privacy agent "Mess with the lights" as mess life --> ransomware life --> privacy life --> mess agent "View my habits" as habits agent "Spy me live" as spy privacy --> habits privacy --> spy agent "Steal cloud data" as data habits --> data spy --> data data ---> cloud agent "Sniff network" as sniff habits ---> sniff spy ---> sniff access --> sniff sniff --> wifi sniff --> phys @enduml

No content

No content

habits ---> access spy ---> access PlantUML!

No content

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 won’t blame anyone using a cylinder instead • Red dotted line for boundary • 100% compatible with Microsoft SDL notation

Flow Diagram: IoT

IoT Device

. Mobile App IoT Device

. Browser Mobile App IoT Device

. Browser Mobile App My Script IoT Device

. Web Site Cloud API Browser Mobile App My Script IoT Device

. Cloud Integration Web Site Cloud API Browser Mobile App My Script IoT Device

. Cloud Integration Web Site Cloud API Browser Mobile App My Script IoT Device Local API

. User Cloud Integration Web Site Cloud API Browser Mobile App My Script MySQL database IoT Device Local API

. User Internet Cloud Integration Web Site Cloud API Browser Mobile App My Script MySQL database IoT Device Local API

. User Internet Cloud Integration Web Site Cloud API Browser Mobile App My Script MySQL database IoT Device Local API

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

. User Internet Cloud Integration Web Site Broadcast UPnP? Cloud API HTTPS Browser Mobile App My Script MySQL database HTTP IoT Device Local API HTTP HTTPS

. User Internet Cloud Integration Web Site Social networks, weather data, etc. Broadcast UPnP? Cloud API HTTPS Browser Mobile App My Script MySQL database HTTP IoT Device Local API HTTP HTTPS

. User Internet Cloud Integration Web Site PHP Social networks, weather data, etc. Broadcast UPnP? Cloud API Node.js HTTPS Browser Mobile App My Script Python MySQL database HTTP IoT Device Local API HTTP HTTPS

. 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!

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 ORM 2 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!

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

1 2 3 Security Controls Checklist 1 IoT device read only Utilization of proper framework ORM 2 3 Add Authentication and HTTPS

Unified Threat Modeling Attack Tree Flow Diagram Security Testing Lessons Learned Abuse Case

Thanks • OWASP Orange County • OWASP Montreal • Security Org at Blizzard • You! @jonathanmarcil jonathan.marcil@owasp.org