What Could Possibly Go Wrong?

Threat Modelling in the 21st Century

TL;DR

  • What is a threat model?
  • Why should we have one?
  • How should we make one?
  • When should we do that?
  • How do we know when we’re done?
  • Does cloud change everything?

Threat Model(l)ing

  • Spot quiz :)

WAT?

An Attackers View of Your System

  • Their ‘business plan’ to attack your system at lowest risk and highest return on investment.

In Context..

  • Threat Model →
  • Risk Assessment →
  • Risk Management →
  • System Development Life Cycle (SDLC) →
  • Regulatory Compliance (ISO27k, PCI-DSS, GDPR)
  • Or because you want to stay in business :)

AKA..

  • Gartner’s ‘Adaptive Security Architecture’ (BS!)
  • Predict, Prevent, Detect, Respond (PPDR) →
  • Resilience modelling

WHY?

Effective Security

  • Well understood
  • Managed risks
  • Planned responses

Efficient Security

  • Prioritised, cost effective controls
  • Estimates of residual risk in business terms
  • Ready made evidence for compliance audits

HOW?

“Think Like an Attacker”

  • Build a model of attacks
  • Estimate cost to attacker
  • Estimate impact to our business
  • Prioritise threats on highest impact/cost ratio
  • Take into risk assessment, control design..

Outside In Modelling

  • Threat actors, motivations
  • Target data and flows across..
  • Boundaries.
  • ‘Crown Jewels’ model

Inside Out Modelling

  • Components
  • Weaknesses
  • Networks
  • Microsoft STRIDE

Samples!

Attack Trees

  • Created by Bruce Schneier in 1999
  • Common in Outside In models
  • Effective when system is a well understood ‘White Box’

Iterative Refinement

  • Created by NCC during consulting work
  • Common in Inside Out models
  • ‘Can’t make it worse’ principle :)
  • Copes with less well understood ‘Grey Box’ systems

WHEN?

Greenfield: Part of the SDLC

  • First model → during first design cycle!
  • Refreshed → material changes in…
    • System functionality or implementation
    • External threat intelligence

Brownfield: Introduce to the SDLC

  • As soon as possible within SDLC
  • Always better to have a model than nothing!
  • Provides risk information to system owners
  • Incremental modelling reduces impact of introduction

DONE?

Model Contains..

  • Quantified risks
  • Testable attacks
  • Operational impacts

Model Checking

  • Security Testing
    • Red / Blue teaming
    • Purple teaming
  • Operational feedback
    • Monitoring behaviour

CLOUD?

Can we SEP it?

  • Somebody Else’s Problem: AWS/Google/Microsoft?
  • Nope!
    • Your architecture, your choice of components, your code
    • New actors & risks
    • New controls though :)

ME :)

YOU?

  • Questions?