it security days - threat modeling

Antonio FontesLength: 45+15 minutes

IT Security Days – March 16th 2011 Yverdon-Les-Bains

Threat Modelingidentifying threats in your webapp before coding: a case study

L7 Sécurité - http://L7securite.ch2

Speaker info

• Antonio Fontes• Owner L7 Sécurité (Geneva, Switzerland)• 6+ years experience in information security• Lecturer at HEIG-VD• Fields of expertise:

– Web applications defense– Security in the development lifecycle– Threat modeling & risk management

• OWASP:– Chapter leader – Geneva– Board member - Switzerland

My objectives for today:

1. You understand the concept of threat modeling

2. You can build a basic but still actionable 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.

Let's learn by doing…

Case study

• A local pediatrician is constantly receiving phone calls (and messages on Facebook) from desperate parents, outside cabinet hours.

Case study

• He hired an assistant but he refuses to answer late evening phone calls (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

• He has a stunning idea: building a webapp for managing his appointments!

Case study

• Basically, he just wants his clients to be able at any time (night and day):– to schedule for an appointment at the closest

free slot available– to describe a few 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 actually just started designing the system on last Monday…

Case study

• It happens (by total chance) that the pediatrician attend the IT Security Days #1 conference

• He heard about pesky guys, who hack into web applications seeking chaos by destroying databases, stealing personal data and selling it on a black market to large corporations that want to control the world!

Case study

• He also meets a guy, who tells him about an obscure technique called threat modeling.

• He says it might help project teams detecting major threats and appropriate countermeasures to their web applications at design time.

Case study

He suddenly realises that the web agency did not talk a lot

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

1. Understand the system

1. Describe (understand) the system

• What is the business requirement behind it?– What role is the system playing in the organization?

• Will it bring money? • Will it be the main revenue source?• Is the system processing online transactions?• Is it storing/collecting sensitive/private information?• Should it be kept always online or is it okay if it stops

sometimes?

– Is the business exposed to particular data regulations? (Privacy? Healthcare? Food? Drugs? Legal? Financial?)

"The system is not built to generate revenue."

"It is not processing orders."

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

"Oh yes, and also provide some basic information on the case (symptoms)."

• What is the motive of your presence?

Motivator CommentMy 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 well and avoid blackhats

I never want 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

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

Motivator CommentMy employees/clients life/safety is at risk (SCADA systems, energy, transports, food & drugs, etc.)

not really…

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

I just want to sleep well and avoid blackhats Yes, preferably.

I never want to be compromised again! not really…

I want to protect my employees/customers privacy YES!

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

I want to keep the money inside my company not really…

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

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

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

• Let's add the developer and the architect to the discussion…

• What will the system look like?– Technologies? – Architecture?– Functionalities? (use cases?)– Components?

• What will be the typical use cases?

"It's a standard web project, including a frontend application connected to a backend database."

"Users must create a profile with basic personal 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?• How will users be authenticated?• Where will the system be hosted?• 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 supervising access, who has entire view on the agenda and can access details of every appointment."

"Authentication is made by username/password."

"The credentials will be stored securely."

"The system will be hosted on our web farm."

"I will connect from work! Of course!"

…"okay, and sometimes from home. If I can…"

• Can we draw this?

• What would be the assets of highest value?– Is there sensitive/private/proprietary/regulated

information anywhere?– Where are credentials stored?– Are there any financial flows?– Is one of these components critical for your

business?– Has the system access (is it connected) to other

more sensitive systems?

"The accounts database contains personal information about my customers and patients."

"The accounts database contains credentials."

"Money doesn't flow through the application."

"If they can't reach it, they will call me…"

"They also host other customers databases on the same network."

• How many occurrences of these assets are you expecting in say…two years?(We are gathering volumetric data here)

"In two years?

I'd say 200-400 families entered in the system.

2'400 appointments.

And 400 urgent appointments…"

2. Identify potential threat sources

• Given what we know, who might be interested in compromising your system?– Who wants to steal the data?– Who wants to sell it?– Who wants to corrupt it?– Who wants to stop it?

Source Realistic? CommentDumb users

Smart users

Script kiddies

Rogue blackhats

Competitors

Other businesses

Organized cybercriminals

Governments / The NSA!!!

Source Realistic? CommentDumb users No Not really.

Smart users Yes Yes, some might try to get an appointment even when it's fully booked.

Script kiddies Yes Statistically, yes.

Rogue blackhats No Not really expecting interest from them.

Competitors Yes Definitely: access to the clients database.

Other businesses Yes Yes. Insurance companies, online drug selling, spammers, etc.

Organized cybercriminals Yes Yes. They might want to resell the data.

Governments / The NSA!!! Maybe… There was a movie I saw..

Source Tactical /Skill levelSmart users

Script kiddies

Competitors

Other businesses

Organized cybercriminals

Source Tactical /Skill levelSmart users Simple eye-catchy attacks (parameter tampering)

Script kiddies Automated intrusion tools, common exploits, injection flaws

Competitors Might hire someone… rogue hacker categoryTop 10 attacks at least

Other businesses Yes. Insurance companies, online drug selling, spammers, etc. might hire someone rogue hacker

Organized cybercriminals Yes. They might want to resell the data. If they identify particular value in the DB (typically: its size!)

• Information can also come directly from the customer:– In information critical organizations, some

managers have access to undisclosed threat information:• National level, international level, industry level, etc.

– Don’t forget to ask:• "Yeah, there is another pediatrician who recently

moved here…"

3. Identify major threats

3. Identify major threat scenarios

• What would be (really) bad for the business?– Which threat source would trigger that 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)?

• 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

3. Identify major threats# Threat Source Attack detailsT1

3. Identify major threats# Threat Source Attack detailsT1 Page defacement, fame hacking Script kiddies - Automated tools

- expl. of injection flawsT2 Users circumventing the appointment lock

feature (already booked)Smart user - Eyesight tampering

T3 Corruption of the central agenda Competitor - expl. of injection flaws - unauthorized appointment cancellation

T4 Extraction of the users info DB Competitor, other bus.

- expl. of injection flaws - unsecure direct references- expl. of authentication flaws

T5 Extraction of the appointment (med) details Competitor,other bus.

- expl. of injection flaws - unsecure direct references- expl. of authentication flaws

T6 User credentials interception Script kiddies - traffic interception attacks- XSS

T7 Doctor's credentials interception Competitor, other bus.

- same as T6- trojan bonus…

3. Identify major threats# Threat ImpactT1 Page defacement, fame hacking High (Tech)

T2 Users circumventing the appointment lock feature (already booked)

Medium (Bus.)

T3 Corruption of the central agenda Medium (Bus.)

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

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

T6 Users credentials stealing Medium (bus)

T7 Doctors' credentials stealing Critical (bus.)-> T5

How would we prevent these attacks?

3. Identify major threats

Th# Attack Control(s)T1 Defacement Layered hardening

T1 Defacement Parameter tampering defences

T4 Privacy data extraction Parameter tampering defences

T4 Privacy data extraction Unpredictable/unexposed profile/accounts referencesT5 Medical data extract. Parameter tampering defences

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

… … …

4. Document what you found(aka "opportunities for risk mitigation")

4. Document the opportunity

• Document:– The threats we identified– The controls, which prevent these threats from

being exercised by the threat-sources• Recommend and prioritize:– What should be absolutely done?– In what order?

L7 Sécurité - http://L7securite.ch

C# Control(s) PriorityC1 Layered hardening High

C2 Parameter tampering defence (input validation) High

C3 Parameter tampering defence (parameterized queries) HighC4 Unpredictable/unexposed profile/accounts references HighC5 Unpredictable/unexposed appointment references High

C6 Defensive "appointment details" access control High

C7 Encrypted data transmission channel at least during auth. Sequence High

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

C9 Output encoding on all dynamic data returned to the user High

… … ...

C# Control(s) StatusC1 Layered hardening Planned

C2 Parameter tampering defence (input validation) Planned

C3 Parameter tampering defence (parameterized queries) PlannedC4 Unpredictable/unexposed profile/accounts references TestedC5 Unpredictable/unexposed appointment references Tested

C6 Defensive "appointment details" access control Tested

C7 Encrypted data transmission channel at least during auth. Sequence Planned

C8 Dynamic authentication model (OTP) for the supervisor account Rejected

C9 Output encoding on all dynamic data returned to the user Planned

… … …

Conclusion…and perspective…

Conclusion• TM seems 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 few timesquickly brings good results:1. Characterize the system2. Identify the threat sources3. Identify the major threats4. Document the countermeasures5. 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 isimportant for the business underassessment will definitely setthe "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

• TMing can be performed early:

Analyze Design Implement Verify Deploy Respond

Security requirements Secure

design

Secure coding

Code review

Security testing Secure

deployment

Incident response

Vulnerability management

Risk analysis Risk

assessment Penetration testing

Governance (Strategy , Metrics)

Policy / Compliance

Training & awareness

Threat modeling

Design review

Conclusion

• TMing can also be performed later:

Analyze Design Implement Verify Deploy Respond

Security requirements Secure

design

Secure coding

Code review

Security testing

Secure deployment

Incident response

Vulnerability management

Risk analysis

Risk assessment

Penetration testing

Governance (Strategy , Metrics)

Policy / Compliance

Training & awareness

Threat modeling

Design review

Threat modeling

Conclusion

• TMing can be performed from an asset perspective:– Aka the asset-centric approach (what we just did

today)• It can be performed from an attacker

perspective:– Aka the attacker-centric approach• Who would attack the system with what means?

Conclusion

• TMing can also be performed according to the system description:– 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 slide)L7 Sécurité - http://L7securite.ch66

Conclusion

• "What should I document 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.

Conclusion

• "Your example was really 'basic'. How can I reach next level?"1. Practice your DFD drawing skills2. Stay updated on new web attacks, threats and

intrusion trends3. 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?

Merci! / Thank you!

Contact me: antonio.fontes@L7securite.ch

Follow me: @starbuck3000

Download us: http://slideshare.net (user: starbuck3000)

it security days - threat modeling

systeml7 scurit http

discussionl7 scurit

doingl7 scurit http

mondayl7 scurit http

case studyl7 scurit

case studyhe

case symptoms

case studyit

Technology

reverse threat modeling

threat modeling: best practices

threat modeling for automotive security...

threat modeling (part 4)

threat modeling (part 5)

introduction to threat modeling

dns threat modeling - owasp · threat modeling using stride...

threat modeling for secure - application security testing...

threat modeling (part 1)

cloud threat modeling

threat modeling - overview

hickman threat modeling

cryptocurrency-based systems threat modeling for · threat...

threat modeling - isaca

adventures in threat modeling

threat modeling - crosscountry consulting

threat modeling and analysis

asset-oriented threat modeling

threat modeling guide - dw.com

threat modeling - secappdev peeters/threat... · threat...