Threat Modeling

pinkyk
Threat_Modeling_16wk_session_2a.pdf

ISOL 536 Security Architecture and Design

Threat Modeling Session 2a

“Strategies for Threat Modeling”

Agenda

• What are you building

• What can go wrong?

• Reading: Chapter 2

What Are You Building?

• Create a model of the software/system/technology

• A model abstracts away the details so you can look at the whole

– Diagraming is a key approach

– Mathematical models of software are rare in commercial environments

What Are You Building?

• Whiteboard diagrams are a great way to start

• Software models for threat modeling usually focus on data flows and boundaries

• DFDs, “swim lanes”, state machines can all help (next slides)

What Are Some Modeling Methods?

• Whiteboard diagrams

• Brainstorming

• Structured (“formal”) diagrams

– Data flow diagrams

– Swim lanes

– State machines

• Mathematical representations of code

Trust Boundaries

• Sometimes left implicit in development – Effective threat modeling requires making boundaries

explicit

• A trust boundary is everywhere two (or more) principals interact – Principals are UIDs (unix)/SIDs (Windows) etc. – Apps on mobile platforms – (Two or more)

• Need to be enforced in some way – Best to rely on the OS – Sometimes not possible (e.g., building a database)

Trust Boundaries

• All interesting boundaries are semi-permeable – Air gaps

– Firewalls

– Require policy mechanisms (which are hard)

• Formal methods help build boundaries – Isolation

– Type safety

– Policy languages

– Reference monitors/kernels

DFD (Data Flow Diagram)

• Developed in the early 70s, and still useful

– Simple: easy to learn, sketch

– Threats often follow data

• Abstracts programs into:

– Processes: your code

– Data stores: files, databases, shared memory

– Data flows: connect processes to other elements

– External entities: everything but your code & data Includes people & cloud software

– Trust boundaries (now made explicit)

Data Flow Diagram (Example)

Swim Lane Diagrams

• Show two or more entities communicating, each “in a lane”

• Useful for network communication

• Lanes have implicit boundaries between them

State Machines

• Helpful for considering what changes security state

– For example, unauthenticated to authenticated

– User to root/admin

• Rarely shows boundaries

How to Threat Model (Summary)

• What are you building?

• What can go wrong?

• What are you going to do about it?

• Check your work on 1-3