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
2. About Oradian … WE’RE HIRING!  What we do  Banking software  Written in Scala  More info at  www.oradian.com
3. Do you even threat model, bro?
4. YOU DO!
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
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
7. We constantly threat model… We’re doing it implicitly
8. What we need is a way to… Implicit approach Structured approach
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
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?
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?
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?
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
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
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. …
16. 1) Modeling the system Diagram
17. 1) Modeling the system Diagram  UML with some alterations
18. 1) Modeling the system Diagram  UML with some alterations  Swim lane
19. 1) Modeling the system Diagram  UML with some alterations  Swim lane  State
20. 1) Modeling the system Diagram  UML with some alterations  Swim lane  State  Data flow  Problems tend to follow the data flow
21. Data flow diagram  Four elements
22. Data flow diagram  Four elements  External entity  Anything outside of your control  Example: user (anonymous, customer, admin) or code outside your control
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)
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
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
26. Quick recap…
27. Example: Online pizza place
28. Possible Attacker Goals?  Free lunch  Steal confidential data  Deface website  Bring service down  Next step  Create attack trees for attacker goals
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
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
31. The “free lunch” attack  One unique path from root to leaf node  One attack scenario
32. The “deface website” attack
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
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
35. A piece of wisdom… “All models are wrong, but some are useful” George Box, 1976
36. Thanks for your time! Questions?