Threat Landscape, Terminology and Attack Modelling

Introduction

Web and application security begins with a disciplined understanding of what must be protected, who may threaten it, how attacks can occur, and which consequences matter to an organisation. Security teams cannot effectively select controls merely by listing vulnerabilities or purchasing tools. They must connect technical weaknesses to realistic threat actors, business assets, attack paths and impacts.

This chapter introduces the vocabulary and analytical methods used to perform that work. It examines threat actors, assets, vulnerabilities, exploits, attack surfaces, impacts and risk. It then applies established modelling approaches—STRIDE, misuse cases, attack trees and MITRE ATT&CK—to web and application environments. The chapter concludes with a risk-based prioritisation method and an illustrative case study.

Threat modelling is not a one-time compliance exercise. It is a structured form of reasoning that should be revisited when an application, dependency, business process or threat environment changes.

Learning Objectives

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

1. Distinguish threats, threat actors, assets, vulnerabilities, exploits, events, impacts and risks.
2. Classify common threat actors and explain their motivations and capabilities.
3. Identify application assets, trust boundaries and attack surfaces.
4. Apply STRIDE, misuse cases, attack trees and MITRE ATT&CK to model threats.
5. Relate technical security events to confidentiality, integrity, availability, safety, privacy and business impact.
6. Prioritise risks using likelihood, impact, exposure and control effectiveness.
7. Recognise the limitations, ethical responsibilities and governance requirements of threat modelling.

1. The Threat Landscape

The threat landscape is the changing collection of actors, motivations, techniques, vulnerabilities, technologies and conditions that can produce harm. It includes external attackers, insiders, suppliers, automated bots, criminal groups, hacktivists, competitors and state-linked organisations.

A modern web application may be exposed through several channels simultaneously:

• browser-based interfaces and mobile clients;
• public APIs and partner APIs;
• authentication and identity services;
• cloud management interfaces;
• software libraries and container images;
• administrative consoles;
• CI/CD pipelines and source-code repositories;
• third-party analytics, payment and communication services; and
• operational technology or physical processes connected to the application.

The threat landscape is shaped by technology and economics. Automated scanning makes low-cost attacks scalable. Cloud services increase deployment speed but may create complex trust relationships. Software supply chains introduce dependencies outside the direct control of the application owner. Artificial intelligence can improve defensive triage, but it can also assist reconnaissance, social engineering and generation of malicious content. AI does not remove the need for human judgement: generated output must be validated, authorised and governed.

1.1 Threat actors

A threat actor is a person, group or organisation capable of conducting an action that may harm an asset. Classification should consider motivation, resources, access, technical skill, persistence and tolerance for detection.

These categories are not mutually exclusive. An employee may be careless rather than malicious, yet still create a serious event. A criminal group may purchase access obtained by an unrelated initial-access broker. A state actor may use criminal infrastructure to conceal its origin. Classification should therefore describe observed behaviour and evidence rather than rely solely on labels.

1.2 Capabilities and motivations

Motivation explains why an actor may attack; capability explains what the actor can do. Relevant capability dimensions include:

• knowledge of the target and its architecture;
• ability to discover and exploit vulnerabilities;
• access to credentials, malware or infrastructure;
• financial resources and time;
• ability to evade detection; and
• willingness to accept legal, financial or operational risk.

A highly technical vulnerability may be less urgent than a simple weakness exposed to a large population of automated attackers. Conversely, a low-visibility administrative interface may deserve priority because a capable actor has specific knowledge and valid credentials.

2. Essential Security Terminology

Clear terminology prevents analytical errors. The following concepts should be kept distinct.

Asset. Anything valuable that requires protection. Assets include data, services, identities, devices, source code, business processes, reputation and human safety.

Threat. A potential cause of an unwanted incident. A threat may be an actor, condition, event or circumstance.

Threat actor. The entity that may intentionally or accidentally cause harm.

Vulnerability. A weakness in design, implementation, configuration, process or human practice that can be used or triggered to produce an adverse result.

Exploit. A method, procedure, tool or code that takes advantage of a vulnerability. A vulnerability can exist without a known exploit, and an exploit can be ineffective if environmental conditions are absent.

Attack. A deliberate attempt to compromise confidentiality, integrity, availability or another security property.

Attack vector. The route or mechanism used to reach a target, such as a phishing message, exposed API, stolen credential or compromised dependency.

Attack surface. The collection of reachable interfaces, components, identities, dependencies and processes through which an attack may occur.

Security control. A safeguard that prevents, detects, responds to or limits an unwanted event. Controls may be technical, administrative, physical or procedural.

Security event. An observable occurrence relevant to security. Not every event is malicious or harmful.

Security incident. An event or group of events that actually or potentially compromises confidentiality, integrity, availability or policy compliance and requires response.

Impact. The consequence of an incident, such as financial loss, service interruption, privacy harm, regulatory exposure or safety harm.

Risk. The possibility that a threat will exploit a vulnerability and produce an impact. Risk is contextual: the same vulnerability can have different significance in different systems.

Residual risk. Risk remaining after controls are implemented.

Risk appetite. The amount and type of risk an organisation is willing to accept in pursuit of its objectives.

A useful conceptual relationship is:

Likelihood represents the estimated chance or frequency of a relevant adverse event over a defined period; impact represents the magnitude of its consequences. This is a decision model rather than a universal law. The scales must be defined, the time horizon must be stated, and uncertainty should be recorded. Multiplying ordinal labels such as “3” and “4” does not create a scientifically precise probability or monetary loss.

3. Assets, Security Properties and Business Impact

3.1 Asset identification

Asset identification should begin with business processes rather than only technical components. For an online payments service, assets may include:

• customer payment details;
• transaction records;
• account balances;
• authentication credentials and session tokens;
• payment-processing APIs;
• source code and deployment secrets;
• service availability; and
• customer trust and regulatory standing.

Assets should be assigned owners. Ownership means accountability for deciding protection requirements, acceptable risk and response priorities; it does not necessarily mean technical administration.

3.2 Security properties

The classic CIA triad consists of:

• Confidentiality: information is accessible only to authorised subjects.
• Integrity: information and system behaviour remain accurate, complete and trustworthy.
• Availability: authorised users can access services and information when required.

Application security often requires additional properties:

• Authenticity: an entity or message is genuine.
• Accountability: actions can be attributed sufficiently for investigation and governance.
• Non-repudiation: evidence supports the claim that an action occurred and was attributable, subject to legal and technical limits.
• Privacy: personal information is collected, used, retained and disclosed appropriately.
• Safety: system behaviour does not create unacceptable physical or human harm.

3.3 Business impact

Technical severity is not identical to business impact. A defect in a low-value test environment may be less important than a moderate defect in a production identity service. Impact analysis should consider:

1. financial loss, including fraud, recovery and interruption costs;
2. legal and regulatory consequences;
3. privacy and individual harm;
4. operational disruption and service-level violations;
5. safety or environmental consequences;
6. loss of intellectual property or competitive advantage; and
7. reputation and customer confidence.

Impact should be assessed with relevant stakeholders, including product owners, legal advisers, privacy officers, operations teams and senior management.

4. Attack-Surface Analysis

Attack-surface analysis identifies where a system can be reached, influenced or misused. It is broader than vulnerability scanning. Scanning may identify known technical weaknesses; attack-surface analysis asks what is exposed, why it is exposed, who can reach it, and what trust relationships exist.

4.1 Application boundaries and trust boundaries

A system boundary defines what is inside the analysis. A trust boundary marks a transition where data or commands move between different levels of trust or administrative control. Examples include:

• a browser communicating with a web server;
• a web server calling a payment provider;
• an application querying a database;
• a production pipeline retrieving a package from a public registry; and
• a customer request entering an administrator-only function.

Each boundary should prompt questions: Is the sender authenticated? Is the data validated? Is the channel protected? Is authorisation checked at the destination? Can the receiving component trust the data, or must it treat it as hostile?

4.2 A practical analysis process

1. Define scope. Record the application, environment, business process, versions, geographic locations and exclusions.
2. Inventory components. Include users, browsers, mobile apps, APIs, services, databases, queues, identity providers, secrets, libraries, cloud resources and third parties.
3. Map data flows. Show data sources, destinations, transformations, storage and trust boundaries.
4. Enumerate entry points. Include URLs, methods, parameters, file uploads, authentication flows, webhooks, administrative functions and deployment interfaces.
5. Identify privileges. Record anonymous, customer, support, administrator, service-account and infrastructure permissions.
6. Identify dependencies. Include operating systems, frameworks, packages, SaaS providers, certificates, DNS, build tools and monitoring systems.
7. Consider non-technical paths. Include help-desk resets, physical access, social engineering and operational procedures.
8. Validate the model. Review it with developers, operators, testers, business owners and, where appropriate, independent assessors.

Attack-surface analysis should be repeated after major architectural changes. Asset inventories become unreliable when they are maintained only manually; automated discovery can help, but discovered items require ownership and classification.

5. Threat-Modelling Frameworks

No single framework answers every question. STRIDE is effective for structured design review; misuse cases emphasise unwanted behaviour; attack trees analyse ways to achieve a goal; MITRE ATT&CK provides a knowledge base for adversary tactics and techniques. They can be combined rather than treated as competitors.

5.1 STRIDE

STRIDE classifies threats by security property:

STRIDE is a prompt, not a vulnerability scanner. Analysts should connect each category to a component, flow, trust boundary, precondition, control and consequence. A threat can affect more than one category; for example, a compromised administrator account may enable spoofing, information disclosure and tampering.

5.2 Misuse and abuse cases

A normal use case describes an intended interaction, such as “customer submits a payment.” A misuse case describes an unwanted interaction, such as “attacker submits a payment with a modified amount.” Abuse cases are often useful when the actor is malicious and the objective is explicit.

A well-formed misuse case identifies:

• the legitimate goal and actor;
• the malicious or accidental actor;
• the preconditions;
• the sequence of actions;
• the security control that should interrupt the sequence; and
• the resulting impact.

Misuse cases are accessible to non-specialists and help product teams express security requirements. They can become vague if they describe only “the attacker hacks the system,” so the analyst should specify observable steps and assumptions.

5.3 Attack trees

An attack tree represents a threat actor’s ultimate goal as a root node and decomposes it into subgoals. AND relationships require all child conditions; OR relationships mean that any child path may be sufficient.

For example, the goal “take over a customer account” might be achieved through:

• obtain the password, OR
• obtain a valid session token, OR
• persuade support staff to reset the account.

The password path might require “discover username” AND “obtain password through phishing or credential reuse.” Attack trees expose alternative paths and single points of failure. They can support prioritisation by recording cost, skill, detectability, preconditions and control coverage. They do not automatically predict attacker behaviour: branches depend on assumptions and available evidence.

5.4 MITRE ATT&CK

MITRE ATT&CK is a publicly maintained knowledge base describing adversary tactics and techniques, including techniques relevant to enterprise, cloud and other environments. Tactics describe the adversary’s objective, while techniques describe how that objective may be pursued. Sub-techniques provide more detailed distinctions.

For application security, ATT&CK can help teams:

• translate observed activity into a common vocabulary;
• map detection and response coverage;
• develop threat-informed test scenarios;
• identify likely post-compromise behaviour; and
• communicate with security operations teams.

ATT&CK is not a complete application threat model and should not be used as a checklist of vulnerabilities. It describes known adversary behaviour, whereas a design review must also consider accidental misuse, novel attacks, business logic flaws and safety or privacy concerns. Technique mappings should be supported by evidence and kept version-aware because knowledge bases evolve.

6. Risk-Based Prioritisation

Threat modelling produces more findings than an organisation can address immediately. Prioritisation should combine technical evidence and business context.

A practical qualitative model uses four dimensions:

• Likelihood: how plausible exploitation is, considering exposure, capability, exploit availability, motivation and existing barriers.
• Impact: consequence if the scenario succeeds.
• Control strength: how effectively preventive, detective and corrective controls reduce likelihood or impact.
• Uncertainty: how incomplete or unreliable the evidence is.

A simple scoring scheme may classify likelihood and impact as Low, Medium or High, then use an agreed matrix. The matrix must be documented because different organisations may assign different meanings to the same label. Where reliable data exists, expected annual loss can be estimated as:

Here, the probability is a value between 0 and 1 for the specified period, and loss magnitude is expressed in a defined unit, such as currency. This estimate assumes that the probability and loss definition are meaningful and that uncertainty is not hidden by false precision. Rare catastrophic events may require scenario analysis rather than simple averaging.

Worked example: prioritising two findings

An online retailer identifies two scenarios for the next year:

• Scenario A: an access-control flaw could expose 50,000 customer records. The estimated probability is 0.08 and the assessed loss magnitude is £200,000.
• Scenario B: a minor public information leak could cause an estimated £20,000 loss with probability 0.30.

Using the expected-loss model:

Scenario A has the higher estimated loss and should normally receive greater priority, even though Scenario B is more likely. The result is not an instruction to ignore Scenario B. Privacy obligations, exploitation ease, customer expectations, control dependencies and uncertainty may change the decision. The figures are illustrative estimates, not measured facts.

A useful risk register should record the scenario, asset, threat actor, vulnerability, existing controls, likelihood, impact, owner, treatment decision, due date and residual risk. Treatment options include mitigation, transfer, avoidance, acceptance or removal of the affected exposure.

7. Illustrative Case Study: Meridian Health Portal

This is a fictional educational case.

Background

Meridian Health operates a patient portal that allows patients to view laboratory results, schedule appointments and send messages to clinicians. The portal uses a single-page web client, an API gateway, an identity provider, a clinical database and a third-party messaging service. A support centre can assist patients with account recovery.

Problem

A security review identifies three concerns: patient identifiers appear in some URL parameters; the API relies on object identifiers supplied by the client; and support staff can reset accounts after answering knowledge-based questions. The organisation wants to prioritise remediation without interrupting clinical operations.

Analysis

The assets are patient records, identity credentials, appointment information, clinical messages, availability and patient trust. Relevant threat actors include external criminals, malicious insiders, opportunistic users and attackers who obtain credentials through phishing.

The attack surface includes the login and recovery pages, API endpoints, browser session, support workflow, messaging integration, database and administrative interfaces. Trust boundaries occur between the browser and API, API and database, Meridian and the identity provider, and Meridian and the messaging supplier.

Applying STRIDE produces the following examples:

An attack tree for “access another patient’s records” has an OR relationship between exploiting object-level authorisation, compromising a clinician account and abusing support recovery. The first path may require only an authenticated patient account and predictable identifiers; this makes it particularly important even if no sophisticated exploit is necessary.

Approach and solution

Meridian assigns owners and implements server-side authorisation checks based on the authenticated subject and the requested record. It removes sensitive identifiers from URLs where feasible and ensures that logs do not retain unnecessary clinical data. Account recovery is redesigned to use a stronger, risk-based process with independent verification and notifications. Rate limits, anomaly detection and alerting are added to unusual record-access patterns. The messaging supplier is reviewed for contractual, privacy and technical safeguards.

The team documents a misuse case: “An authenticated patient attempts to retrieve another patient’s laboratory result.” It creates tests for horizontal privilege escalation, records the expected denial behaviour, and maps relevant post-compromise detection activities using ATT&CK terminology where appropriate. A privacy officer and clinical safety representative review the residual risks.

Outcome

The highest priority is the authorisation weakness because it directly threatens confidential clinical data and may be easy to exploit at scale. The recovery weakness is also urgent because account takeover can enable repeated access and fraud. URL handling is addressed as a defence-in-depth and privacy improvement, not treated as a substitute for authorisation. The organisation retains a documented risk decision for availability risks and schedules resilience testing.

Learning points

1. Authentication does not prove that a user may access every object.
2. Business workflows, especially support procedures, are part of the attack surface.
3. Privacy and clinical safety can be affected by ordinary application-security defects.
4. Threat modelling is stronger when technical, operational and governance stakeholders participate.
5. A framework supports reasoning but does not replace evidence, testing or ownership.

8. Governance, Ethics and Professional Practice

Threat modelling involves information about weaknesses, users, suppliers and organisational processes. Access should follow least privilege, and sensitive architectural details should be stored and shared appropriately. Security professionals must obtain written authorisation before testing systems. A threat model is not permission to exploit a real weakness against production users.

Privacy principles require data minimisation, purpose limitation, retention discipline and appropriate protection of personal information. Models should avoid unnecessary personal data and should distinguish legitimate security monitoring from excessive surveillance. Security decisions should also consider accessibility: controls that exclude users or make recovery impossible can create operational and ethical harm.

Governance practices include:

• assigning a model owner and review date;
• recording assumptions and evidence;
• linking threats to requirements, tests and controls;
• tracking accepted and residual risks;
• protecting the model from unauthorised disclosure;
• reviewing third-party and supply-chain responsibilities; and
• updating the model after incidents, major changes or new intelligence.

A mature organisation measures not only the number of threats identified, but also whether high-priority risks are reduced, whether controls work in practice, whether detection is tested, and whether decisions are understood by accountable owners.

9. Challenges and Limitations

Threat modelling has several limitations. Models can become obsolete as systems change. Analysts may overemphasise technical attacks and overlook fraud, social engineering, insider misuse or unsafe business processes. Frameworks can create false confidence when teams complete categories mechanically. Risk scoring can conceal disagreement behind precise-looking numbers. Threat intelligence may be incomplete, and attacker behaviour is adaptive.

To reduce these weaknesses, teams should use multiple perspectives, record uncertainty, test important assumptions, involve system owners, validate controls through security testing, and revisit the model. Quantitative estimates should be used only when the organisation can explain their basis. Qualitative analysis is valid when its scales and decision rules are explicit.

10. Best-Practice Workflow

A defensible application threat-modelling workflow is:

1. Establish scope, purpose, owners and review criteria.
2. Identify business processes, assets and security properties.
3. Draw the architecture and data flows, including trust boundaries.
4. Enumerate entry points, identities, privileges and dependencies.
5. Generate threats using STRIDE, misuse cases and attack trees.
6. Use ATT&CK to enrich adversary behaviour and detection considerations.
7. Assess likelihood, impact, uncertainty and existing controls.
8. Prioritise risks according to business objectives and legal obligations.
9. Define requirements, mitigations, tests, monitoring and response actions.
10. Record residual risk and obtain an accountable decision.
11. Reassess after material change or new evidence.

This workflow integrates design security with operational security. It also creates traceability: a threat leads to a requirement, the requirement leads to a control, and the control is checked by a test or monitoring capability.

Chapter Summary

Threat modelling provides a structured way to understand and reduce application risk. Threat actors differ in motivation, capability, access and persistence. Assets include data, services, identities, processes, reputation and safety. Vulnerabilities are weaknesses; exploits are methods of using them; impacts are consequences; and risk relates a plausible event to its consequences.

Attack-surface analysis identifies interfaces, dependencies, identities, trust boundaries and operational workflows. STRIDE supplies a security-property-based classification, misuse cases describe unwanted interactions, attack trees decompose attacker goals, and MITRE ATT&CK supplies a shared vocabulary for observed adversary behaviour. These approaches are complementary and must be supported by evidence and professional judgement.

Risk-based prioritisation should consider likelihood, impact, control effectiveness, uncertainty and organisational risk appetite. Effective practice includes clear scope, accountable ownership, privacy and ethical safeguards, testing, documentation and continuous review. The central professional lesson is that application security is not only about finding defects; it is about deciding which scenarios matter most and reducing their consequences in a measurable and governed way.

Key Terms

Asset: Anything valuable that requires protection.

Attack surface: The reachable interfaces, components, identities, dependencies and processes through which attacks may occur.

Attack tree: A decomposition of an attacker’s goal into subgoals and alternative paths.

Attack vector: The route or mechanism used to reach a target.

Exploit: A method or tool that takes advantage of a vulnerability.

Impact: The consequence of a security event or incident.

Incident: An event or events that actually or potentially compromise security or policy.

Misuse case: A description of an unwanted interaction with a system.

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

Residual risk: Risk remaining after controls are applied.

Risk: The possibility that a threat will exploit a vulnerability and cause impact.

Security control: A safeguard that prevents, detects, responds to or limits harm.

STRIDE: A threat-classification model covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

Threat: A potential cause of an unwanted incident.

Threat actor: An entity capable of causing harm.

Threat model: A documented representation of assets, trust relationships, threats, controls and risks.

Trust boundary: A transition between components or domains with different trust assumptions.

Vulnerability: A weakness that may be exploited or triggered to produce harm.

Review Questions

Short Answer Questions

1. Distinguish a vulnerability from an exploit.
2. What is the purpose of a trust boundary in attack-surface analysis?
3. Name the six STRIDE categories.
4. Why is authentication insufficient to guarantee authorised access to every object?
5. Define residual risk.

Long Answer Questions

1. Explain how threat-actor motivation and capability influence risk assessment.
2. Describe a complete attack-surface analysis process for a public web application.
3. Compare STRIDE, misuse cases, attack trees and MITRE ATT&CK, including an appropriate use for each.
4. Explain why technical severity and business impact are not identical.
5. Discuss governance, privacy and ethical responsibilities in threat modelling.

Analytical / Application Questions

1. An authenticated customer can change an account identifier in an API request and retrieve another customer’s invoice. Analyse the scenario using STRIDE, identify the assets and trust boundary involved, and propose preventive and detective controls.
2. Construct an attack-tree description for the goal “fraudulently change a bank-account payout destination.” Identify at least three alternative paths and state which assumptions require validation.
3. A service has a 0.05 annual probability of a £500,000 loss, while another has a 0.25 probability of a £40,000 loss. Calculate both expected losses, then explain why an organisation should not base its final decision on those values alone.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a vulnerability from an exploit?

A. A vulnerability is a business impact, while an exploit is a security control.

B. A vulnerability is a weakness, while an exploit is a method of taking advantage of that weakness.

C. A vulnerability is always an incident, while an exploit is always accidental.

D. A vulnerability is a threat actor, while an exploit is an asset.

Correct Answer: B. A vulnerability is a weakness, while an exploit is a method of taking advantage of that weakness.

Question 2

Which STRIDE category concerns unauthorised modification of data or system behaviour?

A. Spoofing

B. Repudiation

C. Tampering

D. Information disclosure

Correct Answer: C. Tampering

Question 3

Which item is most clearly an attack-surface component?

A. A company’s annual profit target

B. A publicly exposed API endpoint

C. A completed incident report stored offline

D. A security team’s holiday schedule

Correct Answer: B. A publicly exposed API endpoint

Question 4

In an attack tree, an OR relationship means that:

A. All child conditions must occur together.

B. Any one of the child paths may achieve the parent goal.

C. The parent goal is impossible to achieve.

D. Only defensive controls are represented.

Correct Answer: B. Any one of the child paths may achieve the parent goal.

Question 5

What does MITRE ATT&CK primarily provide?

A. A legal certification for secure software

B. A database of adversary tactics and techniques

C. A replacement for application authorisation testing

D. A formula for calculating financial loss

Correct Answer: B. A database of adversary tactics and techniques

Question 6

A threat model identifies a customer who can access another customer’s record by changing an object identifier. Which security property is most directly threatened?

A. Confidentiality

B. Availability

C. Non-repudiation only

D. Environmental sustainability

Correct Answer: A. Confidentiality

Question 7

Using Expected Loss = Probability × Loss Magnitude, what is the expected loss for a probability of 0.05 and a loss magnitude of £500,000?

A. £2,500

B. £25,000

C. £100,000

D. £500,000

Correct Answer: B. £25,000

Question 8

Which statement about risk scores is most accurate?

A. Multiplying ordinal labels always produces a precise monetary prediction.

B. Risk scores are useful only when they are never documented.

C. Scales, assumptions and time horizons should be defined before scores are interpreted.

D. Impact is irrelevant if likelihood is low.

Correct Answer: C. Scales, assumptions and time horizons should be defined before scores are interpreted.

Question 9

Which activity is part of attack-surface analysis?

A. Ignoring third-party services because they are outside the organisation’s network

B. Enumerating entry points, privileges, dependencies and trust boundaries

C. Replacing all qualitative analysis with a vulnerability scanner

D. Classifying every event as a confirmed incident

Correct Answer: B. Enumerating entry points, privileges, dependencies and trust boundaries

Question 10

Why should threat models be revisited after major architectural changes?

A. Threats and trust relationships may change as components and dependencies change.

B. A threat model becomes legally invalid after exactly one year.

C. Frameworks require every threat to be deleted after deployment.

D. Security controls eliminate the need for future analysis.

Correct Answer: A. Threats and trust relationships may change as components and dependencies change.