Cloud, Container, IoT and Operational Technology Security

Introduction and Context

Computing has moved beyond the traditional enterprise data centre. Organisations now operate workloads in public, private and hybrid clouds; package applications in containers; deploy serverless functions; and connect physical devices through the Internet of Things (IoT). Manufacturing plants, utilities, transport systems and hospitals also depend on operational technology (OT) and cyber-physical systems (CPS). These environments create substantial benefits, but they also enlarge the attack surface and introduce safety, availability and supply-chain risks.

Cloud security is not simply the transfer of conventional security controls to a remote data centre. Responsibility is divided between the cloud service provider and the customer. Containers share host resources and therefore require protection at both the application and orchestration layers. IoT devices may be inexpensive, physically exposed and difficult to patch. OT systems often prioritise continuous operation and safety over confidentiality, while using legacy protocols that were not designed for hostile networks.

This chapter examines security principles for these environments and compares their risks, controls and governance requirements.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain cloud service and deployment models and apply the shared-responsibility model.
2. Secure cloud identities, workloads, storage, networks and serverless functions.
3. Describe container and orchestration risks and recommend appropriate controls.
4. Compare IoT, CPS and OT security requirements.
5. Analyse a multi-environment security incident and propose a defensible response.
6. Evaluate availability, safety, privacy, governance and ethical considerations.

1. Cloud Computing and the Shared-Responsibility Model

Cloud computing provides on-demand access to configurable computing resources. Important service models are:

In all models, the provider is generally responsible for security of the cloud, while the customer remains responsible for security in the cloud. The exact boundary varies by provider, service and contract. A managed database may remove operating-system duties, but it does not make weak passwords, excessive permissions or publicly exposed data the provider’s responsibility.

Deployment models include public cloud, private cloud, hybrid cloud and community cloud. Hybrid environments require particular attention to identity federation, private connectivity, consistent logging and data-transfer controls.

A useful governance principle is to identify every asset, its owner, its data classification and its control boundary. Security teams should not assume that a provider’s certification automatically secures customer configurations.

2. Cloud Identity and Access Management

Identity is the primary security control plane in cloud systems. A stolen administrative credential may allow an attacker to create resources, disable logging, access storage and establish persistence without exploiting a traditional server vulnerability.

Effective cloud identity and access management (IAM) includes:

• Federated identity: Employees authenticate through a central identity provider using standards such as SAML or OpenID Connect.
• Multi-factor authentication: Administrative and high-risk access should require phishing-resistant methods where practical.
• Least privilege: Users, applications and services receive only the permissions necessary for defined tasks.
• Role-based access control: Permissions are assigned to roles rather than individually managed wherever possible.
• Separation of duties: For example, a developer may deploy code but not approve production access independently.
• Short-lived credentials: Workloads should use temporary tokens or managed identities instead of embedded long-term keys.
• Privileged access management: Administrative privileges should be just-in-time, monitored and reviewed.
• Access review: Dormant accounts, excessive permissions and unused service roles must be removed.

IAM policies should be tested as code and reviewed for indirect privilege escalation. For example, permission to modify a function that possesses administrative permissions can be equivalent to administrative access, even when the user has not been granted the administrator role directly.

3. Protecting Cloud Workloads, Networks and Storage

Workloads and virtual machines

Cloud virtual machines require hardened images, timely patching, endpoint protection, secure administrative access and restricted management ports. Images should be built from approved baselines and scanned before deployment. Administrative interfaces should not be exposed directly to the public Internet; access should use private connectivity, bastion services or zero-trust gateways.

Security groups, network access-control lists and micro-segmentation should restrict traffic between application tiers. Network controls are valuable, but they cannot replace identity, application authentication or secure coding.

Storage and data protection

Cloud storage failures frequently result from misconfiguration rather than sophisticated exploitation. Controls include:

• default-deny access policies;
• encryption in transit and at rest;
• customer-managed keys where appropriate;
• prevention of public access unless explicitly justified;
• immutable or versioned backups;
• data-loss prevention and classification;
• access logging and anomaly detection; and
• retention and deletion policies.

Encryption reduces exposure but does not solve authorisation failures. If an application is authorised to read a data object, an attacker who compromises that application may still obtain the plaintext.

A sound design separates production accounts or subscriptions from development environments, limits cross-account access and stores secrets in a dedicated secrets-management service rather than source code or configuration files.

Cloud monitoring and resilience

Centralised logs should record authentication, privilege changes, network activity, storage access and administrative actions. Logs need integrity protection, time synchronisation, suitable retention and restricted access. Security information and event management systems can correlate events such as a new access key, an unusual geographic login and bulk data retrieval.

Resilience requires tested backups, recovery objectives and dependency mapping. The recovery time objective (RTO) is the maximum acceptable time to restore a service. The recovery point objective (RPO) is the maximum acceptable period of data loss measured in time. These are organisational requirements, not merely technical settings.

4. Containers and Orchestration

A container packages an application and its dependencies while sharing the host operating-system kernel. This differs from a virtual machine, which normally includes a separate guest kernel. Containers improve portability and deployment speed but increase the importance of image integrity, runtime isolation and orchestrator security.

Container risks

Common risks include:

• vulnerable or malicious base images;
• secrets embedded in images or environment variables;
• containers running as root;
• excessive Linux capabilities;
• insecure container registries;
• exposed management interfaces;
• host-path mounts that bypass isolation;
• vulnerable dependencies;
• untrusted code reaching production; and
• orchestration misconfiguration.

A secure container pipeline scans source code, dependencies, image layers and infrastructure-as-code definitions. Images should be minimal, pinned to trusted versions, signed and verified before deployment. Build systems should be isolated from production credentials.

Kubernetes and orchestration security

An orchestrator controls scheduling, networking, service discovery and secrets. Security therefore exists at several layers: the control plane, nodes, workloads, admission policies, identities and network policies. Recommended practices include role-based access control, private control-plane access, node hardening, namespace separation, admission controls, pod security restrictions, encrypted secrets and network segmentation.

The principle of least privilege applies to service accounts as well as human users. A workload should not automatically receive broad permissions merely because it runs inside a cluster. Runtime monitoring should detect unexpected processes, privilege changes, unusual network connections and attempts to access host resources.

5. Serverless Security

Serverless computing executes functions in response to events while the provider manages much of the infrastructure. It reduces operational administration but introduces event-driven risks:

• overly permissive function roles;
• insecure event sources;
• injection through messages or API requests;
• dependency vulnerabilities;
• excessive function timeout or resource consumption;
• leakage through logs;
• insecure third-party layers; and
• confused-deputy attacks in which a function performs an unintended action using its privileges.

Each function should have a narrowly scoped identity, validated input, controlled outbound access, dependency management and structured logging. Event queues and storage triggers must be authenticated and authorised. Security testing should include both the function and the event chain that invokes it.

6. IoT and Cyber-Physical Systems

IoT refers to connected sensors, actuators, appliances, vehicles and other embedded devices. A cyber-physical system combines computation and networking with physical processes. A smart irrigation controller is IoT; a connected industrial robot is both IoT and CPS.

IoT devices commonly have constrained processing power, long service lives, inconsistent update mechanisms and physical exposure. They may be deployed in large numbers, making individual manual administration impractical. Typical threats include default credentials, insecure firmware, unencrypted communication, weak update mechanisms, exposed debug interfaces, supply-chain compromise, botnet recruitment and privacy-invasive data collection.

Important IoT controls include:

1. Maintain an accurate device inventory and ownership record.
2. Assign unique device identities; never use shared default credentials.
3. Use secure boot and signed firmware.
4. Protect device-to-cloud and device-to-device communication.
5. Provide authenticated, resilient and preferably rollback-capable updates.
6. Disable unnecessary services and physical debugging interfaces.
7. Segment devices from corporate and safety-critical networks.
8. Monitor device behaviour and investigate deviations from the expected baseline.
9. Plan secure decommissioning, credential revocation and data deletion.
10. Apply privacy-by-design to location, health, audio and behavioural data.

A device identity should be bound to hardware or a protected credential store where feasible. However, cryptography alone cannot secure a device whose firmware, update process or administrative service is compromised.

7. Operational Technology and Industrial Control Systems

Operational technology monitors or controls physical equipment. Examples include supervisory control and data acquisition (SCADA), distributed control systems, programmable logic controllers (PLCs), building-management systems and manufacturing-control networks.

OT differs from conventional information technology in several ways:

The confidentiality, integrity and availability triad remains relevant, but priorities vary by process. An incorrect control command may be more dangerous than data disclosure. Safety instrumented systems and independent protective mechanisms should not rely solely on the same network or software that controls the process.

OT security begins with passive asset discovery and a documented process model. Active scanning can disrupt fragile equipment and should be carefully authorised. Network segmentation, industrial firewalls, unidirectional gateways, jump hosts, strict remote access, application allow-listing and tested recovery procedures are common controls.

The Purdue Enterprise Reference Architecture is often used to reason about layers from enterprise systems to control and field devices. It is a conceptual aid rather than a guarantee of security. Modern architectures may require additional zones, conduits and identity-aware controls because cloud analytics and remote maintenance cross traditional boundaries.

8. Comparing Risks and Controls

The same control may have different implementation consequences. Aggressive vulnerability scanning may be acceptable in a cloud test environment but unsafe against a live PLC. Likewise, automatically revoking an IoT certificate may protect a fleet but interrupt a critical medical or industrial service if replacement credentials are unavailable.

9. Security Architecture and Risk Management

A defensible architecture combines preventive, detective, responsive and recovery controls. Zero trust is relevant across these environments: no user, device, workload or network location is automatically trusted. Access decisions should consider identity, device state, resource sensitivity, context and intended action.

Risk analysis should consider likelihood, impact, exposure and uncertainty. It should include safety and societal effects, not merely financial loss. Threat modelling can identify trust boundaries, privileged operations, dangerous commands, data flows and failure modes. STRIDE can assist with software threats, while techniques such as attack trees and MITRE ATT&CK for relevant platforms can support adversary analysis.

Security controls must be proportionate. A low-risk environmental sensor does not necessarily require the same controls as a chemical-process controller, although both need an inventory, identity and update strategy.

10. Illustrative Case: Compromise of a Smart Manufacturing Environment

Background

A fictional manufacturer operates cloud-based analytics, a Kubernetes cluster for production applications, IoT vibration sensors and a plant OT network containing PLCs. A maintenance contractor requires remote access.

Problem

An attacker obtains a contractor credential through phishing. The account lacks strong multi-factor authentication and has broad cloud permissions. The attacker creates an access key, retrieves sensor data from an overly permissive storage bucket and uses a vulnerable container image to obtain access to a cluster service account. From the cluster, the attacker discovers a poorly restricted remote-maintenance path toward the plant network.

Analysis

The incident is not caused by one failed technology. It reflects multiple boundary failures: weak identity governance, excessive permissions, insecure storage configuration, inadequate image control and insufficient segmentation between IT, cloud and OT. The potential impact includes intellectual-property theft, production interruption and unsafe physical operation.

Approach and solution

The organisation first disables the compromised credentials, preserves logs and isolates affected workloads without abruptly shutting down safety-critical processes. It validates PLC state through plant operators and uses independent safety procedures. It then rotates secrets, removes public storage access, rebuilds workloads from approved signed images and restricts service-account permissions.

Longer-term measures include phishing-resistant MFA for contractors, just-in-time remote access, separate cloud accounts, admission controls for container images, passive OT monitoring, a controlled jump host, explicit conduits between zones and rehearsed recovery procedures. Contractor access is redesigned around task, time and asset rather than permanent network reachability.

Outcome and learning points

The organisation restores normal operations without evidence of unsafe actuation, but discovers that its asset inventory was incomplete. The principal lesson is that security must follow data and control flows across environments. Cloud, containers, IoT and OT cannot be governed as isolated technical silos.

11. Governance, Ethics and Regulation

Cloud and connected-device programmes require clear accountability for data ownership, breach notification, cross-border transfer, retention and third-party access. Relevant obligations may include privacy legislation, sector-specific requirements, critical-infrastructure rules and contractual security standards. Exact legal duties depend on jurisdiction and sector; organisations should obtain appropriate legal and compliance advice.

Ethically, designers must consider surveillance, consent, algorithmic decisions, accessibility and the consequences of unsafe automation. A connected device that collects more data than necessary creates avoidable privacy risk. A manufacturer should not conceal unsupported devices or discontinue security updates without an appropriate transition plan.

Artificial intelligence can improve anomaly detection, malware classification and predictive maintenance, but it can also generate false alarms, conceal bias and be manipulated by adversarial data. AI-generated alerts should be explainable enough for operators to assess, and automated actions in safety-critical environments should have bounded authority, human oversight and fail-safe behaviour.

12. Contemporary Developments and Best Practices

Current security practice is moving toward infrastructure as code, policy as code, software bills of materials, confidential computing, workload identity, zero-trust access, secure-by-design regulation and stronger software supply-chain assurance. These developments do not eliminate fundamental risks; they improve repeatability and visibility when implemented correctly.

A practical programme should:

• define responsibility matrices for every cloud and connected service;
• inventory assets, identities, data flows and dependencies;
• enforce MFA and least privilege;
• use secure defaults and automated configuration assessment;
• establish signed, reproducible build and update pipelines;
• segment networks according to trust and consequence;
• monitor identity, workload, device and process behaviour;
• test backups, incident response and safe operating procedures;
• review suppliers and maintenance contractors; and
• measure remediation, coverage and recovery performance rather than relying only on compliance checklists.

The goal is not perfect prevention. It is controlled exposure, rapid detection, safe containment and reliable recovery while preserving essential business and physical processes.

Chapter Summary

Cloud, containers, serverless platforms, IoT, CPS and OT extend computing into shared, distributed and physical environments. The shared-responsibility model requires customers to understand exactly which controls remain theirs. Strong IAM, least privilege, MFA, secure storage, workload hardening, logging and recovery are foundational cloud practices. Container security depends on trusted images, protected registries, constrained service accounts and orchestrator controls. Serverless systems require secure event chains and narrowly scoped function permissions.

IoT security is shaped by scale, constrained devices, physical exposure and long lifecycles. OT and CPS security must account for safety, legacy technology, process integrity and the consequences of downtime. Segmentation, secure updates, inventory, passive monitoring, controlled remote access and tested recovery are broadly important, but controls must be adapted to operational risk. Effective security is therefore an architectural and governance discipline spanning identities, software, devices, suppliers, people and physical processes.

Key Terms

Cloud computing: On-demand provision of shared computing resources.

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

IAM: Identity and access management for users, services and devices.

Least privilege: Granting only the permissions required for an authorised task.

Federated identity: Authentication coordinated between independent identity domains.

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

Orchestrator: Software that schedules and manages containers and their services.

Serverless computing: Event-driven execution in which the provider manages most infrastructure.

IoT: Networked physical devices that sense, process or act on information.

Cyber-physical system: A system integrating computation, networking and physical processes.

Operational technology: Technology that monitors or controls physical operations.

SCADA: Supervisory control and data acquisition system.

PLC: Programmable logic controller used to control industrial processes.

Secure boot: Starting a device only with authenticated firmware.

Network segmentation: Dividing a network to restrict communication and limit compromise.

RTO: Maximum acceptable time to restore a service.

RPO: Maximum acceptable period of data loss measured in time.

Zero trust: Security approach that verifies each access request rather than trusting location.

Software bill of materials: Structured inventory of components in a software product.

Review Questions

Short Answer Questions

1. What does the cloud shared-responsibility model mean?
2. Why should cloud workloads use temporary credentials?
3. Identify two risks associated with container images.
4. Why is passive monitoring often preferred in OT networks?
5. Distinguish IoT from a cyber-physical system.

Long Answer Questions

1. Explain how IAM, network segmentation and logging work together in a cloud environment.
2. Compare security controls for containers and serverless functions.
3. Discuss why OT security priorities differ from conventional IT priorities.
4. Describe a secure lifecycle for an IoT device from deployment through decommissioning.
5. Explain the governance and ethical issues associated with cloud-connected industrial systems.

Analytical / Application Questions

1. A public storage bucket contains manufacturing data, and its access logs show unusual downloads. Analyse the likely control failures and propose an incident-response sequence.
2. Design a segmentation and remote-access architecture for a plant containing cloud analytics, IoT sensors, Kubernetes workloads and PLCs. Justify each trust boundary.
3. A hospital wants to deploy connected infusion pumps that receive cloud updates. Evaluate the security, safety, privacy and availability requirements before deployment.

Multiple Choice Questions with Answers

Question 1

In an Infrastructure as a Service model, which responsibility normally remains with the customer?

A. Maintaining the provider’s physical data-centre power systems

B. Patching and securely configuring the guest operating system

C. Replacing failed physical storage devices

D. Maintaining the cloud provider’s hypervisor

Correct Answer: B. Patching and securely configuring the guest operating system

Question 2

Which control most directly reduces the risk of a stolen long-term cloud access key?

A. Using temporary workload credentials

B. Increasing storage capacity

C. Disabling time synchronisation

D. Publishing access policies publicly

Correct Answer: A. Using temporary workload credentials

Question 3

Why are containers not equivalent to complete virtual machines?

A. Containers cannot run applications

B. Containers always require physical servers dedicated to one application

C. Containers generally share the host operating-system kernel

D. Containers cannot use network connections

Correct Answer: C. Containers generally share the host operating-system kernel

Question 4

Which practice best protects a container deployment pipeline?

A. Allowing unsigned images from any public registry

B. Running every container with unrestricted host privileges

C. Embedding production secrets in image layers

D. Scanning, signing and verifying trusted images

Correct Answer: D. Scanning, signing and verifying trusted images

Question 5

What is a distinctive security challenge of IoT environments?

A. Every device is physically protected inside a data centre

B. Devices may be numerous, constrained and difficult to update

C. IoT devices never collect personal information

D. IoT devices cannot communicate wirelessly

Correct Answer: B. Devices may be numerous, constrained and difficult to update

Question 6

Why can active vulnerability scanning be dangerous in an OT environment?

A. OT systems cannot contain software

B. Scanning always encrypts PLC memory

C. Fragile or legacy equipment may malfunction or be disrupted

D. OT networks do not use addresses

Correct Answer: C. Fragile or legacy equipment may malfunction or be disrupted

Question 7

Which statement best describes the shared-responsibility model?

A. The provider is responsible for every customer configuration

B. The customer is responsible for the provider’s physical facilities

C. Security duties are divided according to the service and contract

D. No party is responsible for cloud security

Correct Answer: C. Security duties are divided according to the service and contract

Question 8

Which principle limits the impact of a compromised serverless function?

A. Granting the function administrator permissions by default

B. Assigning the function a narrowly scoped role

C. Disabling all event validation

D. Storing credentials in source code

Correct Answer: B. Assigning the function a narrowly scoped role

Question 9

What is the primary purpose of network segmentation?

A. To ensure every device can communicate with every other device

B. To restrict communication and limit lateral movement

C. To eliminate the need for authentication

D. To replace software updates

Correct Answer: B. To restrict communication and limit lateral movement

Question 10

In disaster recovery planning, what does RPO describe?

A. The maximum acceptable time to restore service

B. The number of administrators allowed to access a system

C. The maximum acceptable period of data loss measured in time

D. The physical distance between two data centres

Correct Answer: C. The maximum acceptable period of data loss measured in time