Rapid Threat Modeling : case study

rapid Threat Modeling
identifying threats in a webapp before coding it: the
case study of the innocent (but still nice) Doctor

Antonio Fontes
Length: 45+15 minutes

Securitybyte Conference – Sept 6th – 9th 2011
Bangalore

2

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

3

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

4

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.


5

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


6

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)


7

Threat Modeling crash course
A threat model is:
– Reusable: it can serve at different
stages of development, like
design, implementation,
deployment and testing
– Editable: it’s an ongoing
threat assessment of your
application. It should be
updated along with the
application


8

Let's learn by doing…


9

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


10

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) butparents keep finding ways to
contact him outside regular hours.


11

Case study
• His patients have a stunning idea: a webapp
for managing his appointments!


12

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


13

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!


14

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!


15

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


16

Case study

The doctor suddenly realises
that the web agency did not
talk about security the other
day...


17

Case study
• He hires you, for one day.
• Your job is to observe the
project, gather information,
and eventually, issue some
recommendations...


18

Task 1:
Understand and describe the system

a.k.a. « ask questions! »


19

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?


20

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


21

• Is the business under particular data
processing regulation?
– Privacy?
– Healthcare?
– Food? Chemicals? Drugs?
– Transports? Energy?
– Legal? Financial?


22

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


23

"The system is not built to generate revenue."
"It is not processing orders."
"It allows my clients to schedule for an
appointment. "
"Oh, I forgot, and it also allows them to provide
some basic information on the case
(symptoms)."


24

“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!”


25

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)


26

Motivator Comment
My employees/clients life/safety is at risk (SCADA systems, 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!


27

"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.“
"I don't really know of particular regulatory
requirements…"


30

Motivator Comment
My employees/clients life/safety is at risk (SCADA systems, 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 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!


31


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


32

• Please describe the system as you imagine it:
– Technologies?
– Architecture?
– Functionalities? (use cases?)
– Components?
• What will be the major use cases?


33

"It's a standard webapp, including a frontend
application connected to a backend database."
“Clients will 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."


34

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


35

"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
access details of every appointment."
“Users authenticate with username/password."
“Credentials will be stored securely."
"The system will be hosted on our web farm."

36

"I will connect from work! Of course!"

…"and from home, if I can…"


37


Can we draw this?


38

Data-flow diagram


39

also known as… DFD


40

…may show actors…


41

…data processing units…


42

…data storage units…


43

…data transmission channels…


44

…and security trust zones!

Who can
access this?


45

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

46

"The accounts database contains PII about my
patients."
"The accounts database contains credentials."
"Money doesn't flow through the application.“
“The system does not connect to anything else.”
“The system can turn offline. Patients will call
me on my phone, as before!"


47

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

“It is totally secure!”


48

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


49

"In two years?
I'd say around 300 family accounts.

3’600 appointments (6/family/year)

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


50

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

51

Task 2:
Identify potential
threat agents


52

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

53

- 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


54

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


55

“You have a scary way of asking
questions…”


56



57

Threat source Motivation Approach (strategy/tactics)

Dumb users Opportunistic Mistakes

Smart users Opportunistic Circumventing complex GUI

Script kiddies / hackers Opportunistic Use of automated exploit/scanning tools,
(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 ops

58

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


59

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!


60

Threat source
Threats, which were removed:(strategy/tactics)
Motivation Approach

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.
-> no high-profile patients!
APT magic Mixed Joker*


61

Threat source Motivation Comment
Threats, which were prioritized:
Smart users Opportunisti They will try to bypass other patients
c requests
Script kiddies / hackers Opportunisti They will play with their tools
(low-profile) c Several hours investment
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


62

Script Kiddies and low-profile hackers
Threat agent profile
Prevalence HIGH
Damage potential MEDIUM (repeated disturbances, reputation, data
corruption)
Tactics Automated security scanners, exploits testing, exploitation
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)


63

Hacker (high profile)
Threat agent profile
Prevalence LOW
Damage potential MEDIUM to HIGH
(personal reward, contract engagements)
Tactics Combination of automated + manual scanning
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


64

Task 3:
Identify major threat
scenarios


65

3. Identify major threat scenarios
• Which threat scenarios 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)?


66

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!


67

3. Identify major threats
# Threat scenario Agent Attack description
T1
T2
T3
T4
n


68

# Threat Source Attack details
T1 Page defacement, hacking for Script - Automated tools
fame kiddies - expl. of injection flaws
T2 Users circumventing the Smart user - Eyesight tampering
appointment lock feature
(already booked)
T3 Corruption of the central Competitor - expl. of injection flaws
agenda - unauthorized
appointment
cancellation
T4 Extraction of the users info DB Competitor, - expl. of injection flaws
other bus. - unsecure direct
references
- expl. of authentication
http://L7securite.ch flaws

69

# Threat Source Attack details
T5 Extraction of the appointment Competitor, - expl. of injection flaws
(med) details other bus. - unsecure direct
references
- expl. of authentication
flaws
T6 User credentials interception Script - traffic interception
kiddies attacks
- XSS
T7 Doctor's credentials Competitor, - same as T6
interception other bus. - trojan bonus… ☺


70

# Threat Impact
T2 Users circumventing the appointment lock feature Medium (Bus.)
(already booked)
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.)
-> T5


71

How would we prevent/detect each scenario?


72

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


73

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


74

Task 4:
Document your observations
(aka "opportunities for
risk mitigation")


75

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?


76

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

77

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

78

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


80

Conclusion…and opportunities….


81

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


82

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


83

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.


84

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.

85

Conclusion
• TM can be performed early:
Analyze Design Implement Verify Deploy Respond

Security Secure Security Incident
requirements Secure coding testing Secure response
design deployment
Risk Design Vulnerability
Code review management
analysis Threat review Risk
modeling assessment Penetration
testing

Training & awareness

Policy / Compliance

Governance (Strategy , Metrics)


86

Conclusion
TM can also be performed later (risk-based testing):
Analyze Design Implement Verify Deploy Respond

Security Secure Security Secure Incident
requirements Secure coding testing deployment response
design
Risk Design Threat Code Vulnerability
Risk management
analysis Threat review modeling review assessment
modeling Threat Penetration
modeling testing

Training & awareness

Policy / Compliance

Governance (Strategy , Metrics)


87

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)

88

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)


89

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.


90

Conclusion


91

Conclusion


92

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)


93

Conclusion
"Do pediatricians feel more confident about
their web app?"

YES!


94

Questions?


95

Merci! / Thank you!

Contact me: antonio.fontes@L7securite.ch
Follow me: @starbuck3000
Discover L7: http://L7securite.ch
Download these slides:
http://slideshare.net/starbuck3000


96

Recommended readings:
• Guerilla threat modeling (Peter Torr)
http://blogs.msdn.com/b/ptorr/archive/2005/02/22/guerillathreatmodelling.aspx
• Threat risk modeling (OWASP)
http://www.owasp.org/index.php/Threat_Risk_Modeling
• Application threat modeling (OWASP)
http://www.owasp.org/index.php/Application_Threat_Modeling
• Threat modeling web applications (Microsoft)
http://msdn.microsoft.com/en-us/library/ff648006.aspx
• Comments on threat modeling (in French, DLFP)
http://linuxfr.org/news/threat-modeling-savez-vous-quelles-sont-les-
menaces-qui-guette
• NIST SP-800-30: risk management guide
http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf


Rapid Threat Modeling : case study

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Rapid Threat Modeling : case study

Similar to Rapid Threat Modeling : case study (20)

More from Antonio Fontes

More from Antonio Fontes (13)

Recently uploaded

Recently uploaded (20)

Rapid Threat Modeling : case study