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

Fortifying Your Defenses with Threat Modeling

Fortifying Your Defenses with Threat Modeling

Properly securing your applications and data require an understanding of the threats facing them. Threat modeling is the methodology for identifying and quantifying the threats your application can and will face. There are a number of resources available for performing a threat model but this session will get you started building a strategy from nothing.

Eric Mann

May 21, 2019
Tweet

More Decks by Eric Mann

Other Decks in Programming

Transcript

  1. Barbarians at the Gate - Fortifying Your Defenses with Threat

    Modeling Adam Englander Ijeoma Ezeonyebuchi Eric Mann
  2. Hello. Adam Englander Architect, iovation Ijeoma Ezeonyebuchi Mobile Quality Assurance

    Engineer, NPR Eric Mann Director of Engineering, Vacasa
  3. Today’s Session What is Threat Modeling? What is the Process?

    S.T.R.I.D.E. D.R.E.A.D. Practical Illustrations Action Items you can Implement Today
  4. What is Threat Modeling? Threat modeling is a process by

    which potential threats ... can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view. - Wikipedia
  5. What is Threat Modeling? Threat modeling is a process by

    which potential threats ... can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view. - Wikipedia
  6. What is the Process? 01 Document everything you possibly can

    about your application, its use cases, and the users interacting with it.
  7. What is the Process? 01 Document everything you possibly can

    about your application, its use cases, and the users interacting with it. 02 Map out your application - both process flows and data flows.
  8. What is the Process? 01 Document everything you possibly can

    about your application, its use cases, and the users interacting with it. 02 Map out your application - both process flows and data flows. 03 Identify system dependencies.
  9. What is the Process? 01 Document everything you possibly can

    about your application, its use cases, and the users interacting with it. 02 Map out your application - both process flows and data flows. 03 Identify system dependencies. 04 Identify threats.
  10. Identify threats - Spoofing • Phishing - sending email impersonating

    another entity to capture credentials • Session take over - presenting yourself as a currently authenticated user • Logging in with another user’s credentials
  11. Identify threats - Tampering • SQL Injection • Malicious code

    injection • Man-in-the-middle (MITM) attack
  12. Identify threats - Repudiation • Log saturation prevents your ability

    to find bad behavior due to the volume of data • Log disabling prevents logs from being written in the first place • Log manipulation alters the logs to mask the user performing the attack
  13. Identify threats - Information Disclosure • Leaking sensitive data via

    standard means like direct object access • Leaking sensitive data via code repositories • Leaking sensitive data via SQL injection
  14. Identify threats - Denial of Service • DDoS via botnet

    • DoS via load testing tools • DoS via code or data deletion
  15. Identify threats - Elevation of Privilege • Improperly implemented access

    control - hiding admin URLs and not checking user’s privileges • Providing ability for user to active “GOD” mode
  16. Identify threats - DREAD Risk Ratings Score each of the

    following from 1-10 • Damage Potential • Reproducibility • Exploitability • Affected Users • Discoverability
  17. Identify threats - Damage Potential • What is the financial

    impact of the threat? • What is the potential impact on your customer base?
  18. Identify threats - Reproducibility • Can the threat be triggered

    in a web browser, or does it require special skills? • Does the system have to be in a particular state for the attack to be reproduced? • Who would likely be able to reproduce this attack.
  19. Identify threats - Exploitability • What does someone need to

    know to leverage this weakness? • What skills or tools are required to execute the exploit? • Who has the knowledge or skills required?
  20. Identify threats - Affected Users • Which classes of users

    are affected? • How many users are affected?
  21. Identify threats - Discoverability • Is the weakness, threat, or

    vulnerability published in the public eye? • Who would be most likely to discover this vulnerability in the wild? • How much “insider knowledge” would be required to discover this vulnerability?
  22. Practical Illustrations • Add threat modeling to the definition of

    done • Starting from scratch with a new application, service, or feature • Paying down the security debt on existing applications • Continuous review
  23. Practical Illustrations: Definition of Done • Aligns everyone to the

    expectations a. Business owners b. Project management / scrum masters c. Developers d. QA • Ensures the time needed for threat modeling is included in estimates • Ensures it is always done • Helps reinforce the security mindset
  24. Practical Illustrations: Starting from Scratch • Threat model as part

    of your design stage a. Design b. Threat Model c. Adjust Design d. GOTO b • Revisit the end result and threat model any in-development changes
  25. Practical Illustrations: Paying Down Debt • We all have some

    security debt a. Legacy code b. Uneven security practices c. Last minute crucial request from customers d. Insufficient threat modeling • Identify the gaps • Have a plan for paying down your debt • Track progress of the plan • Review progress at regular intervals
  26. Practical Illustrations: Continuous Review • You need to continuously revisit

    threats identified as fully or partially mitigated to ensure they are still mitigated • Refactor your threat models - think of threat modeling like writing code a. The skills you and your team have today are far better than the past b. You use tools better than you have before c. You understand the product and its dependencies better d. Your team changes and acquires different perspectives that can improve the product e. You should constantly improve the product base in the items above
  27. Action Items you can Implement Today • Learn to think

    like an attacker • Promote and reward self-reporting • Start a Bug Bounty