Threat Modeling / Ipad

MARET Consulting | Boulevard Georges Favon 43 | CH 1204 Geneva | Tl +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
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 Threat identification Vulnerabilities identification Impacts analysis
#2
#3 #4 #5 #6
Risk characterization
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
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. Unsecure backups, memory-card access Data interception by locally installed malware
Local capture:

#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
Multiple Process
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 ID
Threat ID
Comment Unsecure backups Memory-card access Data interception by locally installed malware Sniffers, gateways, cache proxies, MitM, etc.
T R
D E
2 (iPad)
T1
3 (TransportInternet) 7 (Banking- App)
T2
T3
Offensive / hostile / corrupt requests
Step #3
Vulnerabilities identification
#3 - Security controls - Example
Threat ID
T1
Family
Feature: local mobile application sandboxing
Controls
Secure offline data storage Secure online data storage (inmemory storage) Secure environment validation (OS + client application integrity) Safeguards against malware Confidential transport - defense in depth - privilege separation - trusted links & endpoint Presence of software security assurance controls in each development lifecycle: - Outsourced Dev - Acme Bank
T2 T3
Feature: data transport security Feature: secure architecture
T3
Process: secure software development
#3 - Vulnerabilities identification
Threat ID
T1
Controls
Secure offline data storage Secure online data storage (in-memory storage) Secure environment validation (OS + client application integrity) Safeguards against malware Confidential transport - defense in depth - privilege separation - trusted links & endpoint Presence of software security assurance controls in each development lifecycle: - Outsourced Dev - Acme Bank
V-ID
V100
Vulnerabilities
??
T2 T3
V200 V300
No Application Level Data Security No Hardening Strategy at Service Layer Poor SDLC activities
T3
V400
#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 level Security activities
-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
Analysis Design
Implementation
Verification Delivery Operations
- Incident response process - Threat / vulnerability management

#3 Web Agency: software development security assurance
Project phase
Analysis
Assurance level
Security activities
Design
Implementation
- involvement of a security architect during the design process
- use of automated code quality analysis tools
Verification Delivery
Operations
- experience with customers conducting regular security evaluations

#3 - Acme Bank: software development security assurance
Project phase
Analysis
Assurance level
Security activities
Design
Implementation
Verification Delivery
Operations
#3 - Software development security assurance: Summary
Actor
Assurance level
Conclusions
Outsourced Dev
- 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).
Acme Bank
- 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

V-400
Intrusion on Banking Application
HIGH
Step #5
Risk estimation
#5 Risk estimation - Example

Tech. Impact Business Impact
R-ID
V-ID
Description
Likelihood
Severity
R-1 V-200 Confidentiality Compliance Reputation
Theft of credentials or personal data during transport
MEDIUM
HIGH
R-2 V-300 Integrity V-400
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
Perform a pentest on the iPad application
Reco. MC Mitigate
Decision
SC.1 R-1
SC.2 R-1
Implement Data encryption for transport Mitigate
SC.3 R-2
Deploy a XML Firewall in front of Web Service Perform code review Perform Pentest
Mitigate
SC.4 R-2
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

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 scurit des systmes d'information et de l'identit numrique"
Backup Slides
#2 - Understanding the threats Threat Spoofing Tampering Repudiation Information

Disclosure
Property
Authentication
Definition
Impersonating something or someone else. Modifying data or code
Example
Pretending to be any of billg, xbox.com or a system update Modifying a game config file on disk, or a packet as it traverses the network
Integrity
Non-repudiation
Claiming to have not I didnt cheat! performed an action Exposing information to someone not authorized to see it Deny or degrade service to users Gain capabilities without proper authorization Reading key material from an app
Confidentiality
Denial of Service
Availability
Crashing the web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole Allowing a remote internet user to run commands is the classic example, but running kernel code from lower trust levels Conseil en technologies is also EoP
Elevation of
Privilege
Authorization
Source: Microsoft SDL Threat Modeling
#3 - V400 - Poor SDLC activities
Software assurance maturity models: SAMM (OWASP)
#2 Data Flow Diagram
External entity People Other systems Microsoft.com etc
Process DLLs EXEs Components Services Web Services Assemblies etc
Data Flow
Data Store Database File Registry Shared Memory Queue/Stack etc
Function call Network traffic Etc
Trust Boundary Process boundary File system


Threat Modeling / Ipad

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Threat Modeling / Ipad

Uploaded by

Copyright:

Available Formats

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

iPad net-Banking Project Technical Risk Assessment

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

Context Technical Risk Assessment approach

A six step process Threat Model DFD STRIDE Model

The TRA relies on a series of six activities:

System characterization Threat identification Vulnerabilities identification Impacts analysis

Ensure service integrity:

Uncontrolled client systems mean unpredictable request behavior

Prevent access from:

Offensive / hostile / corrupt requests

Ensure information confidentiality:

Prevent access from:

Consider project specific risks:

Outsourced vs. in-house development

where will security assurance come from?

Multi-disciplinary project involving three major actors:

Who will be responsible for key security aspects?

Building a threat model

Decompose the Application

Diagramming - Data Flow Diagram - DFD

Determine and Rank Threats

#2 - Data Flow Diagram (DFD)

#2 - DFD - iPad net-Banking

#2 - Threats - iPad net-Banking - Example

#2 - Different threats affect each type of element

3 (TransportInternet) 7 (Banking- App)

Offensive / hostile / corrupt requests

#3 - Security controls - Example

Feature: data transport security Feature: secure architecture

Process: secure software development

Data Sharing between apps ?

Malicious legal App. ?

#3 - V200 - No Application Level Data Security

#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

- Incident response process - Threat / vulnerability management

#3 Web Agency: software development security assurance

- involvement of a security architect during the design process

- use of automated code quality analysis tools

- experience with customers conducting regular security evaluations

#3 - Acme Bank: software development security assurance

#3 - Software development security assurance: Summary

#4 Impact analysis Example

Information disclosure on iPad

Additional controls needed

Information disclosure on data transport

MEDIUM Additional controls needed

Intrusion on Banking Application

Additional controls needed

Intrusion on Banking Application

#5 Risk estimation - Example

R-1 V-200 Confidentiality Compliance Reputation

Theft of credentials or personal data during transport

R-2 V-300 Integrity V-400

Compliance Reputation, Operations

User input tampering attempts resulting in system compromise

R-3 -R-4 -R-5 R-6

Risk treatment and mitigation

#6 Security controls - Example

Implement Data encryption for transport Mitigate