security archeticture

ISOL 536 Security Architecture and Design

Threat Modeling Session 6a

“Processing Threats”

Agenda

• When to find threats

• Playing chess

• How to approach software

• Tracking threats and assumptions

• Customer/vendor

• The API threat model

• Reading: Chapter 7

When to Find Threats

• Start at the beginning of your project

– Create a model of what you’re building

– Do a first pass for threats

• Dig deep as you work through features

– Think about how threats apply to your mitigations

• Check your design & model matches as you get close to shipping

Attackers Respond to Your Defenses

Playing Chess

• The ideal attacker will follow the road you defend

– Ideal attackers are like spherical cows — they’re a useful model for some things

• Real attackers will go around your defenses

• Your defenses need to be broad and deep

“Orders of Mitigation”

Order Threat Mitigation

1st Window smashing Reinforced glass

2nd Window smashing Alarm

3rd Cut alarm wire Heartbeat signal

4th Fake heartbeat Cryptographic signal integrity

By Example:

• Thus window smashing is a first order threat, cutting alarm wire, a third-order threat

• Easy to get stuck arguing about orders • Are both stronger glass & alarms 1st order

mitigations? (Who cares?!) • Focus on the concept of interplay between

mitigations & further attacks

How to Approach Software

• Depth first – The most fun and “instinctual”

– Keep following threats to see where they go

– Can be useful skill development, promoting “flow”

• Breadth first – The most conservative use of time

• Best when time is limited

– Most likely to result in good coverage

Tracking Threats and Assumptions

• There are an infinite number of ways to structure this

• Use the one that works reliably for you

• (Hope doesn’t work reliably)

Example Threat Tracking Tables

Diagram Element Threat Type Threat Bug ID

Data flow #4, web server to business logic

Tampering Add orders without payment checks

4553 “Need integrity controls on channel”

Info disclosure Payment instruments sent in clear

4554 “need crypto” #PCI

Threat Type Diagram Element(s) Threat Bug ID

Tampering Web browser Attacker modifies our JavaScript order checking

4556 “Add order- checking logic to server”

Data flow #2 from browser to server

Failure to authenticate

4557 “Add enforce HTTPS everywhere”

Both are fine, help you iterate over diagrams in different ways

Example Assumption Tracking

Assumption Impact if it’s wrong

Who to talk to

Who’s following up

Follow-up by date

Bug #

It’s ok to ignore denial of service within the data center

Availability will be below spec

Alice Bob April 15 4555

• Impact is sometimes so obvious it’s not worth filling out • Who to talk to is not always obvious, it’s ok to start out blank • Tracking assumptions in bugs helps you not lose track

• Treat the assumption as a bug – you need to resolve it

The Customer/Vendor Boundary

• There is always a trust boundary when:

– Your code goes to someone else’s (device/premises)

– Their data comes to your code

• All about human trust issues

• You need to think about it while deciding what happens over the data flow shown

Your software

Customer device

Your software

Your data center

Generic API Threat Model

• Perform security checks inside the boundary

• Copy before validation for purpose – Is http://evil.org/pwnme.html “valid”?

• Define the purpose for data, validate near that definition

• Manage error reporting

• Document what checks happen where

• Do crypto in constant time

• Address the security requirements for your API

Recap

• When to find threats

• Playing chess

• How to approach software

• Tracking threats and assumptions

• Customer/vendor

• The API threat model