Threat Modeling web applications (2012 update)

Threat analysis and modeling:

case study: a web application

The OWASP Foundationhttp://www.owasp.org

case study: a web applicationConfoo Conference, Montreal, Feb 29th 2012

Antonio [email protected]

Disclaimer: 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 • Interrupt me when you have a question or want to share

a sentence

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

OWASP?

• Open Web Application Security Project

• Not-for-profit organization

• Open access, worldwide reach


OWASP?

• Elected committee

• Leaders:– Project Leaders

– Chapter LeadersChapter 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!


Me

• Antonio Fontes

• Geneva (Switzerland)

• Independant infosec consultant:– Web applications security– 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


You?

• Experienced in infosec?

• Experienced in TAM?

• Which industries?


Objectives

1. We understand concepts and words related to

threat modeling web applications.

2. We know when and how the process should be 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.


Agenda

• Context & motivations

• Case study: OPMC/PLCM

• Conclusion & perspectives• Conclusion & perspectives


Context

• Proliferation of interconnected systems

• Mobile equipment, cloud computing

• Cybersecurity hype

• Victims:• Victims:– Organizations, individuals

– Financial damage

– Reputation damages

– Privacy

– Legal / fines / Compliance

– Mules


Context

• Democratization of web/mobile development

• Lack of visibility on threats/risks:– Developers

– Top Management

– Suppliers / Vendors– 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..


Motivation for threat modeling

• Increase visibility during the project:

– Create opportunities for risk mitigation

– Visibility is actionable – Visibility is actionable

– Produce reusable outputs

– The model makes decision making possible and allows

prioritization of efforts to maintain risk at an

acceptable level.


« 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


Examples

• Money

• Machine or object

• Knowledge• Knowledge

• Know-how

• Tool

• …


« 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.”security breach.”

• Warning: a legitimate and perfectly functional

feature can also be turned into a vulnerability

under appropriate conditions.


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 • 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…


« 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? …


threats

• Natural events: flood, seismic event,…

• Physical evolution or attributes: accident, dust,

corrosion, heat/fire damagecorrosion, heat/fire damage

• Service failures: air conditioned, power,

telecommunications

• Disturbances: radio emissions

• Technical failures: bug, saturation, malfunction


threats

• People:

– Misuses, distractions, errors

– Hackers– Hackers

– Cybercriminals

– Terrorists

– Insiders

– Industrial and state-level espionage

• …

A threatening source of threat that threatens you…


« Impact »

“A change in the capability of an organization or an individual to achieve its/his/her objectives.”

• An impact may induce a • An impact may induce a loss, or a gain.

• In information risk management, we mostly deal with adverse impacts.


impacts

• Generic impacts:– Reputation damage

– Disclosure of strategic information

– Loss of money

– Loss of knowledge or know-how– 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

– …


« 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.


impact vs. scenario

Scenario:

• Someone looking for vulnerabilities on App X

• Vulnerability ‘V’ is found

• Vulnerability ‘V’ is exploited as to execute a data • 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


« 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.


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 • 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.


“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:

– A threat

– One or more assets

– A likelihood (or probability)

– An undesired impact

R= p x i


• Is the cat a threat

source?

• Is the bird vulnerable?

• What would be an

“Risk” OPENOPENOPEN

OPENOPENOPEN!!

• What would be an

undesired scenario?

• What would be the

impact?

• Is the bird actually at risk?


What about danger?

• Danger suggests the almost certainty that the

undesired scenario will actually happen.

• Let’s remain• 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– Confidentiality

– Integrity

– Availability

– Non-repudiation



• 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.



• Organizations each have their own vision of ‘secure’,

based on their worst preoccupation:

– Ecommerce platforms

– Critical infrastructures– Critical infrastructures

– Marketing campaigns

– B2B

– Online communities and social tools

– Electronic banks

– Public adminstrations

– Etc.


Agenda





PLCM: the need

• Planificateur en ligne pour

consultation médicale (Online

Planner for Medical Consultation)

• Mission:• 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


PLCM: the concept

• Use cases:

– Patients:

• Look for a free spot for medical

consult, and book it.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


PLCM: the concept

• Use cases:

– Automation to insurance company:

• Anonymized statistics sent monthly

to an insurance companyto an insurance company


PLCM: the concept

• Vision:

– A web application

– Regular patients have an account– Regular patients have an account

• H+24 booking

– Pro hosting

• As cheap as possible...


PLCM: the customer

• Just talked to a web agency

- Can you do


- Can you do

that?- CHALLENGE

ACCEPTED!!

PLCM: the customer

• The customer comes to Confoo

and attends the “web security”

talk….- Hey security


- Hey security

guy! What do

you think?

Broken

Données

personnellesScript kiddies

ANONYMOUS!!!Données sur des

enfants Données sur

Mots de passe

Cross-Site

Scripting!!!

Espionnage!Insecure

transport of

credentials

Insecure direct

referencesVIP medical

information

- Can you help Broken

authentication


ANONYMOUS!!!

Données

médicales

enfants Données sur

des enfantsAttaques web Hackers!

SQL Injection!

Scripting!!!

Compliance!

credentials

LDAP injection! Insecure

password

storageInsecure

configuration

- Can you help

me?

Threat analysis & modeling

(modélisation de menaces)

A process to identify and document threats to a A process to identify and document threats to a

particular system and their most appropriate

countermeasures.


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.


What is a threat model?

• It is a repeatable process.

• It is an early risk detection & prevention process:

– Conducted at design time– Conducted at design time

– Early threat and countermeasures detection

– Early risk treatment, thus, lower costs.

• It is a simple process:

– Pen and paper activity


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.


Elements of a TM

• Describing the system

• Identifying its valuable assets

• Identifying the threats sources• Identifying the threats sources

• Identifying doomsday scenarios

• Enumerating the most appropriate

measures/security controls


Threat modeling process

1. Describe the system and its assets

2. Identify the threat sources

3. Identity doomsday scenarios3. Identity doomsday scenarios

4. Identify measures/security controls

5. Document all previous outputs.

6. Transmit the threat model.


1. System description

• Describe the system objectives

• Identify the system security requirements

(we did this before, remember?)(we did this before, remember?)

• Draw the system using the dataflow

diagramming (DFD)method



Dataflow Diagramming DEMO



Datastore



Process!



Actor!!!




Connexion!!!!


Trust boundary!!!!!



• Identify high-value assets

– Do we trust the admins?

– Do we trust the other machines?

Trust

boundary

– Do we trust the other machines?

– Anyone probably trying to intercept

communications?




– Who benefits from stealing it? (confidentiality)

– Who wants to buy it? (confidentiality)

Data store

– 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?




– Who wants to imitate (spoof) it?

– Who wants to modify its execution flow?

Process

– 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?




– Who wants to imitate (spoof) the user?

• Can see something? Can write something?

External entity

• 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?




– Who wants to intercept the traffic?

• Secret information?

Dataflow

• 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?




– Loop once again: you now know things you didn’t

know the first round.



• High-value assets:

– Credentials will cross over the wire

– The web application is a gate to – 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



• 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


1. Did you notice?

Training wasn’t needed to understand DFDs!

- Call - Service- Database server- User

External entity ProcessDataflowData store


Process boundary

File system

Network

…

- Call

- Network link

- RPC

- …

- Service

- Executable

- DLL

- Component

- Web service

- Assembly

- …

- Database server

- Config file

- Registry

- Memory

- Queue / stack

- …

- User

- other system

-Partner/supplier

- …

Trust

boundary

2. Threat sources analysis

• Use a threat source enumeration

– Should be provided by corporate.

– By an expert, if no corporate view available.– 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. Generic threat sourcesType Source Intensity exposure comment

Opportunistic

Automated threat

sources (worms..)

High

Automated hands

(hackers w/ tools)

High

Compliance / Law Medium

Targeted

Competition Low

“Anonymous” Low

Insiders Low

Industrial / State

espionage

Low


2. Doctor’s threat sourcesType Source Intensity exposure comment

Opportunistic

Malware-infected

client systems

High

Kids High

Other cabinet Low

Targeted

Other cabinet Low

“Anonymous” Low

Cheating patients Low

Industrial espionage Low

Compliance

regulation

Low


2. Doctor’s threat sourcesType Source Intensity exposure comment

Opportunistic

Malware-infected

client systems

High High Internet

system

Kids High High Internet

system

Targeted

Other cabinet Low High Internet

system

“Anonymous” Low High Internet

system

Cheating patients Low High Internet

system

Industrial espionage Low High Internet

system

Compliance

Regulation

Low Medium Private +

Patient data2/29/2012 72Confoo 2012 Montreal - Threat Modeling - Antonio Fontes

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 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?



• Some help: (Apply these to each threat source)

– What about someone using an automated tool?

– What about self-propagating malware?– What about self-propagating malware?



• Describe the scenario:

– Who will trigger the scenario? (threat source)

• What is the intensity and exposure?• 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



Description The patients identities database gets stolen

Description The passwords database gets broadcasted

Description Patients cheat by replacing other’s appointments with theirs


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 …

3. Doomsday scenariosDescription 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…Reputation: fatal if someone gets to know it…

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)


3. Doomsday scenariosAttack 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

Attack tree The attacker gets access to the cabinet account:

• Repeat with the other scenarios…

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


3. Doomsday scenariosAttack 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)

Attack trees

Patient database

is stolen

Code

injection

Vulnerable

parameter


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

password

Network

sniffing

Patient database

is stolen

Code

injection

Local

stealing

Vulnerable

parameter


Local

intrusion

Known local

password

Physical

intrusion

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

password

Network

sniffingTraffic

interception Malware Weak

password

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameterLocal

intrusion

Known local

password

Physical

intrusion

Stolen cabinet

password

Stolen

credentials

Bruteforced

or Guessed

Malwarepassword

Bruteforce

attack

Hacked

email

3. Doomsday scenarios Attack tree for

scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic

interception MalwareWeak

password

Bruteforce

attack

Hacked

email

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen

credentialsBruteforced

or Guessed

attackemail

4. Identify security controlsAttack tree for

scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

emailCountermeasures analysis

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail

Countermeasures analysis


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email

- ???

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email

- Use validation in all data

entry points

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email

-Use validation in all data

entry points

- ???

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email


entry points

- ???

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email


entry points

- Request authenticated

physical access to server

-

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail-


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email


entry points



- ???

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail- ???


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email


entry points



- Require complex passwords

Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed

attackemail- Require complex passwords


scenario #1

Known local

password

Physical

intrusion

Simple

passwordNetwork

sniffingTraffic


password

Bruteforce

attack

Hacked

email


entry points




Patient database

is stolen


Code

injection

Local

stealing

Vulnerable

parameter

Local

intrusion

Got cabinet

password

Stolen


or Guessed


- Use SSL/TLS


scenario #1

Traffic


password

Bruteforce

attack

Hacked

email


entry points



Patient database

is stolen


Got cabinet

password

Stolen


or Guessed

attackemailphysical access to server


- Use SSL/TLS


scenario #1

Traffic


password

Bruteforce

attack

Hacked

email


entry points



Patient database

is stolen


Got cabinet

password

Stolen


or Guessed

attackemailphysical access to server


- Use SSL/TLS

Patient database

is stolen

4. Identify security controls

Attack tree #1

Countermeasures

- Use validation in all data entry points

Patient database

is stolen

Countermeasures

Attack tree #2

Countermeasures

-Request authenticated physical access to server


- Use SSL/TLS

Attack tree #3

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


4. Identify security controlsAttack tree #3

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 #... - …Attack tree #...

Countermeasures

- …

Attack tree #...

Countermeasures

- …

Attack tree #...

Countermeasures

- …


Documenting the threat model

• Proposition:

1. Context

2. System description2. System description

3. Threat sources


5. Proposed controls

6. Action list


6. Transmit the threat model

• We cannot just “write and throw out” a security

document.

• Recipients often won’t understand it.• Recipients often won’t understand it.

• To increase adoption:

– Present the results to the audience, in person.

– Discuss the countermeasures: cost vs. impact



• 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.



• Typical clients:

– The architects: they should integrate the proposition to update

the design.

– The developers: they usually would benefit from the model – 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.


Going further…

• Attacker centric:

– All threat sources identified: their skills and attacks are

described.

• Asset centric: • 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.


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 DFD threat analysis:– Systematic STRIDE model

• Security posture:

– Compliance

– Defense what we did

– Detection

– Countermeasures


Going further… Injection points


Going further… Infection points


Going further… Disclosure points


Going further… Encryption points


Going further…Technology threat points


Going further

ImplementationInception Design Verification Release Operations

Prevention:


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

Going further…

• STRIDE threat identification toolhttp://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx

• DREAD severity assessment toolhttp://en.wikipedia.org/wiki/DREAD:_Risk_assessment_modelhttp://en.wikipedia.org/wiki/DREAD:_Risk_assessment_model

• OWASP threat risk modelinghttps://www.owasp.org/index.php/Threat_Risk_Modeling

• Microsoft SDL design phase activitieshttp://www.microsoft.com/security/sdl/discover/design.aspx


Agenda





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– 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.


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.– Be simple, stay small.


Next at Confoo:

• Today:

– DIY incident response

• Tomorrow:

– Les navigateurs au service

• Friday:

– Crypto 1o1 pour les

programmeurs

– Web application security – Les navigateurs au service

de vos applications

– Performing security audits

– Web security and you

– Sécurité et Ruby on Rails

– Web application security

trends

– Microsoft Security

Development lifecycle

– Trouvez la faille / Sopt the

flaw!


Meet the OWASP@confoo

Sébastien

@spoint

Philippe

@securesymfony

France Canada


Antonio

@starbuck3000

Switzerland

Jonathan

@jonathanmarcil

Thank you!

For any contact/question/slides

request/inquiry/complaint/love letter/thank you:

email: [email protected]

twitter: @starbuck3000twitter: @starbuck3000

En français:

Newsletter Cybermenaces et sécurité Internet:

http://cddb.ch


Threat modeling cheatsheets


Cheatsheets – Full TM process

1. Describe the context

2. Describe the system:

– Output: business objective +

DFDs + high-value assets

5. Identify (counter)measures

– Output: list of controls for each

attack tree

6. Create the action listDFDs + high-value assets

3. Identify threat sources

– Output: threat exposures

4. Choose/Identify doomsday

scenarios

– Output: attack trees

6. Create the action list

– Output: list of actions, sorted

by:

• Compliance requirements

• High priority items (low cost/high

impact)

• Other actions

7. Document & transmit!


Cheatsheets – Flow & BoundaryCheckpoints:

- Protect the traffic if it allows:

- Credentials

- Private/Patient/Financial data

- Other confidential information

- Data dumpsDataflow

- Call

- Network link

Process

boundary

File system

Network

…Trust

boundary

- Data dumps

- 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?


Dataflow - Network link

- RPC

Cheatsheets - EntityCheckpoints:

- Do you need strong authentication?

- Can this entity conduct transactions?

- Can this entity access high privileges?

- Is the entity connecting from insecure or

untrusted client equipment?

External entity- User

- other system

-Partner/supplier…

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?


Cheatsheets - ProcessCheckpoints:

- How do you authenticate this

process?

- Can someone imitate it?

- How do you validate it?

- Can the process reach more

- Service

- Executable

- DLL

- Component

- Web service

- Assembly

- …Process

- Is the process returning data

outside? - Can the process reach more

sensitive systems?

- Confidential data?

- A physical control system?

- Another organization?

- A backend/transactional system?

- If yes � is it hosted on a secure system?

- Can this process be interrupted?

- If no, how do you prevent this?


outside?

- Can system/error details be disclosed?

- How would you detect leaking data?

- How do you protect client-side attacks?

- Is the process accepting data from

outside the secure boundary?

- Validate everything that comes in.

- Verify that you validate everything.

- Ask a 3rd- party to verify this.

Cheatsheets - DatastoreCheckpoints:

- Who wants that data?

- Will they hack for it? Or will they pay

someone to retrieve it from inside?

- Is the storage protected from local

access?

Data store

- Database

server

- Config file

- Registry

- Memory

- Queue /

stack

- …

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?


Cheatsheets – human threat sourcesType Source Intensity Exposure comment

Opportunistic

Automated threat

sources (worms..)

High

Automated hands

(hackers w/ tools)

High




Targeted

Competition Low-High

“Anonymous” Low-High Evaluate collateral

dmg.

Insiders Low-High

Industrial / State

espionage

Low-

High?

Cheatsheets – Doomsday scenarios

– Data X was stolen

• Credentials/Private data were

disclosed

– Data X was modified

• Who can modify access control

rules? Super admin password?

– User U was able to

withdraw/redirect money

– A secret was intercepted by a guy

sniffing the network

– A highly sensitive user password rules? Super admin password?

– Process P was spoofed to capture

data X

– Code was injected in Process P to

access deeper system

– Process P was interrupted, crashed

or slowed down

– User u denies his/her actions

– User U was able to avoid payment

A highly sensitive user password

was stolen on his infected phone

– A connection link is saturated

– A process or datastore is saturated

by creating cumulative elements of

X


Things you want to remember


Threat Modeling web applications (2012 update)

Technology

Transcript of Threat Modeling web applications (2012 update)