Without understanding cloud security, you could accidentally leave a company's entire customer database open to the public internet, costing millions in fines and lost trust. Cloud and virtualisation security solves the problem of how to protect data and applications when you no longer own the physical servers. For the CAS-005 exam, this topic is a core area because it tests whether you understand who is responsible for what in a cloud environment – the provider or you – and how to enforce controls across shared infrastructure.
Jump to a section
A simple way to picture Cloud and Virtualization Security
7 floors, each with a different family, share one building. The building owner (the cloud provider) owns the walls, roof, plumbing, and electricity. Each family (the customer) owns their own furniture and decides who gets a key to their flat. The building manager installs a secure front door with a keypad, cameras in the hallways, and a fire alarm system – these are the shared security controls. But if one family leaves their window open, a thief could climb in. If another family writes their door code on a sticky note in the hallway, that's their own fault. The provider cannot be blamed for that.
Now imagine some flats are rented furnished (PaaS – you get the furniture but still decorate). Others are empty shells where you bring everything (IaaS – you control the walls and plumbing too). The penthouse is a service where you just move in and they make your bed, cook your meals, and walk your dog (SaaS – you just use the app). The building's shared power generator is virtualisation. It splits one big generator into multiple smaller virtual generators, each dedicated to one flat. If the generator breaks down, all flats lose power – so the provider must secure the hypervisor (the generator software). Each family can install their own safe inside their flat. That's the customer's job. The building owner must secure the basement, the lift shaft, and the roof – the shared infrastructure. This mapping – who secures what – is the shared responsibility model. It is the single most important concept in cloud and virtualisation security for a beginner to grasp.
Cloud computing is the delivery of computing services – servers, storage, databases, networking, software, analytics, and more – over the internet ("the cloud"). Instead of buying and maintaining physical servers in your office, you rent them from a provider like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). This shift changes everything about security. You no longer control the physical building, the cables, or the air conditioning. The provider secures those. But you remain responsible for securing your data, your user accounts, and how you configure the services you use. This division of duties is called the shared responsibility model.
The shared responsibility model is the foundation of cloud security. The provider is always responsible for the security "of" the cloud – the physical hosts, the network, the data centres, and the hypervisor (the software that creates and manages virtual machines). The customer is always responsible for security "in" the cloud – their data, their identity and access management (IAM) – who can log in and what they can do – and their configuration of the cloud services. The exact split depends on the service model: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS).
In IaaS, you get virtual machines, storage, and networks. You are responsible for everything on top of the virtualisation layer: the operating system (OS), the applications, the data, and the firewalls. The provider secures the physical host and the hypervisor. For example, if you spin up an Amazon EC2 (Elastic Compute Cloud) instance – a virtual server – you must patch the OS, set up the firewall rules, and manage user accounts. The provider ensures the physical server it runs on is secure.
In PaaS, you get a platform to build and run your own applications without managing the underlying infrastructure. The provider manages the OS, runtime, middleware, and sometimes the database. You manage your application code and data. For example, if you use Azure App Service to host a web app, the provider automatically applies OS patches. You only worry about your code, the user logins, and the data your app processes.
In SaaS, you get a complete application that runs in the cloud. You just use it through a web browser. The provider manages everything – the OS, the application, the data, the infrastructure. Your responsibility is limited to managing your user accounts and data classification. Examples include Microsoft 365 (email and Office apps) and Salesforce (customer relationship management software). The provider ensures the application is secure, but you are responsible for training your staff not to share passwords and for controlling which employees have access to sensitive customer data.
Virtualisation is the technology that makes cloud computing possible. It allows a single physical computer (a host) to run multiple virtual machines (VMs). Each VM behaves like a separate physical computer, with its own operating system and applications. The hypervisor is the software layer that manages this. Type 1 hypervisors run directly on the hardware (bare-metal) and are typical in data centres (examples: VMware ESXi, Microsoft Hyper-V). Type 2 hypervisors run on top of an operating system (like VirtualBox on your laptop) and are used for testing, not production. Securing the hypervisor is critical because if an attacker compromises it, they could control every VM on that host. This is known as hypervisor escape – a serious vulnerability where an attacker breaks out of a VM to access the host or other VMs.
Containerisation is a lighter form of virtualisation. Instead of running a full OS for each app, containers share the host OS kernel (the core part of the operating system) but isolate the application processes. Docker is the most common container platform. Containers are faster to start and use fewer resources than VMs. However, they also have a different security model. If one container is compromised, it could potentially affect other containers on the same host because they share the kernel. Security measures include using signed images (verified code), running containers with the least privilege (minimum permissions needed), and scanning images for vulnerabilities. Kubernetes is an orchestrator that automates the deployment, scaling, and management of containers. Securing a Kubernetes cluster involves controlling access to the API server, using network policies to restrict traffic between containers, and regularly updating the cluster components.
Key security controls for cloud environments include:
Identity and Access Management (IAM): This is the gatekeeper. It ensures only authorised people and services can access resources. It uses users, groups, roles, and policies. For example, you can create a role that allows a VM to read from a specific storage bucket, and only that VM can do it.
Cloud Key Management Service (Cloud KMS): This manages encryption keys. You can use it to encrypt data at rest (saved on disk) and in transit (moving over the network). You decide who can use the keys and when.
Network Security Groups (NSGs) or Security Groups: These are virtual firewalls. They control inbound and outbound traffic to cloud resources. You can allow traffic only on specific ports (like port 443 for HTTPS) from specific IP addresses.
Logging and Monitoring (Cloud Logging): This records every action in your cloud environment. You can detect unauthorised access attempts, configuration changes, and unusual data transfers. Services like AWS CloudTrail and Azure Monitor are examples.
Multi-Factor Authentication (MFA): This adds a second layer of security beyond a password. Users must prove their identity with something they have (a phone app, a hardware token) and something they know (a password).
A common cloud security principle is the principle of least privilege (PoLP). This means giving users and systems only the permissions they need to do their job – no more. For example, a read-only user should not have delete permissions. This limits the damage if an account is compromised.
Finally, cloud security is not static. You must continuously monitor your environment using tools like vulnerability scanners and compliance frameworks. The shared responsibility model does not mean you can set it and forget it. You must regularly check your configuration, patch your software, and review your IAM policies.
Understand the Shared Responsibility Model
Before configuring anything, draw a clear line between what the cloud provider secures (physical hosts, network, hypervisor) and what you secure (data, IAM, configuration, applications). This determines all subsequent decisions about patching, access control, and monitoring.
Configure Identity and Access Management (IAM)
Create individual user accounts with unique credentials. Enforce strong password policies and enable MFA for all users, especially the root account. Use groups to assign permissions and roles for services that need to access other cloud resources (e.g., a VM reading from a storage bucket). Review and remove unused accounts and permissions regularly.
Set Up Network Security Controls
Define a VPC with separate subnets for public-facing and private resources. Configure Security Groups (stateful firewalls) to allow only necessary traffic on specific ports from specific IP ranges. Use NACLs as a stateless backup for subnet-level filtering. Disable SSH and RDP access from the internet for production servers; use a bastion host (jump box) instead.
Implement Data Protection with Encryption and Key Management
Enable encryption at rest for all storage services (databases, object storage, block storage) using Cloud KMS. Choose between provider-managed keys (easier) and customer-managed keys (more control). Enable encryption in transit by enforcing HTTPS with TLS certificates and configuring all services to use encrypted connections.
Enable Logging, Monitoring, and Alerting
Turn on cloud logging services (e.g., CloudTrail, Azure Monitor) to record all API calls and resource changes. Set up a centralised logging account to store logs securely and prevent tampering. Create alerts for suspicious activities like failed logins, changes to security groups, or unusual data transfers. Regularly review logs to detect potential security incidents.
Harden Virtual Machines and Containers
For VMs, patch the OS and applications regularly, use hardened base images, remove unnecessary software, and apply the principle of least privilege to user accounts. For containers, use trusted images from registries, scan images for vulnerabilities, run containers as non-root, use read-only file systems, and implement network policies in Kubernetes to restrict traffic between pods.
Test and Review Your Security Posture Continuously
Use vulnerability scanners (e.g., Amazon Inspector) to find weaknesses in your cloud resources. Perform regular penetration testing and tabletop exercises to simulate incidents. Review IAM policies quarterly using access analyser tools. Update your backup and disaster recovery plans based on findings. Cloud security is not static – each new service or configuration change must be assessed.
Consider a medium-sized e-commerce company, "ShopBright", migrating its online store from their own data centre to AWS. The IT security lead, Priya, is responsible for securing the new cloud environment. She has one month before the go-live date. Here is the step-by-step reality of what she does:
First, Priya meets with the CTO to define the shared responsibility model clearly. She creates a document that lists what AWS secures (the physical data centres, the network infrastructure, the hypervisor) and what ShopBright secures (the product database, customer accounts, the web application code, and the admin user accounts). She sends this to the entire team. Some developers believe moving to the cloud means the provider does all security – a dangerous misconception. Priya corrects this immediately.
Second, she sets up the cloud account. She uses AWS Organizations to create a structure with multiple accounts: one for production (the live store), one for development (where coders build new features), and one for logging. She creates a root user (super admin) and immediately enables MFA using a hardware security key. She then locks away the root user credentials in a physical safe. She never uses the root account for daily tasks. Instead, she creates IAM users for each employee with carefully scoped permissions:
Developers get permissions to launch EC2 instances only in the development account, not production.
The database administrator gets permissions to manage Amazon RDS (Relational Database Service) but cannot delete the database.
The CTO gets read-only access to production logs.
Priya herself retains permission to modify IAM policies.
Third, she configures network security. She creates a Virtual Private Cloud (VPC) – an isolated section of the AWS cloud – for the production environment. Inside the VPC, she places the web servers in a public subnet (they need to receive customer requests from the internet) and the database servers in a private subnet (no direct internet access). She sets up Security Groups (virtual firewalls) so the web server can only receive traffic on ports 80 (HTTP) and 443 (HTTPS) from anywhere, but the database server can only accept traffic on port 3306 (MySQL) from the web server's security group. This prevents anyone from directly accessing the database from the internet.
Fourth, she implements encryption. She uses AWS Key Management Service (KMS) to generate and manage encryption keys. She enables encryption at rest for the Amazon S3 bucket (cloud storage) that holds customer order data and for the RDS database. She also enforces encryption in transit by configuring the web server to use HTTPS with a TLS certificate from AWS Certificate Manager. She writes a script that automatically rotates the encryption keys every 90 days.
Fifth, she sets up monitoring and alerting. She enables AWS CloudTrail (which logs every API call) and Amazon GuardDuty (a threat detection service that monitors for malicious activity). She creates a CloudWatch alarm that triggers if someone tries to log in from an unrecognised IP address or if there is an unusual spike in data transfer from the database subnet. She configures an alert to go to her phone and email.
Sixth, she performs a vulnerability scan before go-live. She uses Amazon Inspector to scan the web server instances for known vulnerabilities. The scan finds that one Amazon Machine Image (AMI) – a pre-configured server template – is running an outdated version of the Apache web server with a known vulnerability. She replaces that image with a patched version and re-scans.
Finally, she writes a cloud security policy document that includes incident response procedures. If a breach occurs, the document specifies who shuts down the compromised instance, who contacts the customers, and how to restore from a backup. She tests this procedure with a tabletop exercise where the team simulates a ransomware attack on a cloud storage bucket. They find a gap in their backup restoration process and fix it before go-live.
After go-live, Priya's work continues. She reviews IAM permissions quarterly using a tool called IAM Access Analyzer that identifies overly permissive roles. She attends weekly security stand-ups to discuss new threats. She updates the vulnerability scanner rules every month. She also ensures that all employees complete an annual cloud security training module that covers phishing, MFA, and the shared responsibility model. This real-world scenario demonstrates that cloud security is a continuous process of configuration, monitoring, and improvement, not a one-time setup.
The CAS-005 exam tests cloud and virtualisation security heavily. Expect around 10-15% of the total questions to come from this domain. The exam focuses on your ability to apply security controls to specific cloud service models, rather than just memorising definitions. You will see scenario-based questions where you must determine who is responsible for a particular security task given a specific model (IaaS, PaaS, or SaaS).
Here are the exact concepts they love to test:
Shared responsibility model boundaries: These are nearly always tested. A typical question describes an incident like a data leak. You must decide whether the cloud provider or the customer is at fault. The trap is that beginners often assume the provider is responsible for everything. The correct answer is usually the customer, especially for configuration mistakes, misconfigured access controls, or unpatched applications.
Hypervisor security: Expect a question about a vulnerability that allows a guest VM to access the host or other VMs. The correct answer will involve patching the hypervisor or isolating critical VMs on separate physical hosts. You do not need to know hypervisor internals, just the security implication.
Container security patterns: Questions on Docker and Kubernetes are common. They test your knowledge of image signing, running containers as non-root users, using read-only file systems, and network policies. A trap is to assume containers are automatically secure because they are isolated. The correct answer often involves scanning images for vulnerabilities and using secrets management.
Least privilege in IAM: Questions will present a role or policy that is too permissive (e.g., a developer role that allows deleting production databases). The correct answer involves modifying the policy to restrict actions and resources, applying the principle of least privilege.
Cloud Key Management (Cloud KMS): You must understand the difference between customer-managed keys (CMK) and provider-managed keys. A question might ask which option gives the customer the most control over encryption keys. The correct answer is CMK, with the customer managing rotation and access.
Firewalls and Network Security: Expect questions about Security Groups (stateful firewalls) vs. Network Access Control Lists (NACLs) (stateless). You must know that stateful firewalls automatically allow return traffic, while stateless firewalls require explicit rules for both directions. The trap is choosing a stateless option when stateful is simpler and more secure.
Cloud Logging and Monitoring: Questions test which log source would reveal a specific attack (e.g., CloudTrail for API calls vs. VPC Flow Logs for network traffic). You need to know the purpose of each logging service.
Service models: You will see a question asking you to identify the appropriate service model for a given task. For example, "Which model allows you to install a custom operating system?" The correct answer is IaaS. A trap is choosing PaaS because it seems easier, but PaaS does not give you OS-level control.
Backup and disaster recovery: Questions about multi-region deployment and backup retention policies. They test how to ensure availability across geographic regions. The correct answer will involve replicating data to a secondary region automatically.
Common traps the exam sets:
Assuming "the cloud is secure by default." Many services are not secure out of the box (e.g., an S3 bucket is private by default, but a misconfiguration can make it public). The exam will test whether you check the default settings.
Mixing up IaaS and PaaS responsibilities. A question might describe a PaaS scenario and ask about patching the OS. The correct answer is that the provider patches the OS, not the customer. Beginners often get this wrong.
Forgetting about management plane security. The cloud control panel (console) is a target. Questions about securing the root user account and enabling MFA appear frequently.
Overlooking container escape vulnerabilities. You must know that containers do not provide the same isolation as VMs. The exam will test this difference.
To prepare, create a table of the three service models (IaaS, PaaS, SaaS) with the responsibilities for each layer (physical, hypervisor, OS, application, data). Practise applying the shared responsibility model to different scenarios. Memorise the specific AWS, Azure, and GCP service names where relevant, but focus on the concept, not the specific tool. The exam cares more about your reasoning than brand names.
The shared responsibility model means the cloud provider secures the infrastructure, but you are responsible for securing your data, user access, and configurations.
In IaaS you manage the operating system and applications; in PaaS the provider manages the OS; in SaaS the provider manages almost everything except your user accounts and data.
The hypervisor is the critical security boundary in virtualisation – a compromise there can affect every virtual machine on the host.
Containers share the host kernel and are not as isolated as virtual machines, so you must use image scanning, least privilege, and network policies to secure them.
The principle of least privilege means giving users and systems only the permissions they need and nothing more, limiting the blast radius of a compromise.
Cloud security is a continuous process of monitoring, patching, and reviewing configuration – it is not a one-time setup.
Encryption protects data at rest and in transit, but you must also manage the keys and ensure compliance with data residency and lifecycle requirements.
Default cloud service settings are not always secure – you must review and harden each service according to your security requirements.
These come up on the exam all the time. Here's how to tell them apart.
Virtual Machine (VM)
Each VM runs its own full operating system (guest OS) with a separate kernel.
Provides strong isolation because processes in one VM cannot directly access another VM's memory or processes.
Slower to start (minutes) and uses more disk space and memory due to the full OS overhead.
Container
Containers share the host operating system's kernel, not running a separate OS.
Isolation is weaker – a kernel vulnerability can affect all containers on the same host.
Fast to start (seconds) and uses fewer resources because they share the OS.
IaaS (Infrastructure as a Service)
Customer manages the operating system, middleware, runtime, and applications.
Provider manages the physical host, hypervisor, and network infrastructure.
Customer must handle patching of the OS and all installed software.
PaaS (Platform as a Service)
Provider manages the operating system, runtime, and middleware, including patching.
Customer manages only the application code and data, and optionally some configuration settings.
Customer does not have direct access to the underlying OS for patching or configuration.
Stateful Firewall (Security Group)
Automatically allows return traffic for outbound connections without needing an explicit inbound rule.
Operates at the instance level (e.g., a virtual machine), filtering traffic to that specific resource.
Simpler to manage because you only write rules for the initial direction of traffic.
Stateless Firewall (NACL)
Requires explicit rules for both inbound and outbound traffic, even for return traffic.
Operates at the subnet level, filtering all traffic entering or leaving the entire subnet.
More complex to configure but offers granular control over both directions of traffic.
Root User (Cloud Account Owner)
Has unrestricted access to all resources and settings in the cloud account.
Should be used only for initial account setup and emergency recovery, locked away with MFA.
Cannot have its permissions reduced – it always has full access.
IAM User (Identity and Access Management User)
Has only the permissions explicitly assigned via IAM policies, following the principle of least privilege.
Used for daily operational tasks like launching instances, reading logs, or managing storage.
Permissions can be modified, revoked, or granted granularly.
Customer-Managed Encryption Keys (CMK)
The customer creates, manages, rotates, and controls access to the encryption keys using Cloud KMS.
Provides greater control and can meet compliance requirements that mandate the customer controls the keys.
The customer is responsible for key lifecycle, including rotation and deletion, and key backup.
Provider-Managed Encryption Keys
The cloud provider generates and manages the encryption keys automatically.
Simpler to use – the provider handles rotation and protection, requiring less operational effort from the customer.
Some compliance frameworks may not accept provider-managed keys because the customer does not have full control.
Mistake
Once I move to the cloud, the provider takes care of all security for me.
Correct
The provider secures the cloud infrastructure, but you remain responsible for securing your data, user access, and configuration within the services you use – this is the shared responsibility model.
Cloud marketing often emphasises 'security built-in', making beginners think it is a hands-off solution, but the customer must actively configure and monitor security controls.
Mistake
A virtual machine is completely isolated from other VMs on the same host, so no security risk exists between them.
Correct
A hypervisor is designed to isolate VMs, but vulnerabilities (like hypervisor escape) can allow one VM to access another. You must also consider side-channel attacks where one VM could infer data from another sharing the same physical CPU.
The abstraction of virtualisation makes the isolation seem absolute, but researchers have demonstrated practical exploits against common hypervisors.
Mistake
Containers are as secure as virtual machines.
Correct
Containers share the host kernel, so a compromise of one container – or a kernel vulnerability – can affect all containers on that host. VMs have a stronger isolation boundary because each runs its own operating system.
It's easy to assume that since both provide 'isolation', they are equivalent, but the security model differs fundamentally: containers share the OS, VMs do not.
Mistake
Encrypting cloud data automatically makes it compliant with all regulations.
Correct
Encryption is a necessary control, but compliance also requires proper key management, access controls, auditing, data residency (where data is stored), and processes like data lifecycle management. Encryption alone does not make you compliant.
Companies often enable encryption and assume they are done, forgetting that regulations like GDPR also require data minimisation, retention limits, and the ability to delete data on request.
Mistake
The default settings on a cloud service are always secure.
Correct
Default settings vary. For example, Amazon S3 buckets are private by default, but other services may have open default permissions. You must always review and harden default configurations as part of your security posture.
Cloud providers try to balance ease of use with security. Some defaults prioritise getting started quickly, which can mean less restrictive security settings.
Mistake
A cloud firewall (Security Group) alone is sufficient to protect a web application.
Correct
A Security Group is a network-level control. You also need a Web Application Firewall (WAF) to protect against application-layer attacks like SQL injection and cross-site scripting, plus secure coding practices, regular patching, and input validation.
Network firewalls can block ports and IPs but cannot inspect the content of HTTP requests, leaving the application vulnerable to application-level threats.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The shared responsibility model defines which security tasks the cloud provider handles (like physical data centre security and hypervisor maintenance) and which you handle (like user access, data encryption, and application configuration). The exact split depends on whether you use IaaS, PaaS, or SaaS.
A virtual machine runs its own operating system on top of a hypervisor, providing strong isolation because each VM has its own kernel. A container shares the host's kernel with other containers, which means less overhead but also less isolation – a kernel vulnerability could affect all containers on the same host.
A hypervisor is software that creates and runs virtual machines by partitioning the physical hardware. It is a critical security target because if an attacker compromises the hypervisor, they can access all virtual machines running on that physical host, a scenario known as hypervisor escape.
It means granting a user or a service only the minimum permissions necessary to perform their function. For example, a developer who only reads logs should not have permission to delete production databases. This limits the potential damage if their account is compromised.
Key steps include securing access to the API server with strong authentication and authorization, using network policies to restrict traffic between pods, running containers as non-root users, scanning container images for vulnerabilities, and regularly updating the cluster and its components.
No. While cloud providers secure the underlying infrastructure, the default settings of many cloud services may not be secure for production use. You must configure access controls, encryption, logging, and firewalls correctly. A common mistake is leaving a storage bucket open to the public because the default settings were not reviewed.
Cloud Key Management Service (Cloud KMS) is a managed service that creates, stores, and controls access to encryption keys. It helps you encrypt data at rest and in transit, and you can control who can use the keys and how often they are rotated. Without it, managing encryption keys manually is complex and error-prone.
You've finished Cloud and Virtualization Security. Continue through the CAS-005 study guide to build a complete picture of the exam.
Done with this chapter?