CS: Threat Modeling

Threat modeling is the structured habit of asking what could go wrong before attackers do, covering assets, trust boundaries, STRIDE, risk rating with DREAD, attack trees and a step-by-step process that produces a security document.

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

md 
+--------+        +-------------+        +--------------+
|  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:

md 
[ 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

md 
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:

md 
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.

md 
User -> API -> Application -> Database

Now apply STRIDE at each step.

Example Threat Mapping

md 
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

md 
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

md 
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 Approaches

Three lenses for choosing where to start. Selecting the right one depends on system complexity, available expertise, and what you're most worried about.

Attacker-Centric

Start with the adversary. Ask: who would attack this, why, and how?

  • Builds realistic attack scenarios from the attacker's perspective
  • Considers motivation, identity (insider vs external), and capabilities
  • Uncovers attack paths that design-first approaches miss

Asset-Centric

Start with what matters. Ask: what are we protecting, and what happens if we lose it?

  • Maps assets (data, keys, services, brand trust) to potential threats
  • Aligns security priorities with business value
  • Less focused on specific code flaws, more on high-level risk

Systems-Centric

Start with the architecture. Ask: how do components connect, and where can those connections be exploited?

  • Maps subsystems, data flows, and interaction points
  • Applies STRIDE at each component boundary
  • Requires deep system knowledge but produces the most precise threat inventory

In practice, most models combine all three: understand the system structure, identify the valuable assets, then reason from the attacker's perspective.

Threat Modeling Is Iterative

Threat modeling is not a one-time document.

It evolves with the system.

md 
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.

md 
+---------+
| 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.

The Threat Modeling Process

The ideas above fit into a repeatable seven-step process. Following it systematically lets you strengthen security proactively and reduce the likelihood of successful attacks.

txt 
1. Identify assets
2. Architecture overview
3. Decompose the application
4. Document the security profile
5. Identify threats (STRIDE, attack trees)
6. Document threats with a template
7. Rate and prioritise (DREAD)

1. Identify Valuable Assets

Start with what must be protected: sensitive data, critical components, business processes. Their value drives every later prioritisation decision.

2. Develop an Architecture Overview

Create a high-level view of what the application does and how it operates in its environment:

  • Architecture diagrams showing structure and composition
  • Subsystems and their interactions
  • Technologies used, for example a web server such as Nginx, a Python web application with forms authentication, a database such as Oracle, and SSL/TLS protecting HTTP traffic
  • Trust boundaries, data flows, and physical deployment characteristics

Simple diagrams and tables are enough.

3. Decompose the Application

Break the system into smaller parts to uncover hidden threats:

  • Identify trust boundaries around assets; data crossing from an untrusted boundary must be validated, authenticated, and authorised
  • Map data flows from entry points to exit points
  • Understand interactions between internal components and external systems
  • Identify all entry points, since each is a potential attack vector
  • Identify privileged code that accesses sensitive resources or performs critical operations, and make sure it does not expose those resources to untrusted or malicious components

4. Document the Security Profile

Record the security mechanisms and design approaches in place, which highlights where the system may be vulnerable:

  • Input validation
  • Authentication controls
  • Authorisation model
  • Configuration management practices

5. Identify Threats

With the system understood, identify threats at the network, host, and application level. STRIDE (above) answers "what can go wrong in this system?" and each category violates a security property:

STRIDEProperty violated
SpoofingAuthentication
TamperingIntegrity
RepudiationNon-repudiation
Information DisclosureConfidentiality
Denial of ServiceAvailability
Elevation of PrivilegeAuthorisation

Attack trees (threat trees) complement STRIDE by laying out attack paths hierarchically. For example, a tree can show the several ways an attacker could obtain authentication credentials over a network, with the goal at the root and alternative attack steps as branches.

6. Document Threats Using a Standard Template

Record every threat consistently so stakeholders can compare and discuss them:

  • Threat description
  • Target asset
  • Attack techniques
  • Countermeasures
  • Risk rating (left blank until step 7)

7. Perform Risk Rating and Prioritisation

Evaluate each threat by its risk level:

text 
Risk = Probability × Damage Potential

The DREAD framework scores a threat on five factors:

FactorQuestion
Damage potentialHow severe is the impact if exploited?
ReproducibilityHow easily can the attack be repeated?
ExploitabilityHow easy is it to launch the attack?
Affected usersWhat percentage of users is impacted?
DiscoverabilityHow easy is it to discover the vulnerability?

Then bucket threats on a simple scale and update the template:

  • High: requires immediate mitigation
  • Medium: requires timely attention
  • Low: may be deferred depending on cost and effort

Output of the Process

The result is a security document covering:

  • Identified assets and system actors
  • Use cases and system interactions
  • Potential threats and associated vulnerabilities
  • Risk ratings and prioritisation
  • Recommended countermeasures

It shows the system's security posture and is the foundation for ongoing risk management and secure design. Applied throughout the system lifecycle, it improves resilience.