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. 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?
  2. 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
  3. 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
  4. 6.

    What is Threat Modeling? • Application Security activity to analyze

    security in software development • Systematically structure –Attacks –Bad Actors –Countermeasures
  5. 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
  6. 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
  7. 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
  8. 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?
  9. 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?
  10. 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).
  11. 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
  12. 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
  13. 21.
  14. 22.
  15. 23.
  16. 24.
  17. 25.
  18. 26.
  19. 27.
  20. 28.
  21. 29.
  22. 30.
  23. 31.
  24. 32.
  25. 33.
  26. 34.
  27. 35.
  28. 36.
  29. 37.
  30. 38.
  31. 39.
  32. 40.
  33. 41.
  34. 42.
  35. 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
  36. 44.
  37. 45.
  38. 47.
  39. 48.

    Toolkit Component: DFD Diagram • Data Flow Diagram –Actually, not!

    • Connection Flow Diagram –Limit amount of visuals –Focus on attack surface/vectors
  40. 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
  41. 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
  42. 59.

    . User Cloud Integration Web Site Cloud API Browser Mobile

    App My Script MySQL database IoT Device Local API
  43. 60.

    . User Internet Cloud Integration Web Site Cloud API Browser

    Mobile App My Script MySQL database IoT Device Local API
  44. 61.

    . User Internet Cloud Integration Web Site Cloud API Browser

    Mobile App My Script MySQL database IoT Device Local API
  45. 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
  46. 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
  47. 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
  48. 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
  49. 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!
  50. 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!
  51. 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!
  52. 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
  53. 70.

    1 2 3 Security Controls Checklist 1 IoT device read

    only Utilization of proper framework ORM 2 3 Add Authentication and HTTPS
  54. 72.

    Thanks • OWASP Orange County • OWASP Montreal • Security

    Org at Blizzard • You! @jonathanmarcil jonathan.marcil@owasp.org