4. Threat Modeling and Attack-Surface Analysis

Introduction and Context

Secure software development is more effective when security is considered before code is written and continuously revisited as a system changes. Threat modeling provides a structured way to anticipate how a system could be misused, compromised, or disrupted. Attack-surface analysis complements it by identifying the points through which an attacker may interact with the system, obtain influence, move between components, or reach valuable assets.

Threat modeling is not simply the production of a diagram or a list of vulnerabilities. It is a reasoned analysis of assets, actors, trust relationships, system behavior, threats, and controls. It connects architecture with security decision-making. A development team can use it to decide whether an authentication service should be isolated, whether an API should accept a particular input, whether a database requires encryption, or whether a privileged workflow needs additional approval.

For postgraduate practitioners, the important challenge is to move beyond checklist-based security. A useful threat model must reflect business purpose, technical architecture, operational context, attacker capability, regulatory obligations, and uncertainty. It must also remain useful throughout the software lifecycle rather than becoming an obsolete document created at project initiation.

Learning Objectives

By the end of this chapter, students should be able to:

• explain the purpose, scope, and limitations of threat modeling;
• construct data-flow diagrams and identify trust boundaries;
• apply STRIDE, attack trees, MITRE ATT&CK, CAPEC, and risk-ranking methods;
• identify threat actors, assets, attack paths, and security assumptions;
• propose proportionate preventive, detective, and corrective mitigations;
• evaluate a threat model in relation to architecture, governance, and risk appetite;
• maintain threat models as systems, dependencies, and threats evolve.

From Assets to Attack Paths

A threat model begins with the system’s security objectives. Confidentiality, integrity, availability, authenticity, accountability, privacy, and safety may all be relevant, but their relative importance depends on context. A public information site may prioritize availability and integrity, whereas a clinical platform may place equal importance on confidentiality, safety, and accountability.

An asset is something that has value or requires protection. Assets include data, credentials, cryptographic keys, business functions, infrastructure, intellectual property, and trust relationships. An asset need not be a physical object. The ability to approve a payment or issue an identity token is also an asset because misuse can create serious consequences.

A threat is a potential cause of harm. A threat actor is an individual, group, organization, or system capable of causing that harm. Actors may include opportunistic criminals, organized groups, insiders, competitors, hacktivists, nation-state operators, compromised suppliers, or automated bots. Threat modeling should avoid assuming that every actor has identical resources or objectives. Capability, access, motivation, persistence, and tolerance for detection all influence the plausibility of an attack.

A vulnerability is a weakness that can be exploited. A risk arises from the interaction of a threat, a vulnerability, the likelihood of exploitation, and the resulting impact. A system may have a vulnerability without an immediately significant risk if it is isolated and difficult to reach; conversely, a modest weakness in a highly exposed payment workflow may deserve urgent treatment.

An attack path is a sequence of actions that connects an entry point to a target asset. Attack paths frequently cross component boundaries. For example, an attacker may exploit a public API, obtain a low-privilege account, abuse an authorization flaw, access an internal service, and then retrieve sensitive records. Thinking in paths prevents teams from treating vulnerabilities as isolated technical defects.

Modeling the System with Data-Flow Diagrams

A data-flow diagram (DFD) represents how data and control move through a system. In threat modeling, a DFD normally distinguishes four elements:

1. External entities: users, administrators, partner systems, devices, or external services outside the modeled system.

2. Processes: operations that transform, validate, authorize, or transmit data.

3. Data stores: databases, files, queues, caches, logs, backups, and secrets repositories.

4. Data flows: communications or transfers between entities, processes, and stores.

A DFD should be sufficiently detailed to reveal security decisions without becoming an implementation diagram. It should show authentication, authorization, sensitive data, administrative interfaces, third-party dependencies, and important protocols. A single diagram may be supported by several levels: a context diagram, a container-level diagram, and detailed diagrams for high-risk workflows.

The most important feature of a security-oriented DFD is the trust boundary. A trust boundary marks a change in the level of trust, control, or security assumptions between two areas. Examples include the boundary between the public internet and a web application, between a customer network and a cloud service, between a user process and a privileged service, or between an organization and a software supplier.

Trust boundaries are not always identical to network boundaries. Two services in the same virtual network may have different identities, privileges, or assurance levels. Conversely, a secure encrypted connection across a network does not eliminate the need to assess the endpoints. Each crossing should prompt questions such as:

• What is assumed about the sender and receiver?
• Is the data authenticated, authorized, validated, and protected in transit?
• Can an attacker alter, replay, delay, or redirect it?
• What happens if the receiving component is compromised?
• Is the boundary represented in logging and monitoring?

Data-flow modeling should include system states and privileged operations where necessary. A diagram that shows only normal data movement may conceal escalation paths. Administrative channels, recovery mechanisms, batch jobs, deployment pipelines, and support tools often deserve explicit treatment because they can bypass ordinary user controls.

STRIDE as a Structured Threat-Identification Method

STRIDE is a mnemonic for six categories of threats:

• Spoofing: pretending to be another user, service, or device.
• Tampering: unauthorized modification of data, code, configuration, or messages.
• Repudiation: denying an action because evidence is insufficient or unreliable.
• Information disclosure: exposing data to an unauthorized party.
• Denial of service: reducing availability or degrading performance.
• Elevation of privilege: obtaining capabilities beyond those authorized.

STRIDE is applied to DFD elements and trust-boundary crossings. For a payment API, spoofing may involve stolen tokens; tampering may involve changing transaction values; repudiation may result from inadequate audit records; information disclosure may arise from verbose error responses; denial of service may involve resource exhaustion; and elevation of privilege may occur through broken object-level authorization.

STRIDE is valuable because it creates disciplined coverage. It does not, however, calculate risk automatically. A team must still determine which threats are realistic, what assets are affected, how severe the consequences are, and which controls are appropriate. STRIDE can also miss business-logic abuse if analysts focus narrowly on technical categories. It should therefore be supplemented with abuse cases, attack trees, privacy analysis, and domain expertise.

Attack Trees and the Logic of Adversarial Goals

An attack tree starts with an attacker’s ultimate goal and decomposes it into subgoals. The root might be “obtain unauthorized access to patient records.” Lower-level nodes could include obtaining valid credentials, bypassing authorization, compromising an administrator workstation, or exploiting a backup. Nodes connected by OR represent alternative routes; AND nodes represent conditions that must be satisfied together.

Attack trees are particularly useful for understanding combinations of weaknesses. A successful attack may require both an exposed management endpoint and a leaked administrative credential. The tree can expose where one mitigation breaks several routes, such as enforcing phishing-resistant authentication for all privileged accounts.

A good attack tree describes attacker actions rather than merely listing vulnerabilities. It may also record prerequisites, required capability, detectability, estimated effort, and defensive controls. Analysts should avoid treating tree completeness as proof of security: an unknown route may still exist, and the tree’s assumptions must be reviewed when architecture changes.

Relating Threat Models to MITRE ATT&CK and CAPEC

MITRE ATT&CK is a knowledge base describing adversary tactics and techniques observed or modeled across enterprise, cloud, mobile, and other environments. Tactics express objectives such as credential access, discovery, lateral movement, or exfiltration. Techniques describe how those objectives may be achieved. ATT&CK is useful for mapping a threat model to operational detection and response: a modeled attack path can be associated with expected telemetry, detection rules, and response procedures.

CAPEC, the Common Attack Pattern Enumeration and Classification, describes recurring attack patterns, including injection, credential manipulation, abuse of functionality, and resource exhaustion. CAPEC is especially helpful during software design because it describes patterns of exploitation and can be linked to design weaknesses, secure coding practices, and test cases.

These resources serve different purposes. STRIDE helps generate threats from system structure; attack trees express adversarial goals and alternatives; CAPEC captures recurring software attack patterns; and ATT&CK supports adversary-behavior analysis, detection, and response. They should be treated as complementary reference systems rather than interchangeable scoring mechanisms.

For example, a threat model for a cloud administration portal might identify elevation of privilege through an authorization flaw using STRIDE. CAPEC can provide relevant patterns for privilege manipulation. An attack tree can show how the flaw contributes to account takeover. ATT&CK can then support analysis of credential access, valid-account use, cloud service discovery, and data collection after compromise.

Risk Ranking and Mitigation Selection

Threat identification becomes useful only when it supports decisions. A practical ranking method considers impact, likelihood, exposure, attacker capability, exploit prerequisites, detectability, and existing controls. Quantitative estimates may be appropriate where reliable data exists, but false precision is dangerous. Qualitative scales such as low, moderate, high, and critical can be effective if their meanings are explicitly defined.

A useful risk statement has the form: “A specified actor may perform a specified action against a specified component, causing a specified consequence.” For example: “A malicious authenticated customer may alter an object identifier in the reporting API, retrieve another customer’s invoices, and cause confidentiality and regulatory harm.” This is more actionable than “IDOR vulnerability.”

Mitigations should address the attack path and not merely its most visible symptom. Controls may be:

• Preventive, such as strong authentication, least privilege, input validation, segmentation, and secure defaults;
• Detective, such as audit logging, anomaly detection, integrity monitoring, and alerting;
• Corrective or responsive, such as credential revocation, isolation, backup restoration, and incident response procedures;
• Compensating, where the preferred control is not currently feasible but risk can be reduced through another measure.

Teams should record residual risk after mitigation. Acceptance of residual risk must be assigned to an accountable owner, not silently transferred to developers. High-impact assumptions should be documented, tested, and given an expiry or review date.

A Repeatable Threat-Modeling Workflow

An effective workflow is iterative rather than ceremonial. It normally includes the following activities:

1. Establish scope and objectives. Define the system, business processes, environments, users, assets, security objectives, and assumptions.

2. Decompose the architecture. Create DFDs, identify components, data stores, interfaces, privileged functions, dependencies, and trust boundaries.

3. Enumerate threats. Apply STRIDE, abuse cases, attack trees, CAPEC patterns, privacy analysis, and relevant threat intelligence.

4. Develop attack paths. Connect entry points, weaknesses, privileges, movement opportunities, and target assets.

5. Assess risk. Consider impact, likelihood, exposure, control strength, uncertainty, and organizational risk appetite.

6. Select and assign mitigations. Define security requirements, design changes, testing activities, monitoring, ownership, and deadlines.

7. Validate. Review assumptions through architecture review, penetration testing, code analysis, configuration assessment, and tabletop exercises.

8. Maintain. Update the model when there are material changes to code, interfaces, data, identity, deployment, suppliers, or threat intelligence.

The participants should include developers, architects, security specialists, operations personnel, product owners, and—where appropriate—privacy, legal, compliance, and business representatives. Cross-functional participation is important because technical likelihood and business impact are often understood by different groups.

Applied Case: Threat Modeling a Digital Payments Platform

Background

This illustrative case concerns “PayLink,” a fictional platform that allows customers to register accounts, link bank cards through a payment provider, create invoices, and receive payment notifications. The platform contains a web front end, mobile application, API gateway, identity service, payment-service integration, relational database, message queue, analytics store, and administrative console.

Situation and Problem

The product team planned to release a feature allowing merchants to issue refunds through the mobile application. Earlier testing had identified an authorization defect in a different API, but no systematic model existed for the new workflow. Management wanted assurance that the release would not enable fraudulent refunds or expose payment information.

Analysis

The team first mapped the workflow. A merchant authenticated through the identity service sends a refund request to the API gateway. The refund service validates the invoice, calls the external payment provider, stores the result, and publishes a notification. The administrative console can override failed refunds. Trust boundaries existed between mobile clients and the API, the platform and payment provider, the application and database, and ordinary merchant functions and administrative functions.

Using STRIDE, the team identified spoofing through stolen merchant tokens, tampering with refund amounts and invoice identifiers, repudiation caused by incomplete audit records, disclosure through payment-provider responses, denial of service through repeated refund requests, and elevation of privilege through confusion between merchant and administrator roles.

An attack tree was constructed around the goal “obtain unauthorized financial benefit.” One branch involved taking over a merchant account. Another involved changing an invoice identifier to refund a different customer’s transaction. A third involved replaying a valid refund request. The analysis showed that the greatest concern was not a single coding error but the combination of weak object-level authorization, missing idempotency, and insufficient transaction-state validation.

CAPEC patterns informed test cases for parameter manipulation, replay, and abuse of functionality. ATT&CK mapping helped the operations team identify expected signals for valid-account misuse, unusual access patterns, and administrative activity from unmanaged devices.

Approach and Solution

The team required server-side authorization based on the merchant-to-invoice relationship rather than trusting identifiers supplied by the client. Refund amounts were derived from authoritative transaction records, and business rules prevented refunds exceeding the captured amount. Each request received an idempotency key, with duplicate requests producing the same result rather than multiple provider calls. Administrative overrides required stronger authentication, a separate permission, reason codes, and immutable audit events.

The payment-provider response was minimized before storage and display. Rate limits, anomaly detection, and alerts for unusual refund volume were added. Threat-model findings were converted into security requirements, unit and integration tests, deployment checks, and operational runbooks.

Outcome

The release was delayed briefly while authorization and transaction-state controls were implemented. Testing demonstrated that ordinary merchants could no longer access another merchant’s invoice, repeated requests did not generate repeated refunds, and administrative actions were attributable. The model was added to the architecture repository and linked to the refund service’s change record.

Learning Points

The case demonstrates that threat modeling is most valuable when it examines business operations, not only technical components. Attack trees exposed alternative fraud routes, STRIDE supplied systematic coverage, CAPEC supported testing, and ATT&CK connected design concerns with monitoring. It also illustrates why threat models must include administrative paths, third-party interactions, and workflow invariants.

Organizational and Professional Practice

Threat modeling should be integrated with secure architecture review, requirements management, secure coding, testing, vulnerability management, and incident response. In mature organizations, security requirements derived from the model become traceable work items. Code changes are reviewed against affected threats, and security tests are mapped to important attack paths.

A threat-model repository should have ownership, version control, review status, and links to architecture decisions. Teams should distinguish accepted assumptions from verified controls. Models are particularly likely to become stale after cloud migration, identity redesign, acquisition of a new supplier, introduction of an API, or deployment of artificial-intelligence components.

Automation can assist but cannot replace judgment. Tools can generate DFDs from infrastructure descriptions, scan repositories for exposed interfaces, map assets to known techniques, calculate dependency exposure, and monitor changes. Artificial intelligence may suggest threats or summarize architectural changes, but its output requires expert validation. Automated suggestions can omit business logic, misunderstand trust relationships, or overstate threats based on superficial similarity.

Challenges, Limitations, and Common Errors

Several recurring problems reduce the value of threat modeling. Treating the exercise as a one-time compliance document produces stale results. Modeling only the production application while excluding CI/CD pipelines, support tooling, backups, and suppliers leaves important attack paths unexplored. Assuming that a trust boundary is secure because traffic is encrypted confuses confidentiality in transit with trustworthy authorization.

Other common errors include listing vulnerabilities without consequences, ranking every threat as high, failing to identify asset owners, and recommending controls without considering usability or operational feasibility. Teams may also focus on external attackers while neglecting insiders, compromised accounts, malicious dependencies, and accidental misuse.

Threat models are abstractions. They cannot prove that a system is secure, predict every attacker behavior, or replace code review, testing, monitoring, and incident response. Their value depends on accurate assumptions, appropriate scope, skilled analysis, and continued maintenance.

Ethical, Governance, and Regulatory Considerations

Threat modeling involves sensitive architectural information and sometimes personal data. Access to models should be controlled, but excessive secrecy can prevent the collaboration needed for effective analysis. Organizations should document who may view, modify, and approve models and should protect them from unauthorized disclosure.

Privacy threat modeling should address excessive collection, secondary use, inference, re-identification, unauthorized access, retention, and loss of individual control. Security controls must also respect legitimate user rights and avoid disproportionate surveillance. Regulatory obligations may require protection of personal, financial, health, or critical-infrastructure data, but compliance should be treated as a baseline rather than a substitute for engineering judgment.

Professional responsibility requires analysts to communicate uncertainty honestly, escalate material risks, and avoid concealing unresolved weaknesses through ambiguous language. Risk acceptance should be informed, authorized, and reviewable.

Current Developments

Modern threat modeling increasingly addresses cloud-native architectures, service meshes, infrastructure as code, software supply chains, zero-trust identity, and machine-learning systems. Ephemeral workloads make static diagrams less sufficient; architecture metadata, deployment events, and runtime inventories can help maintain current models. Software bills of materials and provenance records improve analysis of dependency-related attack paths.

Continuous threat modeling links architecture changes to automated review. A new public endpoint, permission, data store, or supplier integration can trigger reassessment. For AI-enabled systems, analysts must additionally consider prompt injection, data poisoning, model extraction, sensitive-data disclosure, insecure tool use, and unsafe autonomy. These developments reinforce a central principle: the model must follow the system and its dependencies, not merely the original project plan.

Best Practices

Effective practice is characterized by the following principles:

• model assets, actors, data, privileges, and business workflows together;
• make trust boundaries and security assumptions explicit;
• combine STRIDE with attack trees, abuse cases, CAPEC, ATT&CK, and privacy analysis;
• describe risks as concrete actor-action-consequence statements;
• prioritize attack paths rather than isolated findings;
• assign each mitigation an owner, evidence requirement, and review date;
• include preventive, detective, and recovery controls;
• validate models through testing and operational exercises;
• version models alongside architecture and code changes;
• revisit models after material technical, business, or threat changes.

Chapter Summary

Threat modeling is a structured practice for understanding how systems may be attacked and how security objectives can be protected. Data-flow diagrams reveal processes, stores, flows, and trust boundaries. STRIDE provides systematic threat categories, while attack trees represent attacker goals and alternative routes. CAPEC contributes reusable software attack patterns, and MITRE ATT&CK connects modeled behaviors with detection and response.

A mature process identifies assets, actors, assumptions, vulnerabilities, attack paths, impacts, and residual risks. It converts findings into requirements, design changes, tests, monitoring, and accountable decisions. Threat models are abstractions with limitations, so they must complement secure coding, code analysis, testing, governance, and incident response. Their continued value depends on maintenance as architectures, suppliers, identities, technologies, and threats evolve.

Key Terms

Asset: A data item, capability, system, or resource requiring protection.

Attack path: A sequence of actions connecting an entry point to a target asset.

Attack tree: A hierarchical representation of ways an attacker may achieve a goal.

CAPEC: A catalog of common attack patterns relevant to software and systems.

Data-flow diagram: A model showing entities, processes, stores, and movement of data.

Elevation of privilege: Obtaining authority beyond that legitimately granted.

External entity: A user, system, or organization outside the modeled system boundary.

Information disclosure: Unauthorized exposure of information.

MITRE ATT&CK: A knowledge base of adversary tactics and techniques.

Repudiation: Denial of an action where reliable evidence is unavailable.

Residual risk: Risk remaining after controls have been applied.

Risk appetite: The level and type of risk an organization is willing to accept.

Spoofing: Impersonating an identity, system, or service.

STRIDE: A threat-identification mnemonic covering six major threat categories.

Tampering: Unauthorized alteration of data, code, configuration, or messages.

Threat actor: An entity capable of causing harm to a system or asset.

Threat model: A structured representation of assets, threats, assumptions, and controls.

Trust boundary: A transition between areas with different trust or security assumptions.

Vulnerability: A weakness that can be exploited to cause harm.

Review Questions

Short Answer Questions

1. What is the purpose of a trust boundary in a security-oriented data-flow diagram?

2. Define an attack path and explain why it is more useful than an isolated vulnerability list.

3. What are the six categories represented by STRIDE?

4. How does CAPEC differ from MITRE ATT&CK?

5. What is meant by residual risk?

Long Answer Questions

1. Explain how to construct a data-flow diagram for threat modeling and discuss the information that should be represented.

2. Describe the complete threat-modeling workflow from scoping through maintenance.

3. Compare STRIDE, attack trees, CAPEC, and MITRE ATT&CK in terms of purpose and application.

4. Discuss how threat modeling supports secure architecture, coding, testing, monitoring, and incident response.

5. Analyze the limitations and common organizational failures associated with threat modeling.

Analytical / Application Questions

1. A customer-facing API accepts an object identifier and returns records from a shared database. Develop a threat statement, identify the relevant STRIDE categories, and propose layered mitigations.

2. Construct an attack-tree outline for the goal “issue an unauthorized refund” in a digital payments platform. Identify at least one OR relationship and one AND relationship.

3. A company introduces a cloud-based supplier that receives personal data and administrative credentials. Explain how you would revise the DFD, trust boundaries, threat model, risk assessment, and monitoring plan.

22. Multiple Choice Questions with Answers

Question 1

Which feature of a security-oriented data-flow diagram most directly identifies changes in security assumptions?

A. The number of database tables

B. Trust boundaries

C. The programming language used

D. The user-interface layout

Correct Answer: B. Trust boundaries

Question 2

A user changes an invoice identifier in a refund request to access another merchant’s transaction. Which STRIDE category is most directly involved?

A. Repudiation

B. Denial of service

C. Elevation of privilege

D. Tampering

Correct Answer: D. Tampering

Question 3

What is the primary purpose of an attack tree?

A. To document source-code formatting rules

B. To represent alternative ways of achieving an attacker’s goal

C. To replace penetration testing

D. To calculate network bandwidth

Correct Answer: B. To represent alternative ways of achieving an attacker’s goal

Question 4

Which statement best describes MITRE ATT&CK in relation to threat modeling?

A. It provides a catalog of adversary tactics and techniques useful for detection and response

B. It is a method for drawing database schemas

C. It is a mandatory risk-calculation formula

D. It only describes defects in source code

Correct Answer: A. It provides a catalog of adversary tactics and techniques useful for detection and response

Question 5

A team uses STRIDE to identify threats but does not assess likelihood, impact, or existing controls. What important activity is missing?

A. Risk assessment

B. Data serialization

C. Interface prototyping

D. Compilation

Correct Answer: A. Risk assessment

Question 6

Which control most directly prevents repeated processing of the same refund request?

A. An idempotency mechanism

B. A longer error message

C. A public status page

D. A larger database index

Correct Answer: A. An idempotency mechanism

Question 7

Why should administrative consoles and recovery mechanisms be included in a threat model?

A. They never cross trust boundaries

B. They may provide privileged paths that bypass ordinary user controls

C. They eliminate the need for logging

D. They are unrelated to business risk

Correct Answer: B. They may provide privileged paths that bypass ordinary user controls

Question 8

Which statement correctly distinguishes a vulnerability from a risk?

A. A vulnerability is always more important than a risk

B. Risk considers the possible consequences and likelihood associated with a weakness and threat

C. Risk refers only to source-code defects

D. A vulnerability exists only after exploitation

Correct Answer: B. Risk considers the possible consequences and likelihood associated with a weakness and threat

Question 9

A new supplier begins processing sensitive data. What is the most appropriate threat-modeling response?

A. Ignore the change because the supplier is outside the organization

B. Update data flows, trust boundaries, assumptions, threats, controls, and monitoring

C. Delete the existing threat model

D. Apply only a password policy

Correct Answer: B. Update data flows, trust boundaries, assumptions, threats, controls, and monitoring

Question 10

Which practice best supports the continuing usefulness of a threat model?

A. Keeping it disconnected from architecture and change management

B. Updating it only after a security incident

C. Versioning it and reviewing it after material system or threat changes

D. Restricting participation to one developer

Correct Answer: C. Versioning it and reviewing it after material system or threat changes