This document summarizes an OWASP training session on integrating security and privacy into web application projects. It discusses what OWASP is and its goals of open web application security. It then outlines the agenda and modules to be covered in the training, which include security best practices for the inception, design, coding, and post-coding phases of a web application project. The training aims to help participants understand security risk management and how to incorporate security and privacy into each phase of the development lifecycle.
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. OWASP: what?
• Open
• Web
• Application
• Security
• Project
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2
3. OWASP: what?
• Open
• Web
• Application
• Security
• Project
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2
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
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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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
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. 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. 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. 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. 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. “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. « 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. Examples
• Money
• Machine or object
• Knowledge
• Know-how
• Tool
• …
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 26
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. 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. « 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. 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. 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. « 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. 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. “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. 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. 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. 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
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. Information Security Risk Management
is also about avoiding this:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 41
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 55
ImplementationInception Design Verification Release Operations
Risk level
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. Evolution of software security risk
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 57
ImplementationInception Design Verification Release Operations
Risk level
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. 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. 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. 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
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. 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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Applying risk control in the SDLC
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 79
ImplementationInception Design Verification Release Operations
80. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
81. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
82. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
83. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
84. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
85. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
86. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
87. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
88. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
89. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
90. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
91. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
92. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
93. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
94. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
95. OWASP: what?
• Core principle:
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 3
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 1. System description
• Identify high-value assets:
– Data stores:
– Systems
2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 108
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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
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. 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. 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. 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. 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. 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. 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