1 ® MD Manitoba Telecom Services Inc. Used under license. / Utilisé en vertu d’une licence. MTS Allstream Inc. proprietary. Use pursuant to company instructions

1® MD Manitoba Telecom Services Inc. Used under license. / Utilisé en vertu d’une licence. MTS Allstream Inc. proprietary. Use pursuant to company instructions./Information exclusive à MTS Allstream Inc. Utiliser conformément aux directives de la société.

Threat Modeling and the Zero Day Problem

A quick look at how methodical threat modeling could combat an enterprise’s security problem

Christopher Lee

® MD Manitoba Telecom Services Inc. Used under license. / Utilisé en vertu d’une licence. MTS Allstream Inc. proprietary. Use pursuant to company instructions./Information exclusive à MTS Allstream Inc. Utiliser conformément aux directives de la société.2

Agenda

Software Vulnerabilities are Out of Control! The Basic Vocabulary of Risk Management What is Threat Modeling How does Threat Modeling help, even in the face of Zero-day vulnerabilities?


Coping with Vulnerabilities

Vulnerabilities are being reported at an alarming rate, despite vendors’ focus on writing secure code.

CERT/CC Statistics 1988-2007

Year 2001 2002 2003 2004 2005 2006 2007 – Q1-Q3

# of vulnerabilities

2,437 4,129 3,784 3,780 5,990 8,064 5,568


Cost of Reacting to Those Vulnerabilities…

Two major reactionary response to Software Vulnerabilities Patching System –or- Software Reconfiguration

“10% of machines will need to patched manually at a cost of $50/machine”. - Marc

Donner, executive director, Morgan Stanley

$50 * 500 = $25,000 (plus the cost of patch management software and patch testing). …and this is only for one patch in a 5000-node network…

Major software vendors have published their own “Hardening Guidelines” In essence, accept no system defaults and remove everything that you don’t need. However, the operating system vendor’s harden recommendation could also prevent some

application from working… More importantly, system and/or software reconfiguration tend to cost even more

than applying patches.

Reactive measures are not the answer!


Let’s be Proactive…

More Firewalls? More IDS/IPS? More Heuristics? More Security Widgets? More Consultants? Where is the end to this Madness!


Establish the Language…

Asset Control Threat Vulnerability Risk


Establish the Language - Asset

Asset Something an organization has determined to be valuable and must be protected. e.g. Resource, Process, Product, Infrastructure, Engineering Diagrams, and etc


Establish the Language - Safeguard

Control Product and/or processes employed to mitigate a specific threat( or a group of threats) to an

acceptable level e.g. Firewall, Locked Doors, Smart Cards, DRP/BCP Processes, Insurance, and etc.


Establish the Language - Threat

Threat Activity that represents possible dangers to the Assets e.g. Unexpected Destruction of Buildings, Loss of Power, Destructive Virus, Departure of key

Technical Staff Not possible to protect against all threats


Establish the Language - Vulnerability

Vulnerability Weakness that allow threats to materialize Absence of sufficient safeguard e.g. Poorly Designed Network, Improperly Configured Equipment, Poor Choice of Passwords,

Lack of Redundancy, and etc.


Establish the Language - Risk

Risk = Threat * Vulnerability * Assets Values The degree for which the vulnerability can be exploited by one or more previous identified threats Assessed either Quantitatively or Qualitatively


Threat Modeling

Overview of the methodology:1. Identify Assets

2. Identify Asset Access Mechanism

3. Create Architecture Overview

4. Identify Threats

5. Document Threats

6. Qualify Threats


Threat Modeling – a Walkthrough

ACME Inc. Financial Data Services Migrate from Global Dialer to Internet Client-Server application

• Client: Visual C++ on Win32 platforms

• Server: C++ on AIX

• Middleware: WebSphere MQ-Series

• Database: DB2



Step 1, Identify the Assets

The financial data



Step 2, Identify Asset Access Mechanism

The data is stored in database. And is created, modified, and queried by the end-user through the application server



Step 3, Create Architecture Overview

Windows 2000/XP/ME

Queue Manager

MQ API

Application Server

MQ Client

AIX

AIX

DB2

Application Client

Input Messages

Database Query

Request Queue 0

Request Queue 1

Request Queue 2

Request Queue 3

Request Queue 4

Request Queue 5

Request Queue 6

Request Queue 8

Request Queue 9

Request Queue 7

Firewall

FirewallFinancial Data

Client

Application Server

Database

Reply QueueOutput Messages



Step 4, Identify the Threats Eavesdropping Data during Transit Data Modification/Injection during Transit Single Points of Failure at

• Firewall

• Application Server

• Database Server Lack of communication control / physical separation to the DB2



Step 5, Document the Threats

Threat Description Eavesdropping Data during

Transit

Threat Target Message between Client and

Server

Risk ?????

Attack Technique Traffic Capturing

Countermeasure IPSEC Encryption



Step 6, Qualify the Threats The DREAD Model (4)

High = 3 Medium = 2 Low = 1

Damage Potential The attacker can subvert the security system; get full trust authorization; run as administrator; upload content.

Leaking sensitive information Leaking trivial information

Reproducibility The attack can be reproduced every time and does not require a timing window.

The attack can be reproduced, but only with a timing window and a particular race situation.

The attack is very difficult to reproduce, even with knowledge of the security hole.

Exploitability A novice programmer could make the attack in a short time.

A skilled programmer could make the attack, then repeat the steps.

The attack requires an extremely skilled person and in-depth knowledge every time to exploit.

Affected Users All users, default configuration, key customers

Some users, non-default configuration

Very small percentage of users, obscure feature; affects anonymous users

Discoverability Published information explains the attack. The vulnerability is found in the most commonly used feature and is very noticeable.

The vulnerability is in a seldom-used part of the product, and only a few users should come across it. It would take some thinking to see malicious use.

The bug is obscure, and it is unlikely that users will work out damage potential.



Threat: Eavesdropping Data during Transit Damage Potential = 2 Reproducibility = 3 Exploitability = 2 Affected Users = 3 Discoverability = 2

RISK = 2 + 3 + 2 + 3 + 2 = 12


Apply the Results of Threat Modeling

VPN DialerApplication

Windows 2000/XP/ME

Queue Manager

MQ API

Application Server

MQ Client

AIX

AIX

DB2

Application Client

IPSec VPN

Input Messages

Database Query

VPN ClientRequest Queue 0

Request Queue 1

Request Queue 2

Request Queue 3

Request Queue 4

Request Queue 5

Request Queue 6

Request Queue 8

Request Queue 9

Request Queue 7

VPN Gateway

Firewall

FirewallFinancial Data

Client

Application Server

Database

Reply QueueOutput Messages


Upcoming Advisories?


Time between Vulnerability Discovery and Patch Release

Microsoft Security Bulletin MS05-014 Vendor Notified on Feb-16-2004 (6)

Patch released on Feb-08-2005 (Previously released on Nov-2004)


The Zero-Day Problem…

Patches and workarounds are released after the fact

So is Anti-Virus signatures… So is Intrusion Prevention Signatures… What happens between an exploit for a

vulnerability is discovered and when one of the above is released?


Threat Modeling for the Zero-Day

Threat Modeling gives us: Identification of information assets Identification of threats and associated qualifications Basis for Risk Assessment

• Risk Mitigation Strategies

• Basis for implementation of Products & Processes

No more surprises, no more scrambling, and no more crisis.


Threat Modeling ≠ Silver Bullet

You can’t always eliminate the Risks! Effectiveness depends on Subject Matter Expertise on the implemented technology Evolution of Technology


Conclusion

Race between Reactive Countermeasures and Vulnerability Discovery is a fact of life

Systematic defense, build on thorough Threat Modeling methodology, is your best protection

There is still no silver bullet!


References

1. CERT Statistics: http://www.cert.org/stats/cert_stats.html

2. Marc Donner, “Bits, Bad Guys, and Bucks”, Volume Three, Issue Two, Secure Business Quarterly, http://www.sbq.com/sbq/patch/sbq_patch_mdonner.pdf

3. Dana Epp, “Dana Epp's ramblings at the Sanctuary: Understanding Threat Modeling”, retrieved on May 22, 2005, http://silverstr.ufies.org/blog/archives/000611.html

4. J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, Microsoft Corporation, “Threat Modeling”, retrieved on May 22, 2005, http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx?pull=/library/en-us/dnnetsec/html/thcmch03.asp

5. Carnegie Mellon Software Engineering Institute, “Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0”, retrieved on May 22, 2005 http://www.sei.cmu.edu/publications/documents/99.reports/99tr017/99tr017figures.html

6. Jouko Pynnonen (February, 2005). Posting to the BugTraq mailing list RE: “Internet Explorer zone spoofing with encoded URLs”, retrieved on May 22, 2005, http://www.securityfocus.com/archive/1/389859/2005-02-03/2005-02-09/0


Questions?

Documents

1 ® MD Manitoba Telecom Services Inc. Used under license. / Utilisé en vertu d’une licence. MTS Allstream Inc. proprietary. Use pursuant to company instructions