Threat Modeling and Cloud Security Assessment

Introduction

Cloud environments change the nature of security assessment. Resources can be created programmatically, identities may operate across organisational boundaries, workloads are distributed across regions, and infrastructure may depend on managed services that the customer does not directly administer. Consequently, a conventional perimeter-focused assessment is insufficient. Effective cloud security requires a structured method for identifying assets, understanding how information moves, analysing plausible attacks, evaluating weaknesses, and prioritising controls according to business risk.

Threat modeling is a systematic process for identifying and analysing threats before or during system design. Cloud security assessment is the broader activity of examining whether cloud architectures, configurations, identities, workloads, data stores, operational processes and governance arrangements satisfy security requirements. The two activities are complementary: threat modeling explains what could go wrong and why, whereas assessment determines whether existing controls reduce the risk to an acceptable level.

This chapter develops a practical method based on asset classification, data-flow diagrams (DFDs), STRIDE, attack trees, misuse cases, vulnerability assessment and cloud security posture reviews. The emphasis is not on producing a long list of theoretical threats, but on prioritising threats and controls that are relevant to a particular organisation, workload and regulatory environment.

Learning Objectives

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

1. Classify cloud assets according to business value, sensitivity, criticality and regulatory obligations.
2. Construct and interpret a cloud data-flow diagram.
3. Apply STRIDE, attack trees and misuse cases to identify threats.
4. Distinguish vulnerabilities, threats, risks, controls and residual risks.
5. Conduct a practical vulnerability assessment and cloud security posture review.
6. Prioritise findings using likelihood, impact, exploitability and business context.
7. Recommend preventive, detective, corrective and compensating controls.
8. Explain the governance, ethical and operational limitations of automated assessment.

1. Foundations of Cloud Threat Modeling

1.1 Important terminology

An asset is anything that has value or requires protection, including data, identities, applications, virtual machines, containers, encryption keys, logs, networks and business processes.

A threat is a potential cause of harm, such as credential theft, data disclosure, service disruption or unauthorised modification.

A threat actor is an individual, group or process capable of exploiting a weakness. Actors may be external attackers, malicious insiders, compromised suppliers, negligent users or automated malware.

A vulnerability is a weakness that can be exploited. Examples include excessive permissions, an unpatched component, an exposed management interface or an insecure application programming interface (API).

A control is a safeguard designed to prevent, detect, respond to or recover from an adverse event.

Risk is the possibility that a threat will exploit a vulnerability and produce an undesirable consequence. In practical risk management, risk is analysed using both likelihood and impact rather than by vulnerability severity alone.

Inherent risk is the risk before considering controls. Residual risk is the risk remaining after controls have been applied. Risk acceptance is an informed decision to retain residual risk within an approved tolerance.

1.2 The shared-responsibility model

Cloud security responsibilities are divided between the provider and customer. The provider commonly secures physical facilities, core hardware, and some managed-service infrastructure. The customer remains responsible for matters such as identity configuration, data classification, application security, access policies and, depending on the service model, operating-system and network controls.

The division is not identical across infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). For example, a customer managing virtual machines has more responsibility for patching and host configuration than a customer using a fully managed application. However, the customer cannot transfer accountability for business decisions, lawful processing of data or correct configuration merely by selecting a cloud provider.

A threat model should therefore record the responsibility boundary explicitly. A provider control that is assumed but not contractually or technically verified is a potential assurance gap.

2. Asset Classification and Business Context

Threat modeling begins with assets and their business context, not with security tools. An inventory should identify the asset owner, location, service dependency, data processed, recovery requirement and applicable obligations.

A useful classification uses four dimensions:

A simple classification scheme may label data as Public, Internal, Confidential or Restricted. Labels must be linked to handling rules. For example, Restricted data may require strong encryption, private connectivity, approved geographic locations, privileged-access monitoring and documented retention and deletion.

Classification should also identify regulatory and contractual constraints. Personal data, payment information, health records, intellectual property and government information may have different requirements for access, retention, breach notification and cross-border transfer.

The classification process is not merely administrative. It changes threat priorities. A publicly available marketing page may tolerate limited confidentiality risk but require high availability and integrity. A customer identity database may require all three CIA properties at a high level.

Risk prioritisation

A qualitative risk matrix is often appropriate when precise probability data are unavailable. A common model assigns likelihood and impact scores from 1 to 5 and calculates a risk score:

where R is the risk score, L is the likelihood score and I is the impact score. The scores are ordinal, not precise probabilities; therefore, a result of 12 should not be interpreted as exactly twice the risk of 6. The organisation must define score bands, escalation rules and risk acceptance authority.

A more detailed analysis may consider exposure, exploitability, control strength and business dependency. Such scoring must remain transparent. False precision can cause decision-makers to trust a number more than the evidence supporting it.

3. Data-Flow Diagrams for Cloud Systems

A DFD represents how data moves through a system and where trust changes occur. It is especially valuable in cloud environments because data may cross accounts, regions, providers, networks, APIs and administrative domains.

The main DFD elements are:

• External entity: a user, partner, provider or external system.
• Process: an application, function, container or service that transforms data.
• Data store: a database, object store, queue, backup or log repository.
• Data flow: movement of data between elements.
• Trust boundary: a boundary across which the level of trust, administration or control changes.

A DFD should show authentication flows, administrative paths, service-to-service communication, data replication, backups and logging. It should also identify whether traffic is public, private, encrypted or authenticated.

A practical construction method is:

1. Define the system scope and business purpose.
2. List users, external partners and cloud services.
3. Identify processes and data stores.
4. Draw data flows and label the data type and protocol.
5. Mark trust boundaries, regions, accounts, subscriptions and provider responsibilities.
6. Identify entry points and privileged paths.
7. Validate the diagram with developers, operations staff, data owners and security personnel.

A DFD is a model, not an implementation proof. It becomes inaccurate when teams omit temporary files, diagnostic logs, backup copies, deployment pipelines or administrative access.

4. STRIDE Threat Analysis

STRIDE is a threat-category framework originally associated with Microsoft security engineering. It helps analysts ask consistent questions about common classes of security failure.

STRIDE is a prompting framework rather than a complete risk method. It does not automatically establish likelihood or impact, and it may not capture every business or privacy concern. Analysts should apply the categories to each process, data store, data flow and trust boundary, then record assumptions and evidence.

For example, an object-storage data store may be analysed as follows: spoofing through stolen access keys; tampering through an over-permissive role; repudiation through incomplete access logs; information disclosure through an accidental public policy; denial of service through deletion or quota exhaustion; and elevation of privilege through a role that can modify storage policies.

5. Attack Trees and Misuse Cases

5.1 Attack trees

An attack tree represents how an attacker could achieve a harmful objective. The root is the attacker’s goal, intermediate nodes describe sub-goals, and leaf nodes describe actions or conditions. AND relationships mean that multiple conditions are required; OR relationships mean that any one route may be sufficient.

Consider the goal “exfiltrate restricted customer data.” Possible branches include:

• compromise a privileged administrator account;
• exploit a public application and obtain database credentials;
• abuse an authorised insider account;
• compromise a backup or analytics export;
• exploit a third-party integration.

Each branch can be analysed for prerequisites, controls, detection opportunities and residual risk. Attack trees are particularly useful for showing that a high-value outcome may have several independent paths. Fixing one vulnerability may not eliminate the overall threat.

An attack tree is not a prediction of attacker behaviour. It is a structured exploration of plausible paths. It should be updated when architecture, identity models or external dependencies change.

5.2 Misuse and abuse cases

A normal use case describes an authorised interaction, such as “a customer views an invoice.” A misuse case describes an undesirable interaction, such as “an attacker downloads another customer’s invoice.” An abuse case may emphasise malicious intent, such as “an administrator exports customer records for personal gain.”

Misuse cases connect technical threats to business outcomes. A useful format identifies the legitimate actor, malicious actor, asset, preconditions, harmful action, consequence, detection mechanism and mitigating controls.

For the invoice example, the relevant controls might include object-level authorisation, tenant isolation, signed URLs with short expiry, audit logging, anomaly detection and privacy review. This approach prevents analysts from focusing only on infrastructure weaknesses while overlooking application-level authorisation failures.

6. Vulnerability Assessment in Cloud Environments

Vulnerability assessment is the systematic identification and evaluation of weaknesses. It may include network scanning, host and container scanning, dependency analysis, code review, configuration analysis, identity review and controlled penetration testing.

Cloud assessment requires caution because scanning can trigger provider protections, incur cost, violate acceptable-use rules or affect production availability. Testing scope, authorisation, time windows, source addresses, emergency contacts and data-handling procedures must be agreed in advance.

Important assessment areas include:

1. Identity and access: dormant accounts, excessive permissions, shared credentials, missing MFA, weak federation and ineffective separation of duties.
2. Network exposure: public management ports, unrestricted security-group rules, insecure egress and unprotected APIs.
3. Workloads: missing patches, vulnerable packages, insecure images, exposed secrets, weak container isolation and unsupported operating systems.
4. Data services: public storage, weak database authentication, absent encryption, excessive backup retention and inadequate key management.
5. Application security: injection, broken access control, insecure deserialisation, flawed session management and insufficient API validation.
6. Monitoring and response: incomplete audit logs, unmonitored control-plane activity, missing alert routes and untested response procedures.
7. Resilience: untested backups, single-region dependencies, inadequate quotas and unexamined recovery objectives.

Scanner output is evidence, not a final risk decision. Findings must be validated to remove false positives, determine exploitability in context and identify compensating controls. A low-severity software vulnerability on an isolated, non-sensitive development system may be less urgent than a medium-severity identity misconfiguration exposing a production database.

7. Cloud Security Posture Review

A cloud security posture review examines the configuration and governance of cloud resources against a defined baseline. Baselines may be based on organisational policy, provider guidance, the Center for Internet Security (CIS) benchmarks, ISO/IEC 27001 control objectives, NIST guidance or sector-specific requirements.

A review should examine:

• account and subscription structure;
• root or break-glass account protection;
• identity federation and privileged access;
• logging, monitoring and retention;
• network segmentation and private endpoints;
• storage and database access policies;
• encryption and key lifecycle management;
• vulnerability and patch management;
• infrastructure-as-code controls;
• backup, recovery and disaster planning;
• third-party and marketplace services;
• incident-response readiness;
• exception and risk-acceptance records.

Posture tools can continuously detect drift, such as a storage bucket becoming public or a logging setting being disabled. However, tools may not understand business purpose, data sensitivity, compensating controls or contractual context. Every important finding requires human review and an accountable owner.

A practical assessment workflow

The following workflow integrates the methods in this chapter:

1. Establish scope, objectives, stakeholders and authorisation.
2. Inventory assets and classify data.
3. Document architecture and construct DFDs.
4. Identify trust boundaries and privileged paths.
5. Apply STRIDE to relevant DFD elements.
6. Build attack trees for high-impact outcomes.
7. Write misuse cases for important business functions.
8. Perform posture review, vulnerability assessment and evidence collection.
9. Validate findings and analyse existing controls.
10. Prioritise treatment using business impact and exploitability.
11. Assign owners, deadlines and verification criteria.
12. Reassess after remediation and monitor for configuration drift.

8. Prioritising Threats and Controls

Prioritisation should combine technical evidence with business context. Useful criteria include:

• sensitivity and criticality of the asset;
• exposure to the internet or untrusted tenants;
• exploitability and availability of attack tooling;
• privileges required by the attacker;
• likelihood of detection;
• potential financial, legal, operational and reputational impact;
• control effectiveness and coverage;
• dependency on suppliers or shared services;
• time required to remediate.

Controls should be selected according to the threat path. For example, if the threat is theft of administrator credentials, relevant controls include phishing-resistant MFA, privileged access management, conditional access, short-lived credentials, session recording and anomaly detection. Encrypting a database may reduce disclosure impact but does not prevent an attacker who can legitimately query it.

Control types should be balanced:

• Preventive: stop an event, such as deny policies and network restrictions.
• Detective: identify an event, such as audit logs and alerts.
• Corrective: restore or repair, such as automated rollback and patching.
• Deterrent: discourage misuse, such as warnings and accountability.
• Compensating: provide alternative protection where the preferred control is impractical.

Worked prioritisation example

An assessment identifies an internet-accessible administrative API with password-only authentication. The service manages a database containing Restricted customer data. The organisation assigns likelihood 4 and impact 5 on a five-point scale:

The result falls in the organisation’s “critical” band. The immediate treatment is to restrict exposure, implement federated phishing-resistant MFA, apply least privilege and place the API behind monitored access controls. A later review may reduce likelihood to 1 if evidence demonstrates that the controls operate effectively:

This is not a mathematically measured probability. It is a documented ordinal judgement, and the organisation must verify the control operation before claiming that residual risk has decreased.

9. Illustrative Case: FinServe Cloud Migration

Background

FinServe, a fictional regional finance company, migrates its customer loan-application platform to a public cloud. The platform contains personal data, income records, identity documents and credit decisions. Customers access a web application, brokers submit applications through an API, and analysts use a reporting environment.

Problem

A cloud posture review discovers that a storage container used for document processing is publicly readable. An application role can also read more database tables than required. Logging is enabled for the production account but not for a related analytics account. The organisation initially classifies all findings as “medium” because no confirmed breach has occurred.

Analysis

The asset classification identifies identity documents and financial records as Restricted. The DFD reveals three trust boundaries: customer-to-application, broker-to-API and production-to-analytics. STRIDE analysis identifies information disclosure through public storage, elevation of privilege through the broad application role, and repudiation through incomplete analytics logging.

An attack tree for “obtain customer identity documents” includes public storage access, compromised application credentials and compromised broker credentials. The storage weakness is an immediately available OR branch, so it requires urgent treatment even though no incident is known.

Approach and solution

FinServe removes public access, applies explicit deny-by-default policies and uses private service endpoints. Documents are encrypted with centrally managed keys, and the processing service receives a narrowly scoped role. The organisation implements short-lived broker credentials, MFA for administrators, centralised immutable logging and alerts for unusual downloads. The analytics account is brought under the same logging and access-review standard. A data-retention rule deletes temporary documents after the approved processing period.

The security team validates the changes using policy tests, controlled access attempts, log inspection and a restoration exercise. It also updates the DFD and records the cloud provider’s responsibilities in the risk register.

Outcome

The public exposure is removed, access is limited to the processing workflow, and monitoring covers the previously unobserved account. Residual risks remain, including compromised authorised users and errors in application-level tenant isolation. These are assigned owners and tested through periodic review and application security testing.

Learning points

1. A configuration finding becomes urgent when asset classification shows high impact.
2. No confirmed incident does not mean that exposure is acceptable.
3. Identity, storage, application and logging controls must be analysed together.
4. A posture tool is valuable for discovery but cannot replace architecture analysis.
5. Remediation is incomplete until the control is tested and evidence is recorded.

10. Governance, Ethics and Regulatory Considerations

Threat modeling and assessment involve privileged information. Diagrams may expose architecture, credentials may appear in logs, and vulnerability reports may reveal exploitable weaknesses. Access must be restricted according to need, findings must be encrypted and retention must be controlled.

Testing without authorisation is unethical and may be unlawful. Security professionals should obtain written scope approval, avoid unnecessary collection of personal data, use test accounts where possible and report critical weaknesses through an agreed channel. Penetration testing must not be used as a pretext for accessing unrelated customer information.

Privacy principles such as purpose limitation, data minimisation, accuracy, retention limitation and accountability should influence the threat model. Privacy threats include excessive collection, unauthorised inference, re-identification and inappropriate secondary use, even when traditional confidentiality controls are present.

Regulatory compliance is not equivalent to security. A checklist may demonstrate that a control exists, but it does not prove that the control is effective against the organisation’s actual threats. Conversely, a technically strong control may fail a contractual or legal requirement if evidence, location or retention conditions are not met.

11. Contemporary Developments and Limitations

Cloud-native systems increasingly use containers, serverless functions, service meshes, event-driven architectures and infrastructure as code. These technologies require threat models that include ephemeral resources, software supply chains, deployment pipelines, machine identities and automated policy changes.

Artificial intelligence can assist with asset discovery, log correlation, policy analysis and generation of initial threat hypotheses. It can also produce inaccurate conclusions, overlook business context, expose sensitive data to an external service or create repetitive false positives. AI-generated findings must be reviewed by qualified personnel, and the organisation should document data-handling, model limitations and accountability.

Important limitations of threat modeling include incomplete inventories, rapidly changing architectures, subjective scoring, unknown vulnerabilities, inaccurate diagrams and overconfidence in automated tools. A threat model is therefore a living risk-management artefact. It should be revisited after major changes, incidents, new supplier relationships, regulatory developments or changes in threat intelligence.

Best-Practice Checklist

• Begin with business assets, owners and data classification.
• Record cloud responsibility boundaries explicitly.
• Keep DFDs current and include backups, logs and administrative paths.
• Apply more than one analysis technique to high-impact systems.
• Treat identity and application authorisation as first-class cloud risks.
• Validate scanner and posture findings manually.
• Prioritise exploitability and business impact, not severity labels alone.
• Use preventive, detective and recovery controls together.
• Test remediation and preserve evidence.
• Limit assessment access and protect vulnerability information.
• Reassess continuously because cloud configurations and threats change.

Chapter Summary

Threat modeling provides a structured way to anticipate how cloud systems may be attacked, while cloud security assessment evaluates the effectiveness of existing protections. The process begins with asset discovery and classification, including confidentiality, integrity, availability, criticality and regulatory context. Data-flow diagrams expose information movement, trust boundaries and privileged paths. STRIDE provides a disciplined set of threat questions; attack trees explore alternative routes to harmful objectives; and misuse cases connect technical weaknesses to business abuse.

Vulnerability assessment and cloud security posture review provide evidence about weaknesses in identities, networks, workloads, data services, applications, monitoring and resilience. Their results must be validated and interpreted in context. Risk prioritisation should consider asset value, exposure, exploitability, impact and existing controls. Controls should be selected against threat paths and should include prevention, detection, response and recovery.

Effective assessment is authorised, ethical, evidence-based and continuous. Automated tools and AI can improve scale and speed, but they cannot replace professional judgement, business ownership or verification. The ultimate purpose of threat modeling is not to create documentation; it is to support informed decisions that reduce material risk while preserving business and regulatory objectives.

Key Terms

Asset: Anything valuable that requires protection.

Attack tree: A hierarchical model of alternative paths to an attacker’s objective.

Cloud security posture review: An examination of cloud configurations and governance against defined requirements.

Control: A safeguard that prevents, detects, responds to or recovers from adverse events.

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

Denial of service: An attack that reduces or prevents legitimate availability.

Elevation of privilege: Obtaining permissions beyond those authorised.

Inherent risk: Risk before considering controls.

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

Residual risk: Risk remaining after controls are applied.

Risk acceptance: An authorised decision to retain risk within tolerance.

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

Threat: A potential cause of harm.

Threat actor: A person, group or process capable of causing harm.

Trust boundary: A boundary across which trust, control or administration changes.

Vulnerability: A weakness that can be exploited.

Vulnerability assessment: Systematic identification and evaluation of weaknesses.

Shared responsibility: The division of security duties between cloud provider and customer.

Review Questions

Short Answer Questions

1. What is the difference between a threat, a vulnerability and a risk?
2. Why should backups and logs be included in a cloud data-flow diagram?
3. What does the “E” in STRIDE represent?
4. Define residual risk.
5. Why must scanner findings be manually validated?

Long Answer Questions

1. Explain how asset classification influences cloud threat prioritisation.
2. Describe a method for constructing and validating a data-flow diagram.
3. Compare STRIDE, attack trees and misuse cases as threat-modeling techniques.
4. Explain how a cloud security posture review differs from vulnerability scanning.
5. Discuss the security implications of the shared-responsibility model.

Analytical / Application Questions

1. A public object store contains encrypted personal data, but its access policy permits anonymous listing and downloading. Analyse the issue using STRIDE and recommend controls.
2. Design an attack tree for the objective “alter a production financial transaction.” Identify at least three branches and appropriate preventive and detective controls.
3. A posture tool reports ten medium-severity findings, while an architecture review identifies one high-value database accessible through an over-privileged application role. Explain how you would prioritise the remediation programme and justify your decision.

Multiple Choice Questions with Answers

Question 1

Which STRIDE category concerns unauthorised modification of data or configuration?

A. Spoofing

B. Tampering

C. Repudiation

D. Information disclosure

Correct Answer: B. Tampering

Question 2

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

A. To show where data is backed up

B. To identify where trust, control or administration changes

C. To calculate network bandwidth

D. To identify the oldest system component

Correct Answer: B. To identify where trust, control or administration changes

Question 3

An organisation assigns likelihood 4 and impact 5 using a qualitative matrix. What is the resulting risk score?

A. 9

B. 20

C. 25

D. 45

Correct Answer: B. 20

Question 4

Which technique best represents alternative routes an attacker may use to achieve one harmful objective?

A. Attack tree

B. Asset register

C. Patch schedule

D. Service catalogue

Correct Answer: A. Attack tree

Question 5

Why is a public storage policy especially serious when the stored data is classified as Restricted?

A. It increases application performance

B. It creates a potential information-disclosure path with high business impact

C. It guarantees data corruption

D. It prevents all administrators from accessing the data

Correct Answer: B. It creates a potential information-disclosure path with high business impact

Question 6

Which is an example of a detective control?

A. A deny-by-default network rule

B. Multi-factor authentication

C. An alert on unusual bulk downloads

D. A data deletion procedure

Correct Answer: C. An alert on unusual bulk downloads

Question 7

What is a major limitation of automated cloud posture tools?

A. They cannot identify any configuration changes

B. They always require physical access to the data centre

C. They may lack business context and produce false positives

D. They eliminate the need for risk owners

Correct Answer: C. They may lack business context and produce false positives

Question 8

Which statement best describes residual risk?

A. Risk before a system is designed

B. Risk remaining after controls are applied

C. Risk that has already caused a confirmed incident

D. Risk that exists only outside the cloud

Correct Answer: B. Risk remaining after controls are applied

Question 9

Which item should normally be included in an authorised cloud penetration-testing plan?

A. Unapproved testing of unrelated customer systems

B. Testing scope, time window and emergency contacts

C. Permanent collection of all user data

D. Removal of provider monitoring controls

Correct Answer: B. Testing scope, time window and emergency contacts

Question 10

A role can read every database table although the application needs only two. Which principle is most directly violated?

A. Least privilege

B. Non-repudiation

C. Availability

D. Data retention

Correct Answer: A. Least privilege