Presentation by Dominic White at Metricon 6 in 2011. This presentation is about the methodology behind Sensepost's corporate threat modeling tool.

1. Metricon 6, a Usenix Workshop SensePostThreat Modeling

2. Agenda Introduction What is TM Why TM Our goals with CTM Methodology Entities & Mapping Modeling Risk Calculation & Permutations Analysis Scenario Modeling Brief Comparisons

3. Dominic White @singe http://singe.za.net/ Work: Research: MSc in Security Interests in Privacy, Defensive Tech & Security Management About Me

4. Introduction What is TM Why TM Design Goals 1

5. A model in science is a physical, mathematical, or logical representation of a systemof entities, phenomena, or processes. Basically a model is a simplified abstract view of the complex reality Breadth over depth Represents criteria specific to analysis What is Modeling?

6. A threat model is: “A systematic, non-provable, internally consistent method of modeling a system, enumerating risks against it, and prioritising them.” Systematic Non-Provable Internally Consistent System Model Risk Enumeration Prioritisation What is Threat Modeling?

7. Escaping the Detail Trade Off

8. Usual Drivers of Controls Audit reports Prioritises: financial systems, audit house priorities, auditor skills, rotation plan, known systems Vendor marketing Prioritises: new problems, overinflated problems, product as solution New Attacks Prioritises: popular vulnerability research, complex attacks Individual Experience Prioritises: past experience, new systems, individual motives Why Threat Model?

9. Threat Modeling provides: All (most) information security risks systematic enumeration of risks Prioritisation of risks puts known risks in their place & compares new risks Justification no appeal to expert authority Decision Making scenario modeling to test decisions Education Can involve whole team Why Threat Model?

10. Developed for consultative role i.e. likely not the person making the changes Focus is on: Providing decision making information Rapid initial model creation Hybrid approach Bit of all the others Some parts we just threw out Highly flexible Initially, due to uncertainty, increasingly less so Detailed & aggregated results Includes test plan for verification SensePost CTM Design Goals

11. Methodology Entities & Mappings 2.1

12. Entity Overview Locations Controls Users enforceable trust Interfaces method of system access asset value Attacks likelihood Damage Tests certainty relevance

13. Represent the trust (controls) of a location Interfaces are exposed at locations Users are present at locations Three types: Physical Data centers, Head Office, Remote Sites Network Internet, DMZ, Server Network, User Network Logical / Functional (new) Represent controls within authorisation levels Administrative, authenticated, unauthenticated access Locations

14. Enforceable trust of user group i.e. contractual or controlled trust, not gut feel Users are mapped to locations Interfaces are exposed to users via locations Example general groups: Anonymous unidentified or unauthenticated users External Users suppliers, contractors Internal Employees application users, administrators, call center Users

15. Methods of interacting with a system or asset They are things an attacker could compromise Exposes the value of asset Interfaces to the same system have a consistent value Value can be set to existing system criticality ratings Types Physical Console Access, Hardware Network Remote Desktop, SSH, NTP Functional (new) Represent access to data & functionality within an authorisation role Administrative Access, Approve Transaction Interfaces

16. Users are present at certain locations Many to Many mapping Both are a representation of controls “Company founder in the mission impossible room” vs.. “Unknown Outsider on the Internet” Location type mappings Physical – users who can be physically present Network – users who can access the network Logical – users who have been granted, or have authorisation MappingUsers to Locations

17. Interfaces are present at certain locations Many to Many mapping Constraints Physical interfaces only mapped to physical locations Physical Server in Data Centre A Technical interfaces only mapped to network locations Remote Desktop in Internal Network Functionality interfaces only to functional locations Execute Trade in Broken Role MappingInterfaces to Locations

18. Attacks An attack in performed on an interface to expose some of its value Likelihood is based on factors specific to the attack Excludes trust of users, or controls in place General likelihood defined per attack, but made specific when mapped Popularity, easy of discovery/exploitation, prevalence (DREAD) Initial work into using external attack metrics VERIS – best mapping, sometimes non-discreet CWE – too detailed, vulns specific, no “abuse of privilege” STRIDE – not specific enough Impact is the worst case scenario Defines how much of interface value would be affected (damage) Originally named “risks”

19. Attacks are performed against interfaces Many to one mapping Likelihood & Impact made specific per mapping System CIA should be considered e.g. theft of e-mail may be more damaging to the CEO than the gardener “Could this attack lead to a full compromise of the system?” Examples Physical theft of the Physical Server Password Bruteforce against Outlook Web Access Web Front-End Abuse of Privilege of the Administrator Role MappingAttacks to Interfaces

20. Validate permutations of threat vector combinations Can be any type of test that provides more information Technical test, research, policy work Different tests provide a different level of certainty Proved  Disproved Can be granularly mapped Against a specific entity or combination of entities Tests

21. Methodology Modeling How-to System Template Guidelines 2.2

22. Data Gathering Collect as much information about the environment as you can. Network diagrams, key system documentation, existing risk/criticality analysis, past audit reports Interview Ideally, find a tech generalist with a good overview, then get specific, large company’s knowledge is more distributed Look to validate statements across interviews Get multiple “views” on criticality Testing Light testing to validate claims e.g. basic network footprintingor application use Passive collection Look for problems that should come out in the TM e.g. if they have regular & damaging virus outbreaks and the TM disagrees … ModelingA How-To

23. System Template<Name> |<Description> AA Authentication Source Authorization Integration Source Destination Criticality Include overall rating, individual ratings & reasons Confidentiality Integrity Availability Possession Authenticity Utility Locations Physical Network Functional (controls) Interfaces Include number & locations Physical Network Functional (access) Users Include number & locations Admins Users Support

24. Identify unique entitiesfrom completed system templates and general documentation – reconcile if differences Identify shared infrastructure & create new systems for them Map users & interfaces to locations Linked systems An application's functional interfaces should be mapped to its infrastructure’s functional locations For integrated systems, map functional interfaces to locations depending on access (push vs.. pull vs.. full) Process

25. Keep everything equally specific Summarise when no meaningful security difference Don’t create interfaces per-system for shared infrastructure Don’t represent risks more than once e.g. Don’t map two interfaces to the same system to the same location unless they are different “paths” e.g. administrator access implies “normal” access Avoid catch-all systems such as “user’s computers” rather model them as interfaces to relevant areas 2-tier vs.. 3-tier applications have different access from the application to the DB & vice-versa Modeling Gotchas

26. Methodology Calculations & Permutations 2.3

27. Entity Relationship present at available at performed at performed on performed by

28. Permutations Administrators Exchange MAPI Head Office Remote MAPI Exploit Anonymous

29. Understand concepts in relation to each other Discrete Individually necessary Collectively sufficient risk = threat x vulnerability x impact Disclaimer: Σ – The International Sign for “Stop Reading Here” Risk Equation

30. The tool gives us the following inputs User Trust Location Trust (controls) Interface Value Attack Likelihood Attack Impact But, complete freedom in defining how they are mashed up Input Values

31. risk = threat x vulnerability x impact likelihood = threat x vulnerability risk = likelihood x impact Likelihood

32. risk = applied likelihood + value at risk applied likelihood = attack likelihood (reduced by) user trust + location trust value at risk = value of asset (reduced by) amount of asset exposed by attack Risk Equation Used

33. [6 minus] – Ratings are out of 5 & denote a positive trust value, we want the “distrust” value [multiply 0.2] – We want the trust & impact to moderate the likelihood & value [divide by 2] – We take an average of user & location trust (equally weighted) Risk Equation

34. Methodology Analysis 2.4

35. Takes every permutation & provides analysis graphs & a risk curve Provides three things Risk Curve One view to rule them all Analysis Graphs Slice & Dice Detailed risk searching/pivot table Zoom Threat Model Dashboard

36. Challenge was to provide management view Single number loses too much context Frequency graph of number of “risks” per severity level Risk Curve

37. “Digital” version of risk curve, with ability to show risks per entity type Can view per “perspective” physical, technical, functional Can zoom into showing only risks relating to a specific system Can look at “pivot” risks, i.e. attacks available to someone once they have compromised a system Analysis Graphs

38. Analysis Graphs ExampleAll Perspectives, by Attack

39. Analysis Graphs ExampleAll Perspectives, by Interfaces

40. Analysis Graphs ExampleAll Perspectives, by Users

41. Analysis Graphs ExampleAll Perspectives, by Locations

42. Analysis Graphs ExampleTechnical Perspectives, by Attack

43. Analysis Graphs ExampleFunctional attacks from Active Directory

44. Methodology Scenario Modeling 2.5

45. Area Under Review

46. Risk Frequency

47. Cumulative Risk per Location

48. Cumulative Risk per Threat

49. Suggested Change

50. Resulting Risk Frequency

51. Resulting Risk per Location

52. Recommended Change

53. Resulting Risk Frequency

54. Tool re-write - aiming for cross platform enforcing certain design constraints e.g. physical <-> physical mappings only macro’ing time consuming tasks Adding population size Permutations favour specificity e.g. if you define multiple user groups for one application & not another, the first app has more risks Refining the risk equation Equal consideration of user & location trust may need refining Normalise across physical, network & functional “views” Refining modeling bounding as results are tested Future Work

55. Questions? http://www.sensepost.com/blog/ The End