Threat Modeling / iPad

MARET Consulting | Boulevard Georges Favon 43 | CH 1204 Geneva | Tél +41 22 575 30 35 | [email protected] | www.maret-consulting.ch

Conseil en technologies

Sylvain Maret / Security Architect / 2012-05-24

@smaret

iPad net-Banking Project

Technical Risk Assessment

mailto:[email protected]



Conseil en technologies www.maret-consulting.ch

Agenda

Context

Technical Risk Assessment approach

A six step process

Threat Model – DFD

STRIDE Model

Open discussion


Context


Context

Business case: enable customer access to

portfolio performance reports from mobile

equipments (iPad) located outside the

controlled network.


Actors

ACME Bank

Web Agency

Security Product


The TRA relies on a series of six activities:

#1 • System characterization • System characterization

#2 • Threat identification • Threat identification

#3 • Vulnerabilities identification • Vulnerabilities identification

#4 • Impacts analysis • Impacts analysis

#5 • Risk characterization • Risk characterization

#6 • Risk treatment and mitigation • Risk treatment and mitigation


Step #1

System characterization


#1 - Appropriate safeguards

The selected solution shall implement the

appropriate safeguards to maintain the overall

security to its expected level.

C I A

Required level


#1

Ensure service integrity:

Uncontrolled client systems mean unpredictable

request behavior

Prevent access from:

Offensive / hostile / corrupt requests


#1

Ensure information confidentiality:

While data travels across uncontrolled networks

While the client application is “offline” (turned-off)

While the client application is “online” (running)

Prevent access from:

Network capture:

Sniffers, gateways, cache proxies, MitM, etc.

Local capture:

Unsecure backups, memory-card access

Data interception by locally installed malware


#1

Consider project specific risks:

Outsourced vs. in-house development

where will security assurance come from?

Multi-disciplinary project involving three major actors:

The Bank (Acme - IT projects)

The portfolio performance reporting application (Web Agency)

The sandboxing application (Sysmosoft)

Who will be responsible for key security aspects?


Step #2

Threat identification


#2

Building a threat model

Decompose the Application

Diagramming - Data Flow Diagram - DFD

Determine and Rank Threats

STRIDE model


#2 - Data Flow Diagram (DFD)

External entity

Data store

Multiple Process Process

Data flow Trust Boundary


#2 - DFD - iPad net-Banking


#2 – STRIDE Model

Threat Categories


#2 - Threat Agents


#2 - Threats - iPad net-Banking - Example


#2 - Different threats affect each type of element

DFD

ID

Threat

ID Comment S T R I D E

2

(iPad) T1

Unsecure backups

Memory-card access

Data interception by locally

installed malware

3

(Transport-

Internet)

T2 Sniffers, gateways, cache

proxies, MitM, etc.

7

(Banking- App) T3

Offensive / hostile / corrupt

requests


Step #3

Vulnerabilities identification


#3 - Security controls - Example

Threat

ID

Family Controls

T1 Feature: local mobile application

sandboxing

Secure offline data storage

Secure online data storage (in-

memory storage)

Secure environment validation

(OS + client application integrity)

Safeguards against malware

T2 Feature: data transport security Confidential transport

T3 Feature: secure architecture - defense in depth

- privilege separation

- trusted links & endpoint

T3 Process: secure software

development

Presence of software security

assurance controls in each

development lifecycle:

- Outsourced Dev

- Acme Bank


#3 - Vulnerabilities identification

Threat

ID

Controls V-ID Vulnerabilities

T1 Secure offline data storage

Secure online data storage (in-memory

storage)

Secure environment validation (OS +

client application integrity)

Safeguards against malware

V100 ??

T2 Confidential transport V200 No Application Level

Data Security

T3 - defense in depth

- privilege separation

- trusted links & endpoint

V300 No Hardening Strategy

at Service Layer

T3 Presence of software security assurance

controls in each development lifecycle:

- Outsourced Dev

- Acme Bank

V400 Poor SDLC activities


#3 - V100 - unknown

Device Jailbreaking ?

Data Sharing between apps ?

Malicious legal App. ?


#3 - V200 - No Application Level Data Security

Banking App


#3 - V300 - No Hardening Strategy at Service Layer

No XML Firewall

No Mutual Trust SSL at

WS Transport Level

No Hardening at OS &

Service Level


#3 - V400 - Poor SDLC activities

SDL de Microsoft


#3 - Security Assurance during development

Analysis

Design

Implementation

Verification

Delivery

Operations

-Security requirements

- Compliance reqs., policy

- Secure design / Design security review

- Threat model

- Security testing plan

- Safe APIs

- Secure coding / defensive programming

- Automated source code analysis

- Security testing

- Penetration testing

- Secure default configuration

- Hardening / secure deployment guides

- Configuration validation

- Incident response process

- Threat / vulnerability management

Project phase Assurance

level

Security

activities

?


#3 – Web Agency: software development security assurance

Analysis

Design

Implementation

Verification

Delivery

Operations

- involvement of a security architect

during the design process

- use of automated code quality analysis

tools

- experience with customers conducting

regular security evaluations


level

Security

activities


#3 - Acme Bank: software development security assurance

Analysis

Design

Implementation

Verification

Delivery

Operations


level Security

activities

?


#3 - Software development security assurance: Summary

Outsourced Dev

Acme Bank

Actor Assurance

level

Conclusions

?

- Assurance level is low. Acme Bank shall agree with

vendor on minimum security assurance requirements along the

project, or establish a clear statement of responsibilities (SLA).

- Assurance level is low. Acme Bank shall define minimum

security assurance requirements with project management.


Step #4

Impact analysis


#4 – Impact analysis – Example

V-ID Description Severity Exposure

V-100 Information disclosure on iPad HIGH Additional controls

needed

V-200 Information disclosure on data

transport

MEDIUM Additional controls

needed

V-300 Intrusion on Banking Application HIGH Additional controls

needed

V-400 Intrusion on Banking Application HIGH Additional controls

needed


Step #5

Risk estimation


#5 – Risk estimation - Example

R-ID V-ID Tech.

Impact

Business

Impact Description Likelihood Severity

R-1 V-200 Confidentiality Compliance

Reputation

Theft of credentials

or personal data

during transport

MEDIUM HIGH

R-2 V-300

V-400

Integrity Compliance

Reputation,

Operations

User input

tampering attempts

resulting in system

compromise

LOW HIGH

R-3 -- -- -- -- -- --

R-4 -- -- -- -- -- --

R-5

R-6


Step #6

Risk treatment and mitigation


#6 – Security controls - Example

ID Risk Description Reco.

MC Decision

SC.1 R-1 Perform a pentest on the iPad

application

Mitigate

SC.2 R-1 Implement Data encryption for transport Mitigate

SC.3 R-2 Deploy a XML Firewall in front of Web

Service

Mitigate

SC.4 R-2 Perform code review

Perform Pentest

Mitigate


Conclusion

Security in mind during the project

Iterative process

Risk Assessment during the project

Risk Assessment after deployment

Threat Modeling

A new approach

A guideline for all project


Questions ?


Who am I?

Security Expert

17 years of experience in ICT Security

Principal Consultant at MARET Consulting

Expert at Engineer School of Yverdon & Geneva University

Swiss French Area delegate at OpenID Switzerland

Co-founder Geneva Application Security Forum

OWASP Member

Author of the blog: la Citadelle Electronique

http://ch.linkedin.com/in/smaret or @smaret

http://www.slideshare.net/smaret

Chosen field

AppSec & Digital Identity Security

http://www.citadelle-electronique.net/

http://ch.linkedin.com/in/smaret

http://twitter.com/smaret

http://www.slideshare.net/smaret


References

https://www.owasp.org/index.php/Application_Threat_

Modeling

http://msdn.microsoft.com/en-us/library/ff648644.aspx

http://en.wikipedia.org/wiki/Threat_model

http://www.microsoft.com/security/sdl/default.aspx

http://www.appsec-forum.ch/

https://www.owasp.org/index.php/Application_Threat_Modeling

https://www.owasp.org/index.php/Application_Threat_Modeling




http://en.wikipedia.org/wiki/Threat_model









"Le conseil et l'expertise pour le choix et la mise

en oeuvre des technologies innovantes dans la sécurité

des systèmes d'information et de l'identité numérique"


Backup Slides


#2 - Understanding the threats

Threat Property Definition Example

Spoofing Authentication Impersonating

something or

someone else.

Pretending to be any of billg, xbox.com or

a system update

Tampering Integrity Modifying data or

code

Modifying a game config file on disk, or a

packet as it traverses the network

Repudiation Non-repudiation Claiming to have not

performed an action

“I didn’t cheat!”

Information

Disclosure

Confidentiality Exposing

information to

someone not

authorized to see it

Reading key material from an app

Denial of Service Availability Deny or degrade

service to users

Crashing the web site, sending a packet

and absorbing seconds of CPU time, or

routing packets into a black hole

Elevation of

Privilege

Authorization Gain capabilities

without proper

authorization

Allowing a remote internet user to run

commands is the classic example, but

running kernel code from lower trust levels

is also EoP Source: Microsoft SDL Threat Modeling


#3 - V400 - Poor SDLC activities

Software assurance maturity models: SAMM (OWASP)


#2 – Data Flow Diagram

• People

• Other systems

• Microsoft.com

• etc…

• Function call

• Network traffic

• Etc…

• DLLs

• EXEs

• Components

• Services

• Web Services

• Assemblies

• etc…

• Database

• File

• Registry

• Shared

Memory

• Queue/Stack

• etc…

External

entity Process

Data

Flow Data Store

Trust Boundary

• Process boundary

• File system

Technology

Threat Modeling / iPad