Rapid Threat Modeling : case study

transcript

rapid Threat Modelingidentifying threats in a webapp before coding it: the

case study of the innocent (but still nice) Doctor

Antonio FontesLength: 45+15 minutes

Securitybyte Conference – Sept 6th – 9th 2011

Bangalore

About me

• Antonio Fontes

• Owner L7 Sécurité (Geneva, Switzerland)

• 6+ years experience in information security

• Fields of expertise:

– Online applications defense

– Security integration in the software development lifecycle

– Threat modeling, risk analysis and estimation

• Lecturer at the University of applied sciences, Western Switzerland

• OWASP:

– Chapter leader: Geneva

– Board member: Switzerland

http://L7securite.ch

My objectives for today:

1. You understand the concept of threat modeling and its fast track approach

2. You can build a basic but still actionablethreat model for your web application

threat model for your web application

3. You know when you should build a threat model and what you should document in it

4. This new technique helps you feel more confident about the security of your web application.

Disclaimer

• Don’t expect “100%” coverage

– Our main goal here is to prioritize the security

effort, not to replace testing activities!

• If full analysis is strictly necessary:

– Use system-centric TM instead (much more

systematic)

– Extend with other SDLC security activities: review,

testing, best practices, secure APIs, etc.

Panic mode?

• Don’t write what you see on the slides!

– They will be freely available on request

– and uploaded to:

http://slideshare.net/starbuck3000

Threat Modeling crash course

A repeatable process, to help

identify and document:

– A system’s characteristics and

security requirements

– Data-flows

– Threats

– Potential responses to

these threats (controls)

Threat Modeling crash course

A threat model is:

– Reusable: it can serve at differentstages of development, like design, implementation, deployment and testing

deployment and testing

– Editable: it’s an ongoing threat assessment of yourapplication. It should be updated along with the application

Let's learn by doing…

Case study

• A local pediatrician is

constantly receiving phone

calls (and messages on

Facebook!) from desperate

parents, outside cabinet

opening hours.

Case study

• He hired an assistant but

he refuses to answer late evening phone calls(and apparently, law is on his side…)

(and apparently, law is on his side…)

• He tried hiding his personal phone number (and configuring his Facebook profile to hide his phone

number) but parents keep finding ways to

contact him outside regular hours.

Case study

• His patients have a stunning idea: a webapp

for managing his appointments!

Case study

• Basically, he wants his patients to be able, at

any time (night and day):

– to schedule for an appointment at the closest

free slot available

– to describe the symptoms, to help him, if

necessary, reschedule the appointment or even

contact the family back (in case it looks worse than it

appears).

Case study

• He contacts a local web agency

and describes his need.

• The web agency accepts to build the solution.

(easy job, easy money!)

• They start immediately. Actually, they just

started designing the system yesterday!

Case study

• The pediatrician reads news about an infosec

conference ☺

• He hears about guys, who wear black hats,

hack into web applications, seek chaos by

destroying databases, stealing and selling

personal data on the black market to large

corporations that want to control the world!

Case study

• He meets a guy, who tells him about an

obscure technique called threat modeling.

• He says it might help the outsourcing web

agency to avoid doing some major mistakes,

and implement appropriate countermeasures

in the web application while still at design

Case study16

The doctor suddenly realises

that the web agency did not

talk about security the other

day...

Case study

• He hires you, for one day.

• Your job is to observe the

project, gather information,

and eventually, issue some

recommendations...

Task 1:

Understand and describe the system

a.k.a. « ask questions! »

1. Describe (understand) the system

• What is the motive/driver of the client?

– Compliance?

– Intrusion follow-up?

– Awareness / self-determination / corporate

culture ?

– Is someone-thing in particular threatening the

organization?

– Other reasons?

• What is the business requirement?

• What role is the system playing in the organization?

• Will it be the only/major revenue source?

• Will it bring money?

• Is it processing online transactions?

• Is it feeding other transactional systems?

• Is it storing/collecting sensitive/private information?

• Should it be always online or is it okay if it stops sometimes?

• Is the business under particular data

processing regulation?

– Privacy?

– Healthcare?

– Food? Chemicals? Drugs?

– Transports? Energy?

– Legal? Financial?

• Is the system protecting or supporting the life

of someone? Or can it endanger someone?

– Water cleaning?

– Transportation?

– Energy?

– Health equipment?

– Interactions with the physical environment?

– Weaponized? Military?

"The system is notbuilt to generate revenue."

"It is notprocessing orders."

"It allows my clients to schedule for an appointment. "

appointment. "

"Oh, I forgot, and it also allows them to provide some basic information on the case (symptoms)."

“Well, I guess…certainly compliance with some health information Act?“

“It can be offline.”

“It is not consumed by third-party systems.”

“It is not interacting with people or things.”

“I will be the only one accessing it.”

…”and my assistant, of course!”

1. Describe (understand) the system25

Motivator Comment

My employees/clients life/safety is at risk (SCADA systems,

energy, transports, food & drugs, etc.)

I want to stay compliant with laws and regulations

I just want to sleep peacefully and avoid hackers

I never want my systems to be compromised again!

I want to protect my employees/customers privacy

I want to make sure my customers pay for our goods/services

I want to keep the money inside my company

I cannot afford my website going offline

It is connected to our ERP

Threat Modeling really seems awesome! (seen the ad on TV)

Motivator Comment

not really…

I want to stay compliant with laws and regulations Are there any?

I just want to sleep peacefully and avoid hackers Yes!

I never want my systems to be compromised again! not really…

I want to protect my employees/customers privacy Of course!

I want to make sure my customers pay for our goods/services Not applicable

I want to keep the money inside my company Not applicable

I cannot afford my website going offline Yes. They will call me.

It is connected to our ERP Our what??

Threat Modeling really seems awesome! (seen the ad on TV) Definitely!

"I never had a website for my cabinet." (well, I think…)

"I just don't want a bad thing to happen when this service comes online.“

this service comes online.“

"I don't really know of particular regulatory requirements…"

Motivator Comment

not really…

I want to stay compliant with laws and regulations Are there any? �� YES

I just want to sleep peacefully and avoid hackers Yes!

I want to protect my employees/customers privacy Of course!

I want to make sure my customers pay for our goods/services Not applicable

I want to keep the money inside my company Not applicable

I cannot afford my website going offline Yes. They will call me.

It is connected to our ERP Our what??

Threat Modeling really seems awesome! (seen the ad on TV) Definitely!

Let's add the developer and the architect to the

discussion…

• Please describe the system as you imagine it:

– Technologies?

– Architecture?

– Functionalities? (use cases?)

– Components?

• What will be the major use cases?

"It's a standard webapp, including a frontend application connected to a backenddatabase."

“Clients will create a profile with basic personal information (patient name/lastname, parent

information (patient name/lastname, parent name/lastname, address, email address, phone numbers, username, password."

"Once they have logged in, they can schedule for an appointment."

• What will be its typical usage scenarios?

– Visitors? Members? Other doctors? Access from

outside?

• Who (where) will host the system?

• How will users be authenticated?

• Where will users connect from?

– and where will the doctor connect from?

"Users can connect and see their appointments, edit their info or cancel them."

"The cabinet will be using a supervisor access, who has entire view on the agenda and can

who has entire view on the agenda and can access details of every appointment."

“Users authenticate with username/password."“Credentials will be stored securely.""The system will be hosted on our web farm."

"I will connect from work! Of course!"

…"and from home, if I can…"

Can we draw this?

Data-flow diagram38

also known as… DFD39

…may show actors…40

…data processing units…41

…data storage units…42

…data transmission channels…43

…and security trust zones!44

Who can

access this?

• What/Where are the assets of highest value?

– Is there private/proprietary/regulated information

anywhere?

– Are user credentials stored? Where? How?

– Are there any financial/transactional flows?

– Is one of these components critical for your

business?

– Is the system connected to other more sensitive

systems? (company ERP? Bank? Machines?)

"The accounts database contains PII about my patients."

"The accounts database contains credentials.""Money doesn't flow through the application.“

"Money doesn't flow through the application.“

“The system does not connectto anything else.”

“The system can turn offline. Patients will call me on my phone, as before!"

“We host several customers on our shared hosting environment.”

“It is totally secure!”

• How many occurrences of these assets are

you expecting in say…two years from today?

(We are gathering volumetric data here)

"In two years?

I'd say around 300 family accounts.

3’600 appointments (6/family/year)

And 2400 urgent appointments…(4/family/year)"

End of task 1

• It’s a non-transactional web application

• It is not connected to other systems

• It hosts patient health information + PII

– Data should be protected from unauthorized

access (in-transit + offline)

• It is accessible from the Internet

• It contains usernames + passwords

– Credentials storage should observe best practices

Task 2:

Identify potential

threat agents

2. Identify potential threat agents

- Given what we know, who might be interested

in compromising your system?

- No one!

- Any competitor recently installed?

- Mmmmh…yes…One, actually. She just

arrived. She’s a pediatrician, too.

- Could she steal your patients?

- Any businesses would be interested in

acquiring health details on 300 geographically-

linked families, including their problems,

illnesses, special situations?

- Any businesses interested in acquiring

personal details of 300 families including

usernames, passwords, contact details?

- Mmmmh…probably

• Would anyone want to steal your data?

• Would anyone be able to sell it?

• Would anyone be interested in corrupting it?

• Would anyone benefit from an interruption of

your application?

“You have a scary way of asking

“You have a scary way of asking questions…”

2. Identify potential threat agents56

Threat source Motivation Approach (strategy/tactics)

Dumb users Opportunistic Mistakes

Smart users Opportunistic Circumventing complex GUI

Script kiddies / hackers

(low-profile)

Opportunistic Use of automated exploit/scanning tools,

known vulnerabilities research

(low-profile) known vulnerabilities research

Hackers (higher profile) Targeted Vulnerability research

Competitors Targeted Hiring hackers

Other businesses Targeted Hiring hackers

Organized cybercriminals Targeted 0-day research and trade

Government / Military Targeted Long-term ops

APT magic Mixed Continuous + long-term + multilayer opshttp://L7securite.ch

2. Identify potential threat sources

Which of these sources might hit or target my

business?

– With a high probability?

• Population size

• Exposure

– With a high impact?

• Personal/health information disclosure (compliance)

– With the incentive of a high reward?

• Users/passwords stealing / health information trading

Don’t forget to ask the customer if she/he has

access to confidential threat information:

– CIOs/CSOs in information critical organizations

may have access to undisclosed threat

information:

• National/international/industry threat analysis reports

– Don’t forget to ask!

Threat source Motivation Approach (strategy/tactics)

Dumb users Opportunistic They can do mistakes, but not that critical

Organized cybercriminals Targeted They are not known for targeting small-

sized medical databases

Government / Military Targeted They should not be interested in the data.

Threats, which were removed:

Government / Military Targeted They should not be interested in the data.

-> no high-profile patients!

APT magic Mixed Joker*

Threat source Motivation Comment

Smart users Opportunisti

They will try to bypass other patients

requests

Script kiddies / hackers

(low-profile)

Opportunisti

They will play with their tools

Several hours investment

Hackers (higher profile) Targeted They will try to hack into the application

Threats, which were prioritized:

Hackers (higher profile) Targeted They will try to hack into the application

during a day

Competitors Targeted Hiring a hacker to try stealing/corrupting

data during a few days

Other businesses Targeted Hiring a hacker to try stealing/corrupting

data during a few days

Script Kiddies and low-profile hackers

Prevalence HIGH

Damage potential MEDIUM (repeated disturbances, reputation, data

corruption)

Tactics Automated security scanners, exploits testing, exploitation

of injection flaws, short-term bruteforcing/dictionary

Threat agent profile

of injection flaws, short-term bruteforcing/dictionary

attacks (high HTTP req. freq.)

OWASP Top10 direct attacks (A1, A3, A4, A6, A8, A10)

Business layer attacks No

Countermeasures Request throttling

Strong defense against OWASP T10 direct attacks

Secure configurations (systems, services)

Hacker (high profile)

Prevalence LOW

Damage potential MEDIUM to HIGH

(personal reward, contract engagements)

Tactics Combination of automated + manual scanning

Lower HTTP request frequency

Threat agent profile

Lower HTTP request frequency

Short timespan vulnerability research

Full range OWASP T10 investigation, including A2 and A5

Business layer attacks No

Countermeasures Complete OWASP T10 risk coverage

Task 3:

Identify major threat

scenarios

3. Identify major threat scenarios

• Which threat scenarios would be (really) bad for the business?

– Which threat source would trigger that scenario?

scenario?

– How would she/he/they proceed technically?

– What would be the impact for my business?

• Shameful (bad news)? Bad (financial loss)? Catastrophic (end of the my world)?

3. Identify major threat scenarios

• Some helpers:

– Think about threats induced naturally, by the

technology itself.

– Think about what the CEO really doesn't want.

• Think AIC:

– Availability, integrity, confidentiality

– Apply on every component

of the DFD!

3. Identify major threats

# Threat scenario Agent Attack description

# Threat Source Attack details

T1 Page defacement, hacking for

Script

kiddies

- Automated tools

- expl. of injection flaws

T2 Users circumventing the

appointment lock feature

(already booked)

Smart user - Eyesight tampering

(already booked)

T3 Corruption of the central

agenda

Competitor - expl. of injection flaws

- unauthorized

appointment

cancellation

T4 Extraction of the users info DB Competitor,

other bus.

- unsecure direct

references

- expl. of authentication

flawshttp://L7securite.ch

# Threat Source Attack details

T5 Extraction of the appointment

(med) details

Competitor,

other bus.

- unsecure direct

references

- expl. of authentication

T6 User credentials interception Script

kiddies

- traffic interception

attacks

T7 Doctor's credentials

interception

Competitor,

other bus.

- same as T6

- trojan � bonus… ☺

# Threat Impact

T2 Users circumventing the appointment lock feature

(already booked)

Medium (Bus.)

T3 Corruption of the central agenda Medium (Bus.)

T6 Users credentials stealing Medium (bus)

T1 Page defacement, fame hacking High (Tech)

T4 Extraction of the users info DB High (bus.)

T5 Extraction of the appointment (med) details Critical (bus.)

T7 Doctors' credentials stealing Critical (bus.)

How would we prevent/detect each scenario?

3. Identify major threats72

Th# Attack Scenario prevention controls

T1 Defacement Layered hardening

T1 Defacement Parameter tampering defenses

T4 Privacy data extraction Parameter tampering defenses

T4 Privacy data extraction Unpredictable/unexposed profile/accounts references

T5 Medical data extract. Parameter tampering defenses

T5 Medical data extract. Unpredictable/unexposed appointment references

T5 Medical data extract. Defensive "appointment details" access control

T7 Doctor's account stealing Encrypted data transmission channel

T7 Doctors' account stealing Dynamic authentication (OTP)

T7 Doctors' account stealing Output encoding

… … …

3. Identify major threats73

Th# Attack Scenario detection controls

T1 Defacement Homepage integrity checking

T4 Privacy data extraction Injection of honeypot data + usage monitoring

T5 Medical data extract. Injection of honeypot data + usage monitoring

T7 Doctor's account stealing Out-of-band notification of authentication events

… … …

Task 4:

Document your observations

(aka "opportunities for

risk mitigation")

4. Document

• Document:

– The threat agents model you selected for your TM

– The threat scenarios you identified

– The controls to prevent or detect these threat

scenarios

• Recommend and prioritize:

– What should be absolutely done?

– In what order?

4. Document76

C# Control(s) Priority Cost type

P1 Layered hardening High Medium

P2 Parameter tampering defense (input validation) High Medium

P3 Parameter tampering defense (parameterized queries) High Low

P4 Unpredictable/unexposed profile/accounts references High Medium

P5 Unpredictable/unexposed appointment references High Medium

P6 Defensive "appointment details" access control High Medium

P7 Encrypted data transmission channel at least during auth. Sequence High Medium

P8 Dynamic authentication model (OTP) for the supervisor account High High

P9 Output encoding on all dynamic data returned to the user High Medium

D1 Homepage integrity checking Low Low

D2 Injection of honeypot data + usage monitoring Low High

D3 Injection of honeypot data + usage monitoring Low High

D4 Out-of-band notification of authentication events Low Low

4. Document77

C# Control(s) Priority Action

P1 Layered hardening High Implement

P2 Parameter tampering defense (input validation) High Implement

P3 Parameter tampering defense (parameterized queries) High Implement

P4 Unpredictable/unexposed profile/accounts references High Implement

P5 Unpredictable/unexposed appointment references High Next ver.

P6 Defensive "appointment details" access control High Implement

P7 Encrypted data transmission channel at least during auth. Sequence High Implement

P8 Dynamic authentication model (OTP) for the supervisor account High Next ver.

P9 Output encoding on all dynamic data returned to the user High Implement

D1 Homepage integrity checking Low Implement

D2 Injection of honeypot data + usage monitoring Low Postpone

D3 Injection of honeypot data + usage monitoring Low Postpone

D4 Out-of-band notification of authentication events Low Implement

4. Document

Expected threat coverage for next version:

# Threat Impact Coverage

T1 Page defacement, hacking for fame High Complete (P+D)

T4 Extraction of the users details DB High Complete (P)

T5 Extraction of the appointment (med) details Critical Partial

T7 Doctor's credentials interception Critical Partial

Conclusion…and opportunities….

Conclusion

rTM is imprecise, inexact, undefined:

– Requires good understanding

of the business case

– Requires good knowledge of

web application threats

– Requires common sense

– Can be frustrating the

first times

Conclusion

Repeating the basic process a a few times

quickly brings good results:

1. Characterize the system

2. Identify the threat sources

3. Identify the major threats

4. Document the countermeasures

5. Transmit (translate) to the team

Conclusion

"Who should make the TM?"

– Theoretically: the design team

– Practically: an appsec guy with good knowledge of

internet threats, web attack techniques

and the ability to understand what is

important for the business under

assessment will definitely set

the "efficiency" attribute.

Conclusion

• "When should I make a TM?"

– Sometime is good. Early is better.

– If the objective is to avoid implementing poor

code � do it at design time.

– After v1 is online: when new data "assets" appear

in the data-flow diagram, it's usually a good sign

to update the TM. � yes, it can be updated!

– If you conduct risk-driven vulnerability

assessments or code reviews, the TM will help.

Conclusion

• TM can be performed early:

Analyze Design Implement Verify Deploy Respond

Security Secure Security Incident

response

Security

requirements Secure

design

Secure

coding

Code review

Security

testing Secure

deployment

response

Vulnerability

managementRisk

analysis Risk

assessment Penetration

testing

Governance (Strategy , Metrics)

Policy / Compliance

Training & awareness

Threat

modeling

Design

review

Conclusion

TM can also be performed later (risk-based testing):

Analyze Design Implement Verify Deploy Respond

Security Secure Security Secure Incident

response

Security

requirements Secure

design

Secure

coding

review

Security

testing

Secure

deployment response

Vulnerability

managementRisk

analysisRisk

assessment

Penetration

testing

Governance (Strategy , Metrics)

Policy / Compliance

Training & awareness

Threat

modeling

Design

review

Threat

modeling

Threat

modeling

Conclusion

• TM can be performed from an asset

perspective:

– Aka the asset-centric approach (mostly what we

just did)

• It can be performed from an attacker

perspective:

– Aka the attacker-centric approach

• Who would attack the system with what means?

• (remember the “threat agent profile” cards)

Conclusion

• TMing can also be performed systematically:

– Aka the system-centric approach

– Most detailed and rigorous technique

• Use of threat identification tools: STRIDE

– Spoofing, Tampering, Repudiation, Information disclosure,

Denial of service, Elevation of privileges…

• Use of threat classification tools: DREAD

– Damageability, Reproducibility, Exploitability, Affected

population, Discoverability…

• Structured DFD analysis (see next slides)

Conclusion

• "What should be documented in a TM? "

– Basically: what you think is right. There is no rule

(yet). TM'ing is never absolute.

– If you spend days writing a threat model for a

single web app, there might be a problem…

– Remember that threat modeling is often a way of

both formalizing and engaging on the most

important controls, which might be forgotten

later.

Conclusion90

Conclusion91

Conclusion

• "Your example was really 'basic'.

How can I reach next level?"

1. Practice your DFD drawing skills

2. Stay updated on new web attacks, threats and

intrusion trends

3. Read feedback from field practitioners (some good

references are provided at end of presentation)

4. Standardize your technique:

• ISO 27005 : Information security risk management (§8.2)

• NIST SP-800-30: Risk management guide (§3)

Conclusion

"Do pediatricians feel more confident about

their web app?"

Questions?94

Merci! / Thank you!

Contact me: antonio.fontes@L7securite.ch

Follow me: @starbuck3000

Discover L7: http://L7securite.ch

Download these slides:

http://slideshare.net/starbuck3000

Rapid Threat Modeling : case study

Technology