Skip to content

Creating Your First Threat Model

Jump to bottom
Eric Fitzgerald edited this page Apr 8, 2026 · 4 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 Accessing-TMI and are signed in
  • You are familiar with basic threat modeling concepts (see the Glossary for terminology)
  • 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 the + (add) icon button in the toolbar to open the Create Threat Model dialog
    • If you have no threat models yet, you can also click the "Create Your First Threat Model" button shown in the empty state

  2. Fill in basic information

    • Name (required, max 256 characters): Give your threat model a descriptive name.
      • Example: "Payment Processing System"
    • Description (optional, max 1024 characters): Provide a brief overview of what this threat model covers.
      • Example: "Threat model for the e-commerce payment flow"
    • Framework (defaults to STRIDE): Choose a threat modeling framework.
      • STRIDE -- recommended for applications
      • CIA -- for infrastructure and data
      • LINDDUN -- for privacy threat modeling
      • DIE -- Distributed, Immutable, Ephemeral
      • PLOT4ai -- for AI system threats
    • Confidential (toggle, if enabled by your administrator): Confidential threat models are not automatically shared with the Security Reviewers group. This setting cannot be changed after creation.

  3. Click "Create"

Note: You do not set permissions during creation. By default, you are the owner. You can add collaborators later from the threat model editing page (see Step 6: Collaborate and Share).

Threat Model Status Values

As your security review progresses, update the threat model status to reflect its current state. The following table describes each status value:

Status Description
Not Started The security review has been initiated, but no assessment activities have begun.
In Progress Active assessment is underway, including threat modeling, code review, or testing.
Pending Review Assessment artifacts (such as reports and findings) await formal review by security leads or approvers.
Remediation Required Vulnerabilities or issues have been identified, and the development team must address them.
Remediation In Progress The development team is implementing fixes for identified issues.
Verification Pending Remediation is complete, and the security team must verify its effectiveness.
Approved All issues are resolved and verified. The application meets security criteria for release or deployment.
Rejected The review failed critical criteria. Significant rework is required before re-submission.
Deferred The review is paused (for example, due to resource constraints or application changes), and resumption is planned.
Closed The review is fully completed and archived, with no further action needed.

Step 2: Add a Data Flow Diagram

Data flow diagrams (DFDs) help you visualize your system's components and how they interact.

Create Your First Diagram

  1. In your threat model, click the + (add) icon button in the Diagrams card header

  2. In the Create New Diagram dialog:

    • Diagram Type: Currently fixed to DFD-1.0.0 (Data Flow Diagram)
    • Diagram Name: A default name is generated as "Threat Model Name -- Data Flow Diagram"; you can edit it (max 100 characters)
    • Click "OK" to create the diagram

  3. Add Components

    TMI data flow diagrams support these component types:

    • Process -- a component that transforms data
      • Example: "Payment Processor", "Authentication Service"
    • Data Store -- where data is persisted
      • Example: "Customer Database", "Transaction Log"
    • Actor -- an external user or system that interacts with your system
      • Example: "Customer", "Payment Gateway"
    • Security Boundary -- a boundary between trust zones
      • Example: separating internet-facing components from internal systems
    • Text -- a text annotation for documentation on the diagram

  4. Add Data Flows

    • Connect components with edges that show data movement
    • Label each flow with a data description
      • Example: "Credit Card Info", "User Credentials", "Order Data"

Example Diagram

The following ASCII diagram illustrates a simple payment system:

[Customer (Actor)] --credit card--> [Web Server (Process)]
                                           |
                                    payment request
                                           ↓
                               [Payment Processor (Process)] --transaction--> [Payment Gateway (Actor)]
                                           |
                                     confirmation
                                           ↓
                                  [Transaction DB (Data Store)]

Diagram Best Practices

  • Start simple -- begin with high-level components
  • Add detail gradually -- create separate diagrams for subsystems
  • Show security boundaries -- identify where trust zones change
  • Label everything -- clear labels make threat identification easier
  • Use consistent naming -- keep component names clear and consistent

For more details, see Working-with-Data-Flow-Diagrams.

Step 3: Identify Threats

With your diagram in place, you can now identify potential threats.

Using the STRIDE Framework

If you chose STRIDE, consider each category:

Category Question to Ask
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 the + (add) icon button in the Threats card header on the threat model editing page

  2. Fill in threat details:

    • Name (required, max 100 characters): A short, descriptive name.
      • Example: "SQL Injection in Payment Query"
    • Diagram (optional): Associate the threat with a specific diagram.
    • Cell (optional): Associate with a specific diagram element, filtered by the selected diagram.
    • Asset (optional): Associate with a data asset.
    • Description (max 500 characters): A detailed description of the threat.
    • Threat Type (multi-select): Select one or more categories from your framework.
      • Example: "Tampering" (in STRIDE)
    • Severity: Critical, High, Medium, Low, Informational, or Unknown.
    • Score: Numeric score from 0 to 10 (for example, a CVSS score).
    • Priority: Immediate, High, Medium, Low, or Deferred.
    • Status: Open, Confirmed, Mitigation Planned, Mitigation In Progress, Verification Pending, Resolved, Accepted, False Positive, Deferred, or Closed.
    • Mitigated: Checkbox indicating whether the threat has been mitigated.
    • Include in Report: Checkbox to include this threat in generated reports (default: on).
    • Issue URI: URL linking to an issue in your issue tracker. You can type, paste, or drag and drop the URL.
    • Mitigation (max 1024 characters): Description of mitigation strategies.

  3. Click "Save" to create the threat

Example Threat

Name: "Customer Credit Card Data Interception"

Threat Type: 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.

Severity: High

Priority: Immediate

Status: Open

Mitigation:

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

Step 4: Add Documentation

Use notes to document your analysis, assumptions, and decisions.

Creating Notes

  1. Click the + (add) icon button in the Notes card header on the threat model editing page

  2. Fill in note details:

    • Name (required, max 256 characters): Give the note a descriptive name.
      • Example: "Security Assumptions", "Threat Modeling Decisions"
    • Description (optional, max 2048 characters): A brief description of the note's purpose.
    • Include in Report: Checkbox to include this note in generated reports (default: on).

  3. Use Markdown in the Content field 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 in notes 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 is not included and why?
  • Link to external docs -- reference architecture documents and security policies

For more details, see Using-Notes-and-Documentation.

Step 5: Add Metadata (Optional)

You can extend your threat model with custom key-value metadata.

Adding Metadata

  1. Open the metadata dialog for a threat model, diagram, or other object. You can access this from the object's menu or details view.

  2. 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

For more details, see Metadata-and-Extensions.

Step 6: Collaborate and Share

Once your threat model is ready for review, share it with your team.

Sharing with Team Members

  1. Open the kebab menu (three-dot menu) on the threat model editing page and click "Permissions"

  2. Add collaborators by clicking "Add Permission":

    • Type: Select "User" or "Group"
    • Provider: Select the identity provider (e.g., Google, Microsoft)
    • Subject: Enter the email address, user ID, or group name
      • If you want to share the document with everyone on your TMI instance, set the type to "Group" and enter "everyone" as the subject.
      • If you are authenticated with SAML or your OAuth provider includes groups claims, you can choose a group you belong to.
    • Role: Select the permission level:
      • Reader: View only
      • Writer: Reader, and additionally can edit
      • Owner: Writer, and can change permissions or delete the threat model

  3. Click "Save" to apply the permission changes

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
  • Track versions -- review change history

For more details, see Collaborative-Threat-Modeling.

Step 7: Link to Issue Tracking

You can link each threat to your issue tracking system using the Issue URI field.

Adding Issue Links

  1. Open a threat for editing by clicking on it in the Threats table.

  2. In the Issue URI field, add the URL to your issue tracker:

    • Type or paste the issue URL directly.
    • Alternatively, drag and drop a URL from your browser onto the Issue URI field.
    • Once saved, the URI appears as a clickable hyperlink.

  3. Track implementation:

    • Click the issue link to navigate directly to your issue tracker.
    • Update the threat status as remediation progresses.

For more details, see Issue-Tracker-Integration.

Common Patterns

Application Threat Model

  1. Create a 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 your issue tracker.

Infrastructure Threat Model

  1. Create a network topology diagram.
  2. Show trust boundaries and security zones.
  3. Identify threats using the 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 with the process.
  • Do not try to model everything at once.

Focus on Value

  • Prioritize high-risk areas first.
  • Avoid getting lost in low-risk details.
  • Focus on actionable threats with clear mitigations.

Iterate

  • Threat modeling is not a one-time activity.
  • Update your models as your system evolves.
  • Regular reviews keep models relevant and accurate.

Collaborate

  • Involve developers, architects, and security engineers.
  • Different perspectives uncover different threats.
  • Make threat modeling a team activity, not a solo exercise.

Next Steps

Now that you have created your first threat model, explore these topics to go deeper:

Need Help?

Home

Releases

Getting Started

Deployment

Operation

Troubleshooting

Development

Integrations

Tools

API Reference

Reference

Clone this wiki locally