Seeing the System Through an Attacker’s Eyes.
Threat modeling is the structured way of asking that question _before_ attackers do — while the system is still on paper, not already deployed in production.
“What could go wrong here?”
It is not a tool, not a document, and not a one-time exercise.
Threat modeling is a way of thinking that sits at the intersection of architecture, risk, and real-world attack behavior.
Why Threat Modeling Exists
Modern systems are complex by default:
- Multiple services
- External APIs
- User devices
- Cloud infrastructure
- Firmware, networks, and data stores
Every connection introduces trust, and every trust relationship introduces risk.
Threat modeling exists to:
- Identify what needs protection
- Understand who might attack
- Discover how attacks could happen
- Decide where defenses actually matter
Without threat modeling, security becomes reactive — fixing bugs _after_ damage is done.
Threat Modeling Starts With the System
You cannot protect what you do not understand.
The first step is not “threats” — it is structure.
High-Level System View
+--------+ +-------------+ +--------------+
| User | -----> | Web / API | -----> | Application |
+--------+ +-------------+ +--------------+
|
v
+--------------+
| Database |
+--------------+
At this level, we are not thinking about attacks yet.
We are simply answering:
- What are the components?
- How do they communicate?
- Where does data flow?
This diagram becomes the foundation of the entire threat model.
Assets: What Are We Protecting?
An asset is anything that has value — technical, financial, or reputational.
Assets are not only data.
Common Asset Categories
- User credentials
- Personal data
- Financial records
- Firmware images
- Cryptographic keys
- System availability
- Trust in the brand
Example:
[ Credentials ] [ User Data ] [ Firmware ]
| | |
+--------[ Application ]---------+
If an attacker compromises an asset, something bad happens — money, privacy, safety, or trust.
Threat modeling always revolves around assets.
Trust Boundaries: Where Assumptions Change
A trust boundary is a place where assumptions stop being safe.
Crossing a trust boundary means:
- Data becomes untrusted
- Input must be validated
- Authentication and authorization must be enforced
Example Trust Boundaries
Internet
|
| (Untrusted)
v
+---------+ <-- Trust Boundary
| Backend |
+---------+
|
| (Trusted)
v
+----------+
| Database |
+----------+
If you treat _untrusted_ data as trusted, you have already lost.
Most serious vulnerabilities exist exactly at trust boundaries.
Introducing Threats
A threat is a potential way an attacker could harm an asset.
Threats answer the question:
_“How could this system be abused?”_
They are not vulnerabilities yet — they are _possibilities_.
To make threat discovery systematic, we use threat categories.
STRIDE: A Structured Way to Think About Threats
One of the most widely used threat categorization models is STRIDE.
Each letter represents a class of attacker behavior:
S - Spoofing (pretending to be someone else)
T - Tampering (modifying data or code)
R - Repudiation (denying actions)
I - Information Disclosure (data leaks)
D - Denial of Service (availability loss)
E - Elevation of Privilege (gaining more power)
STRIDE helps ensure you don’t miss entire categories of attacks.
Applying STRIDE to a Data Flow
Let’s take a single data flow and walk through it.
User -> API -> Application -> Database
Now apply STRIDE at each step.
Example Threat Mapping
User -> API
- Spoofing: Fake user identity
- Tampering: Modified request payload
- DoS: Request flooding
API -> Application
- Elevation of Privilege
- Information Disclosure
Application -> Database
- Tampering: SQL injection
- Repudiation: Missing audit logs
This transforms an abstract system into concrete attack scenarios.
Threats Become Risks
Not all threats are equal.
A threat becomes a risk when we consider:
- Likelihood
- Impact
Simple Risk Matrix
Impact
^
| High | Medium | Low
|
+----------------------------> Likelihood
Example:
- Credential theft → High impact, medium likelihood
- UI defacement → Low impact, high likelihood
Threat modeling helps teams prioritize, not panic.
From Threats to Mitigations
A threat model is useless if it stops at identification.
Each significant threat must lead to a decision.
Common Mitigation Strategies
- Authentication
- Authorization
- Encryption
- Input validation
- Rate limiting
- Logging and monitoring
- Secure boot and firmware signing
Example Mapping
Threat: Spoofing
Mitigation: Strong authentication + MFA
Threat: Tampering
Mitigation: Cryptographic signatures
Threat: DoS
Mitigation: Rate limiting + circuit breakers
Security becomes intentional, not accidental.
Threat Modeling Is Iterative
Threat modeling is not a one-time document.
It evolves with the system.
Design -> Threat Model -> Implement
^ |
| v
+-------- Review <---- Change
You revisit the threat model when:
- Architecture changes
- New features are added
- New attackers emerge
- New regulations apply
Living systems require living security.
Threat Modeling in Embedded and IoT Systems
In embedded systems, threat modeling becomes even more critical.
Assets are physical.
Attackers may have the device in their hands.
+---------+
| Attacker|
+---------+
|
v
+---------+ +-------------+
| Device | ---> | Cloud API |
+---------+ +-------------+
Additional threats include:
- Firmware extraction
- Debug interface abuse
- Fault injection
- Supply-chain attacks
Here, threat modeling connects directly to:
- Secure boot
- Hardware root of trust
- OTA update security
The Real Value of Threat Modeling
Threat modeling does not make systems “perfectly secure”.
It does something far more valuable:
- It makes risk visible
- It aligns security with architecture
- It forces early, cheap decisions
- It builds a shared security mindset
A team that threat models consistently does not _hope_ for security —
they design for it.
Closing Thought
Every system already has a threat model.
The only question is:
- Is it implicit and wrong, or
- Explicit and deliberate?
Threat modeling is how engineers stop guessing — and start defending with intent.