3. Risk Assessment and Threat Modelling

Introduction and Context

Secure software development begins with a disciplined understanding of what may go wrong, why it may happen, and which consequences matter most. Security controls are rarely unlimited: development time, operating budgets, architecture options and organizational attention are constrained. Risk assessment and threat modelling provide a reasoned basis for deciding where those resources should be applied.

Risk assessment asks questions such as: What assets require protection? Who might attack them? Which weaknesses could be exploited? What would be the business, legal, operational or human consequences? Threat modelling makes these questions concrete by examining a system’s architecture, trust boundaries, data flows and abuse possibilities. Together, the practices move security from a collection of generic controls to a context-sensitive process of informed decision-making.

For full-stack developers, this work is not limited to a security team. A developer who understands authentication flows, APIs, databases, cloud services and deployment pipelines is well placed to identify threats early. For managers and architects, risk assessment supports prioritization, governance and risk acceptance. For auditors and product owners, it provides evidence that security decisions are systematic rather than arbitrary.

Learning Objectives

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

• identify information, services, identities and business processes as security assets;
• construct and interpret data-flow diagrams and trust boundaries;
• apply STRIDE, attack trees and misuse cases to discover threats;
• distinguish vulnerability, threat, likelihood, impact and risk;
• use CVSS appropriately while recognizing its limitations;
• construct risk matrices and prioritize controls according to business context and risk appetite;
• evaluate threat-model assumptions, residual risk and risk acceptance decisions; and
• apply these methods to a realistic web application scenario.

From Assets to Risk Decisions

An asset is anything whose compromise, loss, alteration or unavailability could cause harm. In a web application, assets include customer records, passwords, payment tokens, source code, administrator privileges, session identifiers, availability of an ordering service and the trustworthiness of transaction records. Assets are not restricted to data. A business process, an API endpoint, a cryptographic key or a reputation-dependent service can also be an asset.

Asset identification should consider the properties of confidentiality, integrity and availability. Confidentiality concerns unauthorized disclosure; integrity concerns unauthorized or improper alteration; and availability concerns timely and reliable access. Other properties may be relevant, including authenticity, accountability, privacy and non-repudiation. The importance of an asset depends on context. A public product catalogue may require high integrity but low confidentiality, whereas a password-reset token may require confidentiality and strong integrity for a short period.

A useful asset inventory records the owner, location, classification, dependencies, required protection properties and consequences of compromise. Ownership matters because someone must be able to approve treatment decisions. Classification may distinguish public, internal, confidential and highly restricted information, although organizations should adapt categories to their governance requirements.

A threat is a potential cause of an unwanted incident, such as a malicious user, compromised dependency, dishonest insider, accidental administrator action or infrastructure failure. A vulnerability is a weakness that may permit a threat to produce harm. A SQL injection flaw is a vulnerability; an attacker exploiting it is a threat event; unauthorized disclosure of customer data is an impact. These terms should not be used interchangeably.

Risk can be expressed conceptually as a combination of likelihood and impact:

Risk = Likelihood of an adverse event × Consequence of that event

This is not always a precise mathematical calculation. Likelihood may be qualitative, quantitative or ordinal, and impact may include financial loss, regulatory exposure, safety consequences, operational interruption and reputational damage. The formula is valuable because it forces analysts to consider both dimensions. A highly probable event with minor consequences may deserve less attention than a less probable event that could stop a critical service.

Establishing Scope and Context

A threat model must have a defined scope. The scope may be a complete product, a new payment feature, an API, a microservice or a major architectural change. Analysts should describe the system’s purpose, users, deployment environments, assumptions, dependencies and out-of-scope components. An unclear scope produces either superficial analysis or an unmanageable list of hypothetical threats.

Business context influences the meaning of risk. A healthcare portal, an online game and an internal reporting tool may use similar web technologies but have different risk appetites and obligations. Risk appetite is the level and type of risk an organization is willing to retain in pursuit of its objectives. Risk tolerance defines acceptable variation around particular objectives. A business may tolerate brief unavailability of a low-value service but have near-zero tolerance for unauthorized alteration of payment instructions.

The analysis should identify stakeholders: customers, administrators, developers, operations personnel, data-protection officers, suppliers and business owners. Their perspectives reveal different impacts. A product manager may emphasize loss of customer trust, while an operations engineer may focus on recovery time and an attorney on reporting obligations.

Data-Flow Diagrams and Trust Boundaries

A data-flow diagram (DFD) represents how information moves through a system. Typical elements are external entities, processes, data stores and data flows. For a web application, the diagram may show a browser or mobile client, content-delivery network, web server, authentication service, API gateway, application services, database, payment provider and logging platform.

The diagram should show not only normal business data but also credentials, tokens, administrative commands, error messages and telemetry. It should identify protocols and important properties, such as whether a connection is encrypted, whether a token is signed, or whether an API call crosses an organizational boundary.

A trust boundary is a point at which the level of trust changes. Examples include the boundary between a public browser and a backend, between application code and a database, between a company and an external payment provider, and between tenants in a multi-tenant system. Threats frequently arise when data crosses a boundary because assumptions about identity, validation, authorization or integrity may not hold on both sides.

DFDs are analytical models rather than complete architecture documentation. They need not display every class or infrastructure component. Their purpose is to make security-relevant flows visible. A useful review asks: Who controls each component? Can the sender be trusted? Is the recipient authentic? What happens if the flow is modified, replayed, delayed or disclosed?

STRIDE: A Structured Threat-Discovery Method

STRIDE is a mnemonic for six categories of threat:

• Spoofing identity: pretending to be another user, service or device. Credential theft and forged service tokens are examples.
• Tampering with data: unauthorized modification of data, code, messages or configuration.
• Repudiation: performing an action without reliable evidence that can establish who performed it. Weak audit trails can create this condition.
• Information disclosure: exposing information to an unauthorized party, whether through an API, log, backup or error message.
• Denial of service: reducing availability or exhausting resources.
• Elevation of privilege: gaining capabilities beyond those legitimately assigned.

STRIDE is applied to elements and flows in a DFD. An external user interface may invite spoofing; a data flow may invite tampering or disclosure; a data store may be vulnerable to disclosure or alteration; and a process may permit privilege elevation. The method is a checklist for discovery, not a substitute for judgment. A threat is meaningful only when tied to a specific asset, weakness, actor and consequence.

The model can be extended with privacy-oriented considerations such as unwanted linkability, identification, non-repudiation concerns and disclosure of personal information. Organizations often combine STRIDE with privacy threat modelling when systems process personal or sensitive data.

Attack Trees and Misuse Cases

An attack tree begins with an attacker’s objective, such as “obtain unauthorized administrator access” or “cause fraudulent refunds.” The objective is the root. It is decomposed into alternative and complementary conditions. For example, unauthorized access might be achieved by stealing a password, exploiting a password-reset weakness or compromising an administrator’s session. If an objective requires several conditions together, they are connected conceptually with AND logic; alternative routes use OR logic.

Attack trees help analysts understand paths rather than isolated vulnerabilities. They can expose high-leverage controls. If several attack routes depend on bypassing authorization, strengthening authorization may reduce risk more effectively than separately addressing every endpoint. Trees may also include estimated cost, skill, access and detectability, but numerical estimates should be treated cautiously.

A misuse case describes a system interaction from the perspective of an actor pursuing an undesirable outcome. “A fraudulent user changes another customer’s shipping address” can be related to the legitimate use case “customer updates an order.” Misuse cases are valuable during requirements analysis because they express security behavior in language understandable to product owners and developers. They can be converted into security requirements, such as object-level authorization, re-authentication for sensitive changes and audit logging.

CVSS and Organizational Risk Matrices

The Common Vulnerability Scoring System (CVSS) provides a standardized method for describing the technical severity of a vulnerability. Its base metrics consider characteristics such as attack vector, attack complexity, privileges required, user interaction, scope, confidentiality, integrity and availability impact. Temporal and environmental considerations can refine the score when information about exploit maturity or a particular deployment is available.

CVSS is useful for comparing technical vulnerabilities and supporting vulnerability-management workflows. It is not a complete business-risk score. A high CVSS issue in an isolated test service may matter less than a moderate technical issue affecting a critical payment process. Conversely, a vulnerability with a lower technical score may be urgent if it affects regulated personal data or is actively being exploited.

A risk matrix classifies risks by combining likelihood and impact, often using categories such as low, medium, high and critical. A matrix should define what each category means. For instance, “high impact” might mean material financial loss, prolonged service interruption, significant privacy harm or regulatory consequences. “Likely” should likewise have an organizational interpretation rather than being an analyst’s intuition.

Matrices are communication tools, not measurements of objective truth. They can create false precision, hide uncertainty and encourage analysts to select a convenient cell. Good practice records assumptions, evidence, confidence and the rationale for the rating. Where feasible, quantitative analysis may estimate ranges of loss and frequency, but such estimates require credible data and should not disguise uncertainty.

Prioritizing Treatment and Controls

After identifying and rating risks, organizations select treatment options: mitigate, avoid, transfer or accept. Mitigation reduces likelihood or impact through controls. Avoidance changes or removes the risky activity. Transfer shifts some financial consequences through contracts or insurance, although accountability and technical responsibility may remain. Acceptance is a deliberate decision to retain risk within approved tolerance; it is not simply a failure to act.

Controls may be preventive, detective, corrective or compensating. Preventive controls include strong authorization, input validation, secure configuration and network segmentation. Detective controls include anomaly detection, audit logging and integrity monitoring. Corrective controls include credential rotation, incident response and backup restoration. A compensating control may reduce exposure when the preferred control cannot yet be implemented.

Control selection should consider effectiveness, implementation cost, usability, operational burden and residual risk. A control that users routinely bypass may be weaker in practice than a slightly less restrictive control that is consistently followed. Defence in depth is important: authentication, authorization, secure session management, monitoring and recovery should support one another rather than relying on a single barrier.

Each important risk should have an owner, treatment decision, target date and verification method. Requirements should be traceable from threat to control to test. For example, a threat of cross-tenant data disclosure may lead to tenant-scoped authorization requirements, automated authorization tests, code review checks and monitoring for anomalous access.

An Illustrative Case: ShopSphere Checkout Platform

Background

ShopSphere is a fictional online marketplace. Its web and mobile clients communicate with an API gateway. The platform contains identity, catalogue, order, payment and notification services. Customer and order data are stored in a relational database, while a third-party payment provider handles card transactions. Administrators use a separate dashboard. The company is preparing a feature that allows customers to change delivery addresses after placing an order.

Situation and Problem

The feature appears simple, but changing an address affects fraud, fulfilment and privacy. The product team proposes accepting an order identifier and a new address through the API. A threat-modelling workshop is conducted before implementation.

Analysis

The DFD identifies the browser, API gateway, order service, database, courier integration and payment provider. Trust boundaries exist between the customer and API, between services, and between ShopSphere and the courier. Assets include order records, customer addresses, session tokens and fulfilment instructions.

STRIDE analysis identifies several threats. An attacker may spoof a customer by stealing a session token. Tampering may occur if a customer changes an order belonging to another account by guessing an order identifier. Information disclosure may arise if an API response returns another customer’s address. Repudiation is possible if address changes are not logged. Denial of service may result from repeated address-update requests. Elevation of privilege could occur if a customer manipulates a role field or invokes an administrative endpoint.

An attack tree for “redirect another customer’s shipment” contains alternative paths: exploit object-level authorization, compromise a customer session, or abuse an internal service. The object-level authorization path is particularly important because the proposed endpoint uses a direct object identifier. The impact is high: privacy harm, delivery fraud, customer support costs and potential regulatory consequences. Likelihood is assessed as medium because the endpoint is internet-facing and the identifier may be discoverable, although exploitation requires a specific authorization weakness.

Approach and Solution

The team introduces server-side authorization that verifies both the authenticated identity and ownership or permitted relationship to the order. It avoids trusting client-supplied role or ownership fields. Sensitive address changes require re-authentication or a suitable step-up mechanism, and changes are permitted only before a defined fulfilment state. The system records the actor, time, previous and new address, request identifier and result, while restricting access to logs.

The API uses rate limiting and generic error responses. The courier integration receives only the information required for fulfilment and authenticates requests independently. Automated tests attempt cross-account access, altered identifiers, replayed requests and unauthorized administrative calls. Monitoring alerts on unusual volumes or repeated failed authorization attempts.

Outcome

The feature is released with a lower residual risk than the original design. The team documents the remaining risk that a compromised legitimate account could still be used to alter that customer’s orders. This risk is addressed through account-protection measures, notifications and recovery procedures rather than being incorrectly described as eliminated.

Learning Points

The case demonstrates that a feature’s business purpose does not reveal its complete security risk. Data-flow modelling exposed trust boundaries, STRIDE generated threat categories, the attack tree showed alternative routes, and risk analysis connected technical weaknesses to business consequences. Most importantly, the control was not merely “use authentication”; it was object-level authorization tied to the business relationship between a user and an order.

Common Errors, Limitations and Governance Concerns

Threat modelling can fail when performed as a one-time workshop with no connection to engineering work. Systems change: APIs are added, cloud permissions evolve, suppliers change and threat actors adapt. Models should therefore be revisited at design milestones, before major releases and after significant incidents.

Another common error is focusing only on external attackers. Insiders, compromised accounts, supply-chain dependencies, accidental disclosure and operational mistakes deserve attention. Analysts may also overemphasize confidentiality while neglecting integrity and availability. A corrupted price or altered deployment pipeline can be more damaging than a read-only disclosure.

Checklists can produce large numbers of theoretical threats with little prioritization. Conversely, teams may dismiss threats because exploitation has not yet been observed. Evidence should influence likelihood, but absence of evidence is not proof of safety. Assumptions—such as “the internal network is trusted” or “the provider validates all requests”—must be stated and verified.

Ethically and legally, risk assessments should minimize unnecessary exposure of personal data. Test data should not contain real sensitive records unless strictly justified and protected. Findings should be shared according to need, with safeguards against turning a report into an exploitation guide. Governance should define who may accept high residual risk, how exceptions expire, and how decisions are reviewed. Privacy, contractual, sector-specific and breach-notification obligations may affect impact assessments and control priorities.

Automation, Tooling and Emerging Practice

Modern development teams integrate threat modelling with architecture repositories, issue trackers and continuous integration. Static analysis, dependency scanners, infrastructure-as-code scanners and dynamic testing can provide evidence for particular threats, but tools do not determine business impact or risk appetite. A vulnerability scanner may identify a library issue; it cannot by itself decide whether the affected service is business-critical.

Automation can maintain DFD elements from service inventories, detect changes to trust boundaries, test authorization policies and correlate findings with asset criticality. Machine-learning systems may assist with anomaly detection or suggest threats from architecture descriptions, but generated suggestions require expert validation. Automation can reproduce inherited assumptions at scale, so model quality, provenance and human accountability remain essential.

Current practice increasingly emphasizes threat-informed engineering, software supply-chain risk, cloud identity analysis, zero-trust principles, privacy threat modelling and continuous control validation. The underlying objective remains stable: understand the system, connect threats to consequences, and make explicit, reviewable decisions about treatment and residual risk.

Best Practices for Professional Use

A mature threat-modelling practice should:

1. begin with business objectives, assets and trust boundaries rather than with a preferred security product;

2. involve developers, architects, operations, product owners and relevant governance specialists;

3. use more than one perspective, such as STRIDE for discovery and attack trees for attack paths;

4. record assumptions, evidence, uncertainty, ownership and risk acceptance decisions;

5. translate threats into testable requirements and regression tests;

6. prioritize according to impact, likelihood, exploitability, exposure and business context;

7. revisit models when architecture, data, dependencies or threats change; and

8. verify that controls work in deployment, not merely that they appear in design documents.

Chapter Summary

Risk assessment and threat modelling provide a structured foundation for secure full-stack development. The process begins by identifying assets and their confidentiality, integrity, availability, privacy and accountability needs. Data-flow diagrams reveal processes, stores, flows and trust boundaries. STRIDE supplies a systematic vocabulary for discovering spoofing, tampering, repudiation, information disclosure, denial of service and elevation-of-privilege threats. Attack trees analyse routes to attacker objectives, while misuse cases convert undesirable behaviour into security requirements.

CVSS supports consistent technical severity assessment but must be supplemented by business impact, exposure, exploitability, regulatory obligations and risk appetite. Risk matrices communicate prioritized decisions when their scales and assumptions are defined. Treatment may involve mitigation, avoidance, transfer or acceptance, with controls selected according to effectiveness, cost, usability and residual risk. Effective practice is continuous, evidence-based and governed by accountable owners. Tools and automation can strengthen the process, but professional judgment remains necessary.

Key Terms

Asset: A resource, process, identity, service or information item requiring protection.

Attack tree: A hierarchical model showing alternative and combined paths to an attacker objective.

Availability: The property that authorized users can access systems and information when required.

CVSS: A standardized framework for rating the technical severity of software vulnerabilities.

Data-flow diagram: A model showing entities, processes, data stores and flows within a system.

Elevation of privilege: Obtaining capabilities or permissions beyond those legitimately assigned.

Impact: The consequence or magnitude of harm resulting from a security event.

Likelihood: The estimated chance that a threat event will occur and produce harm.

Misuse case: A scenario describing undesirable behaviour or an attacker’s use of a system.

Residual risk: Risk remaining after controls have been implemented.

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

Risk matrix: A classification tool that combines likelihood and impact categories.

Security control: A technical, administrative or physical measure that modifies risk.

Spoofing: Impersonating a legitimate user, service or device.

STRIDE: A threat-discovery mnemonic covering six common threat categories.

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

Threat: A potential cause of an unwanted security incident.

Threat modelling: The structured analysis of system design, threats, impacts and controls.

Trust boundary: A point where assumptions about authority, control or trust change.

Vulnerability: A weakness that can be exploited or otherwise contribute to harm.

Review Questions

Short Answer Questions

1. Distinguish an asset, threat, vulnerability and risk using a web application example.

2. What is the purpose of a trust boundary in a data-flow diagram?

3. List and briefly explain the six STRIDE categories.

4. Why is CVSS not a complete measure of business risk?

5. What is meant by residual risk?

Long Answer Questions

1. Explain how an organization can progress from asset identification to selection and verification of security controls.

2. Describe how a data-flow diagram supports STRIDE-based threat modelling. Include the role of trust boundaries.

3. Compare attack trees and misuse cases in terms of purpose, representation and practical use.

4. Explain the strengths and limitations of qualitative risk matrices in organizational decision-making.

5. Discuss how risk appetite, regulatory obligations and business context should influence technical security priorities.

Analytical / Application Questions

1. A customer API accepts an account identifier supplied by the client and returns account details after login. Construct a short threat analysis using STRIDE and recommend prioritized controls.

2. A vulnerability has a high CVSS score in a rarely used internal test service, while a moderate-score authorization flaw affects a public payment service. Explain which should be prioritized and what additional evidence you would gather.

3. Create an attack-tree outline for the objective “change another user’s order,” identify two trust boundaries involved, and propose controls that reduce both likelihood and impact.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a vulnerability from a threat?

A. A vulnerability is a potential attacker, while a threat is a security control.

B. A vulnerability is a weakness, while a threat is a potential cause of an unwanted incident.

C. A vulnerability is the consequence of an incident, while a threat is its likelihood.

D. A vulnerability is always a software defect, while a threat is always an insider.

Correct Answer: B. A vulnerability is a weakness, while a threat is a potential cause of an unwanted incident.

Question 2

In a data-flow diagram, which element most directly represents a change in assumptions about authority or trust?

A. A trust boundary

B. A user interface

C. A database index

D. A deployment label

Correct Answer: A. A trust boundary

Question 3

An attacker modifies an order amount after intercepting an API request. Which STRIDE category is most directly involved?

A. Spoofing

B. Repudiation

C. Tampering

D. Denial of service

Correct Answer: C. Tampering

Question 4

Why should CVSS generally be supplemented by business-context analysis?

A. CVSS cannot describe any technical properties of vulnerabilities.

B. CVSS automatically assumes every system has the same business importance.

C. Technical severity does not by itself establish business impact, exposure or risk appetite.

D. CVSS is intended only for physical security incidents.

Correct Answer: C. Technical severity does not by itself establish business impact, exposure or risk appetite.

Question 5

Which control most directly addresses a customer changing another customer’s order by altering an order identifier?

A. Client-side hiding of the order identifier

B. Server-side object-level authorization

C. A longer password policy only

D. Publicly displaying order identifiers

Correct Answer: B. Server-side object-level authorization

Question 6

In an attack tree, alternative routes to the same attacker objective are normally represented conceptually as which relationship?

A. OR

B. AND

C. NOT

D. SEQUENTIAL encryption

Correct Answer: A. OR

Question 7

Which is the strongest example of deliberate risk acceptance?

A. Ignoring an undocumented vulnerability

B. Deferring all security work indefinitely

C. Recording an approved decision to retain risk within defined tolerance

D. Removing the risk rating from a report

Correct Answer: C. Recording an approved decision to retain risk within defined tolerance

Question 8

A system has low likelihood of compromise but could cause severe regulatory and operational harm. Which conclusion is most appropriate?

A. The risk is automatically low because likelihood is low.

B. The risk requires consideration of high impact and may warrant strong controls.

C. The risk can be ignored until exploitation occurs.

D. Only availability controls are relevant.

Correct Answer: B. The risk requires consideration of high impact and may warrant strong controls.

Question 9

What is a principal limitation of a risk matrix?

A. It cannot communicate risk categories.

B. It always requires exact financial data.

C. It may create false precision if definitions and assumptions are unclear.

D. It cannot be used with qualitative likelihood.

Correct Answer: C. It may create false precision if definitions and assumptions are unclear.

Question 10

Which practice best supports continuous threat modelling?

A. Performing one workshop only after the product is retired

B. Revisiting the model when architecture, dependencies or major features change

C. Replacing business owners with automated scanners

D. Treating internal networks as permanently trusted

Correct Answer: B. Revisiting the model when architecture, dependencies or major features change