Cloud, Container, Mobile, Wireless and IoT Security

Introduction

Modern computing is no longer concentrated in a controlled enterprise data centre. Applications execute across public clouds, private clouds, containers, Kubernetes clusters, service meshes, smartphones, 5G networks, wireless LANs, industrial systems and billions of constrained Internet of Things (IoT) devices. These environments improve elasticity, mobility and automation, but they also enlarge the attack surface and distribute responsibility among vendors, operators, developers, users and device manufacturers.

Security in these environments cannot be achieved by a single perimeter firewall. It requires identity-centred access control, secure software supply chains, workload isolation, cryptographic protection, continuous monitoring, resilient architecture and governance based on explicit responsibility. This chapter evaluates the major security principles and deployment patterns relevant to cloud-native, mobile, wireless, operational technology (OT) and IoT systems.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain shared-responsibility models and distinguish infrastructure, platform and software service risks.
2. Design security controls for virtual networks, APIs, containers, Kubernetes and service meshes.
3. Evaluate mobile-platform, 5G and wireless-network threats and protections.
4. Analyse the special safety, availability and lifecycle requirements of OT and IoT.
5. Select suitable cryptographic mechanisms for constrained and distributed devices.
6. Develop secure deployment, monitoring, governance and incident-response patterns.

1. Security as a Distributed Responsibility

A traditional data-centre model assumes that one organisation owns the hardware, operating systems, networks and applications. Cloud computing changes this assumption. In an Infrastructure as a Service (IaaS) model, the provider generally protects physical facilities, hardware and the hypervisor, while the customer protects guest operating systems, applications, identities, data and network configuration. In Platform as a Service (PaaS), the provider manages more of the operating environment, but the customer remains responsible for application code, data, identities and configuration. In Software as a Service (SaaS), the provider operates the application, although the customer still controls users, data classification, access rights and organisational compliance.

The shared-responsibility model is not a universal legal rule. Exact boundaries depend on the provider, service, region, contract and configuration. A useful management practice is to create a responsibility matrix for every service, identifying who is accountable for prevention, detection, response, evidence preservation and recovery.

A frequent failure is assuming that migration transfers accountability. It does not. Cloud security failures commonly arise from excessive permissions, publicly exposed storage, unprotected secrets, insecure application programming interfaces (APIs), vulnerable dependencies and inadequate logging.

A Risk-Based Model

A simple risk model is:

Likelihood expresses the probability or frequency of a harmful event, while impact represents expected operational, financial, safety, legal or reputational loss. The expression is a prioritisation model rather than a precise physical law. Its values must use a defined scale, and risks should not be compared unless the scales and assumptions are consistent. In cloud environments, impact must include concentration risk: compromise of one identity, image repository or control plane may affect many workloads simultaneously.

2. Cloud-Native Security Architecture

Identity, Policy and Zero Trust

Cloud-native security is primarily identity-centric. Every human, workload, device and automation process should have a distinct identity. Privileges should be granted for a defined purpose, for the minimum practical duration and at the smallest useful scope. Multi-factor authentication (MFA), privileged-access management, short-lived tokens, workload identities and just-in-time elevation reduce the value of stolen credentials.

Zero Trust is a security architecture, not a product. It rejects implicit trust based on network location and requires continuous evaluation of identity, device posture, request context, resource sensitivity and policy. A request may be permitted for one resource and denied for another, even when both originate from the same network.

Policy should be centrally governed but locally enforceable. Policy-as-code allows security rules to be reviewed, tested and deployed alongside infrastructure code. However, automation can also distribute errors rapidly; policy testing, staged deployment and exception governance are essential.

Virtual Networks and Segmentation

Cloud virtual networks contain subnets, routing tables, security groups, network access control lists, gateways and private endpoints. Effective segmentation separates public ingress, application tiers, data services, management planes and backup environments. Segmentation should reflect trust and impact boundaries rather than merely organisational departments.

Important controls include:

• deny-by-default inbound rules;
• explicit egress controls to limit command-and-control traffic and data exfiltration;
• private service endpoints where public exposure is unnecessary;
• centralised flow logs and DNS monitoring;
• separate management and production paths;
• network policies for east-west traffic;
• independent backup accounts or projects.

Virtualisation reduces dependence on physical boundaries but does not eliminate isolation risk. Misconfigured routes, overly broad security groups, vulnerable images and exposed metadata services can provide paths to credentials or other workloads.

APIs and Secrets

APIs are the principal control surface of cloud systems. Security requires authentication, authorisation, input validation, rate limiting, schema enforcement, replay protection where appropriate, secure error handling and comprehensive logging. Authentication proves who is calling; authorisation determines what that caller may do. Confusing the two produces serious vulnerabilities such as insecure direct object references.

Secrets should not be embedded in source code, container images, infrastructure templates or mobile applications. A secrets manager should provide controlled retrieval, encryption at rest, access logging, rotation and emergency revocation. Encryption does not compensate for excessive access to the decryption key.

3. Container and Kubernetes Security

A container packages an application and its dependencies while sharing the host kernel. It is therefore not equivalent to a virtual machine. A container escape, kernel vulnerability or excessive runtime privilege may affect the host and neighbouring workloads.

Container Security Lifecycle

Security begins before deployment:

1. Use minimal, trusted base images.
2. Pin dependencies and record provenance.
3. Scan source code, operating-system packages and images.
4. Sign images and verify signatures at admission.
5. Generate a software bill of materials (SBOM).
6. Run as a non-root user with a read-only filesystem where feasible.
7. Drop unnecessary Linux capabilities.
8. Apply seccomp, mandatory access controls and resource limits.
9. Rebuild images regularly rather than modifying running containers.
10. Monitor runtime behaviour and isolate abnormal workloads.

Image scanning is not proof of safety. A scanner may miss zero-day flaws, malicious logic, insecure configuration or a vulnerable dependency that is not reachable in the deployed context. Provenance, reproducibility and behavioural monitoring are complementary controls.

Kubernetes Control Plane and Workloads

Kubernetes introduces an API server, control-plane components, nodes, namespaces, controllers, admission controls, secrets and service accounts. The API server is a high-value target. Strong authentication, role-based access control (RBAC), audit logs, encrypted transport, protected etcd storage and restricted administrative access are fundamental.

Namespaces provide organisational separation but are not automatically strong security boundaries. Network policies should restrict pod-to-pod communication. Service accounts should be dedicated to workloads and assigned narrowly scoped permissions. Admission policies can reject privileged containers, host-network access, unsigned images or missing security metadata.

Kubernetes secrets are not automatically safe merely because they are called secrets. They require appropriate encryption at rest, access restriction, rotation and avoidance of accidental exposure through logs or manifests. Cluster upgrades, node hardening and control-plane backup must be treated as security activities.

Service Meshes

A service mesh commonly provides a data-plane proxy beside each workload and a control plane that distributes policy and certificates. It can offer mutual TLS (mTLS), service identity, traffic authorisation, telemetry, retries and controlled releases.

mTLS provides encryption and peer authentication between services, but it does not establish that an authenticated service is authorised to access a particular record. Application-level authorisation remains necessary. A mesh also adds operational complexity, certificate-management dependencies and another control plane that must be secured and monitored.

4. Cryptography in Distributed and Constrained Systems

Confidentiality normally uses authenticated encryption, such as AES-GCM or ChaCha20-Poly1305. Authenticated encryption protects both secrecy and integrity. A nonce must be unique for a given key; accidental nonce reuse can seriously compromise security, especially with GCM. Keys require generation from an approved random source, controlled storage, rotation, revocation and separation of duties.

TLS protects data in transit between clients and services. mTLS adds client or workload authentication. Digital signatures provide authenticity and integrity for software updates, images and messages, while hashing supports integrity checking and content addressing. A hash alone does not authenticate data because anyone can compute it; a keyed MAC or digital signature is required when origin authentication matters.

IoT and mobile systems often use hardware-backed key storage, secure elements or trusted execution environments. These improve resistance to extraction but do not solve insecure provisioning, weak authorisation or compromised update infrastructure.

5. Mobile Platform Security

Mobile security combines device, operating-system, application, identity and network controls. Modern platforms use application sandboxing, code signing, permission systems, secure boot, hardware-backed keystores and regular security updates. These controls are valuable only when users and administrators configure them correctly.

Applications should minimise permissions, validate server certificates, protect tokens, avoid sensitive data in logs, use secure local storage and implement robust session revocation. Certificate pinning may reduce exposure to certain interception attacks, but it can complicate key rotation and incident response; it should be deployed only with a carefully designed recovery mechanism.

Mobile threats include malicious applications, phishing, overlay attacks, insecure Wi-Fi, SIM-related attacks, lost devices, spyware, supply-chain compromise and abuse of accessibility services. Mobile device management (MDM) can enforce encryption, screen locks, application policies, remote wipe and compliance checks. Bring-your-own-device programmes require clear separation between personal and organisational data, transparent monitoring and proportionate privacy controls.

6. Wireless Networks and 5G

Wireless communication is exposed to eavesdropping, rogue access points, deauthentication, credential theft, jamming and misconfiguration. Enterprise Wi-Fi should use current strong authentication, protected management frames where supported, certificate-based enterprise authentication, network segmentation and continuous rogue-device detection. Shared passwords are difficult to rotate and do not provide individual accountability.

5G introduces virtualised core networks, software-defined functions, network slicing, edge computing and extensive APIs. These features improve flexibility but enlarge the software and orchestration attack surface. Security must cover subscriber identity, signalling, roaming interfaces, virtual network functions, edge sites, APIs and supply chains. A network slice is a logical service construct, not an automatic security boundary; isolation must be verified through architecture, configuration and testing.

Availability is especially important in radio networks. Jamming and denial-of-service attacks may not be solved by cryptography alone. Redundancy, spectrum monitoring, traffic engineering, rate controls and emergency operating procedures are required.

7. Operational Technology and IoT

OT systems control physical processes such as manufacturing, energy, water and transport. Their priorities often differ from conventional IT: safety and deterministic availability may be more important than rapid patching or confidentiality. An IT security control that interrupts a safety-critical process can create greater harm than the original cyber threat.

IoT devices range from sensors with severe memory and energy constraints to powerful edge gateways. Common weaknesses include default credentials, insecure update mechanisms, exposed debug interfaces, lack of asset inventory, weak randomness, unencrypted protocols, poor certificate validation and unsupported firmware.

A secure IoT lifecycle includes:

• device identity established during trusted provisioning;
• unique credentials rather than shared defaults;
• secure boot and authenticated firmware;
• signed, encrypted and rollback-protected updates;
• least-privilege device and cloud permissions;
• network segmentation and outbound allow-lists;
• local resilience when cloud connectivity fails;
• vulnerability disclosure and end-of-support planning;
• secure decommissioning and credential erasure.

The device is only one part of the system. Gateways, mobile applications, cloud APIs, update servers, analytics platforms and operator consoles must be assessed as one socio-technical ecosystem.

8. Secure Deployment Pattern

A mature deployment pipeline integrates security without treating it as a final inspection. Developers commit code and dependency metadata; automated tests check quality, secrets and known vulnerabilities; builds occur in controlled environments; artifacts receive provenance and signatures; policy gates evaluate configuration; deployment uses least-privilege identities; runtime telemetry feeds detection and response; and lessons from incidents improve the pipeline.

A practical control sequence is:

Figure: Security controls integrated throughout the cloud-native deployment lifecycle.

Illustrative Case: Connected Manufacturing Platform

Background

A manufacturer connects robotic equipment, environmental sensors and production dashboards to a public cloud. The original design places devices on a flat network, uses shared credentials and updates firmware manually.

Problem

A compromised sensor account is used to access an exposed API. The attacker moves laterally toward production controllers and attempts to disrupt operations. The organisation lacks a complete asset inventory and cannot determine which firmware versions are active.

Analysis

The primary failures are not a lack of encryption alone. They include shared identity, weak segmentation, excessive API permissions, poor update governance, insufficient logging and unclear responsibility between the equipment vendor and the manufacturer. Safety and availability constraints also mean that immediate uncontrolled patching is inappropriate.

Approach

The manufacturer creates unique device identities, places sensors in segmented networks, permits only required outbound destinations, and uses a gateway to mediate cloud access. APIs adopt scoped tokens, request validation and rate limits. Firmware is signed, versioned and deployed through staged maintenance windows with rollback capability. Production controllers remain isolated from general-purpose analytics. A hardware and software inventory is linked to vulnerability and incident records. Monitoring correlates device identity, network flow, API activity and unusual process behaviour.

Outcome

The organisation reduces lateral movement, gains traceability and can revoke a device without changing credentials across the entire fleet. It also retains a manual operating mode for safety and continuity.

Learning Points

Security architecture must include the physical process, supplier responsibilities, maintenance procedures and recovery assumptions. A cloud dashboard does not make an OT system cloud-native in the same sense as a stateless web application.

Governance, Ethics and Regulation

Organisations should map controls to applicable privacy, cybersecurity, sectoral safety and telecommunications obligations. Data location, cross-border transfer, retention, breach notification, evidence handling and subcontractor access require contractual and technical controls. Regulators increasingly expect demonstrable governance rather than policy documents alone.

Privacy is especially important for mobile, wireless and IoT systems because location, behavioural and biometric data may be collected continuously. Data minimisation, purpose limitation, informed consent where required, access controls and deletion processes should be designed before deployment. Security monitoring must be proportionate and transparent.

Artificial intelligence can improve anomaly detection, malware triage and vulnerability prioritisation, but models may produce false positives, conceal bias or be manipulated by adversarial inputs. AI-generated code and infrastructure should undergo the same review, testing, provenance and approval as human-generated artefacts. Automated response must include safeguards against disabling legitimate production systems.

Challenges and Limitations

No control is absolute. Encryption cannot prevent authorised misuse; zero trust cannot compensate for incorrect identity data; segmentation can be bypassed through permitted services; scanners produce both false positives and false negatives; and mTLS authenticates endpoints without proving that business actions are legitimate. Legacy OT equipment may not support modern cryptography or patching. Resource-constrained IoT devices may require gateway-based protection, but gateways become high-value concentration points. Cloud centralisation improves manageability while creating systemic dependency and potential blast radius.

Security decisions should therefore consider confidentiality, integrity, availability, safety, privacy, recovery time, operational feasibility and total lifecycle cost. Defence in depth is not the accumulation of unrelated tools; it is the deliberate use of partially independent controls whose failures do not all occur together.

Best-Practice Checklist

• Maintain an accurate inventory of cloud resources, workloads, devices, identities and dependencies.
• Document provider and customer responsibilities for every service.
• Enforce MFA, least privilege, short-lived credentials and periodic access review.
• Segment networks and restrict east-west and egress traffic.
• Secure APIs through strong identity, authorisation, validation, rate limiting and logging.
• Secure the software supply chain with provenance, SBOMs, signed artefacts and reproducible builds where feasible.
• Harden containers and Kubernetes through admission policy, RBAC, network policy and runtime monitoring.
• Use authenticated encryption and protect key lifecycle operations.
• Plan secure provisioning, update, recovery and decommissioning for IoT and OT.
• Test detection, backup restoration, incident response and safe degraded operation.
• Evaluate privacy, safety, supplier and regulatory consequences before deployment.

Chapter Summary

Cloud, container, mobile, wireless and IoT security requires a distributed, identity-centred and lifecycle-oriented approach. Shared responsibility clarifies—but does not eliminate—customer accountability. Cloud-native protection depends on least privilege, segmentation, secure APIs, secrets management, logging and policy automation. Containers and Kubernetes require image provenance, admission control, workload isolation, RBAC and runtime security; service meshes add mTLS and observability but do not replace application authorisation.

Mobile and wireless systems must address device compromise, identity theft, rogue networks, privacy and availability. 5G and edge architectures increase programmability and exposure. OT and IoT require secure identity, authenticated updates, segmentation, lifecycle governance and careful balance between security, safety and availability. Cryptography is essential, but correct key, certificate, nonce and update management is equally important. Effective security integrates technology, people, suppliers, governance and recovery into one continuously tested system.

Key Terms

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

IaaS: Cloud service providing virtualised computing, storage and networking.

PaaS: Managed application platform in which the provider operates much of the runtime.

SaaS: Provider-operated software delivered as a service.

Zero Trust: Architecture requiring explicit, continuously evaluated access decisions.

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

Virtual network: Software-defined network containing cloud routing and security controls.

API: Programmatic interface through which software services exchange requests and data.

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

Kubernetes: Orchestration platform for deploying and managing containerised workloads.

RBAC: Role-based access control that assigns permissions through roles.

Service mesh: Infrastructure layer providing service-to-service communication controls and telemetry.

mTLS: Mutual Transport Layer Security, in which both communicating endpoints authenticate.

SBOM: Inventory of software components and dependencies in an artefact.

Mobile device management: Administrative control of mobile devices and their configurations.

Network slicing: Logical partitioning of network resources for differentiated services.

Operational technology: Systems that monitor or control physical processes.

IoT: Networked devices that sense, compute, communicate or actuate.

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

Authenticated encryption: Cryptographic protection providing confidentiality and integrity together.

Review Questions

Short Answer Questions

1. What does the shared-responsibility model mean in cloud security?
2. Why is a container not equivalent to a virtual machine?
3. Distinguish authentication from authorisation in an API.
4. What security benefits does mTLS provide?
5. Why can OT security priorities differ from conventional IT priorities?

Long Answer Questions

1. Compare the security responsibilities of IaaS, PaaS and SaaS customers.
2. Explain a secure Kubernetes architecture, including RBAC, network policy, admission control and audit logging.
3. Evaluate the advantages and limitations of service meshes for microservice security.
4. Discuss cryptographic and lifecycle requirements for IoT firmware updates.
5. Analyse how 5G virtualisation and edge computing change the telecommunications attack surface.

Analytical / Application Questions

1. Design a segmentation and identity architecture for a cloud-connected manufacturing plant containing sensors, gateways, controllers and analytics services.
2. An organisation discovers that a container image contains a critical vulnerable library but is used by a production service that cannot be interrupted immediately. Develop a risk-based response and recovery plan.
3. Compare two mobile-device policies—corporate-owned devices and bring-your-own-device—and recommend controls for a healthcare organisation handling sensitive location and patient data.

Multiple Choice Questions with Answers

Question 1

In a typical IaaS arrangement, which responsibility normally remains with the customer?

A. Physical security of the provider’s data centre

B. Maintenance of the provider’s hypervisor

C. Configuration of guest operating systems and identities

D. Replacement of failed physical disks

Correct Answer: C. Configuration of guest operating systems and identities

Question 2

Why should cloud egress traffic be controlled?

A. To prevent all encrypted communication

B. To limit command-and-control communication and data exfiltration

C. To eliminate the need for identity management

D. To make public services physically inaccessible

Correct Answer: B. To limit command-and-control communication and data exfiltration

Question 3

Which statement about containers is most accurate?

A. They always provide stronger isolation than virtual machines

B. They share the host kernel and therefore require kernel and runtime hardening

C. They cannot contain vulnerable dependencies

D. They eliminate the need for access control

Correct Answer: B. They share the host kernel and therefore require kernel and runtime hardening

Question 4

What is the main purpose of Kubernetes admission control?

A. To replace all network encryption

B. To enforce deployment policies before workloads are admitted

C. To provide physical access to cluster servers

D. To generate user passwords

Correct Answer: B. To enforce deployment policies before workloads are admitted

Question 5

What does mTLS add to ordinary TLS?

A. Authentication of both communicating endpoints

B. Automatic authorisation for every business operation

C. Removal of the need for certificates

D. Protection against all denial-of-service attacks

Correct Answer: A. Authentication of both communicating endpoints

Question 6

Which practice is most appropriate for IoT device identity?

A. Use one shared password for the entire fleet

B. Use unique device credentials established during trusted provisioning

C. Embed permanent credentials in public documentation

D. Disable authentication to reduce device overhead

Correct Answer: B. Use unique device credentials established during trusted provisioning

Question 7

Why is a digital signature useful for firmware updates?

A. It guarantees that the firmware has no vulnerabilities

B. It provides evidence that the update originated from an authorised signer and was not altered

C. It replaces the need for secure boot

D. It makes encryption keys unnecessary

Correct Answer: B. It provides evidence that the update originated from an authorised signer and was not altered

Question 8

Which is a central concern in mobile application security?

A. Granting every application unrestricted permissions

B. Protecting tokens and sensitive data while minimising permissions

C. Disabling operating-system updates

D. Using shared enterprise credentials

Correct Answer: B. Protecting tokens and sensitive data while minimising permissions

Question 9

Why is a network slice not automatically a complete security boundary?

A. Slices cannot carry encrypted traffic

B. Logical isolation still depends on correct architecture, configuration and testing

C. Slices exist only in wired networks

D. Slices prevent all traffic monitoring

Correct Answer: B. Logical isolation still depends on correct architecture, configuration and testing

Question 10

Which characteristic commonly distinguishes OT security from ordinary office IT security?

A. Safety and deterministic availability may take priority over rapid patching

B. Confidentiality is always irrelevant

C. OT systems never use networks

D. Availability is never important

Correct Answer: A. Safety and deterministic availability may take priority over rapid patching