Assets, Threats, and Mitigations

Table of Contents

What Is Threat Modeling?
Why Threat Modeling Matters
Threat Modeling Process
Identifying Assets
Identifying Threat Actors
Attack Surfaces
Threat Categories
Risk Assessment
Mitigations
Common Threat Modeling Frameworks
Cloud Threat Modeling
Kubernetes Threat Modeling
DevSecOps Threat Modeling
Data Flow Diagrams
Threat Model Template
Enterprise Example
Best Practices


1. What Is Threat Modeling?

Threat modeling is a structured process used to identify:
What needs protection (assets)
What could go wrong (threats)
How attacks might occur
Which controls reduce the risk (mitigations)
The goal is to identify security risks early—during design and development—rather than after deployment.


2. Why Threat Modeling Matters
Threat modeling helps organizations:
Discover design weaknesses
Prioritize security investments
Reduce attack surfaces
Meet compliance requirements
Improve communication between development, operations, and security teams
Build more resilient systems
It is most effective when performed early and updated as systems change.


3. Threat Modeling Process
A common workflow is:
Define System

↓

Identify Assets

↓

Map Data Flows

↓

Identify Threats

↓

Assess Risk

↓

Define Mitigations

↓

Validate Controls

↓

Review Regularly

Threat modeling is an iterative process, not a one-time exercise.


4. Identifying Assets
Assets are anything valuable that should be protected.
Data Assets
Customer information
Payment records
Health records
Source code
Encryption keys
Secrets
Backups
Infrastructure Assets
Virtual machines
Kubernetes clusters
Databases
Storage buckets
Load balancers
Firewalls
Virtual networks
Identity Assets
User accounts
Administrative accounts
IAM roles
Service accounts
API keys
Tokens
Certificates
Business Assets
Revenue-generating applications
Intellectual property
Brand reputation
Regulatory compliance
Customer trust


5. Identifying Threat Actors
Threat actors may include:
External Attackers


Examples:
Cybercriminals
Ransomware groups
Hacktivists
Nation-state actors
Motivations can include financial gain, espionage, disruption, or ideology.
Internal Threats


Examples:
Negligent employees
Malicious insiders
Contractors
Third-party vendors
Internal actors may already have legitimate access, increasing potential impact.
Automated Threats


Examples:
Bots
Vulnerability scanners
Credential stuffing tools
Malware
Automation allows attackers to target many systems quickly.


6. Attack Surfaces
The attack surface is every point where an attacker could interact with the system.

Examples:

Web applications
APIs
Administrative interfaces
Cloud storage
SSH or RDP endpoints
Kubernetes API server
Identity providers
CI/CD pipelines
Third-party integrations
Reducing unnecessary exposure lowers overall risk.


7. Threat Categories
One widely used framework is STRIDE.

Category Example
Spoofing Stolen credentials used to impersonate a user
Tampering Unauthorized modification of data or configuration
Repudiation User denies performing an action due to insufficient logging
Information Disclosure Sensitive data exposed through misconfiguration
Denial of Service Resource exhaustion preventing legitimate access
Elevation of Privilege User gains higher permissions than intended

Other frameworks, such as MITRE ATT&CK, can complement STRIDE by focusing on attacker behaviors.


8. Risk Assessment
Risk is commonly evaluated using:
Likelihood
Impact


Example matrix:
Likelihood Impact Priority
High High Critical
High Medium High
Medium Medium Medium
Low High Medium
Low Low Low

Prioritize mitigations for high-risk scenarios first.


9. Mitigations
Mitigations reduce the likelihood or impact of threats.
Identity


Threat:
Compromised administrator account


Mitigations:
Multi-factor authentication
Least privilege
Privileged access reviews
Temporary administrative access
Networking


Threat:
Unauthorized access to internal services
Mitigations:
Private networking
Firewalls
Network segmentation
Zero Trust access controls
Data


Threat:
Sensitive information exposed
Mitigations:
Encryption at rest
Encryption in transit
Access controls
Data classification
Backup and recovery
Applications


Threat:
Exploitation of software vulnerabilities
Mitigations:
Secure coding
Input validation
Dependency management
Regular patching
Web application firewalls where appropriate


10. Common Threat Modeling Frameworks
STRIDE
Focuses on six categories of threats affecting systems.
DREAD
Scores risk using factors such as:
Damage
Reproducibility
Exploitability
Affected users

Discoverability
(Some organizations now prefer simpler likelihood/impact scoring.)

PASTA
A risk-centric methodology emphasizing attacker objectives and business impact.

MITRE ATT&CK
Maps attacker tactics and techniques observed in real-world incidents and is useful for detection engineering and defensive planning.


11. Cloud Threat Modeling
Cloud assets include:
IAM roles
Virtual networks
Compute instances
Managed databases
Storage buckets
Kubernetes clusters

Common cloud threats:
Threat Example Mitigation
Public storage exposure Block public access by default, review policies
Excessive IAM permissions Least privilege, periodic access reviews
Compromised API keys Secret management, rotation, monitoring
Misconfigured security groups Automated configuration scanning
Unencrypted data Enable encryption by default


12. Kubernetes Threat Modeling
Assets:
Cluster
Nodes
Pods
Secrets
Service accounts
Container images
Threats:
Container escape
Privilege escalation
Exposed Kubernetes API
Malicious container image
Secret leakage
Mitigations:
RBAC
Network Policies
Pod Security Standards
Image scanning
Admission controls
Runtime monitoring


13. DevSecOps Threat Modeling
Pipeline assets:
Developer

↓

Source Code

↓

Build Pipeline

↓

Container Registry

↓

Deployment

↓

Production

Potential threats:
Stolen credentials
Malicious dependencies
Secret exposure
Pipeline tampering
Compromised build agents
Mitigations:
Branch protection
Code review
Secret scanning
Dependency scanning
Artifact signing
Least-privilege service accounts


14. Data Flow Diagrams
Data Flow Diagrams (DFDs) help visualize how information moves through a system.
Example:

User

↓

Load Balancer

↓

Web Application

↓

API

↓

Database

↓

Backup Storage

For each flow, ask:
What data is transmitted?
Is it encrypted?
Who can access it?
What happens if it is intercepted or modified?


15. Threat Model Template
System
Brief description of the application or service.
Assets
Customer data
Source code
Databases
Secrets
Infrastructure
Threat Actors
External attackers
Insiders
Third-party vendors
Automated bots
Attack Surfaces
Web interface
API
Administrative portal
Cloud storage
CI/CD pipeline
Threats
Threat Asset Risk
Credential theft IAM accounts High
SQL injection Database High
Public storage exposure Customer data High
Denial of service Web application Medium

Mitigations
Threat Mitigation
Credential theft MFA, least privilege, monitoring
SQL injection Parameterized queries, input validation
Public storage Restrictive bucket policies, encryption
DoS Rate limiting, autoscaling, traffic filtering


16. Enterprise Example
Scenario
A cloud-hosted e-commerce platform.
Architecture:

Customers

↓

Web Application

↓

API

↓

Kubernetes Cluster

↓

Database

↓

Object Storage

↓

Logging and Monitoring

Assets
Customer accounts
Payment records
Product catalog
API keys
Encryption keys
Threats
Account takeover
API abuse
Data leakage
Ransomware
Supply chain compromise
Insider misuse
Mitigations
MFA for administrators
Web application firewall
API authentication and rate limiting
RBAC
Network segmentation
Encryption
Immutable backups
Continuous monitoring
Incident response playbooks


17. Best Practices
Start threat modeling during system design.
Include developers, operations, and security teams.
Keep architecture diagrams up to date.
Focus on realistic attacker scenarios.
Revisit the threat model after significant architectural changes.
Prioritize high-risk threats first.
Document assumptions and accepted risks.
Validate that planned mitigations are actually implemented.
Align threat models with security testing, logging, and incident response.


Final Summary
Threat modeling is a proactive security practice that helps teams understand what they are protecting, how it could be attacked, and how to reduce risk before systems reach production.
An effective threat model answers three fundamental questions:

What are our critical assets?
What threats could affect those assets?
What mitigations will reduce the likelihood or impact of those threats?


By integrating threat modeling into architecture reviews, Infrastructure as Code, CI/CD pipelines, and cloud operations, organizations can make security decisions based on risk rather than reacting only after vulnerabilities or incidents are discovered.