Threat Modeling / iPad

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

iPad net-Banking Project
Technical Risk Assessment

Sylvain Maret / Security Architect / 2012-05-24
@smaret

Conseil en technologies

Agenda

 Context

 Technical Risk Assessment approach
 A six step process
 Threat Model – DFD
 STRIDE Model

 Open discussion

www.maret-consulting.ch Conseil en technologies

Context


Context

 Business case: enable customer access to
portfolio performance reports from mobile
equipments (iPad) located outside the
controlled network.

Actors Security Product

ACME Bank

Web Agency

The TRA relies on a series of six activities:

#1 • System characterization
#2 • Threat identification
#3 • Vulnerabilities identification
#4 • Impacts analysis
#5 • Risk characterization
#6 • 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.

Required level

C I A

#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 Conseil en technologies
www.maret-consulting.ch

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

Process
External entity Multiple Process

Data store 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 Threat
Comment S T R I D E
ID ID

Unsecure backups
2 Memory-card access
T1
(iPad) Data interception by locally
installed malware

3
Sniffers, gateways, cache
(Transport- T2
proxies, MitM, etc.
Internet)

7 Offensive / hostile / corrupt
T3
(Banking- App) requests


Step #3

Vulnerabilities identification

#3 - Security controls - Example

Threat Family Controls
ID
T1 Feature: local mobile application Secure offline data storage
sandboxing 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 Presence of software security
development assurance controls in each
development lifecycle:
- Outsourced Dev
www.maret-consulting.ch
- Acme Bank Conseil en technologies

#3 - Vulnerabilities identification

Threat Controls V-ID Vulnerabilities
ID
T1 Secure offline data storage V100 ??
Secure online data storage (in-memory
storage)
Secure environment validation (OS +
client application integrity)
Safeguards against malware
T2 Confidential transport V200 No Application Level
Data Security
T3 - defense in depth V300 No Hardening Strategy
- privilege separation at Service Layer
- trusted links & endpoint
T3 Presence of software security assurance V400 Poor SDLC activities
controls in each development lifecycle:
- Outsourced Dev
- Acme Bank

#3 - V100 - unknown

Data Sharing between apps ?

Device Jailbreaking ?

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

Project phase Assurance Security
level activities
-Security requirements
Analysis - Compliance reqs., policy

- Secure design / Design security review
- Threat model
Design - Security testing plan

- Safe APIs
Implementation - Secure coding / defensive programming

?
- Automated source code analysis

- Security testing
Verification - Penetration testing

- Secure default configuration
Delivery - Hardening / secure deployment guides
- Configuration validation

- Incident response process
Operations - Threat / vulnerability management


#3 – Web Agency: software development security assurance

Project phase Assurance Security
level activities

Analysis

- involvement of a security architect
during the design process
Design

- use of automated code quality analysis
Implementation tools

Verification

Delivery

- experience with customers conducting
Operations regular security evaluations

#3 - Acme Bank: software development security assurance

Assurance
Project phase Security
level
activities

Analysis

Design

Implementation
?
Verification

Delivery

Operations

#3 - Software development security assurance: Summary

Actor Assurance Conclusions
level

- Assurance level is low. Acme Bank shall agree with
Outsourced Dev 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
Acme Bank ? 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 MEDIUM Additional controls
transport 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

Tech. Business
R-ID V-ID Description Likelihood Severity
Impact Impact
R-1 V-200 Confidentiality Compliance Theft of credentials MEDIUM HIGH
Reputation or personal data
during transport
R-2 V-300 Integrity Compliance User input LOW HIGH
V-400 Reputation, tampering attempts
Operations resulting in system
compromise
R-3 -- -- -- -- -- --

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

R-5

R-6


Step #6

Risk treatment and mitigation

#6 – Security controls - Example

Reco.
ID Risk Description Decision
MC

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

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

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

SC.4 R-2 Perform code review Mitigate
Perform Pentest


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

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/


"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 Pretending to be any of billg, xbox.com or
something or a system update
someone else.
Tampering Integrity Modifying data or Modifying a game config file on disk, or a
code packet as it traverses the network

Repudiation Non-repudiation Claiming to have not “I didn’t cheat!”
performed an action

Information Confidentiality Exposing Reading key material from an app
Disclosure information to
someone not
authorized to see it
Denial of Service Availability Deny or degrade Crashing the web site, sending a packet
service to users and absorbing seconds of CPU time, or
routing packets into a black hole

Elevation of Authorization Gain capabilities Allowing a remote internet user to run
Privilege without proper commands is the classic example, but
authorization running kernel code from lower trust levels
www.maret-consulting.ch is also EoP Conseil en technologies

Source: Microsoft SDL Threat Modeling

#3 - V400 - Poor SDLC activities

Software assurance maturity models: SAMM (OWASP)


#2 – Data Flow Diagram

External Data
Process Data Store
entity Flow

• People • DLLs • Function call • Database
• Other systems • EXEs • Network traffic • File
• Microsoft.com • Components • Etc… • Registry
• etc… • Services • Shared
• Web Services Memory
• Assemblies • Queue/Stack
• etc… • etc…

Trust Boundary

• Process boundary
• File system

Threat Modeling / iPad

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (12)

Similaire à Threat Modeling / iPad

Similaire à Threat Modeling / iPad (20)

Plus de Sylvain Maret

Plus de Sylvain Maret (20)

Dernier

Dernier (20)

Threat Modeling / iPad