Threat Modeling web applications (2012 update)
Upcoming SlideShare
Loading in...5
×
 

Threat Modeling web applications (2012 update)

on

  • 6,648 views

Threat Modeling (2012)

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

Statistics

Views

Total Views
6,648
Views on SlideShare
6,647
Embed Views
1

Actions

Likes
4
Downloads
187
Comments
0

1 Embed 1

http://www.php-talks.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Threat Modeling web applications (2012 update) Threat Modeling web applications (2012 update) Presentation Transcript

    • 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.orgDisclaimer: no cat was harmed during the preparation of this document.
    • 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
    • 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
    • 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
    • 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
    • You?• Experienced in infosec?• Experienced in TAM?• Which industries? 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 6
    • Objectives1. 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
    • Agenda• Context & motivations• Case study: OPMC/PLCM• Conclusion & perspectives 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 8
    • 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
    • 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
    • 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
    • « 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
    • Examples• Money• Machine or object• Knowledge• Know-how• Tool• … 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 13
    • « 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
    • 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
    • « 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
    • 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
    • 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
    • « 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
    • 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
    • « 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
    • impact vs. scenarioScenario:• 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
    • « 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
    • 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
    • “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
    • “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
    • 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
    • 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
    • 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
    • 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
    • Agenda• Context & motivations• Case study: OPMC/PLCM• Conclusion & perspectives 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 31
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Mots de passe Insecure direct Données references Script kiddies VIP medical personnelles information Insecure Espionnage!des transport of Données sur Cross-SiteBroken 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Threat modeling process1. Describe the system and its assets2. Identify the threat sources3. Identity doomsday scenarios4. Identify measures/security controls5. Document all previous outputs.6. Transmit the threat model. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 45
    • 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
    • 1. System descriptionDataflow Diagramming DEMO 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 47
    • 1. System description2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 48
    • 1. System description Datastore2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 49
    • 1. System description Process!2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 50
    • 1. System description Actor!!!2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 51
    • 1. System description Connexion!!!!2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 52
    • 1. System description Trust boundary!!!!!2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 53
    • 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
    • 1. System description2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 55
    • 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
    • 1. System description2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 57
    • 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
    • 1. System description2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 59
    • 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
    • 1. System description2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 61
    • 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
    • 1. System description2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 63
    • 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
    • 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
    • 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
    • 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
    • Threat modeling process1. Describe the system and its assets2. Identify the threat sources3. Identity doomsday scenarios4. Identify measures/security controls5. Document all previous outputs.6. Transmit the threat model. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 68
    • 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
    • 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 espionage2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 70
    • 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
    • 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
    • Threat modeling process1. Describe the system and its assets2. Identify the threat sources3. Identity doomsday scenarios4. Identify measures/security controls5. Document all previous outputs.6. Transmit the threat model. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 73
    • 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
    • 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
    • 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
    • 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
    • 3. Doomsday scenariosDescription The patients identities database gets stolenSource(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
    • 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
    • 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)Vulnerableparameter Code injection Patient database is stolen2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 80
    • 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 intrusionVulnerable Localparameter intrusion Code Local injection stealing Patient database is stolen2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 81
    • 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 BruteforceVulnerable Local Stolen attackparameter 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
    • 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 83
    • Threat modeling process1. Describe the system and its assets2. Identify the threat sources3. Identity doomsday scenarios4. Identify measures/security controls5. Document all previous outputs.6. Transmit the threat model. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 84
    • 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 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 attack Local Stolen intrusion BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 86
    • 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 87
    • 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 89
    • 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 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 - Require complex passwords attack Local Stolen intrusion BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 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 - Use SSL/TLS Stolen intrusion BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 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 BruteforcedVulnerable credentials or Guessedparameter Local Code Got cabinet stealing injection password Patient database is stolen 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 94
    • 4. Identify security controls tree for Attack scenario #1-Use validation in all data Traffic Weakentry points interception Malware password- Request authenticated Hackedphysical 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
    • 4. Identify security controls tree for Attack scenario #1-Use validation in all data Traffic Weakentry points interception Malware password- Request authenticated Hackedphysical 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
    • 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
    • 4. Identify security controlsAttack tree #3 - Require complex passwordscountermeasures - 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 minutesAttack tree #... -…CountermeasuresAttack tree #... -…CountermeasuresAttack tree #... -…Countermeasures 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 98
    • Threat modeling process1. Describe the system and its assets2. Identify the threat sources3. Identity doomsday scenarios4. Identify measures/security controls5. Document all previous outputs.6. Transmit the threat model. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 99
    • 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
    • Threat modeling process1. Describe the system and its assets2. Identify the threat sources3. Identity doomsday scenarios4. Identify measures/security controls5. Document all previous outputs.6. Transmit the threat model. 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 101
    • 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
    • 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
    • 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
    • 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
    • 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
    • Going further… Injection points2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 107
    • Going further… Infection points2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 108
    • Going further… Disclosure points2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 109
    • Going further… Encryption points2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 110
    • Going further…Technology threat points 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 111
    • 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 review2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 112
    • 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
    • Agenda• Context & motivations• Case study: OPMC/PLCM• Conclusion & perspectives 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 114
    • 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
    • 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
    • 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
    • Meet the OWASP@confoo France Canada Sébastien Philippe @spoint @securesymfony Switzerland Antonio Jonathan @starbuck3000 @jonathanmarcil2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 118
    • 2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 119
    • 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.ch2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 120
    • Threat modeling cheatsheets2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 121
    • Cheatsheets – Full TM process1. Describe the context 5. Identify (counter)measures2. Describe the system: – Output: list of controls for each attack tree – Output: business objective + DFDs + high-value assets 6. Create the action list3. Identify threat sources – Output: list of actions, sorted by: – Output: threat exposures • Compliance requirements4. 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
    • 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 informationDataflow - 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
    • 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
    • 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
    • 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
    • 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
    • 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 payment2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 128
    • Things you want to remember2/29/2012 Confoo 2012 Montreal - Threat Modeling - Antonio Fontes 129