Threat Modeling

Technique · Chapter 11

What It Is

• A structured approach to analyzing an application’s security. A threat is a possible danger that may cause serious harm.
• Identifies and prioritizes potential threats so the team knows where the app is most vulnerable, with the goal of reducing overall security risk.
• Modern practice takes the attacker’s viewpoint (a threat agent is anyone who may attack and exploit vulnerabilities), not just the defender’s.
• Most effective when done during design/development, but can also be applied to existing systems.

High-level flow: decompose the system → identify & categorize threats → prioritize threats → create mitigations.

Decomposing an Application

Build an understanding of the system to uncover vulnerabilities. Catalog:

• Assets — things of value to attackers; physical (credentials, data) or abstract (reputation).
• Potential attackers — external and internal; motivated by the assets identified.
• External entities — users and external systems the app interacts with.
• Entry points — where attackers can interact with the system; attackers concentrate their efforts here.

Identifying & Categorizing Threats — STRIDE

Categorization needs an agreed threat classification model. STRIDE (from Microsoft) defines six categories:

Category	What it is	Counter
Spoofing identity	Posing as someone else (stolen credentials, forged email, altered headers)	Strong authentication
Tampering with data	Modifying data at rest, in transit, or in files	Integrity checks
Repudiation	Denying an action because the system didn’t log/trace it	Non-repudiation: strong auth, thorough logging, digital certificates
Information disclosure	Leaking data to those not authorized (DB reads, in-transit sniffing, verbose errors)	Encryption, least privilege
Denial-of-service	Denying service to valid users; DDoS floods from many sources	Rate limiting, redundancy
Elevation of Privilege	Gaining rights beyond what was granted (dangerous — attacker is inside the trusted system)	Least privilege, authorization checks

Prioritizing Threats — DREAD

Rank by impact, likelihood, and ease of exploit — qualitatively (High/Medium/Low) or with a threat-risk model. DREAD (from Microsoft) scores each factor (e.g. 1–10); the mean of the factors is the threat’s risk level (higher = higher priority):

• Damage potential — how bad if it succeeds (financial liability to reputation damage).
• Reproducibility — how reliably the attack can be reproduced.
• Exploitability — how hard it is to exploit (skill/tooling required).
• Affected users — percentage of the user base impacted.
• Discoverability — how easy to learn about the vulnerability.

Note: many practitioners drop discoverability (DREAD-D) or max it out for every threat — “security by obscurity” is a weak control, so difficulty of discovery shouldn’t lower a threat’s rank.

Responses to Threats

The same options as project software risk management, applied to security:

• Avoid — change things so the risk no longer exists (not all risks can be avoided; avoidance can create new risks).
• Transfer — shift to another party via insurance or contracts (e.g. a cloud provider handling physical/environmental/data security). Insurance may not undo reputational damage.
• Accept — for low-priority threats, knowingly accept the risk.
• Mitigate — implement a security control to reduce likelihood and/or damage.

Types of Security Control

Controls (countermeasures/safeguards) are categorized two ways — by mechanism and by goal — and a control combines one of each (e.g. “technical + detection”):

By mechanism

• Physical — gates, locks, key cards, surveillance, alarms, security personnel; often outsourced to cloud providers.
• Administrative — organizational policies and procedures: security awareness training, escalation plans, ID badges, acceptable-use and password policies, anti-virus mandates, patch procedures, monitoring, service continuity plans. Includes pre-employment screening (background/credit checks) and termination procedures to revoke access promptly — screening is continuous, not one-and-done.
• Technical — technology-based: encryption, hashing, authentication, authorization, logging, monitoring, secure protocols, hardware/network protection, database security.

By goal

• Prevention — avert a threat before it occurs (locks, training, encryption, patches, firewalls, anti-virus).
• Detection — assume prevention will fail; detect and notify (cameras, motion detectors, monitoring, logging, auditing, anti-malware).
• Response — pre-planned reactions (sound alarms, lock doors, escalation/service-continuity plans, take servers offline, quarantine, roll back, restore from backup, revoke permissions).

Related

• Secure by design provides principles that reduce the attack surface exposed here.
• Cryptography and IAM are common technical mitigations.

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.11 “Threat modeling”, pp. 826-855.