Owasp ottawa training-day_2012-secure_design-final

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

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
– Organizational structures, processes, supporting
technologies
– Increased connectivity, interoperability and
complexity
– Legal and regulatory environment
– Asymmetric information in the software market

OWASP: who?
• Elected board
• Leaders:
– Project leaders
– Chapter leaders
• 1’500 Members
– Individual supporters
– Academic / Institutional supporters
– Corporate supporters
– Governments
• 20’000 Participants

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

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
Antonio Fontes
OWASP Geneva
Philippe Gamache
OWASP Montreal
Antonio Fontes
OWASP France

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?

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

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

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)

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

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!

Module 1
Finally!

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

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

– AUTHENTICTY: Protected from deniability of the
nature of a committed action
– NON-REPUDIATION: Protected from deniability of
committing to an action

Source: John
Manuel Kennedy

Privacy
• It’ is a right.
• Sometimes, it’s a
constitutional right.
• 3 fundamental principles:
– Transparency
– Legitimate purpose (finality)
– Proportionality

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.

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.

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

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)

“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
R= p x i

« Asset »
“Something possessed or controlled by an individual
or organization, from which benefit may be
obtained.”
• An asset requires:
limited accessibility and
generates value

Examples
• Money
• Machine or object
• Knowledge
• Know-how
• Tool
• …

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

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…

« 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.
Impact? Severe. Probability? …

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

Examples
• People:
– Misuses, distractions,
errors
– Hackers
– Cybercriminals
– Terrorists
– Insiders
– Industrial and state-level espionage
• …
A threatening source of threat that threatens you…

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

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

“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
R= p x i

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

Examples
• “Zero tolerance”
• “Those we can afford.”
• “Not those ones!”
• “What the boss likes.”
• “Those we have to.”
• “What looks nice.”
• “What??”

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

ISO/IEC 27005

NIST SP800-30

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)

Information Security Risk Management
is also about avoiding this:

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)

– Inception phase
– Design phase
Hands-on:
– Threat modeling
Conclusion

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?

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.

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...
“Is your application
secure?”
“Yes! Of course!”

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

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

• Remember this?
• Probability has increased:
– More complexity, interactions and connectivity
increases exposure to threats.
• Impacts have increased:
– More responsibilities and more penalties.
R= p x i

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

• Confusion between “security feature” and
“secure feature”:
– Features, which enable security: security features
– Features, which are implemented securely: everything

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.

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

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.

Evolution of software security risk
ImplementationInception Design Verification Release Operations
Risk level

Risk level

Risk level
Fixing costs

Risk level
Fixing costs
Accepted risk level

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

• Insecure coding
• Missing security & privacy requirements
• Insecure environment
• Poor incident response
• Technology induced vulnerabilities
• Vulnerable design
• Incomplete requirements
• Insecure configuration
Inception
Design
Release
Operations
Design
Operations
Implementation
Inception

• 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

• 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

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
Source: webappsec.org

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
Source: webappsec.org

Best defense strategy?
Validate each line of produced source code against:
– The presence of any known possible weakness
– The exposure to all known vulnerabilities
It won't work:
- You don't have time
- You don't have money
- You'd need to understand all known
vulnerabilities exhaustively!

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

Risk level
Fixing costs
Accepted risk level
DO THINGS WELL

Risk level
Fixing costs
Accepted risk level
DO THINGS WELL VERIFY

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

Applying risk control in the SDLC
Prevention:
- Analysis of security & privacy requirements
Detection:
-Review

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

Prevention:
- Secure development environment configuration
- Secure coding guidance
Detection:
- Code security review

Prevention:
- N/A
Detection:
- Security testing

Prevention:
- Secure application deployment guidance
Detection:
- Vulnerability/Configuration security assessment

Prevention:
- Maintain secure environments (networks, systems, services)
- Incident response planning
Detection:
- Vulnerability assessment
- Penetration testing

OWASP: what?
• Core principle:

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

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

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

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.

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.

Threat analysis & modeling
A method to identify and document threats to a
particular system and their most appropriate
countermeasures.

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.

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

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.

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

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.

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

• Identify high-value assets:
– Data stores:
– Systems

• 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

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
- …
External entity Process DataflowData store
Trust
boundary

1. Hands-on: ePoney
• Draw the ePoney system using the DFD method:
• Identify high-value assets.
External entity Process DataflowData store
Trust
boundary

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. Hands-on: ePoney
Type Source Intensity exposure comment
Opportunistic
Malware-
infected client
systems
High
Kids High
Targeted
Competition Medium
Sysadmins Medium
Cheating
customers
Medium

2. Hands-on: ePoney
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

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?

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

• 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

• DENIAL OF SERVICE:
– Degrade the service, or stop it.
• ELEVATION OF PRIVILEGE:
– Perform unauthorized actions

• Each DFD component is exposed to specific
STRIDE attributes:
External entity
Process
Dataflow
Data store
S T R I D E

STRIDE attributes:
External entity
Process
Dataflow
Data store
S T R I D E
Attempt to usurp someone’s identity

STRIDE attributes:
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

STRIDE attributes:
External entity
Process
Dataflow
Data store
S T R I D E
- Someone intercepts the traffic

STRIDE attributes:
External entity
Process
Dataflow
Data store
S T R I D E
A payment transaction
data is modified while in
transit

STRIDE attributes:
External entity
Process
Dataflow
Data store
S T R I D E
A user says “he didn’t buy
this.”

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

• 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

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)

3. Hands-on: ePoney
• Apply STRIDE + standard threats on each
component
• Identify 2 other « doomsday » scenarios
Description
Source
Impact
Attack tree #1

4. Identify security controls
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Traffic
interception
Malware
Weak
password
Bruteforce
attack
Hacked
email

Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Traffic
interception
Malware
Weak
password
Bruteforce
attack
Hacked
email
Countermeasures analysis

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

Attack tree #1
countermeasures
- Use secure transport
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Traffic
interception
Malware
Weak
password
Bruteforce
attack
Hacked
email

Attack tree #1
countermeasures
- Recommend installation of security software
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Traffic
interception
Malware
Weak
password
Bruteforce
attack
Hacked
email

Attack tree #1
countermeasures
- Require strong passwords
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Traffic
interception
Malware
Weak
password
Bruteforce
attack
Hacked
email

Attack tree #1
Countermeasures
- Implement automated account lockout and threshold
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Weak
password
Bruteforce
attack
Traffic
interception
Malware
Hacked
email

Attack tree #1
Countermeasures
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Weak
password
Bruteforce
attack
Traffic
interception
Malware
Hacked
email

Attack tree #1
Countermeasures
Identity
usurpation
Stolen credentials
Guessed
credentials
Bruteforced
credentials
Weak
password
Bruteforce
attack
Traffic
interception
Malware
Hacked
email
Identity
usurpation

Attack tree #1
countermeasures
- Force password modification after first use
Attack tree #2
Countermeasures
- …
Attack tree #3
Countermeasures
- …
Attack tree #4
Countermeasures
- …

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

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

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

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.

– Inception phase
– Design phase
Hands-on:
– Threat modeling
Conclusion

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

– Inception phase
– Design phase
Hands-on:
– Threat modeling
Conclusion

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.

Thank you!
For any contact/question/slides
request/inquiry/complaint/love letter/thank you:
By email: antonio.fontes@owasp.org
Follow me on Twitter: @starbuck3000

Threat modeling cheatsheets

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!

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?
Dataflow
- Call
- Network link
- RPC
Process
boundary
File system
Network
…
Trust
boundary

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?
External entity
- User
- other system
-Partner/supplier…

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

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?
Data store
- Database
server
- Config file
- Registry
- Memory
- Queue /
stack
- …

Cheatsheets – human threat sources
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

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

Don’t go further…

Really…

BACKUP SLIDES

Owasp ottawa training-day_2012-secure_design-final

More Related Content

What's hot

Similar to Owasp ottawa training-day_2012-secure_design-final

More from Antonio Fontes

Recently uploaded

Owasp ottawa training-day_2012-secure_design-final