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

Threat Modelling

Threat Modelling

Presentation used to introduce new developers to threat modelling concepts and guide the threat modelling of a specific application.

andresriancho

January 09, 2019
Tweet

More Decks by andresriancho

Other Decks in Programming

Transcript

  1. Threat Modelling
    January 2019

    View full-size slide

  2. Objectives
    ● Convince you that threat modelling is an important part of
    the SDLC
    ● Learn how to do threat modelling
    ● Apply threat modelling to a project and give the team the
    guidelines to apply it to any other project

    View full-size slide

  3. /me
    ● Application and cloud security expert
    ● developer
    ● Open source evangelist
    ● w3af project leader
    ● Independent security consultant

    View full-size slide

  4. Agenda
    ● Introduction
    ○ What is a threat model?
    ○ Why should we create a threat model?
    ○ When should it be done?
    ○ Who should do it?
    ● Core concepts and process
    ○ Data flow diagram
    ○ Process flow diagram
    ○ Threat agents
    ○ Attack tree
    ● Closing the circle
    ○ Identify mitigations and assign owners
    ○ Make sure mitigations are in place

    View full-size slide

  5. What: Something you did many times
    ● Threat modeling is something you've already done
    hundreds of times, you just don't know the name for it
    ● Today we'll focus on improving what you've done by
    formalizing the process and practicing

    View full-size slide

  6. What: Critical security thinking
    ● Threat modeling is a process by which potential threats,
    such as structural vulnerabilities can be identified,
    enumerated, and prioritized – all from a hypothetical
    attacker’s point of view
    ● Critical thinking about application security
    ● Guided application security brainstorming
    ● Not meant to identify implementation bugs such as SQL
    injection, Cross-Site Scripting, etc. There are other tools and
    processes which aim to uncover those.

    View full-size slide

  7. Why: Identify issues in design phase
    ● Identify the application's security requirements during the
    design phase to create secure code later
    ● Helps identify security weaknesses in the application's
    architecture and use-cases
    ● Aims to reduce the number of security issues that will have
    to be fixed after the software is released
    ● Fixing things earlier in the SDLC is cheaper, both in effort
    and money. Use threat modelling when you want to work
    less and be more efficient.

    View full-size slide

  8. When: Design phase
    ● In order to have the highest ROI the threat
    modelling process should be performed during the
    design phase.
    ● Threat modelling can be performed during any
    other phase (such as implementation) where
    issues will be found but they are already part of
    the code and will be harder to solve.

    View full-size slide

  9. Who: Devs, security, QA, architects
    ● The three main actors in the threat modelling
    process are: developers, security experts and
    product owners.
    ● But the perspective of fraud departments, SOC
    (security operations center), customer service, and
    other areas is equally important.

    View full-size slide

  10. Data flow diagram
    Data in transit and rest

    View full-size slide

  11. Data flow diagram
    ● A data flow diagram (DFD) is a graphical representation of
    the flow of data through an information system
    ● We'll try to answer:
    ○ How does the application receive data?
    ○ Where does the application store data?
    ○ How does the application communicate with other
    APIs and databases? Is that communication
    encrypted?
    ○ Does the application communicate with third parties
    (not controlled by our company)?

    View full-size slide

  12. Data flow diagram: Example

    View full-size slide

  13. Data flow diagram: Example

    View full-size slide

  14. Data flow diagram
    ● Identify sensitive data such as:
    ○ Users and passwords
    ○ Credit cards
    ○ Loyalty points
    ○ Account association records
    ● Are there compliance requirements for this application such
    as PCI or HIPAA?
    ● Is data in transit encrypted? What about data at rest?

    View full-size slide

  15. Data flow diagram
    ● Identify attack surface and trust boundaries:
    ○ What is outside our frontend firewall?
    ○ What can be consumed by an internal adversary?
    ○ What can be consumed by a partner?
    ● Make sure all APIs (external and internal) and frontend
    applications are shown in the data flow diagram
    ● Identify different user roles in the application. How do these
    affect the data flow? Can customer support read / write
    customer records? Is there an admin role?

    View full-size slide

  16. Process flow diagram
    High level view of user actions

    View full-size slide

  17. Process flow diagram: Example

    View full-size slide

  18. Process flow diagram: Example

    View full-size slide

  19. Threat agents
    Who'll hack your application

    View full-size slide

  20. Threat agents: Who'll hack us?
    ● The term is used to indicate an individual or group that can
    manifest a threat. It is fundamental to identify who would want
    to exploit the assets of a company, and how they might use
    them against the company.
    ● Most common attackers are:
    ○ Hacker: High technical knowledge
    ○ Fraudster: Aims to find business logic flaw and exploits it
    ○ Competitor
    ○ (internal) developer
    ○ (internal) customer service representative

    View full-size slide

  21. Attack trees
    How you'll get hacked

    View full-size slide

  22. Attack trees: How will they hack us?
    ● Attack trees are conceptual diagrams showing how an asset or
    target might be attacked
    ● Some attacks to use as inspiration:
    ○ Phishing
    ○ Password brute-force
    ○ Password reuse
    ○ Consume unauthenticated services
    ○ Business logic flaw
    ○ Breach of partner's network
    ○ User impersonation
    ○ Intercept communications (web or SMTP)
    ○ Access user's email account

    View full-size slide

  23. Attack trees: Impact and likelihood
    ● Analyze likelihood and impact of these attacks and prioritize
    ● Estimate risk from 1 to 5, where 5 is the highest, use DREAD to
    guide the estimation:
    ○ Damage - how bad would an attack be?
    ○ Reproducibility - how easy it is to reproduce the attack?
    ○ Exploitability - how much work does the attack require?
    ○ Affected users - how many users will be impacted?
    ○ Discoverability - how easy it is to discover the issue?

    View full-size slide

  24. Attack trees: Example

    View full-size slide

  25. Attack trees: Example

    View full-size slide

  26. Identify mitigations and
    assign owners
    Securing the application

    View full-size slide

  27. Securing the architecture and flows
    ● Identifying the issues is just the first part of the story, providing
    guidance on how to fix them is equally important. An
    incomplete or incorrect mitigation can lead to the vulnerability
    still being exploitable.
    ● Mitigations should be implemented for all attacks with high or
    medium risk.
    ● Documenting mitigations is important for developers to be able
    to correctly implement them
    ● Owners should be assigned to each mitigation

    View full-size slide

  28. Track mitigation progress
    ● The application security team is in charge of tracking the
    vulnerability mitigation progress
    ● Each mitigation should be verified to be implemented in
    the source code and confirmed through live testing

    View full-size slide

  29. Let's get our hands dirty
    Applying all concepts

    View full-size slide