COMP 6660 · Enterprise Cybersecurity Cloud Security

00 Introduction

Lessons 5.1–5.4 examined the platforms, endpoints, applications, and databases that constitute the enterprise estate. This lesson examines the platform on which most of them now run: the cloud.

Cloud adoption has been the most significant change in enterprise IT over the past two decades. Where enterprises once ran workloads in data centres they owned and operated, most enterprises now run workloads on cloud platforms they neither own nor administer. The implications for enterprise security are profound. The enterprise no longer controls the physical infrastructure, the network, the hypervisor, or the platform; it operates within an environment administered by a cloud provider — under a shared responsibility model that divides security responsibilities between the provider and the enterprise.

Cloud security is not simply "the same controls in a different place." The characteristics of cloud environments — programmatic interfaces, ephemeral resources, rapid provisioning, shared infrastructure, and provider-managed services — produce distinct security considerations. Identity replaces network as the primary control plane. Misconfiguration becomes a primary risk. Cloud-native controls — IAM policies, security groups, encryption services, logging services — replace traditional infrastructure controls. And the scale and speed of cloud operations require automation in ways that on-premises environments did not.

This lesson examines cloud security in detail. It establishes why cloud security matters. It examines the cloud service and deployment models — IaaS, PaaS, SaaS, and the deployment models that determine what the enterprise manages and what the provider manages. It examines the shared responsibility model — the foundation of cloud security and a frequent source of misunderstanding. It examines cloud identity and access management — the primary control plane in cloud environments. It examines cloud misconfiguration — the most common source of cloud-related breaches. It examines cloud network and data protection — the controls that protect data and traffic in cloud environments. It examines cloud security posture management — the tools that detect misconfiguration continuously. It examines cloud workload protection and cloud monitoring and logging. And it closes with the pitfalls that recur across cloud security programmes.

The material here builds on everything from Lessons 5.1–5.4 — the OS, endpoint, application, and database principles all apply to cloud environments — and connects to the architecture material from Unit 4 and the identity material from Module 1. It prepares for the container and virtualisation security material in Lesson 5.6, which examines the specific platforms through which cloud workloads are increasingly delivered.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 5 outcome U5.2 (cloud and platform security), and to Module 2 outcomes M2.9 and M2.10. See the Unit 5 learning outcomes page for the full mapping.

02 Why cloud security matters

Cloud environments now host the majority of enterprise workloads — applications, databases, analytics, and increasingly operational systems. Understanding why cloud security matters clarifies the priorities that inform the rest of this lesson.

The consequence of cloud security failures

Cloud security failures appear across documented breaches:

• Misconfigured storage. Public cloud storage buckets have been the source of substantial data exposure — customer records, intellectual property, and other sensitive data. A recurring pattern in cloud incidents.
• Permissive IAM policies. Cloud identity policies that grant excessive permissions — permitting access to resources that should be restricted. A frequent source of cloud compromise.
• Exposed management interfaces. Cloud management interfaces exposed to the internet — permitting adversaries to reach the control plane.
• Compromised cloud credentials. Cloud access keys, service account credentials, and federated credentials compromised through phishing, through exposed configuration, or through compromised workloads.
• Supply-chain compromise through cloud services. Cloud services used as attack infrastructure — for command-and-control, for exfiltration, for cryptomining — as part of broader campaigns.

The pattern is consistent: cloud security failures permit access to enterprise data and resources — frequently through misconfiguration rather than through exploitation of technical vulnerabilities. Cloud security is essential — the principles from Lessons 5.1–5.4 apply, but the implementation adapts to the cloud environment.

03 Cloud service and deployment models

Cloud environments are described through service models — which determine what the provider manages and what the enterprise manages — and deployment models — which determine how the cloud is deployed and who uses it. Understanding these models is prerequisite to understanding the shared responsibility model examined in Section 3.

Cloud service models

The general pattern is that as the model moves from IaaS toward SaaS, the provider manages more and the enterprise manages less — but the enterprise always remains responsible for its data, for access to it, and for compliance with regulatory obligations.

Cloud deployment models

Cloud security implications of service and deployment models

The service and deployment models have direct implications for cloud security:

• IaaS requires the most security effort. The enterprise manages operating systems, applications, and configuration — the same disciplines as on-premises infrastructure, but in a cloud environment.
• PaaS shifts platform security to the provider. The provider manages patching, scaling, and platform configuration — but the enterprise retains responsibility for application, data, and identity.
• SaaS shifts most security to the provider. The provider manages the application and its security — but the enterprise remains responsible for access, for data, for integration, and for configuration of the SaaS application's security features.
• FaaS and serverless shift runtime to the provider. The provider manages the runtime and platform — but the enterprise remains responsible for the function code, for its identity, and for the data it processes.
• Multi-cloud multiplies complexity. Each provider has its own security model, its own controls, and its own tooling — multiplying the management burden and increasing the risk of gaps.
• Hybrid cloud requires integration. Workloads spanning public and private cloud require consistent security controls and consistent identity — producing integration challenges.

04 The shared responsibility model

The shared responsibility model is the foundation of cloud security. It divides security responsibilities between the cloud provider and the enterprise — specifying what the provider manages and what the enterprise manages. Understanding the shared responsibility model is essential — misunderstanding it is a frequent source of cloud security failures.

What the shared responsibility model provides

• Clear division of responsibilities. The model specifies what the provider secures and what the enterprise secures — providing clarity about who is accountable for what.
• Foundation for accountability. The enterprise remains accountable for its data, for access to it, and for compliance with regulatory obligations — regardless of what the provider manages.
• Different in each service model. The division of responsibilities varies by service model — IaaS, PaaS, and SaaS place different responsibilities on each party.
• Different in each provider. Each cloud provider publishes its own interpretation of the shared responsibility model — enterprises must understand the model for each provider they use.

The division of responsibilities

What the shared responsibility model means in practice

The shared responsibility model produces several practical implications:

• The enterprise remains accountable. The provider secures the platform; the enterprise secures what it puts on the platform — and remains accountable for the outcomes. "The provider was responsible" is not a defence when the enterprise's data is exposed.
• Identity and access are always enterprise-managed. Regardless of service model, the enterprise controls who can access its resources, how they authenticate, and what they are permitted to do.
• Data is always enterprise-managed. Regardless of service model, the enterprise classifies, protects, retains, and disposes of its own data.
• Configuration is always enterprise-managed. Regardless of service model, the enterprise configures its cloud resources — and misconfiguration is the enterprise's responsibility.
• Compliance is always enterprise-managed. The provider may hold certifications; the enterprise's obligations to regulators, to customers, and to data subjects remain the enterprise's.

Common misunderstandings

The shared responsibility model is frequently misunderstood — producing cloud security failures:

• "The provider handles security." The provider handles the platform; the enterprise handles the workload, the data, and the configuration. Assuming the provider handles everything is a frequent source of exposure.
• "The provider patches the OS." In IaaS, the enterprise patches the OS. In PaaS and SaaS, the provider does. The line depends on the service model — and the enterprise must understand it for each service it uses.
• "The provider encrypts the data." The provider provides encryption options and encryption of the underlying storage. The enterprise controls whether data is encrypted, how keys are managed, and what data is encrypted.
• "The provider monitors for threats." The provider monitors the platform. The enterprise monitors its workloads, its identities, its data, and its configuration.
• "The provider is compliant, so we are compliant." The provider's certifications cover the provider's responsibilities. The enterprise's compliance depends on the enterprise's own controls — including those on the cloud platform.

05 Cloud identity and access management

Cloud identity and access management is the discipline of determining who and what can access cloud resources, and what they can do with them. In cloud environments, identity is the primary control plane — replacing network location as the primary basis for access decisions.

Cloud identity concepts

Cloud IAM in practice

Implementing cloud IAM involves several activities:

• Inventory cloud identities. Identify all cloud identities — human users, service accounts, roles — and their permissions. This is the foundation — without an accurate inventory, cloud IAM is not possible.
• Reduce permissions. Remove excessive permissions — from human users, from service accounts, from roles. Apply least privilege systematically.
• Use roles and federation. Prefer roles and federated identity over long-lived cloud accounts — reducing the risk of credential compromise.
• Eliminate long-lived credentials. Replace static access keys and long-lived credentials with temporary credentials — through role assumption, through workload identity.
• Manage service account credentials. Service account credentials should be secured — vaulted, rotated, and monitored for anomalies.
• Enforce strong authentication. Human cloud users should authenticate with strong authentication — multi-factor, preferably phishing-resistant.
• Monitor cloud identity activity. Monitor for anomalies — unusual authentication, unusual API calls, unusual access patterns.

Common cloud IAM weaknesses

• Over-privileged service accounts. Service accounts with permissions beyond what they require — expanding the consequence of compromise.
• Long-lived access keys. Static access keys that are created once and never rotated — providing persistent access if compromised.
• Exposed credentials. Cloud credentials exposed in code repositories, in configuration files, in container images, or in logs.
• Root account usage. Cloud root accounts used for routine operations — providing excessive privilege and lacking accountability.
• Missing MFA. Cloud accounts without multi-factor authentication — vulnerable to credential compromise.
• Permissive IAM policies. IAM policies that grant excessive permissions — frequently through wildcards (e.g., "Action": "*") — expanding access beyond what is required.
• No monitoring of identity activity. Cloud identity activity not monitored — misuse and compromise not detected.
• Orphaned identities. Cloud identities whose owners have departed or whose purpose has ended — providing continuing access.

06 Cloud misconfiguration

Cloud misconfiguration is the most common source of cloud-related breaches — more common than exploitation of technical vulnerabilities. Because cloud environments are programmatically controlled, configuration errors are frequent and consequential.

Why cloud misconfiguration is common

Common cloud misconfigurations

Preventing and detecting misconfiguration

Preventing and detecting cloud misconfiguration requires several disciplines:

• Infrastructure as code. Defining cloud resources in code — through Terraform, CloudFormation, or equivalent — so that configuration is versioned, reviewed, and deployed consistently.
• Policy as code. Defining security policies in code — through AWS Organizations SCPs, through Azure Policy, through Google Cloud Organization Policy — so that policy is enforced consistently.
• Secure templates and modules. Providing secure templates and modules that developers use — making the secure configuration the easy configuration.
• Cloud security posture management (CSPM). Continuous monitoring of cloud configuration — detecting misconfiguration and drift.
• Configuration scanning in CI/CD. Scanning infrastructure as code for security issues before deployment — catching misconfigurations before they reach production.
• Runtime configuration monitoring. Detecting configuration changes in production — whether intentional or accidental.
• Automated remediation. Automatically remediating detected misconfigurations where feasible — closing the gap between detection and remediation.

07 Cloud network and data protection

Cloud network and data protection provides the controls that protect traffic and data within cloud environments — complementing the identity and configuration controls examined in Sections 4 and 5.

Cloud network protection

Cloud data protection

08 Cloud security posture management

Cloud Security Posture Management (CSPM) is the discipline of continuously assessing cloud configuration against security policy and detecting misconfiguration and drift. It is one of the most consequential cloud security controls — because misconfiguration is the most common source of cloud-related breaches.

What CSPM provides

• Continuous assessment. CSPM assesses cloud configuration continuously — detecting misconfiguration as it occurs, rather than periodically through manual review.
• Policy enforcement. CSPM compares actual configuration against defined security policy — identifying deviations from requirements.
• Drift detection. CSPM detects drift — configuration changes that move resources away from their defined state.
• Multi-cloud coverage. CSPM frequently covers multiple cloud providers — providing consistent assessment across a multi-cloud estate.
• Compliance reporting. CSPM reports on compliance with regulatory frameworks — CIS Benchmarks, PCI DSS, HIPAA, and others.
• Remediation guidance. CSPM frequently provides guidance or automation for remediating detected misconfigurations.

CSPM assessment areas

CSPM in practice

Implementing CSPM involves several activities:

• Define security policy. Define what the enterprise's cloud configuration should look like — the baselines, the controls, the requirements.
• Deploy CSPM tooling. Deploy CSPM tools — either cloud-native (AWS Security Hub, Azure Security Center, Google Security Command Center) or third-party — that assess configuration against policy.
• Integrate with CI/CD. Run CSPM assessments on infrastructure as code — catching misconfigurations before deployment.
• Continuous assessment. Assess cloud configuration continuously — detecting misconfiguration in production.
• Triage findings. Triage CSPM findings — prioritising by severity, by exposure, and by impact.
• Remediate. Remediate detected misconfigurations — through automation where feasible, through manual intervention where not.
• Report. Report on cloud security posture — to operations, to security leadership, and to governance.

CSPM limitations

• Coverage. CSPM coverage depends on the providers and services supported — some services may not be fully assessed.
• False positives. CSPM produces false positives — flagging configurations that are legitimate in the enterprise's context.
• Finding volume. CSPM produces substantial finding volume — requiring prioritisation and remediation capacity.
• Configuration focus. CSPM assesses configuration — it does not assess runtime activity, vulnerabilities, or threats. Complementary controls are required.
• Policy quality. CSPM is only as good as the policy it enforces — weak policy produces weak assessment.

09 Cloud workload protection

Cloud workload protection is the set of controls that protect the workloads running in cloud environments — virtual machines, containers, serverless functions, and the applications they run. The principles from Lessons 5.1–5.3 apply, but the implementation adapts to the cloud environment.

Cloud workload protection platforms (CWPP)

CWPP (Cloud Workload Protection Platform) is the category of tools that protect cloud workloads — providing visibility, vulnerability assessment, threat detection, and response for cloud workloads.

CWPP provides:

• Workload visibility. Visibility into cloud workloads — what workloads exist, what they are doing, what they are exposed to.
• Vulnerability assessment. Assessment of cloud workloads for vulnerabilities — operating system, application, and dependency vulnerabilities.
• Runtime protection. Detection and blocking of malicious activity on cloud workloads — through behavioural analysis, through signatures, through policy.
• Compliance monitoring. Assessment of cloud workloads against security baselines and compliance requirements.
• Integration with cloud-native services. Integration with cloud provider security services — for coordinated protection.

Cloud-native workload protection

Cloud providers offer native workload protection services:

• AWS: Amazon GuardDuty (threat detection), Amazon Inspector (vulnerability assessment), AWS Config (configuration compliance), AWS Security Hub (centralised security findings).
• Azure: Microsoft Defender for Cloud (workload protection, vulnerability assessment, compliance), Azure Sentinel (SIEM/SOAR).
• Google Cloud: Security Command Center (threat detection, vulnerability assessment, compliance), Cloud Armor (DDoS and WAF protection).

Cloud workload protection considerations

10 Cloud monitoring and logging

Cloud monitoring and logging provides the visibility into cloud activity that detection, investigation, and compliance require. It is essential to cloud security — because cloud environments generate substantial telemetry that must be collected, centralised, and analysed.

What cloud logging provides

• API activity logging. Records of cloud API calls — what was called, by whom, from where, and what the outcome was. Cloud API activity is the primary source of cloud audit information.
• Resource activity logging. Records of resource activity — resource creation, modification, and deletion.
• Network activity logging. Records of network traffic — flow logs, VPC flow logs, DNS logs — for network-level visibility.
• Application and workload logs. Logs from applications and workloads running in cloud environments.
• Identity activity logging. Records of cloud identity activity — authentication, authorization, access.
• Configuration change logging. Records of configuration changes — critical for change management, for compliance, and for investigation.

Cloud logging services

Cloud monitoring practices

Effective cloud monitoring involves several activities:

• Enable logging everywhere. Enable cloud logging for all services — API activity, resource activity, network activity, and application logs.
• Centralise logs. Centralise cloud logs — through a SIEM, through cloud logging services, through a dedicated log platform.
• Protect logs. Protect cloud logs — through access controls, through encryption, through integrity mechanisms — so that they cannot be tampered with by adversaries.
• Monitor for anomalies. Monitor cloud activity for anomalies — unusual API calls, unusual resource activity, unusual authentication.
• Integrate with SOC. Integrate cloud logs with the SOC — through SIEM, through XDR, through the SOC's alerting and investigation platforms.
• Detect cloud-specific threats. Detect cloud-specific threats — cryptomining, resource abuse, credential abuse, data exfiltration.
• Retain logs appropriately. Retain cloud logs for sufficient periods — supporting investigation, compliance, and retroactive analysis.

11 Common pitfalls

Enterprise cloud security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Misunderstanding the shared responsibility model

Assuming that the cloud provider handles more than it actually does — producing gaps in the enterprise's responsibilities.

Mitigation: Understand the shared responsibility model for each provider and each service. Document what the enterprise manages.

Pitfall 2 — Over-privileged cloud identities

Cloud identities — service accounts, roles, users — with excessive permissions — expanding the consequence of any compromise.

Mitigation: Apply least privilege to all cloud identities. Review permissions periodically. Use roles rather than long-lived credentials.

Pitfall 3 — Public cloud resources

Cloud resources — storage, databases, management interfaces — publicly accessible when they should not be — exposing data and systems to the internet.

Mitigation: Assess cloud resources for public exposure. Use CSPM to detect public exposure continuously. Restrict public access to what genuinely requires it.

Pitfall 4 — Weak cloud credential management

Cloud credentials — access keys, service account credentials — exposed, not rotated, or long-lived — providing persistent access if compromised.

Mitigation: Use short-lived credentials where feasible. Manage credentials through vaulting, through rotation, through monitoring. Remove unused credentials.

Pitfall 5 — Missing or incomplete logging

Cloud logging not enabled, not centralised, or not monitored — impairing detection, investigation, and compliance.

Mitigation: Enable cloud logging for all services. Centralise logs. Integrate with SOC. Monitor for anomalies.

Pitfall 6 — Unencrypted cloud data

Cloud data without encryption — permitting data exposure if storage, snapshots, or backups are compromised.

Mitigation: Enable encryption at rest for all cloud data — with key management appropriate to the data's sensitivity.

Pitfall 7 — No CSPM

Cloud configuration not continuously assessed — misconfiguration not detected until it is exploited.

Mitigation: Implement CSPM. Assess configuration continuously. Remediate findings.

Pitfall 8 — Multi-cloud complexity

Multiple cloud providers managed with separate tools, processes, and controls — producing inconsistency, gaps, and complexity.

Mitigation: Standardise cloud security across providers where feasible. Use multi-cloud security tooling. Manage the complexity deliberately.

Pitfall 9 — Cloud security treated as separate from enterprise security

Cloud security managed by a separate team, with separate processes, separate tools — disconnected from the enterprise's broader security programme.

Mitigation: Integrate cloud security with the enterprise security programme. Align processes, tools, and governance. Include cloud in SOC operations, incident response, and governance.

Pitfall 10 — Under-investment in cloud security

Cloud security treated as a solved problem — relying on provider defaults, on provider security — without the enterprise's own investment in configuration, monitoring, and controls.

Mitigation: Invest in cloud security proportionate to the enterprise's cloud estate. Recognise the enterprise's responsibilities under the shared responsibility model. Implement enterprise controls alongside provider controls.

12 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Cloud security

The discipline of protecting cloud environments — workloads, data, identities, and configuration — through the enterprise's controls under the shared responsibility model.

Shared responsibility model

The division of security responsibilities between a cloud provider and its customer. The provider secures the platform; the customer secures what they put on the platform.

IaaS (Infrastructure as a Service)

Cloud service model in which the provider manages physical infrastructure and virtualisation; the enterprise manages operating systems, applications, and data.

PaaS (Platform as a Service)

Cloud service model in which the provider manages the platform (including operating systems and runtimes); the enterprise manages applications, data, and configuration.

SaaS (Software as a Service)

Cloud service model in which the provider manages the application and platform; the enterprise manages data, identity, and configuration.

FaaS (Function as a Service)

Cloud service model in which the provider manages all infrastructure and platform layers; the enterprise manages function code, data, and configuration.

Serverless

A cloud computing model in which the provider manages all infrastructure and platform concerns — permitting the enterprise to focus on application code.

Public cloud

Cloud services provided by a third party to multiple customers on shared infrastructure.

Private cloud

Cloud infrastructure dedicated to a single organisation — whether on-premises or hosted.

Hybrid cloud

Combination of public and private cloud — with workloads distributed across both.

Multi-cloud

Use of multiple cloud providers — frequently for resilience, for avoiding vendor lock-in, or for best-of-breed services.

Cloud IAM (Identity and Access Management)

The set of services and policies that determine who and what can access cloud resources, and what they can do with them.

Cloud role

A cloud identity that can be assumed by users, services, or resources — providing temporary credentials with defined permissions.

Workload identity

An identity assigned to a workload — cloud instance, container, serverless function — for accessing cloud services.

Cloud misconfiguration

Incorrect configuration of cloud resources — public storage, permissive IAM policies, exposed management interfaces — creating risk without exploitation of vulnerabilities.

Public storage bucket

Cloud storage made publicly accessible — intentionally or by mistake — exposing data to anyone with the URL or who discovers the bucket.

Security group

A cloud-native firewall that controls what traffic each cloud instance accepts. The primary cloud-native firewall mechanism.

Network ACL

A cloud-native firewall that controls what traffic crosses subnet boundaries. Complements security groups in cloud environments.

VPC (Virtual Private Cloud)

An isolated network environment within a cloud provider — providing network-level isolation for cloud resources.

Private link / endpoint

Private connectivity to cloud services — without traversing the public internet.

Dedicated connection

Provider-managed dedicated connectivity between enterprise networks and cloud environments — AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect.

Cloud KMS (Key Management Service)

Cloud provider services for managing encryption keys — AWS KMS, Azure Key Vault, Google Cloud KMS.

BYOK (Bring Your Own Key)

The practice of bringing the enterprise's own keys to the cloud provider's key management service.

HYOK (Hold Your Own Key)

The practice of holding the enterprise's own keys outside the cloud provider — providing the strongest control but the most operational complexity.

CSPM (Cloud Security Posture Management)

The discipline of continuously assessing cloud configuration against security policy and detecting misconfiguration and drift.

CWPP (Cloud Workload Protection Platform)

The category of tools that protect cloud workloads — providing visibility, vulnerability assessment, threat detection, and response.

CloudTrail

AWS service that logs API activity — providing audit records of what happened in the AWS environment.

GuardDuty

AWS threat detection service — monitoring for malicious activity and unauthorized behavior in AWS environments.

Microsoft Defender for Cloud

Microsoft cloud security service — providing workload protection, vulnerability assessment, and compliance for Azure and hybrid environments.

Cloud-native SIEM

SIEM services delivered by cloud providers — Azure Sentinel, Chronicle, Security Lake — for cloud environments.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below before moving to Lesson 5.6. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined cloud security — the discipline of protecting the platform on which most enterprise workloads now run. The essential points are:

• Cloud security matters because most enterprise workloads now run in cloud environments. Cloud changes the security model, introduces misconfiguration as a primary risk, makes identity the primary control plane, and requires automation at scale.
• Cloud service and deployment models determine what the enterprise manages. IaaS, PaaS, SaaS, and FaaS place different responsibilities on each party. Public, private, hybrid, and multi-cloud deployment models introduce different considerations.
• The shared responsibility model is the foundation of cloud security. The provider secures the platform; the enterprise secures what it puts on the platform — identity, data, configuration, and compliance — and remains accountable.
• Cloud identity is the primary control plane. Least privilege, roles and federation, short-lived credentials, and monitoring of identity activity — the foundation of cloud access control.
• Cloud misconfiguration is the most common source of cloud-related breaches. Public storage, permissive IAM policies, exposed management interfaces, unencrypted data, and missing logging — addressed through infrastructure as code, policy as code, and CSPM.
• Cloud network and data protection provide defence-in-depth. VPCs, security groups, private connectivity, encryption at rest and in transit, and key management — complementing identity and configuration controls.
• CSPM continuously assesses cloud configuration. Detecting misconfiguration and drift — one of the most consequential cloud security controls.
• Cloud workload protection protects the workloads. CWPP and cloud-native services — providing visibility, vulnerability assessment, threat detection, and response for cloud workloads.
• Cloud monitoring and logging provide visibility. API activity, resource activity, network activity, and application logs — collected, centralised, and monitored — supporting detection, investigation, and compliance.
• Common pitfalls recur. Misunderstanding the shared responsibility model; over-privileged cloud identities; public cloud resources; weak credential management; missing logging; unencrypted data; no CSPM; multi-cloud complexity; cloud security treated separately; under-investment in cloud security.

These ideas prepare for Lesson 5.6, which examines container and virtualisation security — the specific platforms through which cloud workloads are increasingly delivered, and which introduce their own security considerations.