Managing Threats - ericfitz/tmi GitHub Wiki

Managing Threats

Learn how to identify, document, and manage threats in TMI.

Overview

Threat management is the core of threat modeling. TMI helps you systematically identify, assess, and track threats to your system.

Threat Frameworks

TMI supports five built-in threat categorization frameworks. You select the framework at the threat model level, which determines the available threat type categories for all threats within that model.

STRIDE

Microsoft's STRIDE framework categorizes threats into six types:

Spoofing -- Impersonating users or systems (applies to Actor, Process)
Tampering -- Unauthorized modification of data (applies to Store, Flow, Process)
Repudiation -- Denying actions without proof (applies to Actor, Store, Process)
Information Disclosure -- Exposing sensitive information (applies to Store, Flow, Process)
Denial of Service -- Making systems unavailable (applies to Store, Flow, Process)
Elevation of Privilege -- Gaining unauthorized access (applies to Process)

CIA

The CIA triad framework focuses on three core security properties:

Confidentiality -- Unauthorized access to data (applies to Actor, Store, Flow, Process)
Integrity -- Unauthorized modification (applies to Actor, Store, Flow, Process)
Availability -- System or data unavailability (applies to Actor, Store, Flow, Process)

LINDDUN

The LINDDUN framework focuses on privacy threats:

Linkability -- Ability to link data items or actions (applies to Actor, Store, Flow, Process)
Identifiability -- Ability to identify a data subject (applies to Actor, Store, Flow, Process)
Non-Repudiation -- Inability to deny an action (applies to Store, Flow, Process)
Detectability -- Ability to detect the existence of data (applies to Store, Flow, Process)
Disclosure of Information -- Exposure of private information (applies to Store, Flow, Process)
Unawareness -- Lack of awareness about data processing (applies to Actor)
Non-Compliance -- Failure to comply with regulations (applies to Store, Flow, Process)

DIE

The DIE (Distributed, Immutable, Ephemeral) framework focuses on modern infrastructure resilience:

Distributed -- System distribution characteristics (applies to Actor, Store, Flow, Process)
Immutable -- Data and system immutability (applies to Actor, Store, Flow, Process)
Ephemeral -- Temporary or disposable nature of components (applies to Actor, Store, Flow, Process)

PLOT4ai

The PLOT4ai framework focuses on AI-specific threats:

Technique & Processes -- AI technique and process risks (applies to Store, Flow, Process)
Accessibility -- AI system accessibility concerns (applies to Actor, Store, Process)
Identifiability & Linkability -- AI data linkage risks (applies to Actor, Store, Flow, Process)
Security -- AI security threats (applies to Actor, Store, Flow, Process)
Safety -- AI safety concerns (applies to Actor)
Unawareness -- Lack of awareness about AI processing (applies to Actor)
Ethics & Human Rights -- Ethical and rights-related concerns (applies to Actor)
Non-Compliance -- Regulatory non-compliance risks (applies to Store, Flow, Process)

Creating Threats

Adding a New Threat

Open a threat model from the dashboard.
Scroll to the Threats card.
Click the + (Add Threat) button in the card header.
Fill in the threat details in the editor dialog.
Click Save.

You can also create threats from within a Working-with-Data-Flow-Diagrams by right-clicking a diagram element.

Threat Properties

Required Fields

Name -- Short, descriptive name (max 100 characters)

Optional Fields

Description -- Detailed explanation of the threat (max 500 characters)
Threat Type -- One or more categories from the threat model's framework (for example, Spoofing or Tampering for STRIDE); supports multi-select
Severity -- Critical, High, Medium, Low, Informational, or Unknown (see Threat Severity Values)
Score -- Numeric risk score
Priority -- Immediate (P0), High (P1), Medium (P2), Low (P3), or Deferred (P4) (see Threat Priority Values)
Status -- Lifecycle status of the threat (see Threat Status Values)
Mitigated -- Boolean flag indicating whether the threat has been mitigated
Mitigation -- Description of how the threat is addressed (max 1024 characters)
Diagram -- Associates the threat with a specific diagram
Cell -- Associates the threat with a specific element within the selected diagram
Asset -- Associates the threat with a data asset
Issue URI -- Link to an external issue tracker (supports drag-and-drop of URLs)
CWE IDs -- One or more Common Weakness Enumeration identifiers (for example, CWE-79); supports chip input and a CWE picker dialog
CVSS -- Common Vulnerability Scoring System vectors and scores; supports CVSS 3.1 and 4.0 through a built-in calculator dialog or direct vector string entry
Include in Report -- Whether to include this threat in exported reports
Metadata -- Custom key-value properties managed through a separate dialog

Threat Identification Techniques

Component-Based Analysis

For each component in your diagram, consider:

What threats apply to this component type?
What data does it handle?
What trust boundaries does it cross?

Data Flow Analysis

For each data flow, consider:

Can data be intercepted?
Can data be modified?
Is data properly validated?
Is data properly encrypted?

STRIDE per Element

Apply STRIDE to each diagram element type. TMI uses the following element-to-threat-type mappings from the STRIDE framework definition:

Process (all six STRIDE categories apply):

Spoofing process identity
Tampering with process
Repudiation of process actions
Information disclosure from process
Denial of service to process
Elevation of privilege in process

Store (data store):

Tampering with stored data
Repudiation of store actions
Information disclosure from store
Denial of service to store

Flow (data flow):

Tampering with data in transit
Information disclosure of data
Denial of service to flow

Actor (external entity):

Spoofing actor identity
Repudiation of actor actions

Trust Boundary Analysis

At each trust boundary, consider:

What authentication occurs?
What authorization is required?
What data validation happens?
What logging exists?

Risk Assessment

TMI uses Severity as the primary qualitative risk classification for threats, rather than separate impact and likelihood fields. When you assess severity, consider both the potential impact (consequences if exploited) and likelihood (probability of occurrence) together to select the appropriate level.

Threat Severity Values

TMI uses the following severity values for threats:

Severity	Description
Critical	Exploitable vulnerability enables complete system compromise, data breach, or safety impact; requires immediate action.
High	Significant impact or high likelihood; enables major unauthorized access, privilege escalation, or service disruption.
Medium	Moderate impact or likelihood; limited data exposure, partial functionality impairment, or requires chained exploits.
Low	Minimal impact or low likelihood; negligible business impact, requires specific conditions or user interaction.
Informational	No direct exploitability; recommendation, best practice deviation, or configuration improvement.
Unknown	Threat severity has not yet been assessed.

Threat Priority Values

TMI uses the following priority values for threats:

Priority	Description
Immediate (P0)	Must be addressed urgently; active exploitation, regulatory violation, or critical business exposure.
High (P1)	Requires prompt resolution; high-risk exposure or upcoming release deadline.
Medium (P2)	Address within standard development cycles; moderate exposure.
Low (P3)	Include in backlog for future cycles; no immediate exposure.
Deferred (P4)	Postponed with documented business approval; tracked but not scheduled.

Risk Scoring

TMI provides two complementary ways to quantify threat risk:

Score -- A numeric score field on each threat for manual or calculated risk values.
CVSS -- Built-in support for CVSS 3.1 and CVSS 4.0 vector strings with automatic score calculation through the integrated CVSS calculator dialog.

The Severity field (Critical through Informational) provides a qualitative risk classification independent of the numeric score.

Mitigation Strategies

Types of Mitigation

Eliminate -- Remove the vulnerability entirely:

Redesign the system
Remove risky features
Change architecture

Reduce -- Lower the risk level:

Add security controls
Implement defenses
Add monitoring

Transfer -- Shift the risk:

Use third-party services
Insurance
Contractual agreements

Accept -- Consciously accept the risk:

Document the decision
Approve at the appropriate level
Monitor over time

Documenting Mitigations

Each threat has a single Mitigation text field (up to 1024 characters) where you describe remediation measures. Use this field in combination with the Status field to track mitigation progress:

Set Status to Mitigation Planned when you define a strategy.
Set Status to Mitigation In Progress when implementation is underway.
Set Status to Verification Pending when mitigation is complete but needs review.
Set Status to Resolved and toggle Mitigated to true when the mitigation is verified.

For structured mitigation tracking beyond the text field, use Metadata key-value pairs to capture details such as control type, owner, or timeline. See Metadata-and-Extensions for more information.

Example Mitigations

Threat: SQL Injection in user search

Mitigations:

Use parameterized queries (Eliminate)
Input validation and sanitization (Reduce)
Web application firewall (Reduce)
Database activity monitoring (Detect)
Least privilege database accounts (Reduce)

Linking Threats to Diagrams, Cells, and Assets

Why Link?

Linking threats to diagrams, cells, and assets helps you:

Track which diagram elements are affected by specific threats
Associate threats with data assets for impact analysis
View threats in context when working with Working-with-Data-Flow-Diagrams

Creating Links

Open the threat for editing (click the threat row, or create a new threat).
Use the Diagram dropdown to associate the threat with a diagram.
Use the Cell dropdown to associate the threat with a specific element within the selected diagram. The cell list filters based on the selected diagram.
Use the Asset dropdown to associate the threat with a data asset.
Click Save.

Each threat can be linked to one diagram, one cell, and one asset. Select "Not associated" to clear a link.

Using Links

View threats associated with diagram elements by right-clicking elements in the Working-with-Data-Flow-Diagrams.
Hover over threat type icons in threat rows to see tooltips listing the associated threat types.

Threat Lifecycle

Threat Status Values

TMI uses the following status values for individual threats:

Status	Description
Open	The finding has been identified and documented but no action has been initiated.
Confirmed	The threat has been validated as legitimate through analysis or evidence.
Mitigation Planned	A remediation or mitigation strategy has been defined and assigned.
Mitigation In Progress	Implementation of controls, code changes, or countermeasures is underway.
Verification Pending	Mitigation is complete; the security team must test or review effectiveness.
Resolved	The threat is fully mitigated and verified; residual risk is acceptable.
Accepted	The threat is acknowledged but intentionally not mitigated (for example, due to business justification); requires formal risk acceptance.
False Positive	Investigation determined the finding is not a valid threat; no further action is required.
Deferred	Action is postponed with approval (for example, for future sprints); includes rationale and due date.
Closed	The finding is archived after resolution, acceptance, or invalidation, with an audit trail.

Tracking Progress

Update the threat Status field as work progresses through the lifecycle.
Set the Issue URI field to link to an external issue tracker ticket. See Issue-Tracker-Integration for details.
Update the Mitigation field to document remediation actions taken.
Toggle the Mitigated flag when mitigation is complete.
Use Metadata key-value pairs to capture additional tracking information.
Review the Audit Trail (accessible from the threat row kebab menu) to see the history of changes.

Integration with Issue Tracking

Linking to External Issues

Each threat has an Issue URI field that you can use to link to an external issue tracker:

Open the threat for editing.
Enter the issue URL in the Issue URI field, or drag and drop a URL onto the field.
Click Save.

Once set, the issue URI appears as a clickable external link icon in the threats table, opening the linked issue in a new tab.

There is no automatic ticket creation or bidirectional status sync. Issue tracking integration is manual through the URI field. See Issue-Tracker-Integration for more information.

Threat Reports and Views

Filtering Threats

The threats card provides a filter bar with the following controls:

Primary filters (always visible):

Name -- Text search for threat names (debounced input)
Severity -- Multi-select dropdown (Critical, High, Medium, Low, Informational, Unknown)
Status -- Multi-select dropdown (Open, Confirmed, Mitigation Planned, and others)
Mitigated -- Tri-state toggle button (mitigated, not mitigated, or show all)

Advanced filters (toggle with the filter icon):

Threat Type -- Multi-select dropdown populated from the threat model's framework (for example, Spoofing or Tampering for STRIDE)
Priority -- Multi-select dropdown (Immediate, High, Medium, Low, Deferred)

A Clear All button appears when any filter is active. Filter, sort, and pagination state persists when you navigate to the threat editor page and back.

Sorting Threats

The threats table supports sortable columns:

Severity (default sort, ascending)
Name (alphabetical)
Status

Sort direction toggles between ascending, descending, and default on each click.

Threats Table Columns

The threats table displays the following columns:

Column	Description
Icon	Threat type icon with tooltip showing threat type categories
Severity	Color-coded severity badge
Name	Threat name
Description	Truncated description text
Status	Status badge
Mitigated	Checkmark icon when mitigated
Hyperlink	External link icon for issue URI (when set)
Actions	Metadata dialog, addons menu, audit trail, and delete

Collaboration on Threats

Team Review

Share the threat model with team members through the permissions dialog (reader, writer, or owner roles). See Collaborative-Threat-Modeling for details.
Team members with write access can edit threats directly.
Use the audit trail to review changes made to individual threats.

Addons

Invoke registered addons on individual threats or in bulk from the threats card header. See Addon-System for details.
Addons that support the "threat" object type appear in the kebab menu for each threat row and in the card header menu.

Best Practices

Be Specific

Write clear, descriptive threat titles.
Provide detailed descriptions of the threat scenario.
Include concrete examples of how the threat could be exploited.
Define specific, actionable mitigations.

Focus on Actionable Threats

Prioritize realistic threats over theoretical ones.
Concentrate on threats that can be mitigated.
Avoid spending excessive time on low-probability scenarios.

Document Decisions

Record why risks were accepted.
Explain why specific mitigations were chosen.
State assumptions made during the analysis.
Note tradeoffs considered.

Regular Review

Review threats as the system changes.
Re-assess as the threat landscape evolves.
Update mitigations when new controls are available.
Close resolved threats promptly.

Link Everything

Link threats to Working-with-Data-Flow-Diagrams.
Link threats to your Issue-Tracker-Integration.
Link threats to relevant documentation using Using-Notes-and-Documentation.
Reference security controls in mitigation descriptions.

Examples

Example 1: Authentication Threat

Field	Value
Name	Brute Force Attack on Login
Threat Type	Elevation of Privilege (STRIDE framework)
Description	Attacker attempts to guess user passwords through automated login attempts.
Severity	High
Priority	High (P1)
Mitigation	Rate limiting (5 attempts per 15 minutes), account lockout after 10 failed attempts, CAPTCHA after 3 failed attempts, multi-factor authentication, password complexity requirements, brute force pattern monitoring.
Mitigated	Yes
Status	Resolved

Example 2: Data Exposure Threat

Field	Value
Name	Sensitive Data in Application Logs
Threat Type	Information Disclosure (STRIDE framework)
Description	Application logs may contain PII or credentials if exceptions are logged verbosely.
Severity	Medium
Priority	Medium (P2)
Mitigation	Log sanitization framework, code review for logging statements, log access controls, automated log scanning, developer training.
Mitigated	No
Status	Mitigation In Progress

Next Steps

Collaborative-Threat-Modeling -- Learn about team-based threat modeling workflows
Issue-Tracker-Integration -- Explore deeper issue tracker integration options
Security-Best-Practices -- Review security best practices for TMI deployments