Threat Modeling Toolkit

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.

09905cce02942fb076f958f4b69fd8f6?s=128

OWASP Montréal

May 23, 2017
Tweet

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!

  21. None
  22. None
  23. None
  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  34. None
  35. None
  36. None
  37. None
  38. None
  39. None
  40. None
  41. None
  42. None
  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
  44. None
  45. None
  46. habits ---> access spy ---> access PlantUML!

  47. None
  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