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 it
  • degraded   - System works with reduced functionality
  • none   - 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.

Next Steps

Understanding HCL Syntax

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us