Your First Threat Model
Let's create your first threat model step by step. By the end of this guide, you'll have a complete threat model for a simple web application.
What You'll Build
A threat model for a basic web application with:
- System metadata and description
- Information assets (data that needs protection)
- Third-party dependencies
- Use cases (user interactions)
- Identified threats
- Security controls
Step 1: Create a New Threat Model
From your dashboard, click the "New Threat Model" button. An empty Threat Model will be created, you can visit it, but there won't be much there. Threatcl Cloud treats HCL threat model files as the source of truth. So get your favourite text editor or IDE ready!
Step 2: Open your favourite editor, and start creating new.hcl
Every threat model starts with basic metadata. Copy this into your new file:
spec_version = "0.2.4"
threatmodel "My Web Application" {
description = "A simple web application for managing user tasks"
author = "@yourname"
attributes {
new_initiative = "true"
internet_facing = "true"
initiative_size = "small"
}
}
spec_version - The threatcl specification version
threatmodel - Give your model a descriptive name
attributes - Preliminary scoping key-value pairs for classification
Tip: Threat models in Threatcl Cloud use HCL (HashiCorp Configuration Language), the same language used by Terraform. It's human-readable and version-control friendly.
You don't need the attributes block, but it helps, review Understanding HCL Syntax for more information.
Step 3: Define Information Assets
Information assets are the data your system processes. Add this inside your threatmodel block:
information_asset "user_data" {
description = "User account information and credentials"
information_classification = "confidential"
}
information_asset "task_data" {
description = "User-created tasks and notes"
information_classification = "internal"
}
Best Practice: Think about what data your system handles and classify it by sensitivity level (public, internal, confidential, restricted).
Step 4: Document Third-Party Dependencies
List external services your application depends on:
third_party_dependency "auth_service" {
description = "OAuth2 authentication provider"
uptime_dependency = "degraded"
uptime_notes = "Users cannot log in without this service"
}
third_party_dependency "database" {
description = "PostgreSQL database"
uptime_dependency = "hard"
uptime_notes = "Application is non-functional without database"
}
uptime_dependency - How critical is this dependency?
hard- System fails completely without itdegraded- System works with reduced functionalitynone- Optional dependency
Step 5: Define Use Cases
Use cases describe how users interact with your system:
usecase {
description = "User logs in to the application"
}
usecase {
description = "User creates a new task"
}
usecase {
description = "User views their task list"
}
usecase {
description = "Administrator manages user accounts"
}
Step 6: Identify Threats
Now for the core of threat modeling - identifying potential threats:
threat "SQL Injection" {
description = "Attacker could steal user credentials through SQL injection"
impacts = ["Confidentiality"]
stride = ["Tampering", "Information Disclosure"]
information_asset_refs = [
"user_data"
]
}
threat "Unauthorized access" {
description = "Unauthorized access to other users' tasks"
impacts = ["Confidentiality", "Integrity"]
stride = ["Information Disclosure", "Elevation of Privilege"]
information_asset_refs = [
"task_data"
]
}
STRIDE Framework:
- Spoofing - Impersonating someone else
- Tampering - Modifying data or code
- Repudiation - Denying actions
- Information Disclosure - Exposing information
- Denial of Service - Disrupting service
- Elevation of Privilege - Gaining unauthorized access
Step 7: Define Security Controls
Controls are the mitigations you implement to address threats. These go inside your threat blocks:
control "input_validation" {
description = "All user input is validated and sanitized"
implemented = true
implementation_notes = "Using validation library v2.3.1"
}
control "parameterized_queries" {
description = "Use parameterized queries to prevent SQL injection"
implemented = true
implementation_notes = "All database queries use prepared statements"
}
control "authorization_checks" {
description = "Verify user owns the resource before allowing access"
implemented = false
implementation_notes = "TODO: Implement in v1.2.0"
}
Important: Be honest about implementation status. Marking a control as implemented = false helps track your security backlog.
Step 8: Save and Validate
Save your HCL file.
If you've installed threatcl (see the CLI Integration guide), you can validate locally:
$ threatcl validate new-tm.hcl Validated 1 threatmodels in 1 files
Or, you can navigate to your Cloud threat model, hit the three-dots menu, and click "Upload new version" to upload your file ‐ it will be validated here too.
Success! You've created your first threat model.