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.

Transcript

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

   View Slide

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

   View Slide

3. Do you even threat model, bro?
   

   View Slide

4. YOU DO!
   

   View Slide

5. 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 Slide

6. 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 Slide

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

   View Slide

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

   View Slide

9. 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 Slide

10. 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 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?
    4. Did I do a decent job with questions 1-3?
    

    View 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?
    

    View 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
    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 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. 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 Slide

15. 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 Slide

16. 1) Modeling the system
    Diagram
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. Data flow diagram
     Four elements
    

    View Slide

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

    View 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)
    

    View 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
    

    View Slide

25. 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 Slide

26. Quick recap…
    

    View Slide

27. Example: Online pizza place
    

    View Slide

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

    View Slide

29. 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 Slide

30. 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 Slide

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

    View Slide

32. The “deface website” attack
    

    View Slide

33. 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 Slide

34. 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 Slide

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

    View Slide

36. Thanks for your time!
    Questions?
    

    View Slide