CSC 382: Computer SecuritySlide #1 CSC 382: Computer Security Threat Modeling

CSC 382: Computer Security Slide #1

CSC 382: Computer Security

Threat Modeling


Topics

1. What is Threat Modeling?

2. Purpose of Threat Modeling.

3. Threat Modeling Process1. Understand adversary’s view of system.

2. Characterize security of system.

3. Evaluate threats.


What is Threat Modeling?

Assessing security risks of a software system from an adversary’s perspective.


Goals of Threat Modeling

1. Understand threats to guard against during requirements analysis.

2. Provide basis for which security mechanisms to include during design.

3. Verify security of system design.4. Provide basis for prescribing secure

implementation practices.5. Provide basis for testing system security

after implementation.


Threat Modeling Process

1. Understand adversary’s view of system.

2. Characterize security of system.

3. Evaluate threats.


Understanding the Adversary’s View

1. Identify System Assets.– System resources that an adversary might attempt to

access, modify, or steal.

– Ex: credit cards, network bandwidth, user access.

2. Identify Entry Points.– Any location where data or control transfers between

the system being modeled and another system.

– Ex: network sockets, RPCs, web forms, files

3. Determine Trust Levels.– Privileges external entities have to legitimately use

system resources.


Identify System Assets

• User login data• User personal data• Web process resources

– Execute code as web server– Network/disk resources

• Application resources• Database server resources

– Access to stored data

• Organization’s reputation


Discover Entry Points

Any method for system to accept input

Example: http://cs.nku.edu/ctrl.psp?pg=login– Web server: cs.nku.edu

• All network protocols that can access host

• Web server specific attacks

– ctrl.psp• Your controller application

– pg=login• The login subsystem invoked by controller

http://cs.nku.edu/ctrl.psp?pg=login


Analyze Entry Points

1. Are you missing any potential back door entry points?

– What if attacker is on the web server?– What if attacker between web and db servers?

2. How does system distinguish between bad and good input?

3. Can system distinguish a request from a legitimate client from a replay attack?


Trust LevelsResources with higher trust levels are accessible to fewer users, but higher trust levels offer access to awider range of resources.

Trust Levels– Remote Unauthenticated Users

– Remote Authenticated User

– Remote Application Admin User

– Web Administrator

– Web Server Process

– DB Administrator


Characterize System Security

1. Use and misuse scenarios.– How do users use the system to fulfill needs?– How could an adversary use these system interfaces to

attack the system?

2. Identify assumptions and dependencies.– How does system security depend on external

systems?– What assumptions do components make about data or

control transfers with other components?

3. Model the system.– Model how system processes data from each entry

point using tools like DFDs.


Use Case Example

UC 1: Login to Web StorePrimary Actor: CustomerStakeholders and Interests:

– Customer: Wants to purchase products.Preconditions: Customer has web access.Postconditions: Customer has access to their

account, with the ability to pay for and ship products.

Summary: Customer gains access to system using an assigned username and password.


Misuse Case Example

MUC 1: Sniff PasswordPrimary Actor: AttackerStakeholders and Interests:

– Attacker: Wants to obtain user credentials.Preconditions: Attacker has access to a machine on

network path between user and system.Postconditions: Attacker has obtained one or more

valid usernames and passwords.Summary: Attacker obtains and later misuses

passwords to gain unauthorized access to system.


Misuse Case Example

Basic Flow:1. Attacker installs network sniffer.

2. Sniffer saves all packets which contain strings matching “Logon,” “Username,” or “Password.”

3. Attacker reads sniffer logs.

4. Attacker finds valid username/password in log.

5. Attacker uses sniffed password to access system.


Misuse Case Example

Alternate Flows:

1a. Attacker not on path between user and system:

1. Attacker uses ARP poisoning or similar attack to redirect user packets through his system.

1b. Customer uses wireless connection. 1. Attacker drives to customer location.

2. Attacker uses wireless sniffer to intercept passwords.

4a. Attacker finds no passwords in log 1. Continue sniffing until a password is found.


Dependencies and Assumptions

What does the system depend on or trust?– Power– Network– Filesystem– Shared libraries– Database– Authentication service– Auditing service– What other programs does system run?


Data Flow DiagramsVisual model of how system processes data.Hierarchical

– Level 0: Models whole system.– Level 1: Models subsystems, …

1. SystemClient

Report System

Database


Level 0 DFD Example

UserUser

AdminAdmin

AuthnAuthnEngineEngine

AuditAuditEngineEngine

ServiceService

MnmgtMnmgtToolToolCredentialsCredentials

Data FilesData Files

Audit DataAudit DataRequestRequest

ResponseResponse

Aut

hnA

uthn

Req

uest

Req

uest

AuthnAuthn

InfoInfo

Set/GetSet/GetCredsCreds

RequestedRequestedFile(s)File(s)

Audit DataAudit Data

SetSet

User DataUser Data

Verify

Verify

User D

ata

User D

ata

Aud

itA

udit

Req

uest

sR

eque

sts

Aud

itA

udit

Info

Info

Aud

itA

udit

Rea

dR

ead

Aud

itA

udit

Writ

eW

rite

GetGetCredsCreds


DFD Exercise

Draw a level 1 data flow diagram of an email service. Don’t forget to include:– Users receiving and sending mail.– Mail server interactions with other mail servers

for non-local messages.– Message store interactions.– Error conditions: What if a user sends a

message to a remote server that’s currently down? You should retry the send later, without bothering the user until X retries have failed.


Evaluate Threats

Identify Threats– For each entry point, determine how an

adversary may attempt to affect an asset.– Based on asset, predict what adversary would

try to do and what his goals would be.

Analyze Threats.– Decompose threats into individual, testable

conditions using techniques like attack trees.– Evaluate risk of threat with DREAD categories.


Identify Threats1. Can an unauthorized network user view

confidential information such as addresses or passwords?

2. Can an unauthorized user modify data like payments or purchases in the database?

3. Could someone deny authorized users access to the application?

4. Could an authorized user exploit a feature to raise their privileges to administrator level?


STRIDE Threat CategorizationSpoofing

ex: Replaying authentication transaction.Tampering

ex: Modifying authentication files to add new user.Repudiation

ex: Denying that you purchased items you actually did.Information disclosure

ex: Obtaining a list of customer credit card numbers.Denial of service

ex: Consuming CPU time via hash algorithm weakness.Elevation of privilege

ex: Subverting a privileged program to run your cmds.


Analyze ThreatsDecompose threats into individual, testableconditions using attack trees.

Attack Trees– Hierarchical decomposition of a threat.– Root of tree is adversary’s goal in the attack.– Each level below root decomposes the attack

into finer approaches.– Child nodes are ORed together by default.– Special notes may indicate to AND them.


Attack Trees—Graph Notation

Goal: Read file from password-protected PC.

Read File

Get Password Network Access Physical Access

Search Desk Social Engineer Boot with CD Remove hard disk


Attack Trees—Text NotationGoal: Read message sent from one PC to another.

1. Convince sender to reveal message.1.1 Blackmail.1.2 Bribe.

2. Read message when entered on sender’s PC.1.1 Visually monitor PC screen.1.2 Monitor EM radiation from screen.

3. Read message when stored on receiver’s PC.1.1 Get physical access to hard drive.1.2 Infect user with spyware.

4. Read message in transit.1.1 Sniff network.1.2 Usurp control of mail server.


Evaluate Risk with DREADDamage Potential

– Extent of damage if vulnerability exploited.Reproducibility

– How often attempt at exploitation works.Exploitability

– Amount of effort required to exploit vulnerability.Affected Users.

– Ration of installed instances of system that would be affected if exploit became widely available.

Discoverability– Likelihood that vulnerability will be discovered.


Quantifying ThreatsCalculate risk value for nodes in attack tree

– Start at bottom of tree.

– Assign a number 1-10 to each DREAD item.

– Assign average of numbers to node.

– Propagate risk values to parent nodes.• Sum risk values if child nodes are ANDed together.

• Use highest risk value of all children if nodes are ORed together.

Alternate technique: monetary evaluation– Estimate monetary value to carry out attacks.

– Propagate values to parent nodes as above.

– Note: smaller values are higher risks in this method.


Attack Tree Exercise

Create an attack tree for the reading a message stored on the mail server that you described in the DFD exercise.– Consider all entry points.– While you’re starting as an unauthorized

network user, consider all trust levels in constructing your tree, with gaining the required trust level to conduct your attack being one of your subgoals.


Key Points1. Goals of Threat Modeling

– Requirements, Design, Implement, Testing.2. Threat Modeling Process

1. Understand adversary’s view of system.2. Characterize security of system.3. Evaluate threats.

3. Threat-modeling Techniques– Attack Trees– Data Flow Diagrams– STRIDE categorization– DREAD risk evaluation– Quantifying risk.


References1. Bishop, Matt, Introduction to Computer Security,

Addison-Wesley, 2005.2. Graff, Mark and van Wyk, Kenneth, Secure Coding:

Principles & Practices, O’Reilly, 2003.3. Howard, Michael and LeBlanc, David, Writing Secure

Code, 2nd edition, Microsoft Press, 2003.4. Schneier, Bruce, Secrets and Lies, Wiley, 2000.5. Swiderski, Frank and Snyder, Window, Threat Modeling,

Microsoft Press, 2004.6. Viega, John, and McGraw, Gary, Building Secure

Software, Addison-Wesley, 2002.7. Wheeler, David, Secure Programming for UNIX and

Linux HOWTO, http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html, 2003.

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html

Documents

CSC 382: Computer SecuritySlide #1 CSC 382: Computer Security Threat Modeling