Threat Modeling Toolkit

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.

Presentation will be done in english.

Speaker Bio:

Jonathan Marcil is the former chapter leader of OWASP Montreal and is now Senior Application Security Engineer at Blizzard Entertainment in beautiful Orange County, California.

Jonathan has been involved with OWASP for many years and has been behind the Media Project which gathered and promoted AppSec conferences video content in the official OWASP YouTube channel. He was also part of NorthSec CTF event as a challenge designer specialized in Web and imaginative contraptions.

He is passionate about Application Security and enjoys architecture analysis, code review, threat modeling and debunking security tools. He holds a diploma in Software Engineering from ÉTS Montreal and has more than 15 years of experience in Information Technology and Security.

Transcript

1. Threat Modeling Toolkit by Jonathan Marcil OWASP Montreal May 2017
2. 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?
3. 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
4. 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
5. My definition of Application Security
6. What is Threat Modeling? • Application Security activity to analyze security in software development • Systematically structure –Attacks –Bad Actors –Countermeasures
7. 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
8. 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
9. 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
10. Existing Models
11. Fresh wisdom: Adam Shostack
12. 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?
13. 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?
14. 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).
15. Toolkit Components • This is what you came for! – At slide #15, not bad..
16. 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
17. 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
18. Attack Tree: Open Safe
19. Attack Tree: IoT • Let’s take an example of a device
20. Whiteboard!
43. 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
46. habits ---> access spy ---> access PlantUML!
48. Toolkit Component: DFD Diagram • Data Flow Diagram –Actually, not! • Connection Flow Diagram –Limit amount of visuals –Focus on attack surface/vectors
49. 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
50. 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
51. Flow Diagram: IoT
52. IoT Device
53. . Mobile App IoT Device
54. . Browser Mobile App IoT Device
55. . Browser Mobile App My Script IoT Device
56. . Web Site Cloud API Browser Mobile App My Script IoT Device
57. . Cloud Integration Web Site Cloud API Browser Mobile App My Script IoT Device
58. . Cloud Integration Web Site Cloud API Browser Mobile App My Script IoT Device Local API
59. . User Cloud Integration Web Site Cloud API Browser Mobile App My Script MySQL database IoT Device Local API
60. . User Internet Cloud Integration Web Site Cloud API Browser Mobile App My Script MySQL database IoT Device Local API
61. . User Internet Cloud Integration Web Site Cloud API Browser Mobile App My Script MySQL database IoT Device Local API
62. 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
63. . 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
64. . 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
65. . 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
66. . 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!
67. 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!
68. 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!
69. 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
70. 1 2 3 Security Controls Checklist 1 IoT device read only Utilization of proper framework ORM 2 3 Add Authentication and HTTPS
71. Unified Threat Modeling Attack Tree Flow Diagram Security Testing Lessons Learned Abuse Case
72. Thanks • OWASP Orange County • OWASP Montreal • Security Org at Blizzard • You! @jonathanmarcil jonathan.marcil@owasp.org