Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Integrating security & privacy
in a web application project
OWASP Ottawa Chapter Training Day
Feb 27th 2012
Module 1: befo...
OWASP: what?
• Open
• Web
• Application
• Security
• Project
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2
OWASP: what?
• Open
• Web
• Application
• Security
• Project
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2
OWASP: why?
• Causes:
– Victims: organizations and individuals
– Vulnerabilities
– Developers and operators
– Organization...
OWASP: who?
• Elected board
• Leaders:
– Project leaders
– Chapter leaders
• 1’500 Members
– Individual supporters
– Acade...
OWASP: how?
• Committees: education, industries, connections,…
• Projects
– 140 documentation and tool projects
• Local ch...
About us
Module 1: before coding
– Security/SDLC basics
– Requirements and Design
– Threat modelling
Module 2: during codi...
About you?
• What's your name?
• Who do you work for?
• What do you do?
• What is your experience with information securit...
Overall objectives
1. You understand the concept of risk management
during both software development and acquisition:
– Un...
Agenda
• Module 1: Before the coding phase
– Key concepts and theory of information security and
risk management
– Underst...
Agenda
• Module 2: During the coding phase
– Web applications attacks and their countermeasures
– Principles of defensive ...
Agenda
• Module 3: After the coding phase
– Planning for security testing and assessment
– Tools and methodologies to test...
Logistics
• Breaks: we will probably stop talking...at some time :)
• Food & Drinks: all inclusive, treat yourself (and be...
Module 1
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 14
Finally!
Module 1: Inception & Design
Information security risk management
Software Security & Privacy
Security & Privacy at design...
Information security?
• In our context, qualified by 3+2 fundamental
attributes:
– CONFIDENTIALITY: Protected from unautho...
Information security?
– AUTHENTICTY: Protected from deniability of the
nature of a committed action
– NON-REPUDIATION: Pro...
Information security?
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 18
Source: John
Manuel Kennedy
Privacy
• It’ is a right.
• Sometimes, it’s a
constitutional right.
• 3 fundamental principles:
– Transparency
– Legitimat...
Privacy
• Data protection often goes
against business objectives:
– Personal data has business value
– Once obtained, pers...
Privacy
• A business organization has a natural tendency to
ignore privacy:
– WARNING: in most situations, it is not inten...
Privacy in Canada
• Previously: Privacy Act of 1980
• Currently:
– Personal information protection and electronic
document...
Privacy in Canada
• Currently:
– Obligation to notify breaches: yes (s11)
– Penalties: yes (s16)
• Order to correct proble...
“Risk”
“Potential that a given threat will exploit features of
an asset (or a group of assets) in such a way that
it would...
« Asset »
“Something possessed or controlled by an individual
or organization, from which benefit may be
obtained.”
• An a...
Examples
• Money
• Machine or object
• Knowledge
• Know-how
• Tool
• …
2/27/2012 OWASP Ottawa Chapter Training Day, Antoni...
« Vulnerability »
“A feature of an asset, that could be accidentally or
intentionally exercised and result in a violation ...
Examples
• Paper is vulnerable to fire, water and…scissors…
• A human body is vulnerable to piercing objects…
• An electri...
« Threat »
“Anything (object, event, person, …) capable of
performing unauthorized or undesired actions
against a system.”...
Examples:
• Natural events: flood, seismic event,…
• Physical evolution or attributes: accident, dust,
corrosion, heat/fir...
Examples
• People:
– Misuses, distractions,
errors
– Hackers
– Cybercriminals
– Terrorists
– Insiders
– Industrial and sta...
« Impact »
“A change in the capability of an organization or an
individual to achieve its/his/her objectives.”
• An impact...
Examples
• Reputation damage
• Disclosure of strategic information
• Loss of money
• Loss of knowledge or know-how
• Disru...
“Risk”
“Potential that a given threat will exploit features of
an asset (or a group of assets) in such a way that
it would...
Information Security Risk Management
“The process of identifying risk, assessing risk and
taking steps to reduce risk to a...
Examples
• “Zero tolerance”
• “Those we can afford.”
• “Not those ones!”
• “What the boss likes.”
• “Those we have to.”
• ...
ISRM tools you can use
• ISO/IEC 27005: Information security risk management
(commercial resource)
http://www.iso.org/iso/...
ISO/IEC 27005
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 38
NIST SP800-30
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 39
4 Risk treatment decisions
• Avoid: withdraw from, or decide not to be involved in, a
risk situation
• Accept: accept the ...
Information Security Risk Management
is also about avoiding this:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fon...
Conclusion
• An information security risk management process relies
on:
– The ability to identify and understand the risk
...
Module 1: Inception & Design
Information security risk management
Software Security & Privacy
Security & Privacy at design...
Software security & privacy
• Information security risk management applied to
the business of software development,
acquis...
What is a secure application?
• An application can be considered secure if:
1. It protects itself [and its underlying comp...
What is a secure application?
3. 2nd Corollary: one in which the developer would
entrust his/her data.
4. 3rd Corollary: a...
Origin of software security risk
• Software is [basically] the result of a translation
of expressed requirements into sour...
Origin of software security risk
• (continued) Software is characterized by:
– It is the product of human work: it inherit...
Origin of software security risk
• Remember this?
• Probability has increased:
– More complexity, interactions and connect...
Origin of software security risk
• Other causes:
– Lack of knowledge/awareness
– Cost of security integration
– Flawed too...
Origin of software security risk
• Confusion between “security feature” and
“secure feature”:
– Features, which enable sec...
Origin of software security risk
Security features:
– Features that, when "enabled", increase the overall
security of a sy...
Origin of software security risk
Secure feature:
– A feature that cannot be circumvented, bypassed,
altered or abused in a...
Origin of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 54
Try remembering the last r...
Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 55
ImplementationInception...
Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 56
ImplementationInception...
Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 57
ImplementationInception...
Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 58
ImplementationInception...
Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 59
ImplementationInception...
Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 60
ImplementationInception...
Software vulnerabilities
• Bugs and defects
– They often impact on availability (crash or use case
interruption)
• In most...
Software vulnerabilities
• Insecure coding
• Missing security & privacy requirements
• Insecure environment
• Poor inciden...
Software vulnerabilities
• They appear during 3 major stages of the SDLC:
– During Inception & Design
• Vulnerable design ...
Software vulnerabilities
• Important: understand that each type of
vulnerability can/should be identified while
observing ...
Typical software weaknesses
• Application Misconfiguration
• Directory Indexing
• Improper Filesystem
Permissions
• Improp...
Web applications attacks
• Abuse of Functionality
• Brute Force
• Buffer Overflow
• Content Spoofing
• Credential/Session
...
Best defense strategy?
Validate each line of produced source code against:
– The presence of any known possible weakness
–...
Risk control strategy
1. Reduce the likelihood of implementing and
shipping vulnerable code:
– Best practices and guidance...
Risk control strategy
2. Increase the likelihood of detecting
vulnerabilities:
– Review & Control activities
3. Prioritize...
Risk control strategy
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 70
ImplementationInception Design Verifi...
Risk control strategy
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 71
ImplementationInception Design Verifi...
Risk control strategy
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 72
ImplementationInception Design Verifi...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 73
ImplementationInception D...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 74
ImplementationInception D...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 75
ImplementationInception D...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 76
ImplementationInception D...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 77
ImplementationInception D...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 78
ImplementationInception D...
Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 79
ImplementationInception D...
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
6. Protect the weakest link
• Identify the weakest link of your design:
– Which components of the system are “out of your
...
7. Don’t mess with crypto
• Hard-coded secrets
• Use of not-so-random randomizers
• Missing encryption of sensitive data
•...
8. AAA
• Any interaction with the application is:
– Authenticated
– Authorized
– Audited
• Client-side access control is n...
9. Transport securely
• Any confidential data (see: classification!)
in transit must be protected from
interception.
• Att...
10. Psychological acceptance
• A new feature usually induces additional
requirement of:
– User skills (or patience/toleran...
Threat analysis & modeling
A method to identify and document threats to a
particular system and their most appropriate
cou...
What isn’t a threat model?
• It is not a solution to all our problems:
– Insecure coding or deployment practices are not
c...
What is a threat model?
• It is a repeatable process.
• It is an early risk detection & prevention process:
– Conducted at...
What is a threat model?
• It is a tool that helps identifying:
– Threats, that might exercise their access to the
applicat...
Major elements of a TM
• A system description
• A list of assets
• A list of threats
• A list of doomsday scenarios
• A li...
Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenario...
1. System description
• Describe the system objectives
• Identify the system security requirements
(we did this before, re...
1. System description
• Identify high-value assets:
– Data stores:
– Systems
2/27/2012 OWASP Ottawa Chapter Training Day, ...
1. System description
• Identify high-value assets:
– Data stores
• Confidential/Private/Strategic information
• Transacti...
Process boundary
File system
Network
…
- Call
- Network link
- RPC
- …
- Service
- Executable
- DLL
- Component
- Web serv...
1. Hands-on: ePoney
• Draw the ePoney system using the DFD method:
• Identify high-value assets.
2/27/2012 OWASP Ottawa Ch...
Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenario...
2. Threat sources analysis
• Use a threat source enumeration
– Should be provided by your management
– Should indicate: so...
2. Hands-on: ePoney
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 114
Type Source Intensity exposure comment...
2. Hands-on: ePoney
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 115
Type Source Intensity exposure Comment...
Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenario...
3. Doomsday scenarios
• Identify root scenarios: (Apply these to each threat source)
– Data theft? (confidentiality)
– Dat...
3. Doomsday scenarios
• A tool to help identify threat scenarios: STRIDE
– Spoofing (authentication)
– Tampering (integrit...
3. Doomsday scenarios
• SPOOFING:
– Attempt to impersonate a user or a component
• TAMPERING:
– Attempt to modify data or ...
3. Doomsday scenarios
• DENIAL OF SERVICE:
– Degrade the service, or stop it.
• ELEVATION OF PRIVILEGE:
– Perform unauthor...
3. Doomsday scenarios
• Each DFD component is exposed to specific
STRIDE attributes:
2/27/2012 OWASP Ottawa Chapter Traini...
3. Doomsday scenarios
• Each DFD component is exposed to specific
STRIDE attributes:
2/27/2012 OWASP Ottawa Chapter Traini...
3. Doomsday scenarios
• Each DFD component is exposed to specific
STRIDE attributes:
2/27/2012 OWASP Ottawa Chapter Traini...
3. Doomsday scenarios
• Each DFD component is exposed to specific
STRIDE attributes:
2/27/2012 OWASP Ottawa Chapter Traini...
3. Doomsday scenarios
• Each DFD component is exposed to specific
STRIDE attributes:
2/27/2012 OWASP Ottawa Chapter Traini...
3. Doomsday scenarios
• Each DFD component is exposed to specific
STRIDE attributes:
2/27/2012 OWASP Ottawa Chapter Traini...
3. Doomsday scenarios
Trust boundaries help identify 2 threats:
– Inbound flow from lower trust zones: increase input
vali...
3. Doomsday scenarios
• Describe the scenario:
– Who will trigger the scenario? (threat source)
• What is the intensity an...
3. Doomsday scenarios
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 129
Description Poney flights can be boo...
3. Hands-on: ePoney
• Apply STRIDE + standard threats on each
component
• Identify 2 other « doomsday » scenarios
2/27/201...
Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenario...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 132
Attack tree #1 Usurpation of...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 133
Attack tree #1 Usurpation of...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 134
Attack tree #1
countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 135
Attack tree #1
countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 136
Attack tree #1
countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 137
Attack tree #1
countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 138
Attack tree #1
Countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 139
Attack tree #1
Countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 140
Attack tree #1
Countermeasur...
4. Identify security controls
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 141
Attack tree #1
countermeasur...
Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenario...
Threat modeling process
1. Describe the system and its assets
2. Identify the threat sources
3. Identity doomsday scenario...
6. Transmit the threat model
• We cannot just “write and throw out” a security
document.
• Recipients often won’t understa...
6. Transmit the threat model
• To increase adoption:
– Complete the threat model with a proposed action list
that you know...
6. Transmit the threat model
• Typical clients:
– The architects: they should integrate the proposition to update
the desi...
Threat modeling approaches
• Attacker centric:
– All threat sources identified: their skills and attacks are
described.
• ...
Module 1: Inception & Design
Information security risk management
Software Security & Privacy
Security & Privacy at design...
Hands-on lab
• Online Hacme Casino system lab:
– Identify the overall security & privacy requirements
– You will receive a...
Module 1: Inception & Design
Information security risk management
Software Security & Privacy
Security & Privacy at design...
Conclusion
• Risks can be identified and mitigated early and regularly
in a web application project.
• There are many oppo...
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 152
Thank you!
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 153
For any contact/question/slides
request/inquiry...
Threat modeling cheatsheets
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 154
Cheatsheets – Full TM process
1. Describe the context
2. Describe the system:
– Output: business objective +
DFDs + high-v...
Cheatsheets – Flow & Boundary
Checkpoints:
- Protect the traffic if it allows:
- Credentials
- Private/Patient/Financial d...
Cheatsheets - Entity
Checkpoints:
- Do you need strong authentication?
- Can this entity conduct transactions?
- Can this ...
Cheatsheets - Process
Checkpoints:
- How do you authenticate this process?
- Can someone imitate it?
- How do you validate...
Cheatsheets - Datastore
Checkpoints:
- Who wants that data?
- Will they hack for it? Or will they pay someone to retrieve ...
Cheatsheets – human threat sources
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 160
Type Source Intensity E...
Cheatsheets – Doomsday scenarios
– Data X was stolen
• Credentials/Private data were
disclosed
– Data X was modified
• Who...
Don’t go further…
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 162
Really…
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 163
BACKUP SLIDES
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 164
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 165
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 166
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 167
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 168
OWASP: why?
• Causes:
– Victims: organizations and individuals
– Vulnerabilities
– Developers and operators
– Organization...
OWASP: why?
• Causes:
– Victims: organizations and individuals
– Vulnerabilities
– Developers and operators
– Organization...
OWASP: why?
• Causes:
– Victims: organizations and individuals
– Vulnerabilities
– Developers and operators
– Organization...
OWASP: why?
• Causes:
– Victims: organizations and individuals
– Vulnerabilities
– Developers and operators
– Organization...
Upcoming SlideShare
Loading in …5
×

Owasp ottawa training-day_2012-secure_design-final

Slides from the first module of the OWASP Ottawa Training Day 2012, "Integrating security and privacy in a web application project" training.

Module 1: before coding (security during inception and design phases)

The training was designed and produced by:
Antonio Fontes (OWASP Geneva) - http://www.slideshare.net/starbuck3000
Philippe Gamache (OWASP Montreal) - http://www.slideshare.net/PhilippeGamache
Sebastien Gioria (OWASP France) - http://www.slideshare.net/SebastienGioria

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Owasp ottawa training-day_2012-secure_design-final

  1. 1. Integrating security & privacy in a web application project OWASP Ottawa Chapter Training Day Feb 27th 2012 Module 1: before coding Antonio Fontes / OWASP Geneva Chapter The OWASP Foundation http://www.owasp.org
  2. 2. OWASP: what? • Open • Web • Application • Security • Project 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2
  3. 3. OWASP: what? • Open • Web • Application • Security • Project 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2
  4. 4. OWASP: why? • Causes: – Victims: organizations and individuals – Vulnerabilities – Developers and operators – Organizational structures, processes, supporting technologies – Increased connectivity, interoperability and complexity – Legal and regulatory environment – Asymmetric information in the software market 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 4
  5. 5. OWASP: who? • Elected board • Leaders: – Project leaders – Chapter leaders • 1’500 Members – Individual supporters – Academic / Institutional supporters – Corporate supporters – Governments • 20’000 Participants 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 5
  6. 6. OWASP: how? • Committees: education, industries, connections,… • Projects – 140 documentation and tool projects • Local chapters: – 250 chapters in 93 countries • Global Appsec Conferences – North America, Latin America, Europe, Asia • Appsec Conferences • Summit 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 6
  7. 7. About us Module 1: before coding – Security/SDLC basics – Requirements and Design – Threat modelling Module 2: during coding – Attacks and countermeasures – Defensive programing Module 3: after coding – Testing and validating the security of your web application 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 7 Antonio Fontes OWASP Geneva Philippe Gamache OWASP Montreal Antonio Fontes OWASP France
  8. 8. About you? • What's your name? • Who do you work for? • What do you do? • What is your experience with information security? • What is your experience with web applications security? • What do you want to learn today? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 8
  9. 9. Overall objectives 1. You understand the concept of risk management during both software development and acquisition: – Understanding, assessing and treating risk 2. You understand the key principles of security and privacy in software systems. 3. You know when and how to increase visibility on risk or mitigate risk in a web application: a. Which is to be developed b. Which is to be acquired 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 9
  10. 10. Agenda • Module 1: Before the coding phase – Key concepts and theory of information security and risk management – Understanding Security and Privacy – The systems acquisition process – The systems development process/lifecycle – Gathering security & privacy requirements – Modeling threats and their countermeasures – Secure design principles: implementing and reviewing systems designs 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 10
  11. 11. Agenda • Module 2: During the coding phase – Web applications attacks and their countermeasures – Principles of defensive programing – Secure coding mindset – Working with 3rd party code/binaries – Analyzing and reviewing the code security (static analysis) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 11
  12. 12. Agenda • Module 3: After the coding phase – Planning for security testing and assessment – Tools and methodologies to test the security of a web application – Evaluating and reporting on vulnerabilities – Managing vulnerabilities and responding to security advisories 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 12
  13. 13. Logistics • Breaks: we will probably stop talking...at some time :) • Food & Drinks: all inclusive, treat yourself (and be polite and thankful with our sponsors) • Smartphones: just put them on the table, silent mode. We all know your mum's face will appear on the screen if there is an emergency. • Assistance: we will rotate: 1 trainer, 1 assistant, 1 asleep • Support material: everything is on the USB stick, including all the slides and tools we will show you. • Don't forget to smile, laugh and share your stories! 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 13
  14. 14. Module 1 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 14 Finally!
  15. 15. Module 1: Inception & Design Information security risk management Software Security & Privacy Security & Privacy at design time – Inception phase – Design phase Hands-on: – Security & Privacy requirements – Threat modeling Conclusion 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 15
  16. 16. Information security? • In our context, qualified by 3+2 fundamental attributes: – CONFIDENTIALITY: Protected from unauthorized access – INTEGRITY: Protected from unauthorized modification – AVAILABILITY: Protected from unaccepted reduction of service 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 16
  17. 17. Information security? – AUTHENTICTY: Protected from deniability of the nature of a committed action – NON-REPUDIATION: Protected from deniability of committing to an action 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 17
  18. 18. Information security? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 18 Source: John Manuel Kennedy
  19. 19. Privacy • It’ is a right. • Sometimes, it’s a constitutional right. • 3 fundamental principles: – Transparency – Legitimate purpose (finality) – Proportionality 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 19
  20. 20. Privacy • Data protection often goes against business objectives: – Personal data has business value – Once obtained, personal data is an unlimited resource: collect once, copy anytime anywhere. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 20
  21. 21. Privacy • A business organization has a natural tendency to ignore privacy: – WARNING: in most situations, it is not intentional! • Regulations and laws: – They create a framework of fines and legal actions directed on public and private organizations. – Consequently, they constitute a financial incentive to protect personal data. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 21
  22. 22. Privacy in Canada • Previously: Privacy Act of 1980 • Currently: – Personal information protection and electronic documents Act (PIPEDA) http://www.parl.gc.ca/36/2/parlbus/chambus/house/bills/government/C-6/C- 6_4/C-6_cover-E.html – Enforced by the Privacy Commissioner of Canada http://www.priv.gc.ca/ • Has power to: investigate, audit and publish 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 22
  23. 23. Privacy in Canada • Currently: – Obligation to notify breaches: yes (s11) – Penalties: yes (s16) • Order to correct problems • Order to notify the incident • Award damages to the victims – Applies to deceased: yes (s2) (Disclaimer: this is the result of a 5 minutes Google search) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 23
  24. 24. “Risk” “Potential that a given threat will exploit features of an asset (or a group of assets) in such a way that it would cause harm to its owner.” • A risk requires: – A threat – One or more assets with one or more vulnerabilities – A likelihood (or probability) – An undesired impact 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 24 R= p x i
  25. 25. « Asset » “Something possessed or controlled by an individual or organization, from which benefit may be obtained.” • An asset requires: limited accessibility and generates value 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 25
  26. 26. Examples • Money • Machine or object • Knowledge • Know-how • Tool • … 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 26
  27. 27. « Vulnerability » “A feature of an asset, that could be accidentally or intentionally exercised and result in a violation of the information system’s security policy or a security breach.” • Warning: a legitimate and perfectly functional feature can also be turned into a vulnerability under appropriate conditions. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 27
  28. 28. Examples • Paper is vulnerable to fire, water and…scissors… • A human body is vulnerable to piercing objects… • An electrical system may be vulnerable to a power surge… • A highly secure web application stored in a highly secure server may be vulnerable to an earthquake… 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 28
  29. 29. « 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. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 29 Impact? Severe. Probability? …
  30. 30. Examples: • Natural events: flood, seismic event,… • Physical evolution or attributes: accident, dust, corrosion, heat/fire damage • Service failures: air conditioned, power, telecommunications • Disturbances: radio emissions • Technical failures: bug, saturation, malfunction 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 30
  31. 31. Examples • People: – Misuses, distractions, errors – Hackers – Cybercriminals – Terrorists – Insiders – Industrial and state-level espionage • … 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 31 A threatening source of threat that threatens you…
  32. 32. « Impact » “A change in the capability of an organization or an individual to achieve its/his/her objectives.” • An impact may induce a loss, or a gain. • In information risk management, we mostly deal with adverse impacts. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 32
  33. 33. Examples • Reputation damage • Disclosure of strategic information • Loss of money • Loss of knowledge or know-how • Disruption of activity • Temporary exposure to health damage • A fine caused by a breach of compliance • A broken machine • … 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 33
  34. 34. “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 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 34 R= p x i
  35. 35. Information Security Risk Management “The process of identifying risk, assessing risk and taking steps to reduce risk to an acceptable level.” • ISRM requires: – Users, tools and activities to identify, assess and reduce risk (it’s a process!) – An accepted risk level 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 35
  36. 36. Examples • “Zero tolerance” • “Those we can afford.” • “Not those ones!” • “What the boss likes.” • “Those we have to.” • “What looks nice.” • “What??” 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 36
  37. 37. ISRM tools you can use • ISO/IEC 27005: Information security risk management (commercial resource) http://www.iso.org/iso/catalogue_detail?csnumber=56742 • NIST SP-800-30: Risk management guide for information security systems http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf • OWASP Risk Rating methodology https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 37
  38. 38. ISO/IEC 27005 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 38
  39. 39. NIST SP800-30 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 39
  40. 40. 4 Risk treatment decisions • Avoid: withdraw from, or decide not to be involved in, a risk situation • Accept: accept the burden of potential harm • Reduce: take action to reduce the likelihood or the impact of a given risk scenario • Transfer: share the burden with another party (insurance, delegation) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 40
  41. 41. Information Security Risk Management is also about avoiding this: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 41
  42. 42. Conclusion • An information security risk management process relies on: – The ability to identify and understand the risk • Which impacts may result form which scenarios? – The ability to assess the risk • Which scenarios can actually be exercised for real? – The ability to control the risk to an acceptable level • What is the acceptable level? • Which actions are taken to treat the risk to the acceptable level? • Software security risk management activities fall under the overall information security risk management process of an organization (ISO 27002#12.5: Security in development and support processes) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 42
  43. 43. Module 1: Inception & Design Information security risk management Software Security & Privacy Security & Privacy at design time – Inception phase – Design phase Hands-on: – Security & Privacy requirements – Threat modeling Conclusion 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 43
  44. 44. Software security & privacy • Information security risk management applied to the business of software development, acquisition and operations. • Contextualization: – What is “secure” software? • Notion of acceptable security and privacy risk level – What defines the security level of a given application? – Which tools and activities can help us identify, assess and control the security of an application? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 44
  45. 45. What is a secure application? • An application can be considered secure if: 1. It protects itself [and its underlying components] from unauthorized access (confidentiality), modifications (integrity), illegitimate service disruptions (availability) and plausible acts of deniability (non-repudiation and authenticity). 2. Corollary: the expected level of protection is defined by the actual level of effort required to circumvent its protections. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 45
  46. 46. What is a secure application? 3. 2nd Corollary: one in which the developer would entrust his/her data. 4. 3rd Corollary: and of his/her spouse, parents, children, friends, etc... 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 46 “Is your application secure?” “Yes! Of course!”
  47. 47. Origin of software security risk • Software is [basically] the result of a translation of expressed requirements into source code. • It is characterized by: – A construction consisting of a sequence of input/output activities: the Software Development Lifecycle – Interactions: with users and other systems 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 47
  48. 48. Origin of software security risk • (continued) Software is characterized by: – It is the product of human work: it inherits effects naturally caused by our actions: distractions, errors, misinterpretations, errors of judgment, incompetence, etc. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 48
  49. 49. Origin of software security risk • Remember this? • Probability has increased: – More complexity, interactions and connectivity increases exposure to threats. • Impacts have increased: – More responsibilities and more penalties. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 49 R= p x i
  50. 50. Origin of software security risk • Other causes: – Lack of knowledge/awareness – Cost of security integration – Flawed tools and APIs – A prevalent misconception of security in software: • Strong passwords • Authentication forms • SSL • and………………………… : 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 50
  51. 51. Origin of software security risk • Confusion between “security feature” and “secure feature”: – Features, which enable security: security features – Features, which are implemented securely: everything 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 51
  52. 52. Origin of software security risk Security features: – Features that, when "enabled", increase the overall security of a system. – i.e.: an authentication mechanism, a group and users management console, a function to encrypt data, a RegExp validation library, etc. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 52
  53. 53. Origin of software security risk Secure feature: – A feature that cannot be circumvented, bypassed, altered or abused in a way that compromises the security of the overall system. – i.e.: any feature of a software system. • A file upload function • A form • A list of links to all your account statements 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 53
  54. 54. Origin of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 54 Try remembering the last response to a call for proposal or functional specifications document you read. What was the content under the "Security" section? Very probably: authentication ("we can connect to your AD server", access control ("you will be able to manage users and groups"), and…nothing else.
  55. 55. Evolution of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 55 ImplementationInception Design Verification Release Operations Risk level
  56. 56. Evolution of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 56 ImplementationInception Design Verification Release Operations Risk level
  57. 57. Evolution of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 57 ImplementationInception Design Verification Release Operations Risk level
  58. 58. Evolution of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 58 ImplementationInception Design Verification Release Operations Risk level Fixing costs
  59. 59. Evolution of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 59 ImplementationInception Design Verification Release Operations Risk level Fixing costs Accepted risk level
  60. 60. Evolution of software security risk 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 60 ImplementationInception Design Verification Release Operations Risk level Fixing costs Accepted risk level
  61. 61. Software vulnerabilities • Bugs and defects – They often impact on availability (crash or use case interruption) • In most cases, they are triggered during normal usage • Sources: – Flawed design or construction – Incorrect configuration 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 61
  62. 62. Software vulnerabilities • Insecure coding • Missing security & privacy requirements • Insecure environment • Poor incident response • Technology induced vulnerabilities • Vulnerable design • Incomplete requirements • Insecure configuration 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 62 Inception Design Release Operations Design Operations Implementation Inception
  63. 63. Software vulnerabilities • They appear during 3 major stages of the SDLC: – During Inception & Design • Vulnerable design causes vulnerabilities – During Implementation • (Weak) coding cause vulnerabilities – During Operations • System is installed on a vulnerable host or configured improperly 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 63
  64. 64. Software vulnerabilities • Important: understand that each type of vulnerability can/should be identified while observing the output artifacts: – Inception & Design vulnerabilities: • Reviewing specification requirements & design documents – Implementation vulnerabilities: • Reviewing the source code – Operational vulnerabilities: • Testing the environment and the overall configuration 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 64
  65. 65. Typical software weaknesses • Application Misconfiguration • Directory Indexing • Improper Filesystem Permissions • Improper Input Handling • Improper Output Handling • Information Leakage • Insecure Indexing • Insufficient Anti-automation • Insufficient Authentication • Insufficient Authorization • Insufficient Password Recovery • Insufficient Process Validation • Insufficient Session Expiration • Insufficient Transport Layer Protection • Server Misconfiguration 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 65 Source: webappsec.org
  66. 66. Web applications attacks • Abuse of Functionality • Brute Force • Buffer Overflow • Content Spoofing • Credential/Session Prediction • Cross-Site Scripting • Cross-Site Request Forgery • Denial of Service • Fingerprinting • Format String • HTTP Response Smuggling • HTTP Response Splitting • HTTP Request Smuggling • HTTP Request Splitting • Integer Overflows • LDAP Injection • Mail Command Injection • Null Byte Injection • OS Commanding • Path Traversal • Predictable Resource Location • Remote File Inclusion (RFI) • Routing Detour • Session Fixation • SOAP Array Abuse • SSI Injection • SQL Injection • URL Redirector Abuse • XPath Injection • XML Attribute Blowup • XML External Entities • XML Entity Expansion • XML Injection • XQuery Injection 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 66 Source: webappsec.org
  67. 67. Best defense strategy? Validate each line of produced source code against: – The presence of any known possible weakness – The exposure to all known vulnerabilities 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 67 It won't work: - You don't have time - You don't have money - You'd need to understand all known vulnerabilities exhaustively!
  68. 68. Risk control strategy 1. Reduce the likelihood of implementing and shipping vulnerable code: – Best practices and guidance – Know-how (training & awareness) – Tools and processes • Automation! 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 68
  69. 69. Risk control strategy 2. Increase the likelihood of detecting vulnerabilities: – Review & Control activities 3. Prioritize: – Know your (or your boss's) risk appetite – Evaluate the most appropriate risk treatment choice (accept, transfer, avoid, mitigate or…procrastinate) – Take risks. (you'll have to anyway) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 69
  70. 70. Risk control strategy 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 70 ImplementationInception Design Verification Release Operations Risk level Fixing costs Accepted risk level DO THINGS WELL
  71. 71. Risk control strategy 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 71 ImplementationInception Design Verification Release Operations Risk level Fixing costs Accepted risk level DO THINGS WELL VERIFY
  72. 72. Risk control strategy 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 72 ImplementationInception Design Verification Release Operations Risk level Fixing costs Accepted risk level Doing things well Verifying - Do things well and at every stage - Review all artefacts as soon as they are produced
  73. 73. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 73 ImplementationInception Design Verification Release Operations Prevention: - Analysis of security & privacy requirements Detection: -Review
  74. 74. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 74 ImplementationInception Design Verification Release Operations Prevention: - Secure design and architecture guidance - Secure software requirements definition guidance - Awareness of web induced risks - Threat modeling Detection: - Requirements/specification analysis - Design security review
  75. 75. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 75 ImplementationInception Design Verification Release Operations Prevention: - Secure development environment configuration - Secure coding guidance Detection: - Code security review
  76. 76. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 76 ImplementationInception Design Verification Release Operations Prevention: - N/A Detection: - Security testing
  77. 77. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 77 ImplementationInception Design Verification Release Operations Prevention: - Secure application deployment guidance Detection: - Vulnerability/Configuration security assessment
  78. 78. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 78 ImplementationInception Design Verification Release Operations Prevention: - Maintain secure environments (networks, systems, services) - Incident response planning Detection: - Vulnerability assessment - Penetration testing
  79. 79. Applying risk control in the SDLC 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 79 ImplementationInception Design Verification Release Operations
  80. 80. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  81. 81. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  82. 82. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  83. 83. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  84. 84. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  85. 85. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  86. 86. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  87. 87. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  88. 88. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  89. 89. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  90. 90. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  91. 91. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  92. 92. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  93. 93. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  94. 94. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  95. 95. OWASP: what? • Core principle: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
  96. 96. 6. Protect the weakest link • Identify the weakest link of your design: – Which components of the system are “out of your control”? Unstable? Unknown? Emotional? …? • Exercise increased control as soon as you can: – Increase control at the next closest component 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 96
  97. 97. 7. Don’t mess with crypto • Hard-coded secrets • Use of not-so-random randomizers • Missing encryption of sensitive data • Missing a cryptographic step • Not using a secure encryption mode • Not using a randomized initialization vector in chaining encryption modes • Storing credentials with reversible encryption • Using poor algorithms for secret-to-key derivation • Unexpected loss of entropy • Failure to follow specification • Failure to use optimal asymmetric encryption padding • Failure to store keys securely • Failure to destroy keys securely • Failure to revoke keys securely • Failure to distribute keys securely • Failure to generate keys securely • Failure to use adequate encryption strength • Use of unauthorized encryption strength • Use of broken encryption algorithms • Failure to prevent reversible one-way hashing • Failure to prevent inference/statistical observation • … 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 97
  98. 98. 8. AAA • Any interaction with the application is: – Authenticated – Authorized – Audited • Client-side access control is not access control! – It’s…user interface design... – Web apps: • always consider that the user knows ALL highly sensitive URLs and form values (browser history + request tampering). 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 98
  99. 99. 9. Transport securely • Any confidential data (see: classification!) in transit must be protected from interception. • Attributes of a sensitive transaction must be protected from tampering while in- transit. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 99
  100. 100. 10. Psychological acceptance • A new feature usually induces additional requirement of: – User skills (or patience/tolerance) – Operational resources (support information, hardware, time and skills) • Before observing the beauty of a given design/source code, validate it can actually enter production state on a long-term basis. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 100
  101. 101. Threat analysis & modeling A method to identify and document threats to a particular system and their most appropriate countermeasures. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 101
  102. 102. What isn’t a threat model? • It is not a solution to all our problems: – Insecure coding or deployment practices are not covered by a TM • It is not an exact science: – 1 book covers the topic. – It was written in 2004. By Microsoft engineers. – A second book is…being…written. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 102
  103. 103. What is a threat model? • It is a repeatable process. • It is an early risk detection & prevention process: – Conducted at design time – Lower cost of risk mitigation • It is a simple process: – Pen and paper activity 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 103
  104. 104. What is a threat model? • It is a tool that helps identifying: – Threats, that might exercise their access to the application – Scenarios, that may result in damage/harm – Controls, that may help blocking or detecting these scenarios • Ultimately, a threat model helps prioritize security efforts. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 104
  105. 105. Major elements of a TM • A system description • A list of assets • A list of threats • A list of doomsday scenarios • A list of measures/security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 105
  106. 106. Threat modeling process 1. Describe the system and its assets 2. Identify the threat sources 3. Identity doomsday scenarios 4. Identify measures/security controls 5. Document all previous outputs. 6. Transmit the threat model. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 106
  107. 107. 1. System description • Describe the system objectives • Identify the system security requirements (we did this before, remember?) • Draw the system using the dataflow diagramming (DFD)method 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 107
  108. 108. 1. System description • Identify high-value assets: – Data stores: – Systems 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 108
  109. 109. 1. System description • Identify high-value assets: – Data stores • Confidential/Private/Strategic information • Transactional/High integrity data – Systems • High availability systems • Business critical systems • Control systems • Systems with access to other sensitive systems 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 109
  110. 110. 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 - … 1. System description 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 110 External entity Process DataflowData store Trust boundary
  111. 111. 1. Hands-on: ePoney • Draw the ePoney system using the DFD method: • Identify high-value assets. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 111 External entity Process DataflowData store Trust boundary
  112. 112. Threat modeling process 1. Describe the system and its assets 2. Identify the threat sources 3. Identity doomsday scenarios 4. Identify measures/security controls 5. Document all previous outputs. 6. Transmit the threat model. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 112
  113. 113. 2. Threat sources analysis • Use a threat source enumeration – Should be provided by your management – Should indicate: source + likelihood/intensity • Evaluate exposure: – How accessible is the system to the threat source? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 113
  114. 114. 2. Hands-on: ePoney 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 114 Type Source Intensity exposure comment Opportunistic Malware- infected client systems High Kids High Targeted Competition Medium Sysadmins Medium Cheating customers Medium
  115. 115. 2. Hands-on: ePoney 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 115 Type Source Intensity exposure Comment Opportunistic Malware- infected client systems High Elevated Internet application Kids High Elevated Internet application Targeted Competition Medium Elevated Internet application Sysadmins Medium Elevated Externally hosted Cheating customers Medium Elevated Typical user
  116. 116. Threat modeling process 1. Describe the system and its assets 2. Identify the threat sources 3. Identity doomsday scenarios 4. Identify measures/security controls 5. Document all previous outputs. 6. Transmit the threat model. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 116
  117. 117. 3. Doomsday scenarios • Identify root scenarios: (Apply these to each threat source) – Data theft? (confidentiality) – Data/system tampering? (integrity) – Access to sensitive systems? (integrity) – Service disruption? (availability) – Deniability? (authenticity / non-repudiation) – Avoid payment? – Withdraw money? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 117
  118. 118. 3. Doomsday scenarios • A tool to help identify threat scenarios: STRIDE – Spoofing (authentication) – Tampering (integrity) – Repudiation (non-repudiation) – Information disclosure (confidentiality) – Denial of service (availability) – Elevation of privileges (authorization) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 118
  119. 119. 3. Doomsday scenarios • SPOOFING: – Attempt to impersonate a user or a component • TAMPERING: – Attempt to modify data or code • REPUDIATION – Claiming to have not performed an action • INFORMATION DISCLOSURE – Exposing information to someone not authorized 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 119
  120. 120. 3. Doomsday scenarios • DENIAL OF SERVICE: – Degrade the service, or stop it. • ELEVATION OF PRIVILEGE: – Perform unauthorized actions 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 120
  121. 121. 3. Doomsday scenarios • Each DFD component is exposed to specific STRIDE attributes: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 121 External entity Process Dataflow Data store S T R I D E
  122. 122. 3. Doomsday scenarios • Each DFD component is exposed to specific STRIDE attributes: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 122 External entity Process Dataflow Data store S T R I D E Attempt to usurp someone’s identity
  123. 123. 3. Doomsday scenarios • Each DFD component is exposed to specific STRIDE attributes: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 123 External entity Process Dataflow Data store S T R I D E -Someone directly modifies database content through system access. - A tampering request is forged by a user
  124. 124. 3. Doomsday scenarios • Each DFD component is exposed to specific STRIDE attributes: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 124 External entity Process Dataflow Data store S T R I D E - Someone intercepts the traffic
  125. 125. 3. Doomsday scenarios • Each DFD component is exposed to specific STRIDE attributes: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 125 External entity Process Dataflow Data store S T R I D E A payment transaction data is modified while in transit
  126. 126. 3. Doomsday scenarios • Each DFD component is exposed to specific STRIDE attributes: 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 126 External entity Process Dataflow Data store S T R I D E A user says “he didn’t buy this.”
  127. 127. 3. Doomsday scenarios Trust boundaries help identify 2 threats: – Inbound flow from lower trust zones: increase input validation effort! – Outbound flow to lower trust zone: restrict information (typically: error details!) 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 127
  128. 128. 3. Doomsday scenarios • Describe the scenario: – Who will trigger the scenario? (threat source) • What is the intensity and exposure? – What will be the impact? • Theft? Loss? Corruption? Disruption? Money? • Legal? Reputation? Productivity? Health? – How will the scenario be realized? • Describe how the attack is performed 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 128
  129. 129. 3. Doomsday scenarios 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 129 Description Poney flights can be booked without payment Source Cheating customers (intensity: high; exposure: elevated) Impact Financial: direct loss of revenue Intensity is average unless the attacks is published Attack tree #1 Usurpation of another user’s identity (threat type S) - account credentials are stolen by attacking user emails - account credentials are guessed (brute-force) - account credentials are intercepted (man in the middle) Attack tree #2 Modification of account credits without payment (threat type T) - Transaction tampering during the credit buying operation - Execution of arbitrary code (code injection)
  130. 130. 3. Hands-on: ePoney • Apply STRIDE + standard threats on each component • Identify 2 other « doomsday » scenarios 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 130 Description Source Impact Attack tree #1
  131. 131. Threat modeling process 1. Describe the system and its assets 2. Identify the threat sources 3. Identity doomsday scenarios 4. Identify measures/security controls 5. Document all previous outputs. 6. Transmit the threat model. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 131
  132. 132. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 132 Attack tree #1 Usurpation of another user’s identity (threat type S) - account credentials are stolen by attacking user emails - account credentials are guessed (brute-force) - account credentials are intercepted (man in the middle) Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Traffic interception Malware Weak password Bruteforce attack Hacked email
  133. 133. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 133 Attack tree #1 Usurpation of another user’s identity (threat type S) - account credentials are stolen by attacking user emails - account credentials are guessed (brute-force) - account credentials are intercepted (man in the middle) Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Traffic interception Malware Weak password Bruteforce attack Hacked email Countermeasures analysis
  134. 134. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 134 Attack tree #1 countermeasures - Don’t send password in email - Send a lifetime limited password reset link Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Traffic interception Malware Weak password Bruteforce attack Hacked email
  135. 135. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 135 Attack tree #1 countermeasures - Don’t send password in email - Send a lifetime limited password reset link - Use secure transport Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Traffic interception Malware Weak password Bruteforce attack Hacked email
  136. 136. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 136 Attack tree #1 countermeasures - Don’t send password in email - Send a lifetime limited password reset link - Use secure transport - Recommend installation of security software Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Traffic interception Malware Weak password Bruteforce attack Hacked email
  137. 137. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 137 Attack tree #1 countermeasures - Don’t send password in email - Send a lifetime limited password reset link - Use secure transport - Recommend installation of security software - Require strong passwords Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Traffic interception Malware Weak password Bruteforce attack Hacked email
  138. 138. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 138 Attack tree #1 Countermeasures - Don’t send password in email - Send a lifetime limited password reset link - Use secure transport - Recommend installation of security software - Require strong passwords - Implement automated account lockout and threshold Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Weak password Bruteforce attack Traffic interception Malware Hacked email
  139. 139. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 139 Attack tree #1 Countermeasures - Don’t send password in email - Send a lifetime limited password reset link - Use secure transport - Recommend installation of security software - Require strong passwords - Implement automated account lockout and threshold Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Weak password Bruteforce attack Traffic interception Malware Hacked email
  140. 140. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 140 Attack tree #1 Countermeasures - Don’t send password in email - Send a lifetime limited password reset link - Use secure transport - Recommend installation of security software - Require strong passwords - Implement automated account lockout and threshold Identity usurpation Stolen credentials Guessed credentials Bruteforced credentials Weak password Bruteforce attack Traffic interception Malware Hacked email Identity usurpation
  141. 141. 4. Identify security controls 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 141 Attack tree #1 countermeasures - Force password modification after first use - Use secure transport - Recommend installation of security software - Require strong passwords - Implement automated account lockout and threshold Attack tree #2 Countermeasures - … Attack tree #3 Countermeasures - … Attack tree #4 Countermeasures - …
  142. 142. Threat modeling process 1. Describe the system and its assets 2. Identify the threat sources 3. Identity doomsday scenarios 4. Identify measures/security controls 5. Document all previous outputs. 6. Transmit the threat model. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 142
  143. 143. Threat modeling process 1. Describe the system and its assets 2. Identify the threat sources 3. Identity doomsday scenarios 4. Identify measures/security controls 5. Document all previous outputs. 6. Transmit the threat model. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 143
  144. 144. 6. Transmit the threat model • We cannot just “write and throw out” a security document. • Recipients often won’t understand it. • To increase adoption: – Present the results to the audience, in person. – Discuss the countermeasures: cost and delay 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 144
  145. 145. 6. Transmit the threat model • To increase adoption: – Complete the threat model with a proposed action list that you know is acceptable. – Don’t ask too much: maintain the view on the global system. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 145
  146. 146. 6. Transmit the threat model • Typical clients: – The architects: they should integrate the proposition to update the design. – The developers: they usually would benefit from the model transparently, through the updated specification. – The security testing team: they now know what to test precisely! – The software editor: if you are acquiring software, you can add the threat model to the software acceptance procedure. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 146
  147. 147. Threat modeling approaches • Attacker centric: – All threat sources identified: their skills and attacks are described. • Asset centric: – Assets are identified and sorted by value. Typical threats are enumerated in the form of “doomsday scenarios”. • System centric: – Systematic application of the STRIDE + standard threats model on each component of the system and full enumeration of all countermeasures. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 147
  148. 148. Module 1: Inception & Design Information security risk management Software Security & Privacy Security & Privacy at design time – Inception phase – Design phase Hands-on: – Security & Privacy requirements – Threat modeling Conclusion 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 148
  149. 149. Hands-on lab • Online Hacme Casino system lab: – Identify the overall security & privacy requirements – You will receive a list of core use cases (i.e.: create account, logout, transfer chips, play blackjack ,etc.) – For each use case: • Inform the design team of potential requirements that should be taken into consideration • Perform a threat model 2/27/2012 OWASP Ottawa Chapter Training Day - Antonio Fontes 149
  150. 150. Module 1: Inception & Design Information security risk management Software Security & Privacy Security & Privacy at design time – Inception phase – Design phase Hands-on: – Security & Privacy requirements – Threat modeling Conclusion 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 150
  151. 151. Conclusion • Risks can be identified and mitigated early and regularly in a web application project. • There are many opportunities for both doing well and detecting problems: – Security and privacy requirements checklist – Design analysis & review with principles – Threat modeling • The main objective is to produce functional / technical / design specifications that will induce developers into implementing secure features. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 151
  152. 152. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 152
  153. 153. Thank you! 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 153 For any contact/question/slides request/inquiry/complaint/love letter/thank you: By email: antonio.fontes@owasp.org Follow me on Twitter: @starbuck3000
  154. 154. Threat modeling cheatsheets 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 154
  155. 155. Cheatsheets – Full TM process 1. Describe the context 2. Describe the system: – Output: business objective + DFDs + high-value assets 3. Identify threat sources – Output: threat exposures 4. Choose/Identify doomsday scenarios – Output: attack trees 5. Identify (counter)measures – Output: list of controls for each attack tree 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! 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 155
  156. 156. Cheatsheets – Flow & Boundary Checkpoints: - Protect the traffic if it allows: - Credentials - Private/Patient/Financial data - Other confidential information - 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? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 156 Dataflow - Call - Network link - RPC Process boundary File system Network … Trust boundary
  157. 157. Cheatsheets - Entity Checkpoints: - 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? - Is the entity connecting from a multi-user system? - Is data being stored at that entity? - How do you protect it from tampering? - How do you protect it from 3rd party access? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 157 External entity - User - other system -Partner/supplier…
  158. 158. Cheatsheets - Process Checkpoints: - How do you authenticate this process? - Can someone imitate it? - How do you validate it? - 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? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 158 - Service - Executable - DLL - Component - Web service - Assembly - … Process - Is the process returning data 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.
  159. 159. Cheatsheets - Datastore Checkpoints: - 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? - If no, what are the threats? - Can you encrypt it? - If you encrypt it, where would be the keys? - Is there some compliance or regulation that forces usage of encryption? - Is the datastore located on a mobile system? - What if the support gets stolen?lost? 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 159 Data store - Database server - Config file - Registry - Memory - Queue / stack - …
  160. 160. Cheatsheets – human threat sources 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 160 Type Source Intensity Exposure Scenarios Opportunistic threat Automated threat sources (worms..) High Automated hands (hackers w/ tools) High Compliance / Law Medium Targeted threat Competition “Anonymous” Insiders Industrial / State espionage
  161. 161. 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? – 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 – User U was able to withdraw/redirect money – A secret was intercepted by a guy sniffing the network – 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 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 161
  162. 162. Don’t go further… 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 162
  163. 163. Really… 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 163
  164. 164. BACKUP SLIDES 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 164
  165. 165. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 165
  166. 166. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 166
  167. 167. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 167
  168. 168. 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 168
  169. 169. OWASP: why? • Causes: – Victims: organizations and individuals – Vulnerabilities – Developers and operators – Organizational structures, processes, supporting technologies – Increased connectivity, interoperability and complexity – Legal and regulatory environment – Asymmetric information in the software market 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 4
  170. 170. OWASP: why? • Causes: – Victims: organizations and individuals – Vulnerabilities – Developers and operators – Organizational structures, processes, supporting technologies – Increased connectivity, interoperability and complexity – Legal and regulatory environment – Asymmetric information in the software market 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 4
  171. 171. OWASP: why? • Causes: – Victims: organizations and individuals – Vulnerabilities – Developers and operators – Organizational structures, processes, supporting technologies – Increased connectivity, interoperability and complexity – Legal and regulatory environment – Asymmetric information in the software market 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 4
  172. 172. OWASP: why? • Causes: – Victims: organizations and individuals – Vulnerabilities – Developers and operators – Organizational structures, processes, supporting technologies – Increased connectivity, interoperability and complexity – Legal and regulatory environment – Asymmetric information in the software market 2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 4

×