Glossary - ericfitz/tmi GitHub Wiki
Glossary
This page defines TMI-specific terms and concepts used throughout the application and documentation.
Core Concepts
Threat Model
A comprehensive document that identifies, analyzes, and documents potential security threats to a system or application. In TMI, a threat model contains diagrams, threat assessments, and recommendations for risk mitigation.
Data Flow Diagram (DFD)
A visual representation of how data moves through a system. DFDs show processes, data stores, actors, security boundaries, and the data flows between them. The foundation for threat identification.
Element
A component within a Data Flow Diagram. Types include:
- Process - Application or service that processes data
- Data Store - Database, cache, or file system
- Actor - Person, system, or external entity that interacts with the modeled system
- Security Boundary - Boundary delineating different security zones
- Text Box - Annotation or label element for documentation
Data Flow
A connection between elements showing the movement of data. Data flows are analyzed for security threats.
Threat
A potential security risk or vulnerability identified in a threat model. Each threat has a name (not "title"), and may include description, severity, likelihood, risk level, score, priority, status, mitigation details, CWE identifiers, CVSS vectors, and an optional link to an issue tracker. Threats can be associated with a specific diagram and cell element.
Threat Framework
A structured methodology for identifying threats. Supported frameworks:
- STRIDE - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
- CIA - Confidentiality, Integrity, Availability
- LINDDUN - Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance (privacy-focused)
- DIE - Distributed, Immutable, Ephemeral (cloud-native security)
- PLOT4ai - Privacy-focused framework for AI/ML threat modeling
Security & Access Control
Authorization
The process of determining what authenticated users are allowed to do. TMI implements role-based authorization.
Role
A permission level assigned to users for specific objects:
- Owner - Full read/write/delete permissions; can change authorization and ownership
- Writer - Read and write permissions; cannot delete or change authorization
- Reader - Read-only access; cannot modify or delete
Permission
A specific capability granted by a role:
- Read - View object and its contents
- Write - Modify object properties and content
- Delete - Remove object permanently
- Share - Change authorization and ownership
Owner Field
The user designated as the object's owner. The owner field takes absolute precedence over the authorization list and automatically grants owner-level permissions regardless of other authorization entries.
Authorization Field
A list of subjects (users or groups) and their assigned roles for an object. Different from the owner field; doesn't provide owner-level permissions.
Pseudo-Group
A special group identifier with predefined behavior. The "everyone" pseudo-group grants access to all authenticated users, regardless of their identity provider.
Subject
An entity (user or group) referenced in authorization:
- user - Individual user identified by email or username
- group - Collection of users from an identity provider
Identity Provider (IdP)
An external service that authenticates users and provides identity information. TMI supports dynamically configured providers via two protocols:
- OAuth 2.0 / OpenID Connect - Any standards-compliant OIDC provider (e.g., Google, GitHub, Microsoft Entra ID) configured through environment variables or YAML
- SAML 2.0 - Any SAML-compliant identity provider (e.g., Okta, ADFS) configured with metadata URL and attribute mappings
Providers are not hard-coded; each deployment configures the set of enabled providers.
API & Integration
REST API
HTTP-based API for programmatic access to threat models, diagrams, and threats. Follows RESTful principles with JSON payloads.
WebSocket
Real-time bidirectional communication protocol enabling collaborative diagram editing. Used for live updates when multiple users edit simultaneously. WebSocket connections use ticket-based authentication: clients first request a short-lived ticket via the REST API (/ws/ticket), then present that ticket as a query parameter when establishing the WebSocket connection. This avoids exposing JWTs in WebSocket URLs or server logs.
OAuth 2.0 with PKCE
Industry-standard authentication protocol. TMI uses the OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange, RFC 7636) for secure authentication with external identity providers. PKCE prevents authorization code interception attacks and is mandatory for all OAuth flows. Only the S256 code challenge method is supported.
JWT (JSON Web Token)
A cryptographically signed token representing an authenticated user. Used to authorize API requests.
OpenAPI
Specification format for documenting REST APIs. TMI's REST API is fully documented in OpenAPI 3.0.3.
AsyncAPI
Specification format for documenting asynchronous message protocols. TMI's WebSocket protocol is documented in AsyncAPI.
API Workflow
A sequence of API calls representing a common integration pattern (e.g., creating a threat model, adding diagrams, identifying threats).
Database
PostgreSQL
Relational database storing persistent threat model data including models, diagrams, threats, and user information.
Redis
In-memory cache and message broker providing:
- Real-time WebSocket connection management
- Edit lock coordination for concurrent editing
- Session cache
- Temporary data storage
Schema
The structure of database tables and their relationships. Includes tables for threat models, diagrams, threats, users, authorization, audit trails, and metadata. Schema changes are managed through GORM AutoMigrate, which automatically creates and updates tables, columns, indexes, and constraints based on Go struct definitions at server startup.
Development & Deployment
Configuration
Settings that control TMI server behavior at runtime:
- Server settings (port, interface, timeouts)
- Database credentials
- Authentication settings
- TLS/HTTPS configuration
Environment
A deployment context:
- Development - Local development with relaxed security
- Staging - Production-like environment for testing
- Production - Live environment serving users
Container
A lightweight, isolated execution environment for applications. TMI components (server, PostgreSQL, Redis) run in Docker containers.
Grype
Open-source container vulnerability scanner from Anchore. Scans container images for CVEs and generates reports in multiple formats (SARIF, JSON, table). Part of the Anchore toolchain alongside Syft (SBOM generation).
TLS/HTTPS
Encryption protocol for securing network communication. Required for production deployments.
Secrets
Sensitive configuration values including passwords, API keys, and OAuth credentials. Should never be committed to version control.
Collaboration
Real-time Editing
Multiple users simultaneously editing a diagram with automatic synchronization via WebSocket.
Edit Lock
Mechanism preventing conflicting edits when multiple users modify the same diagram element. Managed through Redis.
Change Notification
Real-time notification to all connected clients when a diagram is modified.
Metadata & Extensions
Metadata
Custom key-value pairs attached to threat models, diagrams, threats, and elements. Enables extension without schema changes.
Custom Properties
User-defined attributes stored as metadata, such as:
- Risk ratings
- Mitigation status
- Owner assignments
- Compliance references
Common Terms
CVE (Common Vulnerabilities and Exposures)
A unique identifier for a publicly disclosed security vulnerability. Example: CVE-2023-12345
CVSS Score
A numerical rating (0-10) representing vulnerability severity. Used to prioritize patching.
Vulnerability
A security weakness that could be exploited by attackers.
Patch
A software update that fixes a vulnerability or bug.
Role-Based Access Control (RBAC)
Security model restricting system access based on user roles.
Least Privilege
Security principle granting users only the minimum permissions needed to perform their tasks.
Audit Log
Record of user actions for security monitoring and compliance.
Related Pages
- Security-Best-Practices - Security terminology and concepts
- API-Specifications - API-related terms
- Configuration-Reference - Configuration-related terms
- Authorization Reference - Detailed authorization rules