Threat Modeling (2012) Case study of a web application Antonio Fontes Confoo 2012 Conference - Montreal (CA)

1. The OWASP Foundation
http://www.owasp.org
Threat analysis and modeling:
case study: a web application
Confoo Conference, Montreal, Feb 29th 2012
Antonio Fontes
antonio.fontes@owasp.org
Disclaimer: no cat was harmed during the preparation of this document.

2. Logistics
• This is a huge slide deck. Get prepared for it!
• You will get all the slides at the end of the session:
– http://slidehsare.net/starbuck3000
• Interrupt me when you have a question or want to share
a sentence
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 2

3. OWASP?
• Open Web Application Security Project
• Not-for-profit organization
• Open access, worldwide reach
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 3

4. OWASP?
• Elected committee
• Leaders:
– Project Leaders
– Chapter Leaders
• 1’500 members
– Individual, Academic , Corporate
• 20’000 meetings and conference participants
• 140 documentation and tools projects
• 250 chapters in 93 countries
• 1 website: https://www.owasp.org
• Montreal chapter!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 4

5. Me
• Antonio Fontes
• Geneva (Switzerland)
• Independant infosec consultant:
– Web applications security
– Risk visibility and management
– Training & Coaching
• Cybercrime/threat analysis report:
– http://cddb.ch (in French)
• OWASP:
– Switzerland Board Member
– Geneva Chapter Leader
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 5

6. You?
• Experienced in infosec?
• Experienced in TAM?
• Which industries?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 6

7. Objectives
1. We understand concepts and words related to
threat modeling web applications.
2. We know when and how the process should be
performed.
3. We can identify high priority efforts.
4. The resulting tool is repeatable and simple to
use.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 7

8. Agenda
• Context & motivations
• Case study: OPMC/PLCM
• Conclusion & perspectives
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 8

9. Context
• Proliferation of interconnected
systems
• Mobile equipment, cloud computing
• Cybersecurity hype
• Victims:
– Organizations, individuals
– Financial damage
– Reputation damages
– Privacy
– Legal / fines / Compliance
– Mules
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 9

10. Context
• Democratization of web/mobile development
• Lack of visibility on threats/risks:
– Developers
– Top Management
– Suppliers / Vendors
• Communities struggle to talk to each other:
– Lack of time?
– Motivation?
• Personal data:
– Increasing value
– Collect once, process anytime
– Threat of control, regulation, fines, legal actions..
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 10

11. Motivation for threat modeling
• Increase visibility during the project:
– Create opportunities for risk mitigation
– Visibility is actionable
– Produce reusable outputs
– The model makes decision making possible and allows
prioritization of efforts to maintain risk at an
acceptable level.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 11

12. « Asset »
“Something possessed or controlled by an individual
or organization, from which benefit may be
obtained.”
• An asset requires:
limited accessibility and
generates value
• Assets can be intangible
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 12

13. Examples
• Money
• Machine or object
• Knowledge
• Know-how
• Tool
• …
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 13

14. « Vulnerability »
“A feature of an asset, that could be accidentally or
intentionally exercised and result in a violation of
the information system’s security policy or a
security breach.”
• Warning: a legitimate and perfectly functional
feature can also be turned into a vulnerability
under appropriate conditions.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 14

15. Examples
• Paper is vulnerable to fire, water and…scissors…
• A human body is vulnerable to piercing objects…
• An electrical system may be vulnerable to a
power surge…
• A highly secure web application stored in a highly
secure server may be vulnerable to an
earthquake…
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 15

16. « Threat »
“Anything (object, event, person, …) capable of
performing unauthorized or undesired actions
against a system.”
• A threat requires:
resources, skills, and
access to a given
system. Impact? Severe. Probability? …
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 16

17. threats
• Natural events: flood, seismic event,…
• Physical evolution or attributes: accident, dust,
corrosion, heat/fire damage
• Service failures: air conditioned, power,
telecommunications
• Disturbances: radio emissions
• Technical failures: bug, saturation, malfunction
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 17

18. threats
• People:
– Misuses, distractions,
errors
– Hackers
– Cybercriminals
– Terrorists
A threatening source of threat that threatens you…
– Insiders
– Industrial and state-level espionage
• …
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 18

19. « Impact »
“A change in the capability of an organization or an
individual to achieve its/his/her objectives.”
• An impact may induce a
loss, or a gain.
• In information risk
management, we mostly
deal with adverse impacts.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 19

20. impacts
• Generic impacts:
– Reputation damage
– Disclosure of strategic information
– Loss of money
– Loss of knowledge or know-how
– Disruption of activity
• Specific impacts:
– Temporary exposure to health damage
– A fine caused by a breach of compliance
– A broken machine
– …
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 20

21. « scenario »
“a sequence of events that bring a system from an
initial state to another state.”
• Beware of the confusion between final state and
impact.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 21

22. impact vs. scenario
Scenario:
• Someone looking for vulnerabilities on App X
• Vulnerability ‘V’ is found
• Vulnerability ‘V’ is exploited as to execute a data
exfiltration operation
• Data is retrieved outside the system
• Data is sold/leaked to a third party.
Impact:
• Loss of secret information leaked to the
competition financial damage
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 22

23. « vulnerability »
“Attribute of an asset, which when accidently or
intentionally exercised allows the execution of an
undesired scenario.”
• Warning: a vulnerability is not necessarily technical (XSS,
SQLi, CSRF, etc.). Many legitimate features in software
can be turned into vulnerabilities once used under
particular circumstances.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 23

24. vulnerabilities
• A sheet of paper is vulnerable to fire, or scissors.
• The human body is vulnerable to piercing.
• An electronic appliance is vulnerable to power
surges.
• An ultra secure web application hosted on a ultra
secure host remains vulnerable to an earthquake.
• A 4096-bits cryptographic key is vulnerable to a
gun pointed at the key holder.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 24

25. “Risk”
“Potential that a given threat will exploit features of
an asset (or a group of assets) in such a way that
it would cause harm to its owner.”
• A risk requires:
R= p x i
– A threat
– One or more assets
– A likelihood (or probability)
– An undesired impact
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 25

26. “Risk” OPENOPENOPEN
OPENOPENOPEN!!
• Is the cat a threat
source?
• Is the bird vulnerable?
• What would be an
undesired scenario?
• What would be the
impact?
• Is the bird actually at risk?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 26

27. What about danger?
• Danger suggests the almost certainty that the
undesired scenario will actually happen.
• Let’s remain
« proportional… »
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 27

28. What is « secure software »?
• First we need to understand what can go wrong.
• Information systems security properties:
– Confidentiality
– Integrity
– Availability
– Non-repudiation
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 28

29. What is « secure software »?
• A web application is «secure» when it:
1. it protects itself [and its components] from
unauthorized access or modification.
2. its performance can be degraded for other reasons
than legitimate activity.
3. its users cannot deny their actions.
4. protects the privacy of the people involved in the
data it is processing.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 29

30. What is « secure software »?
• Organizations each have their own vision of ‘secure’,
based on their worst preoccupation:
– Ecommerce platforms
– Critical infrastructures
– Marketing campaigns
– B2B
– Online communities and social tools
– Electronic banks
– Public adminstrations
– Etc.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 30

31. Agenda
• Context & motivations
• Case study: OPMC/PLCM
• Conclusion & perspectives
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 31

32. PLCM: the need
• Planificateur en ligne pour
consultation médicale (Online
Planner for Medical Consultation)
• Mission:
1. Help the secretary activities of a
group of pediatricians working
in several cities.
2. Enable online medical appointments
3. Accelerate the initial diagnostic and prioritize
emergency cases
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 32

33. PLCM: the concept
• Use cases:
– Patients:
• Look for a free spot for medical
consult, and book it.
• Cancellation of appointments
– Doctors’ cabinet:
• Handling of urgent cases
• Pre-diagnostic of patients based on initial
basic survey answers and comments.
• Appointment re-arrangement when necessary
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 33

34. PLCM: the concept
• Use cases:
– Automation to insurance company:
• Anonymized statistics sent monthly
to an insurance company
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 34

35. PLCM: the concept
• Vision:
– A web application
– Regular patients have an account
• H+24 booking
– Pro hosting
• As cheap as possible...
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 35

36. PLCM: the customer
• Just talked to a web agency
- Can you do
that?
- CHALLENGE
ACCEPTED!!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 36

37. PLCM: the customer
• The customer comes to Confoo
and attends the “web security”
talk….
- Hey security
guy! What do
you think?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 37

38. PLCM: the customer
• The customer comes to Confoo
and attends the “web security”
talk….
- Hey security
guy! What do
you think?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 38

39. Mots de passe Insecure direct
Données
references
Script kiddies
VIP medical personnelles
information Insecure
Espionnage!des transport of
Données sur Cross-Site
Broken
enfants Can youANONYMOUS!!!
-credentials
Données surhelp Scripting!!!
authentication me?des enfants
Attaques web Hackers!
LDAP injection! SQL Injection! Insecure
Insecure Données password
Compliance! configuration storage
médicales
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 39

40. Threat analysis & modeling
(modélisation de menaces)
A process to identify and document threats to a
particular system and their most appropriate
countermeasures.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 40

41. What isn’t a threat model?
• It is not a solution to all problems:
– Insecure coding or deployment practices are not
covered by a TM
• It is not an exact science:
– 1 book covers the topic.
– It was written in 2004. By Microsoft engineers.
– A second book is being written.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 41

42. What is a threat model?
• It is a repeatable process.
• It is an early risk detection & prevention process:
– Conducted at design time
– Early threat and countermeasures detection
– Early risk treatment, thus, lower costs.
• It is a simple process:
– Pen and paper activity
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 42

43. What is a threat model?
• It is a tool that helps identifying:
– Threats, that might exercise their access to the
application
– Scenarios, that may result in damage/harm
– Controls, that may help blocking or detecting these
scenarios
• Ultimately, a threat model helps prioritize
security efforts.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 43

44. Elements of a TM
• Describing the system
• Identifying its valuable assets
• Identifying the threats sources
• Identifying doomsday scenarios
• Enumerating the most appropriate
measures/security controls
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 44

45. Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenarios
4. Identify measures/security controls
5. Document all previous outputs.
6. Transmit the threat model.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 45

46. 1. System description
• Describe the system objectives
• Identify the system security requirements
(we did this before, remember?)
• Draw the system using the dataflow
diagramming (DFD)method
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 46

47. 1. System description
Dataflow Diagramming DEMO
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 47

48. 1. System description
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 48

49. 1. System description
Datastore
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 49

50. 1. System description
Process!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 50

51. 1. System description
Actor!!!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 51

52. 1. System description
Connexion!!!!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 52

53. 1. System description
Trust boundary!!!!!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 53

54. 1. System description Trust
boundary
• Identify high-value assets
– Do we trust the admins?
– Do we trust the other machines?
– Anyone probably trying to intercept
communications?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 54

55. 1. System description
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 55

56. 1. System description
Data store
• Identify high-value assets
– Who benefits from stealing it? (confidentiality)
– Who wants to buy it? (confidentiality)
– Who wants to read it? (confidentiality)
– Who benefits from destroying it? (integrity)
– Who benefits from modifying it? (integrity)
– What data is under regulation/compliance control?
• Is it travelling outside the system?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 56

57. 1. System description
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 57

58. 1. System description
Process
• Identify high-value assets
– Who wants to imitate (spoof) it?
– Who wants to modify its execution flow?
– Is this system able to reach a more sensitive system?
• A control system? Physical machine?
• Another organization?
• A backend/transactional system ?
– Is it okay if this process gets shut down?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 58

59. 1. System description
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 59

60. 1. System description
External entity
• Identify high-value assets
– Who wants to imitate (spoof) the user?
• Can see something? Can write something?
– Is the user interested in denying his/her actions?
– Is the user using trusted equipment? (malware…)
– Does someone want to control one or more of your
clients/users systems?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 60

61. 1. System description
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 61

62. 1. System description
Dataflow
• Identify high-value assets
– Who wants to intercept the traffic?
• Secret information?
• Credentials?
– Who wants to modify it?
• Transactions?
– Flow direction:
• Can this flow directly allow bad data into our system?
• Can this flow directly feed sensitive data outside it?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 62

63. 1. System description
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 63

64. 1. System description
• Identify high-value assets
– Loop once again: you now know things you didn’t
know the first round.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 64

65. 1. System description
• High-value assets:
– Credentials will cross over the wire
– The web application is a gate to
the insurance company systems
– The databases are regulated and may probably trigger
high interest when either at-rest or in-transit.
– No network sniffing at the doctor’s cabinet (wired
ADSL line) but might be malware
• Need to ensure passwords cannot be stolen by a keylogger
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 65

66. 1. System description
• High-value assets:
– 2 malicious data injection flows.
Increase attention there!
– 3 disclosure flows. Watch out for error messages and
handling!
– 2 high-value client systems: increase output encoding
attention there!
– 2 highly regulated datastores
– 2 highly regulated dataflows
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 66

67. 1. Did you notice?
Training wasn’t needed to understand DFDs!
External entity Data store Dataflow Process
- User - Database server - Call - Service
- other system - Config file - Network link - Executable
-Partner/supplier - Registry - RPC - DLL
-… - Memory -… - Component
- Queue / stack - Web service
-… - Assembly
-…
Process boundary
Trust File system
boundary Network
…
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 67

68. Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenarios
4. Identify measures/security controls
5. Document all previous outputs.
6. Transmit the threat model.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 68

69. 2. Threat sources analysis
• Use a threat source enumeration
– Should be provided by corporate.
– By an expert, if no corporate view available.
– Enumeration should indicate:
• source + likelihood/intensity
• Evaluate the exposure to the threat source:
– How easily can the threat source reach the system?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 69

70. 2. Generic threat sources
Type Source Intensity exposure comment
Automated threat High
sources (worms..)
Opportunistic Automated hands High
(hackers w/ tools)
Compliance / Law Medium
Competition Low
“Anonymous” Low
Targeted Insiders Low
Industrial / State Low
espionage
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 70

71. 2. Doctor’s threat sources
Type Source Intensity exposure comment
Malware-infected High
client systems
Opportunistic
Kids High
Other cabinet Low
“Anonymous” Low
Targeted
Cheating patients Low
Industrial espionage Low
Compliance Low
regulation
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 71

72. 2. Doctor’s threat sources
Type Source Intensity exposure comment
Malware-infected High High Internet
client systems system
Opportunistic
Kids High High Internet
system
Other cabinet Low High Internet
system
“Anonymous” Low High Internet
system
Targeted
Cheating patients Low High Internet
system
Industrial espionage Low High Internet
system
Compliance Low Medium Private +
Regulation Patient data
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 72

73. Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenarios
4. Identify measures/security controls
5. Document all previous outputs.
6. Transmit the threat model.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 73

74. 3. Doomsday scenarios
• Some help: (Apply these to each threat source)
– Wants to steal your data? To sell it?
– Wants to modify your data?
– Wants to get access to your internal network?
– Wants to get access to another network through yours?
– Wants to stop/disturb your activity?
– Wants to deny his/her actions?
– Wants to avoid payment?
– Wants to withdraw money?
– Wants to damage your reputation?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 74

75. 3. Doomsday scenarios
• Some help: (Apply these to each threat source)
– What about someone using an automated tool?
– What about self-propagating malware?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 75

76. 3. Doomsday scenarios
• Describe the scenario:
– Who will trigger the scenario? (threat source)
• What is the intensity and exposure?
– What will be the impact?
• Theft? Loss? Corruption? Disruption? Money?
• Legal? Reputation? Productivity? Health?
– How will the scenario be realized?
• Describe how the attack is performed
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 76

77. 3. Doomsday scenarios
Description The patients identities database gets stolen
Description The passwords database gets broadcasted
Description Patients cheat by replacing other’s appointments with theirs
Description The insurance company gets under attack by our own server
Description A cabinet’s credentials get stolen by a third party
Description …
Description …
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 77

78. 3. Doomsday scenarios
Description The patients identities database gets stolen
Source(s) Other cabinet or some sort of espionage
(intensity: low; exposure: elevated)
Impact Financial: probably loss of revenue if another cabinet
Reputation: fatal if someone gets to know it…
Attack tree The data is obtained through a code injection:
#1 - an input parameter is not properly validated
- a DB code injection is performed on the parameter
- the data is returned to the attacker (either inline, or
through a file created on the system)
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 78

79. 3. Doomsday scenarios
Attack tree The data is obtained from within the hosting network:
#2 -The attacker gets into the system
- The attacker copies the files on an external media or
sends them
- The data can be read natively
Attack tree The attacker gets access to the cabinet account:
#3 - The password is guessed or bruteforced
- The password is intercepted on the wire
- The password is intercepted on the cabinet’s system
• Repeat with the other scenarios…
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 79

80. 3. Doomsday scenarios Attack trees
Attack tree #1 The data is obtained through a code injection:
- an input parameter is not properly validated
- a DB code injection is performed on the parameter
- the data is returned to the attacker (either inline, or through a
file created on the system)
Vulnerable
parameter
Code
injection
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 80

81. 3. Doomsday scenarios Attack trees
Attack tree #2 The data is obtained from within the hosting network:
-The attacker gets into the system
- The attacker copies the files on an external media or sends them
- The data can be read natively
Simple Network
password sniffing
Known local Physical
password intrusion
Vulnerable Local
parameter intrusion
Code Local
injection stealing
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 81

82. 3. Doomsday scenarios Attack trees
Attack tree #3 The attacker gets access to the cabinet account:
- The password is guessed or bruteforced
- The password is intercepted on the wire
- The password is intercepted on the cabinet’s system
Simple Network Traffic
password sniffing interception Weak
Malware
Known local Physical Hacked password
password intrusion email
Bruteforce
Vulnerable Local Stolen attack
parameter intrusion credentials
Bruteforced
Code Local Stolen cabinet
or Guessed
injection stealing password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 82

83. 3. Doomsday scenarios Attack tree for
Simple Network scenario #1
password sniffing Traffic Weak
interception Malware password
Known local Physical
Hacked
password intrusion Bruteforce
email
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 83

84. Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenarios
4. Identify measures/security controls
5. Document all previous outputs.
6. Transmit the threat model.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 84

85. 4. Identify security controls tree for
Attack
Simple Network scenario #1
password sniffing Traffic Weak
interception Malware password
Known local Physical
Hacked
password intrusion Bruteforce
email
Countermeasures analysis attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 85

86. 4. Identify security controls tree for
Attack
Simple Network scenario #1
password sniffing - ??? Traffic Weak
interception Malware password
Known local Physical
Hacked
password intrusion Bruteforce
email
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 86

87. 4. Identify security controls tree for
Attack
Simple Network scenario #1
- Use validation in all data
password sniffing entry points
Traffic Weak
interception Malware password
Known local Physical
Hacked
password intrusion Bruteforce
email
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 87

88. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception
- ??? Malware password
Known local Physical
Hacked
password intrusion Bruteforce
email
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 88

89. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception
- ??? Malware password
Known local Physical
Hacked
password intrusion Bruteforce
email
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 89

90. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception Malware
- Request authenticatedpassword
Known local Physical
physical access to server
Hacked
password intrusion Bruteforce
email
-
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 90

91. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception Malware
- Request authenticatedpassword
Known local Physical
physical access to server
Hacked
password intrusion Bruteforce
email
- ???
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 91

92. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception Malware
- Request authenticatedpassword
Known local Physical
physical access to server
Hacked
password intrusion Bruteforce
email
- Require complex passwords
attack
Local
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 92

93. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception Malware
- Request authenticatedpassword
Known local Physical
physical access to server
Hacked
password intrusion Bruteforce
email
- Require complex passwords
attack
Local - Use SSL/TLS
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 93

94. 4. Identify security controls tree for
Attack
Simple Network -Use validation in allscenario #1
data
password sniffing entry points
Traffic Weak
interception Malware
- Request authenticatedpassword
Known local Physical
physical access to server
Hacked
password intrusion Bruteforce
email
- Require complex passwords
attack
Local - Use SSL/TLS
Stolen
intrusion Bruteforced
Vulnerable credentials
or Guessed
parameter
Local
Code Got cabinet
stealing
injection password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 94

95. 4. Identify security controls tree for
Attack
scenario #1
-Use validation in all data Traffic Weak
entry points interception Malware password
- Request authenticated Hacked
physical access to server email Bruteforce
attack
- Require complex passwords
- Use SSL/TLS Stolen
Bruteforced
credentials
or Guessed
Got cabinet
password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 95

96. 4. Identify security controls tree for
Attack
scenario #1
-Use validation in all data Traffic Weak
entry points interception Malware password
- Request authenticated Hacked
physical access to server email Bruteforce
attack
- Require complex passwords
- Use SSL/TLS Stolen
Bruteforced
credentials
or Guessed
Got cabinet
password
Patient database
is stolen
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 96

97. 4. Identify security controls
Patient database
is stolen
Attack tree #1 - Use validation in all data entry points
Countermeasures
Attack tree #2 -Request authenticated physical access to server
Countermeasures - Require complex passwords
- Use SSL/TLS
Attack tree #3 - Require complex passwords
Countermeasures - Implement account temporary auto-lockout mechanism
- Use strong authentication for the cabinet accounts
- Don’t send password by email
- Force password reset link expiration after X minutes
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 97

98. 4. Identify security controls
Attack tree #3 - Require complex passwords
countermeasures - Implement account temporary auto-lockout mechanism
- Use strong authentication for the cabinet accounts
- Don’t send password by email
- Force password reset link expiration after X minutes
Attack tree #... -…
Countermeasures
Attack tree #... -…
Countermeasures
Attack tree #... -…
Countermeasures
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 98

99. Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenarios
4. Identify measures/security controls
5. Document all previous outputs.
6. Transmit the threat model.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 99

100. Documenting the threat model
• Proposition:
1. Context
2. System description
3. Threat sources
4. Doomsday scenarios
5. Proposed controls
6. Action list
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 100

101. Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenarios
4. Identify measures/security controls
5. Document all previous outputs.
6. Transmit the threat model.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 101

102. 6. Transmit the threat model
• We cannot just “write and throw out” a security
document.
• Recipients often won’t understand it.
• To increase adoption:
– Present the results to the audience, in person.
– Discuss the countermeasures: cost vs. impact
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 102

103. 6. Transmit the threat model
• To increase adoption:
– Complete the threat model with a proposed action list
that you know is acceptable.
– Don’t ask too much:
maintain the view
on the global system.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 103

104. 6. Transmit the threat model
• Typical clients:
– The architects: they should integrate the proposition to update
the design.
– The developers: they usually would benefit from the model
transparently, through the updated specification.
– The security testing team: they now know what to test
precisely!
– The software editor: if you are acquiring software, you can add
the threat model to the software acceptance procedure.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 104

105. Going further…
• Attacker centric:
– All threat sources identified: their skills and attacks are
described.
• Asset centric:
– Assets are identified and sorted by value. Typical threats are
enumerated in the form of “doomsday scenarios”.
• System centric:
– Systematic application of the STRIDE + standard threats model
on each component of the system and full enumeration of all
countermeasures.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 105

106. Going further…
• Variable abstraction-level DFDs:
– Do you trust the server? The application server? The web server? The
calling class? The calling web service?
• Systematic DFD threat analysis:
– Systematic STRIDE model
• Security posture:
– Compliance
– Defense  what we did
– Detection
– Countermeasures
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 106

107. Going further… Injection points
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 107

108. Going further… Infection points
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 108

109. Going further… Disclosure points
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 109

110. Going further… Encryption points
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 110

111. Going further…Technology threat points
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 111

112. Going further
Inception Design Implementation Verification Release Operations
Prevention:
- Secure design and architecture guidance
- Secure software requirements definition guidance
- Awareness of web induced risks
- Threat analysis & modeling
Detection:
- Requirements/specification analysis
- Design security review
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 112

113. Going further…
• STRIDE threat identification tool
http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
• DREAD severity assessment tool
http://en.wikipedia.org/wiki/DREAD:_Risk_assessment_model
• OWASP threat risk modeling
https://www.owasp.org/index.php/Threat_Risk_Modeling
• Microsoft SDL design phase activities
http://www.microsoft.com/security/sdl/discover/design.aspx
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 113

114. Agenda
• Context & motivations
• Case study: OPMC/PLCM
• Conclusion & perspectives
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 114

115. Conclusion
• TAM is an opportunity for early risk treatment:
– No source code required!
– Broad availability of common threats and countermeasures
– Look at the history: most scenarios are already known
• TAM is an opportunity for better design:
– The final action list can be given to an architect and to be
considered as intimately part of the requirements specification.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 115

116. Conclusion
• TAM is also an opportunity for loosing focus:
– Always keep the big picture in mind: who are we protecting
from and why?
– Be simple, stay small.
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 116

117. Next at Confoo:
• Today: • Friday:
– DIY incident response – Crypto 1o1 pour les
• Tomorrow: programmeurs
– Les navigateurs au service – Web application security
de vos applications trends
– Performing security audits – Microsoft Security
Development lifecycle
– Web security and you
– Trouvez la faille / Sopt the
– Sécurité et Ruby on Rails flaw!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 117

118. Meet the OWASP@confoo
France Canada
Sébastien Philippe
@spoint @securesymfony
Switzerland
Antonio Jonathan
@starbuck3000 @jonathanmarcil
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 118

119. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 119

120. Thank you!
For any contact/question/slides
request/inquiry/complaint/love letter/thank you:
email: antonio.fontes@owasp.org
twitter: @starbuck3000
En français:
Newsletter Cybermenaces et sécurité Internet:
http://cddb.ch
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 120

121. Threat modeling cheatsheets
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 121

122. Cheatsheets – Full TM process
1. Describe the context 5. Identify (counter)measures
2. Describe the system: – Output: list of controls for each
attack tree
– Output: business objective +
DFDs + high-value assets 6. Create the action list
3. Identify threat sources – Output: list of actions, sorted
by:
– Output: threat exposures
• Compliance requirements
4. Choose/Identify doomsday • High priority items (low cost/high
scenarios impact)
• Other actions
– Output: attack trees
7. Document & transmit!
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 122

123. Cheatsheets – Flow & Boundary
Process … Checkpoints:
Trust boundary
boundary File system - Protect the traffic if it allows:
Network - Credentials
- Private/Patient/Financial data
- Call - Other confidential information
Dataflow - Network link
- Data dumps
- RPC
- Can you trust the admins?
- If no, what are the potential threats?
- Will people sniff traffic there?
- If yes, protect the link.
- Are there “ennemy” hosts in the
same trust zone?
- If yes, what are the potential threats?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 123

124. Cheatsheets - Entity
- User Checkpoints:
External entity - other system - Do you need strong authentication?
-Partner/supplier…
- Can this entity conduct transactions?
- Can this entity access high privileges?
- Is the entity connecting from insecure or
untrusted client equipment?
- Is the entity connecting from a multi-
user system?
- Is data being stored at that entity?
- How do you protect it from tampering?
- How do you protect it from 3rd party
access?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 124

125. Cheatsheets - Process
- Service - Web service Checkpoints:
Process - Executable - Assembly - How do you authenticate this
- DLL -…
- Component process?
- Can someone imitate it?
- Is the process returning data - How do you validate it?
outside? - Can the process reach more
- Can system/error details be disclosed? sensitive systems?
- How would you detect leaking data?
- Confidential data?
- How do you protect client-side attacks?
- A physical control system?
- Is the process accepting data from - Another organization?
outside the secure boundary? - A backend/transactional system?
- Validate everything that comes in. - If yes is it hosted on a secure system?
- Verify that you validate everything. - Can this process be interrupted?
- Ask a 3rd- party to verify this. - If no, how do you prevent this?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 125

126. Cheatsheets - Datastore
- Database - Memory Checkpoints:
Data store server - Queue /
- Config file stack - Who wants that data?
- Registry -… - Will they hack for it? Or will they pay
someone to retrieve it from inside?
- Is the storage protected from local
access?
- If no, what are the threats?
- Can you encrypt it?
- If you encrypt it, where would be the keys?
- Is there some compliance or regulation
that forces usage of encryption?
- Is the datastore located on a mobile
system?
- What if the support gets stolen?lost?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 126

127. Cheatsheets – human threat sources
Type Source Intensity Exposure comment
Automated threat High
sources (worms..)
Opportunistic Automated hands High
(hackers w/ tools)
Compliance / Law Medium
Competition Low-High
“Anonymous” Low-High Evaluate collateral
dmg.
Targeted
Insiders Low-High
Industrial / State Low-
espionage High?
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 127

128. Cheatsheets – Doomsday scenarios
– Data X was stolen – User U was able to
• Credentials/Private data were withdraw/redirect money
disclosed – A secret was intercepted by a guy
– Data X was modified sniffing the network
• Who can modify access control – A highly sensitive user password
rules? Super admin password? was stolen on his infected phone
– Process P was spoofed to capture – A connection link is saturated
data X
– A process or datastore is saturated
– Code was injected in Process P to by creating cumulative elements of
access deeper system X
– Process P was interrupted, crashed
or slowed down
– User u denies his/her actions
– User U was able to avoid payment
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 128

129. Things you want to remember
2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 129