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
  2. About Oradian … WE’RE HIRING!  What we do 

    Banking software  Written in Scala  More info at  www.oradian.com
  3. 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
  4. 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
  5. 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
  6. 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?
  7. 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?
  8. 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?
  9. 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
  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 (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
  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 (attack trees) 3. …
  12. 1) Modeling the system Diagram  UML with some alterations

     Swim lane  State  Data flow  Problems tend to follow the data flow
  13. Data flow diagram  Four elements  External entity 

    Anything outside of your control  Example: user (anonymous, customer, admin) or code outside your control
  14. 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)
  15. 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
  16. 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
  17. Possible Attacker Goals?  Free lunch  Steal confidential data

     Deface website  Bring service down  Next step  Create attack trees for attacker goals
  18. 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
  19. 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
  20. The “free lunch” attack  One unique path from root

    to leaf node  One attack scenario
  21. 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
  22. 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