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 codingAntonio Fontes / OWASP Geneva Chapter

The OWASP Foundationhttp://www.owasp.org

OWASP: what?

• Open

• Web

• Application

• Security

• Project

2/27/2012 OWASP Ottawa Chapter Training Day, Antonio Fontes 2

OWASP: what?

• Core principle:


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 usModule 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 objectives1. 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 & DesignInformation 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


Information security?– AUTHENTICTY: Protected from deniability of the

nature of a committed action

– NON-REPUDIATION: Protected from deniability of

committing to an action


Information security?


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 systemshttp://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

• OWASP Risk Rating methodologyhttps://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




Risk level

Fixing costs




Risk level

Fixing costs

Accepted risk level




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


Software vulnerabilities• 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







– Inception phase

– Design phase

Hands-on:


– Threat modeling

Conclusion


Inception phase

• Risk:

– Failing to identify security & privacy requirements

• Action(s):

– Security & privacy requirements analysis / review

– Preliminary risk assessment

• Inputs:

– Data classification

– Business services/functions classification


Inception phase

• Output:

– Security & privacy requirements that must be

considered during the project

– Estimation of effort required to reach production with

an acceptable risk level:

• No security?

• Which prevention activities (trained personnel)?

• Which control activities?


Inception phase

• Case study: presentation of the ePoney

application

• Hands-on:

– Identify security and privacy requirements

– Evaluate criticality of the project and estimate

required security effort


Hands-on: S&P requirements1. What data types?

– Personal/VIP/children data

– Payment data

– Financial data

– Health/patient data

– Intellectual/Strategic data

– Public data

2. What service criticality ?– Core business service

– Supporting service

– Auxiliary service

3. Other considerations ?– Security aware personnel?

– Security trained personnel?

– Trusted hosting environment?

– Outsourced development?

– Internet accessible?

– Trusted users?

– Trusted client systems?

– Authentication required?

– Connected to critical systems?


Hands-on: S&P requirements

• Visibility on security and privacy requirements:

– Data storage/collection/transport requirements

– Compliance with particular regulations � design

• Visibility on effort required:

– Do we need training? Experts?

– Self-assessed security? Driven by security team?

– What controls?

• Design review? Code review? Penetration test?


Design phase

• Risk:

– Failing to understand requirements

– Failing to integrate undocumented requirements

– Failing to apply secure design principles

– Failing to evaluate threats and countermeasures

• Project-specific threats

• Technology induced threats:

– Web apps: OWASP Top 10 risks

– Framework specific: Java, PHP, Dotnet, RoR, etc.


Design phase

• Actions:

– Review specifications and requirements with S&P in

mind

– Use/validate secure design principles

– Identify/validate threats and countermeasures

• Threat analysis and modeling (TAM)


Design phase

• Inputs:

– S&P Requirements

– Business requirements

– Technology specific threats and countermeasures

• Outputs:

– Intermediate: threat model

– Robust architecture design


10 Secure design principles1. Trust no one! (whoever talks to your system is an enemy.)

2. Fail safely! (think about escalators in malls: if they stop, you can walk.)

3. Keep it simple! (be both lazy and responsible.)

4. Be transparent! (transparency of mechanism)

5. Enforce privacy! (it is a civil right, not an optional feature.)

6. Protect the weakest link! (think about boxing fights: they wear gloves and…)

7. Don’t mess with crypto! (if you don't have a PhD in crypto, don't pretend.)

8. Triple A! (authenticate, authorize and audit)

9. Transport securely! (data traveling from node A to B can be eavesdropped)

10. Keep it acceptable! (what do your guts tell you about this design?)


1. Trust no one• Trust no one:

– The user is evil.

– The host is poorly configured.

– The network is a botnet nest.

– Sysadmins and DBAs are mafia.

• Validate input:

– Always canonicalize.

– Whitelist when you can.

– Blacklist when you must.

– Protect configuration and access

control stores

• Least privilege

– Always deny unless written

otherwise.

• Separation of privileges

– Levels of assurance (LOAs)

– Multi-user scenarios


2. Fail safe

• The application will fail.

• 2 consequences:

– Information disclosure

– Breach of workflow integrity

• Good design practice:

– Fail silently: never show unnecessary data

– Fail safely: default case is always “no”

– Example: ATM failure (no flying cash notes!)


3. Economy of mechanism

• Keep security simple and…simple.

• Centralize logic and disseminate control

– Implement oncepackage org.company.api.security

{

bool HasPermission(Permissions p)

{

}

}

– Disseminate everywhere


4. Transparency of mechanism

• Obfuscation is like translation: once you know

the rule, translation is immediate.

• Example: Truecrypt full-disk encryption. If you

know the source code, the encryption algorithm,

the key size, the mode of operation and

initialization vector, can you read an encrypted

disk?

• Principle: consider the architecture as public.


5. Maintain privacy

• Privacy is never in the wish-list of a business: it

costs a lot and it reduces flexibility.

• Privacy is a civil right. Your opinion doesn't count

here: ignoring this right is illegal.

• Approach:

– Proportionality : collect what you really need.

– Transparency : inform the users.

– Security: prepare for a breach, protect the users.


6. Protect the weakest link


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 EAttempt 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 EA 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 credentialsGuessed

credentials

Bruteforced

credentials

Traffic

interceptionMalware

Weak

password

Bruteforce

attack

Hacked

email







Identity

usurpation


credentials

Bruteforced

credentials

Traffic

interceptionMalware

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


credentials

Bruteforced

credentials

Traffic

interceptionMalware

Weak

password

Bruteforce

attack

Hacked

email



Attack tree #1

countermeasures



- Use secure transport

Identity

usurpation


credentials

Bruteforced

credentials

Traffic

interceptionMalware

Weak

password

Bruteforce

attack

Hacked

email



Attack tree #1

countermeasures




- Recommend installation of security software

Identity

usurpation


credentials

Bruteforced

credentials

Traffic

interceptionMalware

Weak

password

Bruteforce

attack

Hacked

email



Attack tree #1

countermeasures





- Require strong passwords

Identity

usurpation


credentials

Bruteforced

credentials

Traffic

interceptionMalware

Weak

password

Bruteforce

attack

Hacked

email



Attack tree #1

Countermeasures






- Implement automated account lockout and threshold

Identity

usurpation


credentials

Bruteforced

credentials

Weak

password

Bruteforce

attack

Traffic

interceptionMalware

Hacked

email



Attack tree #1

Countermeasures







Identity

usurpation


credentials

Bruteforced

credentials

Weak

password

Bruteforce

attack

Traffic

interceptionMalware

Hacked

email



Attack tree #1

Countermeasures







Identity

usurpation


credentials

Bruteforced

credentials

Weak

password

Bruteforce

attack

Traffic

interceptionMalware

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


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.


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.


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: [email protected]

Follow me on Twitter: @starbuck3000

Threat modeling cheatsheets


Cheatsheets – Full TM process1. 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 & BoundaryCheckpoints:

- 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 - EntityCheckpoints:

- 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 - ProcessCheckpoints:

- 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 - DatastoreCheckpoints:

- 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








