2. Threats, Adversaries and Security Models

Introduction and Context

Cloud services, connected devices, enterprise applications, and operational technologies have expanded the scope of organizational security. A business system is no longer protected by a single network boundary. It may depend on public cloud identities, software-as-a-service platforms, application programming interfaces, mobile endpoints, Internet of Things (IoT) devices, third-party suppliers, and automated deployment pipelines. Each dependency creates possible paths to compromise.

Security professionals therefore need more than lists of vulnerabilities. They must understand who may attack a system, why an attack may occur, how an intrusion develops, which assets and trust relationships are involved, and what controls can interrupt the process. This chapter introduces threat analysis and security models that support those decisions. It connects adversaries and motivations with attack lifecycles, threat modeling, attack trees, STRIDE, MITRE ATT&CK, the cyber kill chain, least privilege, and secure-by-design principles.

A useful distinction is that a vulnerability is a weakness, a threat is a potential cause of harm, and risk is the combination of the likelihood and impact of that harm. A threat model makes these relationships explicit. It does not predict every attack; rather, it provides a disciplined way to identify plausible abuse scenarios and select proportionate safeguards.

Learning Objectives

After completing this chapter, students should be able to:

1. distinguish threats, vulnerabilities, risks, attack surfaces, and security controls;

2. classify adversaries according to capability, access, motivation, and resources;

3. explain common attack lifecycles in cloud, IoT, and enterprise environments;

4. construct and interpret threat models, attack trees, and STRIDE analyses;

5. use MITRE ATT&CK and the cyber kill chain to analyze adversary behavior;

6. apply least privilege and secure-by-design principles to architectural decisions;

7. evaluate limitations, ethical issues, and organizational implications of threat modeling; and

8. recommend controls for a realistic multi-environment security scenario.

From Assets to Adversaries

Threat analysis begins with assets. Assets include information, identities, applications, devices, services, processes, and business capabilities. Confidentiality protects information from unauthorized disclosure; integrity protects it from unauthorized alteration; and availability ensures that authorized users can obtain it when needed. Cloud and IoT systems also require attention to safety, privacy, resilience, authenticity, and accountability.

The attack surface is the collection of exposed points through which an attacker may attempt access or influence. Examples include internet-facing APIs, exposed management interfaces, weak credentials, over-permissive cloud roles, vulnerable firmware, untrusted software libraries, and supplier connections. The attack surface is dynamic: a temporary cloud workload, a newly connected sensor, or a changed firewall rule may create exposure without appearing in a conventional asset inventory.

An adversary is an individual, group, organization, or process capable of causing harm. Adversaries differ in motivation and capability. Cybercriminals commonly seek financial gain through fraud, ransomware, credential theft, or extortion. Nation-state groups may pursue espionage, strategic influence, military advantage, or disruption. Insiders may act maliciously, negligently, or under coercion. Hacktivists often seek publicity or ideological impact. Competitors, contractors, and opportunistic attackers may exploit information or access for varied purposes.

Capability is not the same as sophistication. An attacker with modest technical skill may cause major damage by using stolen cloud credentials or a misconfigured storage service. Conversely, a highly capable actor may be constrained by time, access, operational security, or the need to avoid detection. Threat assessment should therefore consider capability, opportunity, intent, persistence, access, and tolerance for risk.

A threat event becomes a security incident when it results in, or credibly threatens, unauthorized activity. Risk analysis normally considers likelihood and impact, but these should not be treated as precise numerical truths when evidence is weak. Qualitative ratings can support prioritization, provided that assumptions are recorded and reviewed.

Common Attack Paths in Connected Environments

Attackers frequently combine several weaknesses rather than exploiting one dramatic flaw. A typical path may begin with reconnaissance of an organization’s public services, continue through phishing or credential reuse, move into a cloud identity, expand permissions, access data stores, and finally affect business operations. In an IoT environment, an attacker may exploit default credentials or outdated firmware, use a device as a foothold, pivot to a management network, and target enterprise systems.

Cloud environments alter traditional assumptions about location and control. The organization may not own the underlying hardware, while responsibility is divided between the cloud provider and customer. A provider may secure the physical infrastructure, but the customer may still be responsible for identity configuration, data permissions, workload images, secrets, and logging. Misunderstanding this shared responsibility model can create defensive gaps.

Identity is a central attack path. Password spraying, phishing, token theft, consent abuse, exposed access keys, and excessive privileges can allow an attacker to operate through legitimate services. Because activity may use valid accounts, network perimeter controls alone are insufficient. Strong authentication, conditional access, short-lived credentials, privilege separation, and behavioral monitoring are essential.

Supply-chain paths arise when attackers compromise software dependencies, managed service providers, update mechanisms, or development tools. IoT systems add physical and lifecycle concerns: devices may remain deployed for years, have limited computational resources, receive infrequent patches, and be installed in locations that are difficult to inspect. Security must therefore be considered during procurement, provisioning, operation, maintenance, and decommissioning.

Attack Lifecycles as Analytical Models

Attack lifecycles provide a temporal view of intrusion. The cyber kill chain traditionally describes reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. Its value lies in identifying opportunities to prevent or detect an attack before the final objective. Its limitation is that modern attacks are not always linear. Cloud compromise may begin with a valid credential and omit conventional malware delivery; insider activity may begin inside the environment; and attackers can repeat or parallelize stages.

MITRE ATT&CK offers a behavior-oriented knowledge base organized around tactics such as reconnaissance, initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact. Techniques describe how an objective may be achieved. ATT&CK is useful for mapping observed behavior to defensive coverage, developing detection rules, conducting threat-informed exercises, and identifying gaps. It is not a complete risk model: technique presence does not by itself establish likelihood, business impact, or an appropriate control.

The two models can be used together. The kill chain encourages disruption across an intrusion sequence, whereas ATT&CK provides a more granular vocabulary for behavior. For example, a phishing message may represent delivery or initial access; subsequent credential dumping, cloud discovery, privilege escalation, and data collection can be mapped to relevant ATT&CK techniques. Analysts should avoid treating either framework as a rigid checklist. Evidence, environment, adversary objectives, and business context remain decisive.

Threat Modeling: Making Assumptions Visible

Threat modeling is a structured process for identifying what can go wrong and deciding how to reduce the resulting risk. A practical model begins by defining scope and security objectives, identifying assets and actors, representing system components and trust boundaries, enumerating threats, evaluating risk, selecting mitigations, and validating the design. It should be repeated when architecture, suppliers, data flows, or threat conditions change.

Data-flow diagrams are particularly useful. They show processes, data stores, external entities, data flows, and trust boundaries. A trust boundary is a point where assumptions about identity, authority, control, or data protection change. Examples include an API gateway to an internal service, a device network to an enterprise network, or a customer tenant to a provider-managed service.

STRIDE is a threat classification method. Its categories are:

• Spoofing: pretending to be another identity.
• Tampering: unauthorized alteration of data or code.
• Repudiation: denying an action when reliable evidence is absent.
• Information disclosure: exposing information to unauthorized parties.
• Denial of service: reducing or preventing availability.
• Elevation of privilege: gaining authority beyond that intended.

STRIDE prompts analysts to examine each relevant process, flow, and data store. For example, an IoT telemetry API may face spoofing if device identities are weak, tampering if messages lack integrity protection, information disclosure if tenant isolation fails, denial of service if rate controls are absent, and elevation of privilege if a device role can invoke administrative functions. STRIDE is systematic, but it does not automatically rank business impact or identify every privacy and safety concern.

Attack Trees and Risk Reasoning

An attack tree expresses an attacker’s objective as a hierarchy of subgoals. The root might be “obtain unauthorized access to customer records.” Child nodes may include compromising an administrator account, exploiting an exposed service, abusing a supplier connection, or obtaining access through an insider. Each branch can be decomposed further. For example, compromising an administrator account may require discovering the account, acquiring a credential, bypassing authentication controls, and using the account without detection.

Logical relationships matter. An OR node means that any child may achieve the parent objective; an AND node means that several conditions are required. Analysts can annotate branches with prerequisites, estimated effort, detectability, and control coverage. Attack trees support design reviews because they focus attention on how controls break attack paths rather than merely listing vulnerabilities.

They also have limitations. Estimates may reflect analyst bias, dependencies may be uncertain, and trees can become unwieldy in complex systems. They should be treated as living reasoning artifacts, not mathematical proof. Combining attack trees with asset criticality, exposure data, incident history, and business impact produces more useful prioritization.

Least Privilege and Secure by Design

Least privilege means that a subject receives only the permissions necessary for an authorized task, for only as long as necessary. Subjects include users, services, applications, devices, and automation pipelines. Effective implementation includes role separation, just-in-time elevation, scoped service identities, resource-level permissions, approval workflows, periodic review, and rapid revocation. Least privilege is not simply “give fewer permissions”; excessive restriction can encourage workarounds and undermine operational reliability. Permissions must be usable, observable, and aligned with actual tasks.

In cloud systems, least privilege may require separating deployment, administration, billing, security monitoring, and application roles. In IoT, a sensor should normally publish only to its designated service and should not possess broad network or administrative privileges. In software delivery, build systems should not automatically obtain unrestricted production access.

Secure by design places security requirements in architecture, procurement, development, and operations rather than adding controls after deployment. Relevant practices include threat modeling during design, secure defaults, strong identity, encryption, dependency management, safe update mechanisms, isolation, logging, failure containment, privacy minimization, and resilience testing. The principle is especially important for IoT products, where insecure defaults can persist across a large installed base and patching may be difficult.

Security models should also recognize zero trust: access is not granted merely because a request originates from an internal network. Decisions should consider identity, device posture, resource sensitivity, context, and continuous verification. Zero trust is an architectural approach, not a single product or a claim that trust can be eliminated entirely.

An Illustrative Case: The Connected Cold-Storage Network

Background

A fictional food-distribution company operates refrigerated warehouses. Temperature sensors send telemetry to an IoT gateway, which forwards data to a cloud analytics platform. A supplier maintains the gateways remotely. Warehouse staff use a web dashboard, while an enterprise identity provider manages employee authentication.

Situation and Problem

An assessment discovers that several gateways use a shared supplier account, firmware updates are performed manually, and the cloud dashboard grants broad read and write permissions to most supervisors. The company’s primary concern is theft of customer information, but loss of temperature integrity could also spoil inventory and create safety consequences.

Analysis

The asset inventory identifies sensor data, control commands, customer records, gateway credentials, cloud identities, and warehouse operations as important assets. Trust boundaries exist between sensors and gateways, gateways and the cloud, the supplier and management interface, and the enterprise identity provider and dashboard.

A STRIDE review identifies spoofing through shared accounts, tampering through unauthenticated control messages, repudiation because supplier actions are not individually logged, information disclosure through broad dashboard access, denial of service through gateway flooding, and elevation of privilege through the supervisor role. An attack tree with the objective “alter refrigeration settings” includes branches for compromising a gateway, abusing a cloud role, or misusing supplier access.

Using ATT&CK terminology, analysts consider valid-account use, remote services, discovery, privilege escalation, and impact. The kill-chain view emphasizes opportunities to prevent delivery of malicious updates, detect unusual supplier access, and contain actions before operational impact.

Approach and Strategy

The company assigns unique supplier identities with multifactor authentication, limits access to approved gateways, and requires time-bound authorization. Gateway credentials are rotated and stored in a managed secrets service. Sensor identities are device-specific, telemetry is integrity-protected, and gateways are segmented from general enterprise systems. Cloud roles are redesigned according to job function, with separate read-only, operational, and administrative permissions.

Secure update mechanisms validate signed firmware and support rollback. The dashboard records immutable, attributable administrative events and sends high-risk actions for approval. Detection rules identify unusual locations, repeated authentication failures, unexpected firmware changes, and commands outside operational patterns. A response plan defines how to isolate a gateway while preserving refrigeration safely.

Outcome

The redesign does not eliminate all risk, but it removes shared accountability, reduces unnecessary privilege, improves evidence quality, and limits the consequences of a compromised device or account. Periodic exercises test whether the organization can revoke supplier access, maintain operations, and restore trusted configurations.

Learning Points

The case demonstrates that threat modeling must include business and physical consequences, not only information disclosure. It also shows that identity, segmentation, update integrity, logging, and recovery work together. No single framework supplies the answer; STRIDE structures threat discovery, attack trees expose alternative paths, ATT&CK supports behavioral analysis, and least privilege and secure design shape the resulting controls.

Organizational and Professional Considerations

Threat modeling is partly technical and partly organizational. Architects understand system dependencies; operations teams understand failure modes; business owners understand impact; privacy specialists understand data obligations; and legal or compliance personnel understand contractual and regulatory requirements. Excluding any of these perspectives can produce a technically elegant but operationally unsuitable model.

Privacy must be considered when monitoring users, devices, and behavior. Security logs should be protected, retained for a justified period, and accessed according to legitimate need. Penetration testing and adversary simulation require authorization, defined scope, safety controls, and responsible handling of discovered data. Analysts must distinguish defensive research from unauthorized access, and organizations should establish disclosure and incident-reporting procedures.

Common mistakes include treating compliance controls as a complete threat model, focusing only on external attackers, assuming that a cloud provider secures customer configuration, ignoring availability and safety, failing to model third parties, and producing diagrams that are never updated. Another mistake is confusing a framework mapping with risk reduction. A system may be mapped extensively to ATT&CK and still lack effective detection, response, recovery, or ownership.

Current Developments

Modern threat analysis increasingly incorporates software bills of materials, identity-centric detection, cloud-native application protection, infrastructure-as-code scanning, and automated configuration assessment. Machine learning can help identify anomalous access or prioritize signals, but models may produce false positives, inherit biased data, or be manipulated by adversaries. Automation should support analyst judgment and be governed by clear thresholds and rollback procedures.

Threat-informed defense is also becoming more collaborative. Organizations use sector intelligence, incident reporting, supplier assurance, and purple-team exercises to test whether controls detect and disrupt realistic behaviors. At the same time, edge computing, autonomous devices, serverless workloads, and machine-to-machine identities create new trust relationships. The enduring requirement is not to adopt every new tool, but to maintain accurate asset knowledge, explicit assumptions, accountable access, and tested resilience.

Best-Practice Guidance

A mature program should:

• maintain an authoritative inventory of assets, identities, data flows, suppliers, and trust boundaries;
• model threats during design and revisit them after material changes;
• combine STRIDE, attack trees, ATT&CK, and lifecycle analysis according to purpose;
• prioritize controls by business impact, exploitability, exposure, and detectability;
• enforce least privilege for people, services, devices, and automation;
• use secure defaults, strong authentication, segmentation, protected updates, and meaningful logs;
• test prevention, detection, response, recovery, and safe degradation;
• document assumptions, owners, residual risk, and review dates; and
• include privacy, safety, legal, and ethical considerations in security decisions.

Chapter Summary

Threats arise from the interaction of assets, vulnerabilities, adversaries, opportunities, and business consequences. Cloud, IoT, and enterprise environments create distributed attack surfaces in which identity, supply chains, APIs, devices, and configuration are as important as network boundaries. Attack lifecycles help analysts identify points for prevention and detection, while MITRE ATT&CK provides a behavior-oriented vocabulary. Threat modeling makes assets, data flows, trust boundaries, assumptions, and mitigations explicit. STRIDE supports systematic threat discovery, and attack trees reveal alternative routes to an adversary’s objective. Least privilege and secure-by-design principles reduce the likelihood and impact of compromise. Effective practice combines technical controls with governance, privacy protection, supplier oversight, continuous review, and tested recovery.

Key Terms

Threat: A potential cause of harm to an asset or organization.

Vulnerability: A weakness that may be exploited by a threat actor.

Risk: The possibility of loss or harm, commonly assessed through likelihood and impact.

Adversary: An individual, group, organization, or process capable of causing harm.

Attack surface: The exposed points through which an attacker may interact with a system.

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

Threat modeling: A structured process for identifying threats and selecting mitigations.

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

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

Cyber kill chain: A lifecycle model describing stages commonly associated with an intrusion.

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

Least privilege: Granting only the access necessary for an authorized task and period.

Secure by design: Integrating security requirements into design and development from the outset.

Lateral movement: An attacker’s movement from one compromised system or account to another.

Privilege escalation: Obtaining authority greater than originally granted.

Defense in depth: Using multiple complementary safeguards so one failure does not expose the whole system.

Shared responsibility: The division of security obligations between a cloud provider and its customer.

Zero trust: An approach that requires explicit, context-aware verification rather than implicit network trust.

Residual risk: Risk remaining after safeguards have been implemented.

Review Questions

Short Answer Questions

1. Distinguish a threat, vulnerability, and risk.

2. Why are trust boundaries important in a cloud-IoT architecture?

3. List and briefly explain the six STRIDE categories.

4. What is the purpose of an attack tree?

5. Explain least privilege for a machine identity.

Long Answer Questions

1. Compare the cyber kill chain and MITRE ATT&CK as analytical models. Explain how they may be used together.

2. Describe a complete threat-modeling process for an internet-facing enterprise application.

3. Explain how cloud shared responsibility affects threat analysis and control ownership.

4. Discuss secure-by-design principles for an IoT product with a long operational lifespan.

5. Analyze the organizational, privacy, and ethical issues involved in security monitoring.

Analytical / Application Questions

1. Construct a high-level attack tree for the objective “exfiltrate sensitive data from a cloud storage service.” Identify at least two AND or OR relationships and propose controls.

2. A supplier uses one shared remote-access account to maintain hundreds of connected devices. Apply STRIDE and least-privilege reasoning to identify the major weaknesses and recommend a redesign.

3. An employee account logs in from an unfamiliar location, creates a new cloud access key, discovers storage resources, and downloads unusual volumes of data. Map the sequence to relevant attack-lifecycle or ATT&CK concepts and propose preventive and detective controls.

22. Multiple Choice Questions with Answers

Question 1

A cloud administrator role allows a user to read, modify, and delete resources even though the user only performs inventory reviews. Which principle is most directly violated?

A. Defense in depth

B. Least privilege

C. Non-repudiation

D. Availability

Correct Answer: B. Least privilege

Question 2

In STRIDE, an attacker altering temperature commands sent to an IoT gateway represents which category?

A. Spoofing

B. Repudiation

C. Tampering

D. Information disclosure

Correct Answer: C. Tampering

Question 3

Which statement best describes MITRE ATT&CK?

A. A replacement for asset valuation and business-impact analysis

B. A knowledge base of adversary tactics and techniques

C. A cryptographic standard for cloud storage

D. A model limited to physical security incidents

Correct Answer: B. A knowledge base of adversary tactics and techniques

Question 4

An attack tree uses an OR relationship between “steal an administrator token” and “exploit an exposed management interface.” What does this indicate?

A. Both conditions must occur

B. Neither condition can achieve the objective

C. Either branch may achieve the parent objective

D. The branches apply only after recovery

Correct Answer: C. Either branch may achieve the parent objective

Question 5

Why may a traditional linear cyber kill chain be insufficient for a cloud identity compromise?

A. Cloud systems cannot be monitored

B. The compromise may begin with valid credentials and omit malware delivery

C. The kill chain only describes physical attacks

D. Identity attacks cannot produce impact

Correct Answer: B. The compromise may begin with valid credentials and omit malware delivery

Question 6

Which design choice best supports secure by design for an IoT device?

A. Deploying with a shared default administrator password

B. Relying on users to add security after installation

C. Providing signed updates, unique identities, and secure defaults

D. Allowing unrestricted outbound network access

Correct Answer: C. Providing signed updates, unique identities, and secure defaults

Question 7

A data-flow diagram shows an API receiving requests from the public internet and invoking an internal database service. What should the boundary crossing primarily prompt analysts to examine?

A. Trust and authorization assumptions

B. Office furniture placement

C. Employee holiday schedules

D. Printer toner consumption

Correct Answer: A. Trust and authorization assumptions

Question 8

A supplier’s remote maintenance activity cannot be tied to an individual because all engineers use one account. Which STRIDE concern is most evident?

A. Repudiation

B. Denial of service

C. Tampering only

D. Information disclosure only

Correct Answer: A. Repudiation

Question 9

Which recommendation best addresses a compromised IoT gateway being used to reach enterprise systems?

A. Remove all logging

B. Segment the gateway network and restrict permitted communications

C. Give the gateway domain-administrator privileges

D. Disable firmware validation

Correct Answer: B. Segment the gateway network and restrict permitted communications

Question 10

What is a key limitation of mapping an environment to ATT&CK?

A. It automatically calculates business risk

B. It guarantees that every attack will be prevented

C. It does not by itself establish likelihood, impact, or control effectiveness

D. It cannot describe attacker behavior

Correct Answer: C. It does not by itself establish likelihood, impact, or control effectiveness