Cloud, Virtualised, Mobile, IoT and OT Security

Introduction and Context

Digital transformation has moved computing beyond the traditional enterprise data centre. Organisations now combine public-cloud services, private clouds, virtual machines, containers, smartphones, Internet of Things (IoT) devices and operational-technology (OT) systems. These technologies improve scalability, mobility, automation and business continuity, but they also enlarge the attack surface and complicate accountability.

A server in a company-owned data centre, a managed database in a public cloud, a connected medical sensor and a programmable logic controller (PLC) may all support one business process. They differ substantially in ownership, update mechanisms, network protocols, safety consequences and available security controls. Effective security therefore requires more than selecting a single product. It requires understanding responsibility, identity, architecture, lifecycle management, resilience and the consequences of failure.

This chapter examines how to secure hybrid environments while supporting innovation. It treats cloud, virtualisation, mobile, IoT and OT security as connected disciplines rather than isolated technologies.

Learning Objectives

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

• explain cloud service and deployment models;
• assess shared-responsibility boundaries;
• design controls for cloud identities, workloads, storage, containers and services;
• describe virtualisation threats and suitable countermeasures;
• evaluate mobile-device and mobile-application risks;
• identify IoT weaknesses across the device lifecycle;
• distinguish OT security from conventional IT security;
• analyse hybrid-environment risks and propose proportionate controls;
• discuss governance, privacy, safety, ethics and regulatory implications.

1. Cloud Computing and the Shared-Responsibility Model

Cloud computing provides on-demand access to configurable computing resources, commonly through measured consumption and elastic capacity. The principal service models are:

Deployment may be public, private, community or hybrid. A hybrid environment integrates separately managed environments, often through identity federation, APIs, private connectivity or data replication.

The shared-responsibility model means that security duties are divided rather than transferred completely to the provider. The exact boundary depends on the service, contract and configuration. A provider may secure physical facilities and core infrastructure, while the customer remains responsible for excessive permissions, exposed storage, weak credentials, insecure application code and unlawful data use.

A useful professional practice is to create a responsibility matrix for every important service. It should identify who is accountable for preventive, detective, corrective and recovery controls. The matrix should also identify dependencies: for example, a cloud application may depend on an identity provider, DNS service, logging platform and external software library.

Cloud Identity and Access Management

Identity is the primary security control plane in cloud environments. Network location is insufficient because users, administrators, workloads and automated pipelines may access resources from many locations.

A robust identity architecture includes:

1. Central identity governance. Use an authoritative identity source, lifecycle workflows and timely removal of leavers.
2. Federation and single sign-on. Federated authentication reduces password duplication, but the federation service becomes highly consequential.
3. Multi-factor authentication. Prefer phishing-resistant methods such as hardware-backed passkeys or security keys for privileged access.
4. Least privilege. Grant only the permissions necessary for a defined task and duration.
5. Privileged access management. Use just-in-time elevation, approval, session logging and emergency-access procedures.
6. Workload identities. Applications and automation should use short-lived, narrowly scoped identities rather than embedded long-term secrets.
7. Continuous review. Analyse unused privileges, anomalous access, impossible travel, unusual API calls and changes to authentication policy.

Role-based access control assigns permissions through roles, while attribute-based access control evaluates attributes such as department, resource sensitivity, device assurance and location. Both require accurate attributes and carefully designed policies. A policy that denies access by default is safer than one that attempts to enumerate every allowed situation, but denial rules must be tested to prevent operational disruption.

Cloud Workloads, Storage and Services

Workload security begins before deployment. Infrastructure-as-code should be reviewed, version controlled, scanned and subject to approval. Secure images should be hardened, signed and continuously assessed for vulnerabilities. Unnecessary services, ports, packages and administrative interfaces should be removed.

Cloud storage requires particular attention because a single policy error can expose large datasets. Controls include:

• private-by-default storage;
• explicit resource policies and access reviews;
• encryption in transit and at rest;
• customer-managed keys where justified by risk;
• separation of key administrators from data administrators;
• retention, legal-hold and secure-deletion rules;
• immutable backups for high-value data;
• data-loss-prevention monitoring;
• alerts for public exposure and unusual downloads.

Encryption does not automatically make data safe. Access to keys, metadata leakage, compromised applications and lawful-access obligations remain important. Data classification should determine where data may be stored, replicated and processed.

Cloud services are frequently composed through APIs. API security requires strong authentication, authorisation at the object and function level, input validation, rate limiting, secure error handling, inventory management and monitoring. Secrets should be stored in a managed secrets service and rotated according to risk.

2. Virtualisation and Container Security

Virtualisation abstracts physical resources so that multiple virtual machines share a host through a hypervisor. It supports isolation, rapid provisioning and disaster recovery, but compromise of the hypervisor or management plane can affect many workloads.

Important virtualisation risks include:

• vulnerable or misconfigured hypervisors;
• exposed management interfaces;
• virtual-network missegmentation;
• insecure snapshots and images;
• excessive administrator privileges;
• stale virtual machines containing sensitive data;
• side-channel or resource-exhaustion attacks;
• unmonitored migration traffic;
• weak separation between development and production.

The management plane should be isolated, restricted to approved administration paths and protected by strong authentication. Hypervisors, guest systems and management tools require coordinated patching. Templates should be hardened and scanned before approval. Snapshots must be governed because they may contain credentials, memory contents or regulated data.

Containers share the host operating-system kernel, unlike conventional virtual machines that generally include separate guest kernels. Containers therefore offer efficient packaging but require careful protection of the host and orchestration platform. Key controls include signed images, minimal base images, dependency scanning, non-root execution, read-only filesystems where feasible, restricted Linux capabilities, admission policies, network policies, runtime detection and protected orchestration credentials.

A software supply-chain process should record the origin and components of images. A software bill of materials (SBOM) supports vulnerability analysis, although an SBOM alone does not demonstrate that a vulnerability is exploitable or that the deployed component is actually reachable.

3. Mobile Security

Mobile devices combine personal identity, corporate data, sensors, cameras, location information and third-party applications. Their portability creates risks from loss, theft, insecure networks, malicious applications, social engineering and unauthorised modification.

A mobile security programme should include:

• mobile-device management or unified endpoint management;
• secure enrolment and device attestation where available;
• screen-lock and encryption requirements;
• operating-system and application update policies;
• separation of corporate and personal data;
• remote lock and selective or full wipe procedures;
• application allowlists or risk-based application controls;
• phishing-resistant authentication;
• secure mobile-application development;
• backup and privacy controls;
• clear bring-your-own-device agreements.

Mobile applications should use secure storage provided by the operating system, minimise permissions, validate certificates correctly and avoid placing tokens or personal data in logs. APIs must enforce authorisation on the server; hiding a function in a mobile interface is not a security control. Developers should consider rooted or jailbroken devices, reverse engineering, insecure deep links, insecure local databases and third-party software development kits.

Organisations must balance security with privacy. Excessive monitoring of personal devices can be unlawful or unethical, particularly where location, contacts or personal communications are collected without necessity and transparency.

4. IoT Security

IoT systems consist of devices, connectivity, gateways, cloud services, applications and users. Examples include environmental sensors, smart-building controls, connected vehicles and consumer devices. The apparent simplicity of a sensor can conceal a complex supply chain and a permanent network presence.

IoT risks include default credentials, insecure firmware, unsigned updates, exposed debug ports, weak cryptography, hard-coded secrets, insecure wireless protocols, poor inventory and unsupported devices. Physical access may allow extraction of firmware or manipulation of sensors. A compromised device can become a botnet member, pivot into a corporate network or generate unsafe readings.

Security should begin with procurement. Requirements should address unique credentials, secure boot, signed updates, vulnerability disclosure, support lifetime, logging, data minimisation and end-of-life disposal. Devices should be inventoried continuously, assigned to owners and segmented according to function and consequence. A sensor that only sends measurements should not be able to initiate arbitrary connections to business systems.

A useful lifecycle is:

1. define security and privacy requirements;
2. assess suppliers and device provenance;
3. provision unique identities and keys;
4. segment and monitor deployment;
5. patch and rotate credentials;
6. respond to compromise;
7. revoke identities and securely retire the device.

IoT data may reveal occupancy, health, behaviour or industrial processes. Collection should be necessary, proportionate and governed by retention and access rules.

5. Operational Technology Security

OT controls physical processes. Industrial-control systems may include supervisory control and data acquisition (SCADA), distributed-control systems, PLCs, safety-instrumented systems and building-management systems. OT security must preserve confidentiality and integrity, but availability, process stability and human safety commonly receive priority.

OT environments differ from ordinary IT environments in several respects:

A secure OT architecture uses zones and conduits. Safety systems, controllers, supervisory systems, engineering workstations and enterprise networks should be separated according to function and risk. Firewalls, unidirectional gateways, jump servers and monitored remote access can reduce exposure. Direct internet connectivity to controllers is unacceptable.

OT monitoring should be largely passive where active scanning could disrupt equipment. Asset inventories must include firmware, communication paths, process role and safety significance. Patching requires vulnerability assessment, vendor guidance, offline testing and a compensating-control plan when immediate patching is impossible.

Incident response must integrate cyber, engineering, safety and continuity teams. A technically successful containment action may be unsafe if it abruptly stops a process. Recovery plans should define safe states, manual operation, spare equipment, validated backups and communication with regulators or emergency services.

6. Hybrid-Environment Architecture and Zero Trust

Hybrid environments fail when trust relationships are assumed rather than designed. A secure architecture treats every connection as a controlled interaction between an authenticated subject, a device, an application and a resource.

Zero Trust is an architectural approach, not a single product. Its practical principles include verifying explicitly, applying least privilege and assuming breach. Controls commonly include identity-aware proxies, device health assessment, microsegmentation, workload identity, continuous logging and policy enforcement near the resource.

Figure: A zero-trust control point mediating access across hybrid resources.

Central visibility is essential. Logs from identity providers, cloud control planes, endpoints, applications, network devices and OT monitoring should be time-synchronised and protected from tampering. Detection engineering should prioritise high-value events such as creation of privileged accounts, policy changes, public storage exposure, unusual data transfer and unauthorised remote engineering access.

7. Governance, Risk and Professional Practice

Risk assessment should consider likelihood, impact, exposure, detectability and recovery capability. Numerical scoring can support prioritisation but should not create false precision. A low-probability event may still require urgent treatment if it could cause fatalities, major environmental damage or systemic loss of trust.

Governance should define asset ownership, security baselines, exception approval, supplier assurance, incident reporting and evidence retention. Relevant obligations may include data-protection law, sector-specific regulation, contractual requirements and safety regulation. Organisations should map controls to suitable frameworks such as the NIST Cybersecurity Framework, ISO/IEC 27001, ISO/IEC 27017 for cloud security, ISO/IEC 27018 for protection of personal data in public clouds, IEC 62443 for industrial automation and control systems, and applicable mobile or payment standards.

Third-party risk is especially significant because cloud providers, device manufacturers, managed-service providers and software suppliers may have privileged access or control update mechanisms. Due diligence should examine security practices, vulnerability disclosure, subcontractors, breach notification, data location, portability, exit assistance and independent assurance reports.

Artificial intelligence is increasingly used for cloud anomaly detection, mobile threat analysis and industrial predictive maintenance. It can improve scale but can also generate false positives, conceal uncertainty and expose sensitive telemetry. AI outputs should be treated as decision support, with human oversight, protected training data, tested models and documented accountability. Attackers may manipulate sensor inputs or exploit machine-learning services, making provenance and validation important.

8. Illustrative Case: A Hybrid Manufacturing Organisation

Background

A fictional manufacturer operates cloud-based enterprise applications, a private data centre, mobile devices for field engineers and an OT network containing PLCs and a supervisory system. Production telemetry is sent to a cloud analytics platform.

Problem

An engineer’s stolen laptop was used to access a remote-support account. The account had excessive privileges and connected through a flat network path to an engineering workstation. Investigation also found public exposure of a cloud storage bucket containing historical telemetry and several factory sensors using shared credentials.

Analysis

The incident was not caused by one technical defect. It involved weak identity governance, insufficient device assurance, poor network segmentation, cloud-storage misconfiguration and inadequate IoT lifecycle management. The business impact included potential intellectual-property disclosure and a credible risk of unsafe process manipulation.

Approach and Solution

The organisation implemented phishing-resistant MFA and privileged, time-limited access for engineers. Remote access was routed through a monitored jump server, with device health checks and approval for each maintenance session. The OT network was divided into zones, and communications were restricted to documented conduits. Passive monitoring established an asset inventory without disrupting production.

Cloud storage was made private by default, with automated exposure alerts, encryption-key separation and retention rules. IoT devices received unique credentials, were placed in a restricted segment and were replaced where secure updates were impossible. Cloud telemetry access was redesigned using workload identities and narrowly scoped roles. Incident-response exercises included engineering and safety personnel.

Outcome

The organisation reduced unnecessary privilege, improved detection of anomalous remote access and established a tested process for safe OT recovery. It also accepted that some legacy devices could not be fully secured and documented compensating controls and replacement priorities.

Learning Points

Security responsibility follows the architecture, not the marketing label of a service. Identity, segmentation and lifecycle governance must cover cloud and physical environments together. In OT, a technically elegant control is unsuitable if it can destabilise a safety-critical process. Risk acceptance must be explicit, time-bound and approved by accountable owners.

9. Challenges and Limitations

No control eliminates risk. Multi-cloud environments can produce inconsistent policy, duplicated logs and complex identity federation. Strong segmentation may increase operational cost and complicate troubleshooting. Encryption can create key-recovery challenges. Automated vulnerability scanners may disrupt fragile OT systems or miss business-context risks. Device attestation and AI detection depend on trustworthy measurements. Finally, security programmes can fail through human factors when controls are inconvenient, unexplained or unsupported by leadership.

Effective programmes therefore combine technology with clear ownership, usable processes, skilled personnel, testing and continuous improvement. Tabletop exercises, red-team assessments, configuration reviews, backup restoration tests and supplier reviews provide evidence that controls work in practice.

Chapter Summary

Cloud, virtualisation, mobile, IoT and OT systems form an interconnected digital environment with different ownership models and consequences of failure. Cloud security depends on understanding shared responsibility, protecting identities, governing workloads and storage, and securing APIs and supply chains. Virtual machines require hypervisor and management-plane protection, while containers require secure images, restricted privileges and orchestrator security.

Mobile security combines device management, application security, privacy and phishing resistance. IoT security must address procurement, unique identity, secure updates, segmentation, monitoring and end-of-life disposal. OT security gives particular weight to safety, availability, process integrity, passive monitoring and carefully tested change. Hybrid environments benefit from zero-trust principles, central visibility and explicit trust boundaries. Governance, supplier assurance, regulatory compliance and human accountability remain essential, especially when AI and automation are introduced.

Key Terms

Cloud computing: On-demand delivery of configurable computing resources.

Shared responsibility: Division of security duties between a service provider and customer.

IaaS: Cloud model providing virtualised infrastructure resources.

PaaS: Cloud model providing a managed application platform.

SaaS: Cloud model delivering a complete hosted application.

Federation: Trust arrangement allowing identities from one domain to access another.

Workload identity: Identity assigned to an application, service or automated process.

Least privilege: Granting only the access necessary for an authorised task.

Virtual machine: Software-defined computer running on a hypervisor.

Container: Isolated application package sharing the host operating-system kernel.

SBOM: Inventory of software components and dependencies.

Mobile-device management: Administrative control of enrolled mobile devices.

IoT: Network of physical devices that sense, process or communicate data.

OT: Technology that monitors or controls physical processes.

SCADA: Supervisory control and data-acquisition system.

PLC: Programmable logic controller used to control industrial equipment.

Zero Trust: Security approach based on explicit verification and least privilege.

Microsegmentation: Dividing an environment into small, separately controlled security zones.

Secure boot: Startup process that verifies authorised software before execution.

Compensating control: Alternative measure used when a preferred control cannot be implemented.

Review Questions

Short Answer Questions

1. What does the cloud shared-responsibility model mean?
2. Why are cloud identities considered a primary control plane?
3. State two security differences between containers and virtual machines.
4. Why must IoT devices be managed across their entire lifecycle?
5. Why can active vulnerability scanning be unsuitable for some OT environments?

Long Answer Questions

1. Compare IaaS, PaaS and SaaS, explaining how customer security responsibilities change between them.
2. Explain how a zero-trust architecture can support secure hybrid cloud and enterprise environments.
3. Discuss the principal security controls for cloud storage and cloud APIs.
4. Compare IT and OT security priorities, change processes and incident-response requirements.
5. Explain how mobile, IoT and supplier risks can affect privacy and organisational governance.

Analytical / Application Questions

1. A company discovers that a cloud storage repository is publicly accessible, mobile engineers share a privileged account, and factory sensors use default passwords. Analyse the underlying governance failures and propose a prioritised remediation plan.
2. Design a segmented architecture for an organisation containing public-cloud workloads, a private data centre, mobile users and an OT network. Identify trust boundaries, identity controls, monitoring requirements and recovery considerations.
3. An old industrial controller cannot be patched without a production shutdown. Evaluate the risk and recommend compensating controls, evidence requirements and a replacement decision process.

Multiple Choice Questions with Answers

Question 1

Which responsibility normally remains with a customer using Infrastructure as a Service?

A. Physical security of the provider’s data centre

B. Replacement of failed provider storage hardware

C. Configuration of the guest operating system and access permissions

D. Security of the hypervisor code

Correct Answer: C. Configuration of the guest operating system and access permissions

Question 2

Which control most directly reduces the risk of a stolen administrator password being used alone?

A. Multi-factor authentication

B. Network address translation

C. Data compression

D. Increasing storage capacity

Correct Answer: A. Multi-factor authentication

Question 3

Why are container images commonly signed and scanned?

A. To increase processor speed

B. To establish provenance and identify vulnerable components

C. To eliminate the need for runtime controls

D. To replace network segmentation

Correct Answer: B. To establish provenance and identify vulnerable components

Question 4

Which practice is most appropriate for cloud object storage?

A. Make all repositories public for easy collaboration

B. Use private-by-default access and alert on exposure

C. Store keys in application source code

D. Permit anonymous administrative access

Correct Answer: B. Use private-by-default access and alert on exposure

Question 5

Which statement best describes OT security?

A. Confidentiality always has priority over safety

B. Frequent untested patching is preferred

C. Safety and stable physical operation are major security objectives

D. OT systems should be directly connected to the internet

Correct Answer: C. Safety and stable physical operation are major security objectives

Question 6

What is a principal purpose of mobile-device management?

A. To guarantee that every application is trustworthy

B. To enforce device policies and support actions such as remote wipe

C. To remove the need for user authentication

D. To make APIs unnecessary

Correct Answer: B. To enforce device policies and support actions such as remote wipe

Question 7

Which IoT practice is strongest?

A. Use one shared password for all devices

B. Leave debug interfaces enabled permanently

C. Provision unique identities and provide signed updates

D. Avoid maintaining an asset inventory

Correct Answer: C. Provision unique identities and provide signed updates

Question 8

In a zero-trust architecture, access decisions should primarily be based on:

A. Implicit trust derived from network location

B. Explicit verification, context and least privilege

C. Physical proximity to the server

D. Whether the request uses a familiar brand of device

Correct Answer: B. Explicit verification, context and least privilege

Question 9

Why are OT incident-response actions coordinated with engineering and safety teams?

A. Cybersecurity tools cannot create logs in OT

B. A containment action may affect physical safety or process stability

C. OT systems never contain vulnerabilities

D. Safety teams manage all cloud identities

Correct Answer: B. A containment action may affect physical safety or process stability

Question 10

Which measure best limits the effect of a compromised IoT sensor?

A. Place it in a restricted network segment with narrowly defined communications

B. Give it unrestricted access to enterprise systems

C. Disable all monitoring

D. Use the same credentials as the cloud administrator

Correct Answer: A. Place it in a restricted network segment with narrowly defined communications