What is Threat Modeling?

  • Structured representation of all the information that affects the security of an application.
  • Structured approach to identifying, analyzing, and mitigating potential security threats in a system, application, or network.
  • Helps teams anticipate risks and design countermeasures before attackers can exploit vulnerabilities.
  • When should you do it? Early and continuously in the development lifecycle.
  • Typical steps? Identify assets, Enumerate threats, Assess risks, Apply mitigations, Validate.
  • Common methodologies? STRIDE, DREAD, PASTA, Attack Trees
  • STRIDE vs DREAD? STRIDE categorizes threats, DREAD quantifies risk.
  • Attack trees and Data Flow Diagrams (DFDs) can be used to visualize threat models.

How to do Threat Modeling?

Diverse perspectives:

  • Make sure you have diverse perspectives involved in the process:
    • Business Persona:
      • Focuses on business outcomes, and the value being delivered to customer.
      • Intimately understands the functional and non-functional requirements of the workload.
    • Developer Persona:
      • Understands how the system works, thinks about how to implement mitigations.
    • Adversary Persona:
      • Unauthorized user roleplay – helps devise threats.
      • Takes advantage of design flaws to achieve a particular objective.
    • Defender Persona:
      • Defines security controls to mitigate threats devised by adversary.
      • Evaluates whether proposed mitigations are manageable in terms of operational support, monitoring, incident response.
    • AppSec SME:
      • Familiar with the threat modeling process – moderates discussions.
      • Depth of IT and security knowledge.
      • Makes sure balance between security and customer outcomes is met.

Threat Modeling Process

  • What are we working on?

    • Model the system so that there’s shared understanding between teammates.
    • Define the scope.
    • Diagram doesn’t need to be 100% accurate, have necessary simplifications.
      • Ask yourself: “Will adding this help us to find more threats overall?” when deciding whether to include a particular detail in the system model.
      • Too much detail may become a distraction from finding threats.
    • Use Data Flow Diagrams (DFDs) to model the exchange of data between system elements.
      • processes: receive data, perform computation, output data.
      • data stores: data kept at rest.
      • external entities: elements you don’t control — outside your system boundaries.
      • human actors: differentiate between external entities and human actors because threats and mitigations may be different.
      • data flows: actually list down the data that will be contained in the flows
      • trust boundary / zone of trust: any place where data changes its level of trust. within a zone of trust, all elements are considered to be equally or similarly trusted – security controls are often applied at trust boundaries.
    • Control plane might be ignored for a simplistic view, but it is useful for identifying internal threats so it may necessary in real world systems.

  • What can go wrong?

    • What threats can occur? What is their likelihood and impact? (Risk = Likelihood*Impact)
    • Apply STRIDE per element to identify threats
      • Spoofing (violates authenticity) — Mitigate with authentication
      • Tampering (violates integrity) — Mitigate with signatures (hashing), minimize human access to production data (including config, code, etc)
      • Repudiation (violates non-repudiation) — Mitigate with append-only, immutable logging
      • Information Disclosure (violates confidentiality) — Mitigate with encryption, least privilege access controls
      • Denial of Service (violates availability) — Mitigate with rate limits (throttling), least privilege access controls
      • Elevation of Privilege (violates authorization) — Mitigate with authorization, access controls
    • Use threat grammar to write about identified threats:
      • [threat source] [prerequisites] **can** [threat action], **which leads to** [threat impact], **negatively impacting** [impacted assets].
      • threat source: entity (a threat actor/internet based threat actor/internal or external actor
      • prerequisites: conditions required for attack to be viable (with access to another user’s token/with admin access)
      • threat action: actions (spoof another user/tamper with data in database/make thousands of concurrent requests)
      • threat impact: direct impact of successful threat action (unauthorized access to user’s bank account info/modify the username for all time high score/web app unable to handle requests)
      • impacted assets: (user banking data/video game score list/web app)
      • can additionally have “impacted goal” as well (CIA)
    • Can use threat composer tool to structure your threats.
    • Assume there are no mitigations at this stage – focus only on possible threats.

  • What are we going to do about it?

    • Prioritize threats and select mitigations.
    • Handle Risk:
      • Avoid: Remove the feature if not essential to business.
      • Mitigate: Administrative (background checks on personnel, policy), Technical (encryption, authentication)and Physical mitigations (fences, security guards, locks)
      • Transfer: CDNs, Outsourcing, MSSPs, Contracts/SLAs, Cyber Insurance
      • Accept: If this risk is low and it is not a critical application, consider accepting it to save mitigation expenses.
    • Apply security controls such as least privilege, secure defaults, encryption, authentication, monitoring/logging, segmentation, other AWS native security services.

  • Did we do a good enough job?

    • Repeat the STRIDE per element process after you have applied mitigations to ensure other threats didn’t open up.
    • Validate that mitigations successfully implemented.
    • Improve the process itself, finetune it for your org to make it better over time.

External Resources