Risk Assessment and Threat Modeling

Introduction

Modern web applications combine browsers, mobile clients, APIs, databases, cloud services, identity providers, third-party libraries, and operational systems. Each connection creates opportunities for misuse. Security engineering therefore begins not with selecting a tool, but with understanding what must be protected, from whom, through which paths, and with what consequences.

Risk assessment and threat modeling provide a structured way to answer these questions. Risk assessment evaluates the significance of possible adverse events. Threat modeling represents how an application can be attacked and identifies controls that interrupt those attack paths. Used together, they help development teams prioritize limited time and money according to likelihood, impact, business context, and legal obligations.

This chapter presents asset identification, actor analysis, trust boundaries, vulnerability and attack-path analysis, STRIDE, attack trees, OWASP resources, CVSS, risk matrices, and control prioritization. The methods are useful during architecture, design, implementation, testing, deployment, and change management.

Learning objectives

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

• identify information, technical, business, and operational assets;
• distinguish threat actors, threats, vulnerabilities, and risks;
• draw system boundaries, data flows, and trust boundaries;
• apply STRIDE and attack trees to web applications;
• interpret OWASP guidance and CVSS scores without treating them as automatic priorities;
• calculate and use a qualitative or semi-quantitative risk rating;
• prioritize controls using likelihood, impact, exploitability, exposure, and business context;
• explain limitations, ethical responsibilities, and governance requirements in threat modeling.

1. Foundations: from assets to risk

An asset is something valuable that requires protection. Assets include more than databases. Examples are customer records, authentication tokens, source code, payment transactions, service availability, audit logs, brand reputation, and the safety of users. An asset may be tangible, such as a server, or intangible, such as confidentiality or trust.

A threat actor is an individual, group, organization, or environmental cause capable of producing harm. Actors may include opportunistic attackers, organized criminal groups, malicious insiders, competitors, hacktivists, nation-state groups, careless employees, or automated malware. Accidental causes—such as misconfiguration or hardware failure—are often modeled as threats even though they have no malicious intent.

A threat is a potential cause of an unwanted event. A stolen session token, denial of service, fraudulent transaction, or alteration of an access-control rule is a threat scenario. A vulnerability is a weakness that can be exploited or triggered. Examples include missing authorization checks, insecure deserialization, weak secrets, excessive privileges, and unpatched dependencies.

Risk is the possibility that a threat will exploit a vulnerability and cause harm. A useful conceptual model is:

Likelihood expresses how probable or feasible the scenario is; impact expresses the magnitude of harm if it occurs. This is a decision model, not a law of nature. Organizations must define scales consistently, document assumptions, and include business context. A low-frequency event with catastrophic regulatory or safety consequences may deserve more attention than a frequent event with minor inconvenience.

Risk treatment normally follows four choices:

1. Avoid the risk by discontinuing or redesigning the activity.
2. Reduce it through preventive, detective, or corrective controls.
3. Transfer or share some consequences through contracts or insurance, while recognizing that accountability may remain.
4. Accept the residual risk through an explicit, authorized decision.

Acceptance should never mean that nobody noticed the risk. It should identify an owner, rationale, expiry or review date, and monitoring conditions.

Important distinctions

2. Scoping the system and identifying assets

A threat model must have a defined scope. State which application, versions, environments, interfaces, data flows, and dependencies are included. A useful scope statement might include the web front end, public API, identity provider integration, order database, deployment pipeline, and production administration interface, while excluding an unrelated internal reporting system.

Asset discovery can use architecture diagrams, data inventories, source repositories, cloud accounts, API specifications, logs, interviews, and regulatory records. Classify data according to organizational policy. Typical dimensions are confidentiality, integrity, and availability (CIA):

• Confidentiality: preventing unauthorized disclosure.
• Integrity: preventing unauthorized alteration or destruction.
• Availability: ensuring timely and reliable access.

Add authenticity, accountability, privacy, and safety when relevant. A public product catalog may have low confidentiality requirements but high integrity requirements. An administrator credential has high confidentiality and integrity value even if it contains no personal data.

Asset valuation should consider direct loss, recovery cost, business interruption, legal and regulatory consequences, contractual obligations, affected people, and reputational damage. Avoid valuing only the storage medium; the consequences of manipulating a small authorization table may exceed those of stealing a much larger collection of public data.

3. Actors, entry points, and trust boundaries

An entry point is an interface through which data or commands enter a component: a login endpoint, file upload, webhook, browser form, administrative console, message queue, or deployment pipeline. An exit point is a place where data leaves a component, such as a database query, email service, browser response, or log sink.

A trust boundary is a change in the level of trust applied to users, processes, data, or networks. Examples include:

• an unauthenticated Internet user crossing into a public API;
• an API crossing into a privileged database service;
• a tenant boundary separating one customer from another;
• an application crossing into a third-party payment provider;
• a build pipeline crossing into production deployment;
• a browser boundary where untrusted client input reaches a server.

Trust is not binary. Authentication establishes an identity claim; authorization determines what that identity may do. A request from an authenticated user can still be untrusted with respect to object ownership, input validity, or business rules. Every boundary should prompt questions about authentication, authorization, validation, encoding, encryption, rate limiting, logging, and failure behavior.

A data-flow diagram (DFD) commonly represents external entities, processes, data stores, data flows, and trust boundaries. It should show data types rather than merely network topology. For example, a payment token and a customer password should be distinct flows because they have different handling requirements.

Figure: A simplified data-flow diagram showing components, flows, and trust boundaries.

4. STRIDE threat analysis

STRIDE is a mnemonic for six classes of threat. It is most effective when applied to each process, data store, data flow, and external entity in a DFD.

STRIDE is a classification method, not a complete risk-ranking method. It helps generate scenarios, but the team must still estimate feasibility, impact, existing controls, and residual risk. One scenario may belong to multiple categories: a successful injection can cause information disclosure and tampering.

For privacy-focused work, LINDDUN is a complementary framework addressing linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance. Safety analysis, abuse cases, and resilience analysis may also be needed because STRIDE does not fully capture every business or human consequence.

5. Attack trees and attack paths

An attack tree models how an attacker could achieve a defined goal. The root is the goal, intermediate nodes are subgoals, and leaves are conditions or actions. An OR node means any child may be sufficient; an AND node means all relevant children are required.

For example, the goal “fraudulently change an order” might be achieved through:

• compromise an employee account OR exploit a broken object-level authorization check;
• if compromising an account, obtain credentials AND bypass or defeat MFA;
• if exploiting authorization, identify another order AND submit a modified request AND evade business-rule validation.

Attack trees are valuable because they expose assumptions and reveal control points. A control that blocks a common leaf may not remove the risk if an alternative branch remains. Teams can annotate leaves with required skill, access, tooling, detectability, and business impact. Avoid treating tree values as exact probabilities unless reliable evidence supports that interpretation.

An attack path is a sequence through components and weaknesses. For example: phishing → account takeover → token theft → API access → missing tenant check → disclosure. Path analysis encourages defense in depth: MFA may reduce the first step, token binding or short sessions may reduce the second, authorization checks block the fourth, and monitoring can detect the sequence.

6. OWASP resources and vulnerability analysis

The Open Worldwide Application Security Project (OWASP) provides widely used application-security resources. The OWASP Top 10 is an awareness document describing major classes of web application risk; it is not a complete testing standard or a substitute for architecture-specific analysis. OWASP ASVS provides verifiable security requirements at increasing assurance levels. The OWASP Testing Guide supports test planning, while the Software Component Verification Standard and dependency-related resources assist supply-chain governance.

Use OWASP resources appropriately:

1. map application features and trust boundaries;
2. select relevant ASVS requirements and testing activities;
3. identify likely vulnerability classes;
4. verify controls through code review, automated tests, dynamic testing, configuration review, and manual analysis;
5. record evidence, limitations, owners, and remediation dates.

A scanner finding is evidence for investigation, not automatically a confirmed vulnerability. Validate reachability, affected versions, exploit preconditions, compensating controls, and business impact. Conversely, the absence of a scanner finding does not prove security; authorization logic and business abuse cases often require human analysis.

7. CVSS and organizational risk

The Common Vulnerability Scoring System (CVSS) provides a standardized way to express the technical severity of a vulnerability. CVSS v4.0 separates metric groups including Base, Threat, Environmental, and Supplemental metrics. The Base score describes intrinsic severity under defined assumptions; Threat metrics can reflect exploit maturity, and Environmental metrics adapt severity to a particular organization.

CVSS is not the same as organizational risk. A high CVSS vulnerability in an isolated development server may be less urgent than a medium-scored authorization flaw affecting a revenue-critical, Internet-facing service. Prioritization should combine CVSS with exposure, asset value, exploit intelligence, compensating controls, affected population, regulatory obligations, and remediation cost.

Teams should cite the applicable CVSS version and vector, preserve the assessment date, and avoid changing a published score without documenting the rationale. Scores should support—not replace—engineering judgment.

8. Risk matrices and prioritization

A common qualitative matrix assigns likelihood and impact values from 1 to 5. A semi-quantitative score can be expressed as:

where L is the likelihood rating and I is the impact rating. If each is an ordinal category rather than a measured quantity, R is a ranking aid, not a probability or monetary loss. An organization might define 1–4 as low, 5–9 as moderate, 10–16 as high, and 17–25 as critical, but thresholds must be approved locally.

A more economically oriented model is expected annual loss:

Here pᵢ is the estimated annual probability of scenario i, Cᵢ is its monetary consequence, and the sum covers relevant scenarios. This model assumes that estimates are comparable, consequences are represented in monetary terms, and scenario overlap is handled. In practice, probability and cost may be uncertain; ranges, sensitivity analysis, and expert judgment are preferable to false precision.

Worked example

An online learning service identifies a possible cross-tenant disclosure. The team rates likelihood as 4 out of 5 because the endpoint is public, the flaw is straightforward to exploit, and similar code exists in several modules. Impact is rated 5 out of 5 because records contain personal and assessment data and disclosure could trigger notification obligations. The matrix score is:

Under the stated thresholds, 20 is critical. The team therefore assigns an immediate owner, blocks release of the affected feature, adds server-side authorization tests, reviews all equivalent endpoints, and deploys monitoring. The score does not prove that disclosure will occur; it justifies urgent treatment under the organization’s decision rules.

Prioritization should consider control effectiveness and residual risk. A preventive control reduces likelihood; a backup, incident response plan, or graceful degradation control may reduce impact. Controls should be mapped to the attack path and tested for coverage, not merely listed in a compliance document.

9. Applied case: illustrative digital marketplace

Background

Consider a fictional marketplace, ShopSphere, with a browser front end, REST API, identity provider, order database, payment processor, administrator portal, and cloud object storage. Customers can view orders, upload receipts, and request refunds. Support staff can search customer accounts.

Problem

During design review, the team discovers that the API accepts an order identifier supplied by the client. The initial implementation checks whether the requester is authenticated but does not verify that the order belongs to that requester. Uploaded receipts are stored in an object bucket, and support searches are logged inconsistently.

Analysis

Assets include order history, addresses, payment-related tokens, receipts, staff credentials, and audit records. Actors include customers, attackers, compromised staff accounts, and third-party service accounts. Trust boundaries exist between the Internet and API, API and database, API and object storage, and ShopSphere and the payment processor.

The missing ownership check is an elevation-of-privilege and information-disclosure threat under STRIDE. An attack tree for “obtain another customer’s receipt” has an OR branch for exploiting the order endpoint or compromising a support account. The endpoint branch requires discovering a valid identifier, submitting a request, and receiving a response without an ownership check.

The impact is high because receipts may contain personal information. Likelihood is high because the endpoint is Internet-facing and identifiers appear sequential. The team records the scenario as critical under its matrix. CVSS may help describe the technical vulnerability, but the organization’s business and privacy consequences determine urgency.

Approach and solution

The team implements authorization on the server using a policy that checks both authenticated identity and resource ownership. It replaces predictable identifiers exposed to clients where appropriate, while recognizing that identifier randomization is not a substitute for authorization. It adds negative tests for cross-tenant access, reviews every endpoint returning order data, restricts object-storage access through application-mediated authorization, and applies short-lived signed URLs with appropriate scope and expiry.

Support searches receive role-specific authorization, query minimization, and complete audit events containing actor, action, target, outcome, and timestamp. Logs exclude secrets and are protected against unauthorized alteration. Rate limiting and alerting address enumeration attempts. The release process requires threat-model review for changes affecting tenant isolation.

Outcome and learning points

The immediate defect is removed, related endpoints are tested, and monitoring improves detection. The broader lesson is that authentication alone does not establish authorization. Threat modeling is most effective when it examines data flows, business rules, alternative attack branches, and operational evidence—not only network firewalls or vulnerability scanner output.

10. Governance, ethics, and limitations

Threat modeling can expose sensitive architecture and weaknesses. Store models according to information-classification policy, restrict access, and avoid placing live secrets or exploitable details in general documentation. Security testing must be authorized, scoped, rate-limited, and conducted without accessing unnecessary personal data. Researchers should follow responsible disclosure processes and preserve evidence appropriately.

Regulatory and contractual duties may affect risk decisions. Privacy laws can impose data minimization, security, breach notification, retention, and individual-rights requirements. Sectoral requirements may impose stronger controls for payment, health, education, or critical infrastructure data. Compliance is a constraint and source of evidence, not proof that an application is secure.

Threat models also have limitations. They may become stale as systems evolve, omit undocumented dependencies, encode expert bias, or encourage checklist completion. Automated tools can discover patterns but rarely understand business authorization or novel attack chains. Schedule threat-model reviews at architecture changes, major releases, new integrations, significant incidents, and periodic governance checkpoints.

Contemporary practice increasingly includes software bills of materials, dependency monitoring, infrastructure-as-code review, cloud identity analysis, continuous attack-surface management, and security checks in CI/CD. Generative AI can help summarize architecture or propose abuse cases, but generated output requires expert verification. Do not provide confidential source code or personal data to an unapproved model, and do not treat AI output as evidence of security.

Best-practice workflow

A practical workflow is:

1. define scope, assumptions, and security objectives;
2. inventory assets, actors, entry points, dependencies, and data classifications;
3. draw and validate data-flow diagrams and trust boundaries;
4. enumerate STRIDE, privacy, abuse, safety, and resilience scenarios;
5. build attack trees or paths for significant goals;
6. identify vulnerabilities and map them to OWASP guidance and applicable standards;
7. rate likelihood, impact, technical severity, exposure, and business context;
8. select controls that break attack paths and reduce residual risk;
9. assign owners, deadlines, evidence, and acceptance authority;
10. verify controls through testing and revisit the model as the system changes.

Chapter Summary

Risk assessment and threat modeling are complementary security-engineering activities. Assessment prioritizes scenarios according to likelihood and impact; modeling explains how threats can move through assets, interfaces, vulnerabilities, and trust boundaries. A strong analysis identifies assets and actors, distinguishes authentication from authorization, and represents data flows rather than relying on a simple network diagram.

STRIDE provides a systematic threat vocabulary, while attack trees and attack paths expose alternative ways to reach an attacker’s goal. OWASP resources guide application requirements and testing, and CVSS communicates technical vulnerability severity. Neither replaces business-context analysis. Risk matrices and expected-loss models can support decisions when their assumptions and uncertainty are explicit.

Effective controls are selected because they interrupt realistic attack paths, reduce likelihood or impact, and can be verified. Models must be governed, ethically handled, updated as systems change, and connected to ownership, monitoring, incident response, and residual-risk acceptance.

Key Terms

Asset: Something valuable that requires protection.

Attack path: A sequence of actions and weaknesses leading to an attacker goal.

Attack tree: A hierarchical representation of ways to achieve an attack goal.

Authentication: Establishing or verifying an identity claim.

Authorization: Determining what an authenticated identity may do.

CVSS: A standardized framework for communicating vulnerability severity.

Data-flow diagram: A representation of processes, stores, entities, and data movements.

Impact: The magnitude of harm produced by a risk scenario.

Likelihood: The estimated probability or feasibility of a risk scenario.

OWASP: An open community providing application-security knowledge, standards, and tools.

Residual risk: Risk remaining after controls are applied.

Risk: The possibility of harm arising from a threat exploiting a vulnerability.

Risk matrix: A table combining likelihood and impact categories.

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

Threat: A potential cause of an unwanted event.

Threat actor: An entity or cause capable of producing harm.

Trust boundary: A point where assumptions about trust change.

Vulnerability: A weakness that can be exploited or triggered.

Review Questions

Short Answer Questions

1. Distinguish an asset, threat, vulnerability, and risk.
2. Why is authentication insufficient to guarantee authorization?
3. What is the purpose of a trust boundary in a data-flow diagram?
4. Name the six STRIDE categories.
5. Why should CVSS not be used as the sole basis for remediation priority?

Long Answer Questions

1. Explain a complete threat-modeling workflow for a multi-tenant web application.
2. Compare STRIDE and attack trees, including the strengths and limitations of each.
3. Explain how confidentiality, integrity, and availability influence asset valuation.
4. Discuss how OWASP ASVS, testing guidance, and vulnerability scanners can be used together.
5. Explain risk treatment options and the governance requirements for accepting residual risk.

Analytical / Application Questions

1. A public API verifies login but returns any invoice whose identifier is supplied. Identify the assets, trust boundary, STRIDE categories, attack path, and three priority controls.
2. A vulnerability has a likelihood rating of 3 and impact rating of 5 on a 1–5 matrix. Calculate the score using R = L × I, then explain why the score alone may not determine urgency.
3. Design an attack tree for the goal “deploy unauthorized code to production.” Identify at least two alternative branches and controls that interrupt each branch.

Multiple Choice Questions with Answers

Question 1

Which STRIDE category primarily concerns unauthorized disclosure of data?

A. Spoofing

B. Tampering

C. Information disclosure

D. Denial of service

Correct Answer: C. Information disclosure

Question 2

What is the main purpose of identifying a trust boundary?

A. To measure database storage capacity

B. To identify where assumptions about trust change

C. To calculate network bandwidth

D. To replace authorization testing

Correct Answer: B. To identify where assumptions about trust change

Question 3

A risk matrix uses R = L × I. If likelihood is 4 and impact is 5, what is the score?

A. 9

B. 16

C. 20

D. 25

Correct Answer: C. 20

Question 4

Which statement best describes CVSS?

A. It is a complete business continuity plan

B. It communicates technical vulnerability severity

C. It proves that a system is compliant

D. It replaces threat modeling

Correct Answer: B. It communicates technical vulnerability severity

Question 5

In an attack tree, an OR node means that:

A. All child conditions are required

B. Any sufficient child branch may achieve the parent goal

C. No child branch can achieve the goal

D. The node represents only a defensive control

Correct Answer: B. Any sufficient child branch may achieve the parent goal

Question 6

Which control most directly addresses broken object-level authorization?

A. Checking resource ownership on the server

B. Increasing client-side animation speed

C. Compressing all JavaScript files

D. Changing the database backup schedule

Correct Answer: A. Checking resource ownership on the server

Question 7

Which statement about the OWASP Top 10 is most accurate?

A. It is an exhaustive security testing standard

B. It is an awareness resource describing major application-risk classes

C. It automatically fixes vulnerabilities

D. It is a replacement for access-control design

Correct Answer: B. It is an awareness resource describing major application-risk classes

Question 8

Which risk treatment explicitly stops the activity that creates the risk?

A. Acceptance

B. Transfer

C. Avoidance

D. Monitoring

Correct Answer: C. Avoidance

Question 9

In the expected annual loss expression EAL = ∑ᵢ pᵢ × Cᵢ, what does Cᵢ represent?

A. The annual probability of scenario i

B. The monetary consequence of scenario i

C. The number of controls applied

D. The CVSS base score

Correct Answer: B. The monetary consequence of scenario i

Question 10

Why is a scanner finding not automatically a confirmed vulnerability?

A. Scanners cannot produce any useful evidence

B. Findings require validation of reachability, conditions, controls, and impact

C. Only users can identify vulnerabilities

D. A vulnerability exists only after an incident

Correct Answer: B. Findings require validation of reachability, conditions, controls, and impact