Threat Modeling

There are a lot of ways to do it

  • STRIDE
  • DREAD
  • PASTA
  • OCTAVE
  • Kill Chain
  • VAST
  • Trike
  • Attack Graphs
  • etc etc etc

What's the point?

  • We want to be safer
  • We don't want to waste time
  • We don't want unnecessary complexity
  • Important to know what risks we can mitigate, want to mitigate, or accept

Threat Model

  • What are our assets?
  • Where are our attackers?
  • What paths exist between attacker and assets?
  • What are our boundaries?
  • What risks will we accept?

(later stage) Who are our attackers?

What's a boundary?

  • Any limitation imposed on an attacker with a non-neglible cost to bypass.
  • What counts as a boundary may depend on attacker positioning.
  • Every boundary has a cost to bypass.
  • Determining cost is something you can ask your security friends to help you with - what attackers are willing to spend, capable of performing, etc, is what many security professionals spend their time learning about

(lock)

Vibes based - locks are safe, right?

(locks)

locks are safe, more locks are safer?

"defense in depth"

(locks)

Vibes are cool but we can't ignore costs

more locks = more complexity

(gold)

What are we protecting?

(gold)

Where is our attacker?

  • Outside?
  • Maybe inside! But outside is a good place to start

(gold)

What paths exist?

(gold)

What are our boundaries?

  • Lock on door

(gold)

Risks?

Open Window

Open Door

  • Sturdy
  • Locked

Attack Graph

Tines Command Runner

  • Accepts Python code from customer
  • Executes Python code as Linux user based on id of team
  • Runs inside of a Docker container
  • Designed for self hosted - multiple teams, one customer

Docker Container - tines-command-runner

TCR

TCR

user 2000

python harness - uid 2001

python harness - uid 2002

python harness - uid 2003

Where's the attacker?

TCR

TCR

user 2000

python harness - uid 2001

python harness - uid 2002

python harness - uid 2003

Compromised team member/ run script

Where do attackers want to go?

TCR

TCR

user 2000

python harness - uid 2001

python harness - uid 2002

python harness - uid 2003

Where do attackers want to go?

Host

TCR

TCR

Postgres access?

Tines App?

Users? SSH Keys? etc

Logging?

Kernel Exploit

Misconfigured Container

  • Follow best practices
  • Pentest
  • Patch
  • Seccomp

Attack Graph

Malicious Run Script

Host Access

TCR Exploit

  • Limited access to TCR

Threat Model

  • What are our assets?
  • Where are our attackers?
  • What are our boundaries?
  • What risks do we accept?

Cloud

  • All customer assets, Tines assets
  • Python Harness from free user account
  • Docker, Linux DAC
  • Full responsibility is on Tines

Self Hosted

  • Single customer's assets
  • Python Harness for already compromised customer user
  • Docker, Linux DAC
  • Shared responsibility with customer

Threat Model

  • What are our assets?
  • Where are our attackers?
  • What are our boundaries?
  • What risks do we accept?

Cloud

  • All customer assets, Tines assets
  • Python Harness from free user account
  • Docker, Linux DAC
  • Full responsibility is on Tines
  • Cross-Tenancy violations
  • Easier attacker positioning
  • Same boundaries
  • Lower tolerance for risk

New boundaries?

  • Cost of escaping Fargate is much higher than Docker, mitigates accessing host
  • What if we reset the state of the container after every execution?

 

Customers share the TCR but these boundaries would mitigate risks if they work

Path to access host is mitigated

TCR

TCR

Postgres access?

Tines App?

Users? SSH Keys? etc

Logging?

Path across executions is mitigated

TCR

TCR

TCR

TCR

Execution 1

Execution 2

Wipe

Some problems

Theory

TCR

TCR

Postgres access?

Tines App?

Users? SSH Keys? etc

Logging?

Reality

TCR

TCR

Host

Firecracker

Docker

We need to restart the entire VM, otherwise attacker can just escape to guest OS

Theory

TCR

TCR

TCR

TCR

Execution 1

Execution 2

Wipe

Reality

TCR

TCR

TCR

TCR

Execution 1

Execution 2

Wiping a container is really hard in a way that provides a real boundary

Solution?

  • Restart the entire VM - guess access won't matter, "wipe" will be sufficient
    • Cost is high
    • Complexity is high

Lambdas!

  • Cloud version already uses a lambda per run script
  • Lambdas can run docker containers
  • Just do the same thing?