Skip to content

Creating Your First Threat Model

Jump to bottom
Eric Fitzgerald edited this page Nov 12, 2025 · 2 revisions

Creating Your First Threat Model

This guide walks you through creating your first threat model in TMI, from start to finish.

Prerequisites

  • You have accessed TMI and are signed in
  • You're familiar with basic threat modeling concepts
  • You have a system or application you want to analyze

Step 1: Create a New Threat Model

  1. Navigate to the Dashboard

    • After signing in, you'll see your TMI dashboard
    • Click "New Threat Model" or "Create Threat Model"

  2. Fill in Basic Information

    • Name: Give your threat model a descriptive name
      • Example: "Payment Processing System"
    • Description: Provide a brief overview
      • Example: "Threat model for the e-commerce payment flow"
    • Framework: Choose a threat modeling framework
      • STRIDE (recommended for applications)
      • CIA (for infrastructure/data)
      • Custom (define your own; requires creating a new framework definition file; see frameworks).

  3. Set Initial Permissions (optional)

    • By default, you're the owner
    • You can add collaborators later
    • If you want to make your threat model visible to everyone on your TMI instance, add permission for the group "everyone".

  4. Click "Create"

Step 2: Add a Data Flow Diagram

Data flow diagrams (DFDs) help visualize your system's components and interactions.

Create Your First Diagram

  1. In your threat model, click "New Diagram" or "Add Diagram"

  2. Name your diagram

    • Example: "Payment Flow Overview"
    • Use descriptive names for multiple diagrams

  3. Add Components

    TMI diagrams support several component types:

    • Process: A component that transforms data
      • Example: "Payment Processor", "Authentication Service"
    • Data Store: Where data is stored
      • Example: "Customer Database", "Transaction Log"
    • External Entity: External user or system
      • Example: "Customer", "Payment Gateway"
    • Trust Boundary: Security boundary between trust zones
      • Example: Separating internet-facing components from internal systems

  4. Add Data Flows

    • Connect components with arrows showing data movement
    • Label flows with data description
      • Example: "Credit Card Info", "User Credentials", "Order Data"

Example Diagram

Here's a simple payment system diagram:

[Customer] --credit card--> [Web Server]
                                   |
                        payment request
                                   ↓
                          [Payment Processor] --transaction--> [Payment Gateway]
                                   |
                             confirmation
                                   ↓
                          [Transaction DB]

Diagram Best Practices

  • Start simple: Begin with high-level components
  • Add detail gradually: Create separate diagrams for subsystems
  • Show trust boundaries: Identify where trust zones change
  • Label everything: Clear labels make threat identification easier
  • Use consistent naming: Keep component names clear and consistent

Step 3: Identify Threats

With your diagram in place, identify potential threats.

Using STRIDE Framework

If you chose STRIDE, consider each category:

  • Spoofing: Can an attacker impersonate a user or component?
  • Tampering: Can an attacker modify data or code?
  • Repudiation: Can actions be denied after the fact?
  • Information Disclosure: Can sensitive data be exposed?
  • Denial of Service: Can the system be made unavailable?
  • Elevation of Privilege: Can an attacker gain unauthorized access?

Adding Threats

  1. Click "New Threat" or "Add Threat"

  2. Fill in threat details:

    • Title: Short, descriptive title
      • Example: "SQL Injection in Payment Query"
    • Category: Select from your framework
      • Example: "Tampering" (in STRIDE)
    • Description: Detailed description of the threat
    • Impact: What happens if exploited?
    • Likelihood: How likely is this threat?
    • Risk Level: High, Medium, Low
    • Status: New, Investigating, Mitigated, Accepted

  3. Link to diagram components (optional but recommended)

    • Associate threats with specific diagram elements
    • Helps track where threats exist in your system

  4. Add mitigation strategies:

    • Describe how to address the threat
    • Link to related security controls
    • Track implementation status

Example Threat

Title: "Customer Credit Card Data Interception"

Category: Information Disclosure (STRIDE)

Description: An attacker could intercept credit card data transmitted between the customer browser and web server if TLS is not properly implemented.

Impact: HIGH - Exposure of customer payment information, regulatory penalties, reputational damage

Likelihood: MEDIUM - Requires network position, but possible on public WiFi

Mitigation:

  • Implement TLS 1.3 for all connections
  • Use HSTS headers
  • Regular TLS configuration audits

Step 4: Add Documentation

Document your analysis using Notes.

Creating Notes

  1. Click "New Note" or "Add Note"

  2. Give it a title

    • Example: "Security Assumptions", "Threat Modeling Decisions"

  3. Use Markdown for formatting:

    ## Security Assumptions

- Users authenticate via OAuth 2.0
- All data in transit uses TLS 1.3+
- Payment card data is not stored

## Trust Boundaries

- Internet to DMZ
- DMZ to internal network
- Application tier to data tier

  4. Include Mermaid diagrams for visual documentation:

    ```mermaid
flowchart LR
    A[Customer] --> B[Web App]
    B --> C[Payment Service]
    C --> D[Payment Gateway]
```

Documentation Best Practices

  • Document assumptions: What are you assuming about security?
  • Record decisions: Why did you make certain choices?
  • Note out of scope items: What's not included?
  • Link to external docs: Reference architecture docs, security policies

Step 5: Add Metadata (Optional)

Extend your threat model with custom metadata.

Adding Metadata

  1. Select any object (threat model, diagram, threat)

  2. Find the metadata section

  3. Add key-value pairs:

    • compliance: PCI-DSS
    • owner: security-team
    • environment: production
    • review-date: 2025-06-01

Metadata Use Cases

  • Categorization: Group related items
  • Compliance tracking: Link to compliance requirements
  • Workflow integration: Connect to external systems
  • Custom reporting: Filter and report based on metadata

Step 6: Collaborate and Share

Share your threat model with your team.

Sharing with Team Members

  1. Click "Share" or "Manage Access"

  2. Add collaborators:

    • Enter email address or username
      • If you want to share the document with everyone on your TMI instance, add the group "everyone".
      • If you are authenticated with SAML or your OAuth provider includes groups claims, you can choose a group you belong to.
    • Select permission level:
      • Reader: View only
      • Writer: Reader, and additionally can edit
      • Owner: Writer, and can change permissions or delete the threat model

  3. Send invitations

Real-Time Collaboration

  • Multiple users can edit simultaneously
  • See collaborator cursors and changes in real-time
  • WebSocket-based synchronization
  • No need to refresh or save manually

Collaboration Best Practices

  • Set clear roles: Assign appropriate permission levels
  • Communicate changes: Use notes to document major changes
  • Review together: Use real-time editing for review sessions
  • Version tracking: Review change history

Step 7: Integrate with Issue Tracking

Link threats to your issue tracking system by adding the issue URL to your threat.

Creating Issue Links

  1. In a threat, find the "Issue Tracker" section

  2. Create or link an issue:

    • Click "Create Issue" to create new

  3. Track implementation:

    • Issue status syncs with TMI
    • Track remediation progress

See Issue Tracker Integration for detailed setup.

Common Patterns

Application Threat Model

  1. Create high-level architecture diagram
  2. Create detailed diagrams for each major component
  3. Identify threats using STRIDE
  4. Document security controls
  5. Track remediation in issue tracker

Infrastructure Threat Model

  1. Create network topology diagram
  2. Show trust boundaries and security zones
  3. Identify threats using CIA framework
  4. Document existing controls
  5. Prioritize gaps

API Threat Model

  1. Create sequence diagrams showing API flows
  2. Focus on authentication and authorization
  3. Identify data validation threats
  4. Document rate limiting and abuse prevention
  5. Track API security requirements

Tips for Success

Start Small

  • Begin with a manageable scope
  • Expand as you become comfortable
  • Don't try to model everything at once

Focus on Value

  • Prioritize high-risk areas
  • Don't get lost in low-risk details
  • Focus on actionable threats

Iterate

  • Threat modeling is not one-and-done
  • Update as your system evolves
  • Regular reviews keep models relevant

Collaborate

  • Involve developers, architects, security
  • Different perspectives find different threats
  • Make it a team activity

Next Steps

Now that you've created your first threat model:

Need Help?

Home

Getting Started

Deployment

Operation

Troubleshooting

Development

Integrations

Tools

API Reference

Reference

Clone this wiki locally