Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Attack Trees - A different approach to doing security

Attack Trees - A different approach to doing security

“Is our system secure?”

No, it’s not.
There’s no absolutely secure system.

Apps get broken all the time, often in ways its designers never even imagined. Attacks thought to be beyond the ability of mortal men yesterday become common thing today. So the term "security" doesn't have any real meaning unless we can answer questions like "Secure from whom?" or "Secure for how long?"

But in order to answer all these questions, we need an efficient and understandable way to model threats against our system. Enter attack trees.

Attack trees provide us with a new way of understanding how our system might be attacked and how to prioritize security measures to be implemented. It also makes it easy for product managers and technical people to have a conversation about the prioritization of security features, and to understand whether a new feature will affect the security of the system. Finally, attack trees are designed to ensure that the whole team has visibility and even ownership of the security process for the product.

In this session we’ll learn how to approach our system in a new way, how to think like an attacker, how to document, evaluate and rate the threats, and how to communicate them effectively to the whole team.

Hrvoje Crnjak

August 23, 2018
Tweet

More Decks by Hrvoje Crnjak

Other Decks in Technology

Transcript

  1. Attack Trees
    A different approach to doing
    security
    JavaCro Rovinj, Croatia – May 2018
    Hrvoje Crnjak
    Scala developer @ Oradian

    View full-size slide

  2. About Oradian …
    WE’RE HIRING!
     What we do
     Banking software
     Written in Scala
     More info at
     www.oradian.com

    View full-size slide

  3. Do you even threat model, bro?

    View full-size slide

  4. Threat model my house…
     Assets
     Stereo
     TV
     Laptop
     Attackers
     Thief
     Neighbor
     Someone I owe money
     Ways to break in
     Break window
     Pick a lock
     Find the key under the mat

    View full-size slide

  5. Threat model my web service…
     Assets
     Client info
     Account info
     Money
     Attackers
     Hacker
     Employee
     Employee of service provider
     Ways to attack
     Steal credentials
     Bypass security
     Hack underlying DB

    View full-size slide

  6. We constantly threat model…
    We’re doing it implicitly

    View full-size slide

  7. What we need is a way to…
    Implicit approach
    Structured approach

    View full-size slide

  8. Structured threat modeling
    4 basic questions
    1. What am I building?
    2. What can go wrong?
    3. What am I going to do about it?
    4. Did I do a decent job with questions 1-3?
    9

    View full-size slide

  9. Structured threat modeling
    4 basic questions
    1. What am I building?
     A: model of the system
    2. What can go wrong?
    3. What am I going to do about it?
    4. Did I do a decent job with questions 1-3?

    View full-size slide

  10. Structured threat modeling
    4 basic questions
    1. What am I building?
     A: model of the system
    2. What can go wrong?
     A: model of the possible attacks
    3. What am I going to do about it?
    4. Did I do a decent job with questions 1-3?

    View full-size slide

  11. Structured threat modeling
    4 basic questions
    1. What am I building?
     A: model of the system
    2. What can go wrong?
     A: model of the possible attacks
    3. What am I going to do about it?
     A: analyze, categorize, mitigate
    4. Did I do a decent job with questions 1-3?

    View full-size slide

  12. Structured threat modeling
    4 basic questions
    1. What am I building?
     A: model of the system
    2. What can go wrong?
     A: model of the possible attacks
    3. What am I going to do about it?
     A: analyze, categorize, mitigate
    4. Did I do a decent job with questions 1-3?
     A: no simple answer

    View full-size slide

  13. Structured threat modeling
    4 basic questions
    1. What am I building?
     A: model of the system
    2. What can go wrong?
     A: model of the possible attacks (attack trees)
    3. What am I going to do about it?
     A: analyze, categorize, mitigate
    4. Did I do a decent job with questions 1-3?
     A: no simple answer

    View full-size slide

  14. Structured threat modeling
    4 basic questions
    1. What am I building?
     A: model of the system
    2. What can go wrong?
     A: model of the possible attacks (attack trees)
    3. …

    View full-size slide

  15. 1) Modeling the system
    Diagram

    View full-size slide

  16. 1) Modeling the system
    Diagram
     UML with some alterations

    View full-size slide

  17. 1) Modeling the system
    Diagram
     UML with some alterations
     Swim lane

    View full-size slide

  18. 1) Modeling the system
    Diagram
     UML with some alterations
     Swim lane
     State

    View full-size slide

  19. 1) Modeling the system
    Diagram
     UML with some alterations
     Swim lane
     State
     Data flow
     Problems tend to follow the data flow

    View full-size slide

  20. Data flow diagram
     Four elements

    View full-size slide

  21. Data flow diagram
     Four elements
     External entity
     Anything outside of your control
     Example: user (anonymous, customer, admin) or code outside your control

    View full-size slide

  22. Data flow diagram
     Four elements
     External entity
     Anything outside of your control
     Example: user (anonymous, customer, admin) or code outside your control
     Process
     Any running code
     Example: some service (accounting, shipping, authentication)

    View full-size slide

  23. Data flow diagram
     Four elements
     External entity
     Anything outside of your control
     Example: user (anonymous, customer, admin) or code outside your control
     Process
     Any running code
     Example: some service (accounting, shipping, authentication)
     Data Flow
     Communication between elements
     Example: customer sends purchase order to the system

    View full-size slide

  24. Data flow diagram
     Four elements
     External entity
     Anything outside of your control
     Example: user (anonymous, customer, admin) or code outside your control
     Process
     Any running code
     Example: some service (accounting, shipping, authentication)
     Data Flow
     Communication between elements
     Example: customer sends purchase order to the system
     Data Store
     Anything that stores data
     Example: DB, registry, file

    View full-size slide

  25. Quick recap…

    View full-size slide

  26. Example: Online pizza place

    View full-size slide

  27. Possible Attacker Goals?
     Free lunch
     Steal confidential data
     Deface website
     Bring service down
     Next step
     Create attack trees for attacker goals

    View full-size slide

  28. Attack tree
     Tree-like diagrams showing how an attack goal might be
    achieved
     Creator
     Bruce Schneider, 1999
     Elements
     Root node
     The attacker’s goal
     All other nodes
     Different steps to achieving the goal

    View full-size slide

  29. Attack tree
     Elements
     Root node
     The attacker’s goal
     All other nodes
     Different ways to achieve the goal
     Rules
     2 types of node relationship
     OR relationship
     Node satisfied when at least one child node is satisfied
     AND relationship
     Node satisfied when ALL child nodes are satisfied
     Attack occurs when
     Root node is satisfied

    View full-size slide

  30. The “free lunch” attack
     One unique path from root to leaf node
     One attack scenario

    View full-size slide

  31. The “deface website” attack

    View full-size slide

  32. What next?!
     Run attack scenarios through system model
     Figure out what’s plausible and what’s not
     Assign measurable values to nodes
     Is it plausible?
     YES, NO, probability
     The cost of doing it
     Manpower, processing power, bandwidth, …
     Skillset required to do it
     Impact
     Prioritize
     Based on the parameters you wrote down and your requirements
     Mitigate

    View full-size slide

  33. Should you do it?
    Pros
     You get the big picture
     Threat model becomes explicit
     Everyone can see and understand
    security concerns
     Provides a formal way of doing
    security
     You get to catch problems early
    Cons
     You need to put in the work
     Hard to start without an
    experienced threat modeler on
    board

    View full-size slide

  34. A piece of wisdom…
    “All models are wrong,
    but some are useful”
    George Box, 1976

    View full-size slide

  35. Thanks for your time!
    Questions?

    View full-size slide