BCS601 Cloud Computing Module-4

Module-4
Cloud Security: Top concern for cloud users, Risks, Privacy Impact Assessment, Cloud
Data Encryption, Security of Database Services, OS security, VM Security, Security Risks Posed by Shared
Images and Management OS, XOAR, A Trusted Hypervisor, Mobile Devices and Cloud Security
Cloud Security and Trust Management: Cloud Security Defense Strategies, Distributed
Intrusion/Anomaly Detection, Data and Software Protection Techniques, Reputation-Guided Protection of
Data Centers.
Textbook 2 Cloud Computing Theory and Practice by Dan C. Marinescu
Chapter 11: 11.1 to 11.3, 11.5 to 11.8, 11.10 to 11.14
Textbook 1: Chapter 4: 4.6

Introduction to Cloud Security

Early Computing Security vs. Cloud Security
• Traditional security: Focused on physical access to isolated systems.
• Networked security: Once computers connected via the Internet, threats multiplied
exponentially.
• Cloud security:
o Data is distributed across multiple locations.
o Users lack direct control over security measures.
o New attack vectors due to shared resources (e.g., multi-tenancy).
Growing Importance of Cloud Security
• Cyberwarfare: Nation-states now exploit cloud vulnerabilities (e.g., Stuxnet
malware).
• Pandora’s Box of Threats: Malware can now spread globally, affecting business,
government, and personal data.
• Target-rich environment: Cloud systems are lucrative targets for hackers due to:
o Large-scale data storage.
o Centralized computing power.
o Potential vulnerabilities in virtualization and APIs.

11.1 SECURITY, THE TOP CONCERN FOR CLOUD USERS

Misconceptions About Cloud Security
• Some believe outsourcing security to cloud providers makes their systems safer.
• Reality:
o Cloud introduces new security risks.
o Service Level Agreements (SLAs) do not offer full legal protection.
o Users must extend trust to the Cloud Service Provider (CSP).
Major User Concerns
Unauthorized Access & Data Theft
• Data in storage is more vulnerable than data in transit or during processing.
• Insider threats: Rogue employees at CSPs can steal or misuse sensitive data.
Data Lifecycle & Control Issues
• Users have no control over actual data deletion.
• CSPs automatically back up data without user consent.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 1

BCS601 Cloud Computing Module-4

• Risks:
o Deleted records might still exist in backups.
o Attackers could recover residual data.
Lack of Standardization & Interoperability
• No global security standards for cloud computing.
• Unanswered questions:
o How to recover data if the CSP shuts down?
o What happens if prices increase unexpectedly?
o How difficult is switching CSPs?
Auditing & Compliance Challenges
• Full security audits on cloud infrastructure are nearly impossible.
• Legal compliance issues:
o Data laws differ across countries.
o Users don’t know where data is stored.
Emerging Threats from Autonomic Computing
• Autonomic features (self-repair, self-optimization) introduce new vulnerabilities:
o Harder to track and investigate security breaches.
o Automated systems may fail unpredictably.
Multi-Tenancy Security Concerns
• Shared cloud environments → Data breaches affect multiple users.
• Example: A hacked database can expose millions of user records.
Legal & Jurisdiction Issues
• Cloud data centers exist in multiple countries.
• Unclear jurisdiction:
o Which country's laws apply?
o What about data that crosses multiple borders?
• Data outsourcing risks:
o CSPs may subcontract data handling, making security compliance difficult.
o Example: Microsoft subpoenaed to provide Hotmail user emails.

11.2 CLOUD SECURITY RISKS

• Cloud services are easily accessible, leading to security risks if ethical guidelines and
security policies are not followed.
• Cloud platforms can be exploited to launch cyberattacks on infrastructure
components.
• Two key questions:
1. How can cloud resources be prevented from nefarious use?
2. What security risks do cloud users face?
2. Broad Categories of Cloud Security Risks
A study identifies three major security risk classes:
1. Traditional security threats (existing in networked systems but amplified in cloud
environments).
2. Threats to system availability (disruptions to cloud service reliability).

Dr. Sampada K S, Associate professor CSE RNSIT pg. 2

BCS601 Cloud Computing Module-4

3. Threats from third-party data control (loss of transparency and control over data
management).
A. Traditional Security Threats
• Increased Impact: Due to the large user base and shared resources.
• Responsibility Gaps: Unclear boundaries of security responsibility between the
cloud provider and the user.
• Key Attack Vectors:
o Distributed Denial of Service (DDoS) attacks → Overloading cloud services
to block legitimate access.
o Phishing → Tricking users into providing sensitive credentials.
o SQL Injection → Exploiting web applications to manipulate databases.
o Cross-Site Scripting (XSS) → Injecting malicious scripts into web pages.
• Authentication & Authorization Risks:
o Assigning different privilege levels to enterprise users is complex.
o Merging internal security policies with cloud security models is challenging.
B. System Availability Threats
• Disruptions can be caused by:
o System failures, power outages, or cyberattacks.
o Data lock-in → Customers may be unable to move data when needed.
o Phase transitions in complex cloud systems → Unexpected failures due to
rapid demand shifts.
o Unverified application results → Users cannot always trust the accuracy of
cloud computations.
C. Third-Party Data Control Risks
• Lack of Transparency:
o Users do not have full visibility into how data is handled.
o Cloud providers may subcontract services to untrusted third parties.
• Data Loss Risks:
o Poor storage quality or hardware failures can lead to irretrievable data loss.
o Legal challenges in proving whether cloud data has been deleted.
• Cloud Provider Espionage:
o Cloud providers may access or misuse user data.
o Example: AWS Terms of Service
▪ Disclaims liability for data breaches, losses, and service outages.
3. Cloud Security Alliance (CSA) Reports on Security Threats
A. 2010 CSA Report - Seven Major Cloud Threats
1. Abuse of cloud resources (e.g., using AWS for cyberattacks).
2. Insecure APIs (exposing cloud services to unauthorized access).
3. Malicious insiders (employees misusing privileged access).
4. Shared technology vulnerabilities (hypervisor and VM isolation flaws).
5. Account hijacking (stolen credentials granting attackers full access).
6. Data loss and leakage (accidental or intentional data deletion or exposure).
7. Unknown risk profiles (inadequate risk assessment by users).
B. 2016 CSA Report - Top Twelve Cloud Security Threats

Dr. Sampada K S, Associate professor CSE RNSIT pg. 3

BCS601 Cloud Computing Module-4

1. Data breaches → Loss of financial, health, and proprietary data.

2. Compromised credentials & weak authentication → Due to poor password security.
3. Hacked APIs → Weak interfaces expose cloud systems.
4. Exploited system vulnerabilities → Attackers leverage known software flaws.
5. Account hijacking → Cybercriminals steal cloud service access.
6. Malicious insiders → Untrustworthy employees with elevated privileges.
7. Advanced persistent threats (APTs) → Long-term, undetected cyber espionage.
8. Permanent data loss → Unrecoverable deletion due to insufficient backups.
9. Inadequate diligence → Users failing to conduct proper risk assessments.
10. Cloud service abuse → Cloud resources misused for botnets or spamming.
11. Denial of Service (DoS) attacks → Overwhelming cloud services to make them
unavailable.
12. Shared technology risks → Multi-tenancy vulnerabilities in hypervisors and VMs.
C. 2011 CSA Report - Risk Mitigation Strategies
• Provides guidelines on minimizing cloud security risks:
o Multi-factor authentication (MFA) for user logins.
o Encryption of sensitive data.
o Regular security audits of cloud platforms.
o Network segmentation & access control.
4. Cloud Attack Surface Analysis
A research study categorizes cloud attack surfaces into six groups:
A. User Attack Vectors
1. Attacks from the Service Provider
o SSL certificate spoofing, browser cache exploits, phishing.
2. Attacks from the Cloud Infrastructure
o Unauthorized data access by cloud administrators.
B. Service Attack Vectors
3. Attacks from Users
o SQL injection, buffer overflow exploits, privilege escalation.
4. Attacks from the Cloud Infrastructure
o Hypervisor flaws leading to VM takeovers.
C. Cloud Infrastructure Attack Vectors
5. Attacks from Users
o Cloud control system breaches.
6. Attacks from the Services
o Exhausting cloud resources, causing denial-of-service (DoS).
5. Additional Cloud Security Threats & Risks
• Security Risks from Hardware Failures & Natural Disasters
• Cloud-related malware & cyber-espionage
• Inadequate infrastructure design leading to security gaps
• Point-of-Sale (POS) intrusions and payment fraud
• Insider privilege misuse & web application vulnerabilities
• Physical theft or unauthorized access to cloud data centers
6. Risk Mitigation Strategies

Dr. Sampada K S, Associate professor CSE RNSIT pg. 4

BCS601 Cloud Computing Module-4

• User Best Practices:

o Use strong, unique passwords & multi-factor authentication.
o Encrypt sensitive data at rest and in transit.
o Regularly update security patches for cloud applications.
• Cloud Provider Best Practices:
o Implement role-based access control (RBAC).
o Ensure secure API implementations.
o Monitor anomalous activities & insider threats.
o Conduct regular penetration testing & security audits.

11.3 Cloud Data Security & Encryption Techniques

1 Introduction to Privacy
• Definition: Privacy refers to the right of individuals, groups, or organizations to keep
personal or proprietary information from being disclosed.
• Legal Recognition:
o Universal Declaration of Human Rights (Article 12) protects individuals from
arbitrary interference.
o U.S. Constitution does not explicitly mention privacy but provides protection
through the Bill of Rights (1st, 3rd, 4th, 5th, and 9th Amendments).
o United Kingdom: Privacy is protected by the Data Protection Act.
o European Court of Human Rights: Has developed multiple documents
defining privacy rights.
2. Privacy Laws and Their Limitations
• Privacy is not absolute; it may be restricted by:
o Taxation laws requiring disclosure of personal income.
o Freedom of speech conflicts when privacy clashes with transparency.
o Varied global privacy laws: What is private in one country may be public in
another.
3. Digital Age Privacy Challenges
• Identity Theft: Personal data voluntarily shared online can be stolen or misused.
• Stringent Regulations in the EU:
o The "Right to Be Forgotten" allows individuals to request removal of personal
data from the internet.
o GDPR (General Data Protection Regulation) imposes strict controls on data
handling.
• Public Clouds & Privacy Risks:
o Data is stored unencrypted on third-party servers.
o Cloud Service Providers (CSPs) own and control storage infrastructure, limiting
user control.
4. Cloud Privacy Concerns
• Lack of User Control:
o Users do not know the exact location of their data.
o Cloud providers make backups without user consent.
• Unauthorized Secondary Use:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 5

BCS601 Cloud Computing Module-4

o CSPs may use personal data for advertising (e.g., Google Ads).
• Data Proliferation:
o Data may be copied, duplicated, and stored across multiple servers and
jurisdictions.
• Dynamic Provisioning & Outsourcing Risks:
o Third-party CSPs may subcontract data storage without disclosing it to users.
o Legal complexities arise when CSPs go bankrupt or merge.
5. Privacy Regulations & Fair Information Practices
Federal Trade Commission (FTC) Guidelines for Privacy Protection:
1. Notice: Websites must clearly disclose data collection, usage, and storage policies.
2. Choice: Users should be able to control how their data is used.
3. Access: Users must be able to review and correct personal data.
4. Security: Websites must take reasonable steps to protect collected data.
• Legislative Challenges:
o There are no universal standards for privacy protection across countries.
o Laws such as the EU GDPR set high standards, but compliance varies globally.
6. Privacy Impact Assessment (PIA) in Cloud Computing
• Definition: PIA is a tool used to evaluate privacy risks in information systems.
• Purpose:
o Identify and address privacy concerns before system deployment.
o Ensure compliance with legal regulations.
• Implementation:
o Conducted by governments, corporations, and CSPs.
o Required in some countries for public sector IT projects.
7. PIA Tools and Methodologies
• PIA Report Components:
o Project Information: Description of data collection and processing.
o Privacy Risks: Identification of vulnerabilities.
o Stakeholders: Who handles and accesses data?
o Security & Transparency: How data is protected and disclosed.
o Cross-Border Data Flows: Evaluating the legality of international data
transfers.
• PIA Knowledge Base (KB):
o Maintained by domain experts.
o Uses questionnaires and rule-based systems to identify risks.
• Automated PIA Tools:
o Web-based tools can generate automated privacy risk reports.
o Some tools incorporate AI-based assessments.

11.5 CLOUD DATA ENCRYPTION

Introduction to Cloud Data Encryption
• Governments, corporations, and users are concerned about storing sensitive data on
public clouds.
• Encryption is the primary solution for protecting outsourced data.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 6

BCS601 Cloud Computing Module-4

• Cloud service providers (CSPs) offer encryption services, e.g., AWS Key Management
Service (KMS), which integrates with services like EBS, S3, RDS, Redshift, etc.
• Encryption SDKs are available for developers to enhance security in cloud applications.
Foundations of Cryptography for Cloud Security
1.CSP Encryption Offerings:
o Amazon AWS Key Management Service (KMS):
1. Creates & manages encryption keys.
2. Integrated with AWS services: EBS, S3, RDS, Redshift, WorkMail,
Elastic Transcoder.
o AWS Encryption SDK: Provides encryption tools for developers.
Research & Cryptographic Foundations:
o RSA Cryptosystem (1978): Basis of public-key cryptography.
o Paillier Cryptosystem (1999):
1. Uses composite residuosity classes (factoring large numbers).
2. Supports homomorphic properties for secure computation.
o Fully Homomorphic Encryption (FHE) (2009, Craig Gentry, Stanford
University):
1. Allows computation on encrypted data without decryption.
2. Significant breakthrough in privacy-preserving cloud computing
2.Homomorphic Encryption
• Ensures that computations on encrypted data yield the same results as operations on
plaintext data.
• Concept: A homomorphic function f(a) on encrypted data maintains structure-
preserving properties.
• Allows arithmetic and logic operations without decrypting data, closing the
vulnerability window.
• Challenges: High computational overhead; FHE currently impractical for large-scale
cloud applications.

• Challenge: Data must be decrypted for processing, creating a vulnerability window.

• Solution: Homomorphic encryption allows computations on encrypted data without
decryption.
• Concept:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 7

BCS601 Cloud Computing Module-4

o Homomorphism is a structure-preserving map between two algebraic

structures.
o If f(·) is a homomorphic function, then:
▪ f(a ⊕ b) = f(a) ⊗ f(b)
▪ This means performing an operation on encrypted values is equivalent
to performing the operation on plain values and then encrypting the
result.
• Key Benefit: Data remains encrypted during processing, eliminating the decryption
vulnerability.
2.1 Fully Homomorphic Encryption (FHE)
• Major Breakthrough (Craig Gentry, 2009)
o Enables general computations on encrypted data.
o Solves the privacy problem in cloud computing.
• Challenges:
o Extremely slow compared to plaintext processing.
o Processing overhead increases by orders of magnitude.
o Example:
▪ Early FHE implementations took ~6 minutes per operation.
▪ Optimized versions reduced this to ~1 second.

3. Searchable Encryption for Cloud Databases

Queries often require logic and arithmetic operations on encrypted data.
• Issue: Queries must be performed on encrypted cloud databases, but encryption
reduces search efficiency. Standard encryption prevents indexing and ordering, making
search operations inefficient.
• Problem with Traditional Encryption:
o Encrypting entire database columns makes querying inefficient.
o Indexes (e.g., B-Trees) no longer work, requiring full table scans.
• Solutions:
o Order-Preserving Encryption (OPE): OPE preserves order among encrypted
numeric values, enabling range queries.
o Searchable Symmetric Encryption (SSE): SSE enables keyword-based
search without decrypting the entire database.
SSE protocols support conjunctive search, Boolean queries, and structured data
search.

4. Order-Preserving Encryption (OPE)

• Maps numeric values into a much larger encrypted range while preserving order.
• Uses a randomized function ensuring that encrypted values maintain relative order.
• Use Case: Enables B-tree indexes on encrypted columns in NoSQL databases.
• Goal: Encrypt numeric data while preserving ordering to allow efficient range
queries.
• Method:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 8

BCS601 Cloud Computing Module-4

o Maps a range of plaintext values (1, ..., M) into a much larger ciphertext range
(1, ..., N).
o Ensures encrypted values maintain relative order (but not actual values).
• Example:
o OPE transforms values while preserving order:
▪ Original: 10 < 20 < 30
▪ Encrypted: X1 < X2 < X3 (unknown values, but still ordered).
• Implementation:
o Uses a negative hypergeometric distribution (NHG).
o Encrypts values via binary search and probabilistic assignments.
• Advantage:
o Enables efficient range queries without decrypting data.
• Limitation:
o Trade-off between security and searchability (attackers may infer order).

5. Searchable Symmetric Encryption (SSE)

• Use Case: Secure searches on encrypted cloud databases.
• Principle:
o Client stores only a cryptographic key.
o Client encrypts query → sends to cloud → gets encrypted result → decrypts
locally.
• Benefits:
o Protects against data leaks by encrypting queries & responses.
o Prevents explicit data exposure to the cloud provider.
• Potential Weakness:
o Query pattern leakage (attackers may infer patterns).
• Advancements:
o SSE now supports:
▪ Boolean queries
▪ Multi-keyword searches
▪ Phrase & substring searches
▪ Wildcard & range searches
• Notable Research Works:
o SSE with Boolean Queries [86].
o SSE extended to range, substring, wildcard, and phrase queries [168].
• Example Use Case:
o Encrypted Wikipedia search (prototype implementation).

5. Threats to Private Cloud Data

Threats:
External attacks: Hackers exploiting vulnerabilities in CSP infrastructure.
Internal threats: Malicious insiders accessing sensitive data.
Network attacks: Man-in-the-middle attacks during data transfer.
Defensive Measures:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 9

BCS601 Cloud Computing Module-4

o Strong encryption before storage (AES, RSA, ECC, FHE).

o Controlled access via cryptographic key management.
o Secure multi-party computation for data processing.

• Private cloud data is safer from outsiders, but still vulnerable to insider threats.
• Potential Risks:
o Insiders accessing log files can:
▪ Infer database hot spots (frequently accessed areas).
▪ Copy sensitive data selectively.
▪ Use extracted data for malicious activities.
• Countermeasures:
o Role-based access control (RBAC): Restricts insider access.
o Audit logging & monitoring: Detects suspicious behavior.
o Data partitioning & protection rings: Limits access to critical data.

8. Cloud Data Encryption Challenges and Future Directions

• Performance Issues: FHE remains computationally expensive.
• Search Optimization: Improved SSE methods are needed for efficiency.
• Privacy-Preserving Computation: Secure enclaves and zero-knowledge proofs can
enhance cloud security.
• Regulatory Compliance: Encryption strategies must align with laws like GDPR,
HIPAA, and PCI-DSS.

• Cloud data encryption is essential for securing sensitive information.

• Ongoing research aims to balance security, efficiency, and compliance.
• Organizations must implement robust cryptographic techniques to mitigate security
risks in cloud environments.

11.6 SECURITY OF DATABASE SERVICES

Database-as-a-Service (DBaaS) is a key component of cloud computing, offering users

scalable, managed database solutions. However, delegating database management to cloud
providers raises serious security concerns regarding data integrity, confidentiality, and
availability.
Entities Involved in DBaaS Security
1. Data Owners - Individuals or organizations that generate and own the data.
2. Database Users - Clients accessing the DBaaS for queries and data retrieval.
3. Cloud Service Providers (CSPs) - The companies that host and manage cloud
databases.
4. Third-Party Auditors (TPAs) - Independent entities that verify compliance and
security.
Major Security Threats to DBaaS
1. Data Integrity and Confidentiality Risks

Dr. Sampada K S, Associate professor CSE RNSIT pg. 10

BCS601 Cloud Computing Module-4

• Unauthorized Access - Weak authentication and access control mechanisms expose

databases to unauthorized users.
• Insider Threats - Superusers with excessive privileges can manipulate, leak, or delete
sensitive data.
• Encryption Issues - Inconsistent use of encryption or weak encryption keys can make
stored data vulnerable.
2. External Attacks
• SQL Injection - Attackers manipulate database queries to gain unauthorized access or
modify data.
• Man-in-the-Middle (MitM) Attacks - Interception of data transmitted between users
and DBaaS.
• Side Channel Attacks - Exploiting patterns in database access to infer confidential
information.
3. Multi-Tenancy Risks
• Data Leakage - Different users sharing the same physical infrastructure increases the
risk of data leaks.
• Illegal Data Recovery - Improperly sanitized storage devices can allow retrieval of
previously deleted data.
4. Availability Risks
• Denial-of-Service (DoS) Attacks - Overloading the database service to make it
inaccessible.
• Resource Exhaustion - Inefficient allocation of database resources can lead to system
crashes.
Security Measures for DBaaS
1. Strong Authentication and Access Control
• Implement multi-factor authentication (MFA).
• Enforce role-based access control (RBAC) to limit user privileges.
2. Data Encryption and Secure Storage
• Encrypt data at rest and in transit using strong cryptographic standards.
• Use homomorphic encryption to allow computations on encrypted data without
decryption.
3. Secure Backup and Disaster Recovery
• Maintain regular backups with version control.
• Implement geo-redundancy to ensure data availability in case of disasters.
4. Auditing and Monitoring
• Enable log tracking for access and modification records.
• Utilize anomaly detection systems to detect suspicious database activity.

11.7 OPERATING SYSTEM SECURITY

Operating System (OS) security ensures the protection of applications, data, and hardware
against unauthorized access, manipulation, and malicious attacks. The OS acts as an
intermediary between applications and hardware, making it a critical component in securing
cloud computing environments.
Key Security Aspects of an OS

Dr. Sampada K S, Associate professor CSE RNSIT pg. 11

BCS601 Cloud Computing Module-4

1. Access Control - Policies that define how users and applications interact with system
resources.
2. Authentication Mechanisms - Validating user identities before granting access.
3. Data Protection - Encrypting sensitive files and securing storage.
4. System Integrity - Preventing unauthorized modifications to the OS.
5. Application Security - Isolating and securing applications to prevent exploitation.
Major Security Threats to Operating Systems
1. Unauthorized Access and Privilege Escalation
• Attackers exploit weak passwords, misconfigured permissions, and software
vulnerabilities to gain higher privileges.
• Insider threats can misuse admin privileges to manipulate system settings.
2. Malware Attacks
• Viruses, worms, Trojans, ransomware, and spyware target OS vulnerabilities.
• Rootkits allow attackers to maintain persistent access while hiding malicious activities.
3. Application Vulnerabilities
• Buffer Overflows - Attackers execute arbitrary code by injecting excessive data into
application buffers.
• Code Injection Attacks - Malicious scripts injected into applications to execute
harmful commands.
4. OS Configuration and Patch Management Issues
• Unpatched OS software allows attackers to exploit known vulnerabilities.
• Default configurations may have insecure settings, leading to unauthorized access.
5. Lack of Secure Communication
• Unencrypted network connections expose data in transit to interception and
modification.
• Man-in-the-Middle Attacks compromise authentication and data integrity.
Security Measures for Operating Systems
1. Mandatory Access Control (MAC) Policies
• Prevent unauthorized processes from accessing sensitive system resources.
• Example: SELinux (Security-Enhanced Linux) enforces strict access policies.
2. Strong Authentication and User Management
• Implement password complexity rules and MFA.
• Use least privilege principles (LPP) to restrict admin privileges.
3. Regular Patch Management
• Automate OS updates to address vulnerabilities.
• Use vulnerability scanners to identify and patch security loopholes.
4. Secure File Systems and Encryption
• Encrypt sensitive files using BitLocker (Windows) or LUKS (Linux).
• Implement file integrity monitoring (FIM) to detect unauthorized changes.
5. Application Sandboxing and Trusted Path Execution
• Isolate applications to prevent cross-contamination of system resources.
• Use trusted execution environments (TEE) for secure processing.
6. Network Security Hardening
• Enforce firewall policies and restrict unnecessary ports.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 12

BCS601 Cloud Computing Module-4

• Utilize Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS).
7. System Logging and Monitoring
• Enable event logging to track security incidents.
• Use Security Information and Event Management (SIEM) solutions for real-time
analysis.

11.8 VIRTUAL MACHINE SECURITY

Virtual Machines (VMs) are widely used in cloud computing, allowing multiple operating
systems to run on a single physical server. However, they introduce unique security challenges
due to shared resources, hypervisor vulnerabilities, and potential misconfigurations.
1.1 Definition of Virtual Machine Security
VM security refers to the protection of virtualized environments from unauthorized access,
data breaches, malware attacks, and system vulnerabilities. It involves securing both the
hypervisor and guest VMs to maintain data confidentiality, integrity, and availability.
1.2 Importance of VM Security
• Ensures data confidentiality and prevents unauthorized access.
• Protects shared resources in multi-tenant cloud environments.
• Prevents hypervisor attacks that can compromise multiple VMs.
• Safeguards virtual networks from malware and lateral attacks.
• Supports regulatory compliance (e.g., GDPR, HIPAA, ISO 27001).

2. Key Components of Virtual Machine Security

Securing a VM environment requires protecting the following key components:

2.1 Virtual Machine Monitor (VMM) / Hypervisor

• The hypervisor is the software layer that manages VMs and hardware resources.
• If compromised, an attacker can control all guest VMs on a server.
• Types of Hypervisors:
o Type 1 (Bare-metal): Runs directly on hardware (e.g., VMware ESXi,
Microsoft Hyper-V, Xen).
o Type 2 (Hosted): Runs on a host OS (e.g., VirtualBox, VMware Workstation).
• Security Concern: Hypervisors have privileged access to the system and are prime
targets for attackers.
2.2 Guest Virtual Machines

Dr. Sampada K S, Associate professor CSE RNSIT pg. 13

BCS601 Cloud Computing Module-4

• Each VM operates independently and may run a different OS.

• Security Concern: A compromised VM can attack the host system or other VMs (VM
escape attacks).
2.3 Virtual Networking
• Virtual switches and routers manage traffic between VMs.
• Security Concern: Misconfigured virtual networks can expose VMs to external
attacks.
2.4 Virtual Storage
• Cloud-based storage (e.g., Amazon S3, Google Cloud Storage) is used to store VM data.
• Security Concern: Data exposure or loss due to misconfigured access controls.

• Common Virtual Machine Security Threats

NIST security group distinguishes two groups of threats, hypervisor-based and VM-based.
There are several types of hypervisor-based threats:
1. Starvation of resources and denial of service for some VMs. Probable causes: (a)
badly configured resource limits for some VMs; (b) a rogue VM with the capability to
bypass resource limits set in hypervisor.
2. VM side-channel attacks: malicious attack on one or more VMs by a rogue VM under
the same hypervisor. Probable causes: (a) lack of proper isolation of inter-VM traffic due
to misconfiguration of the virtual network residing in the hypervisor; (b) limitation of
packet inspection devices to handle high speed traffic, e.g., video traffic; (c) presence
of VM instances built from insecure VM images, e.g., a VM image having a guest OS
without the latest patches.
3. Buffer overflow attacks.

There are also several types of VM-based threats:

1. Deployment of rogue or insecure VM; unauthorized users may create insecure
instances from images or may perform unauthorized administrative actions on existing
VMs. Probable cause: improper configuration of access controls on VM administrative
tasks such as instance creation, launching, suspension, re-activation and so on.
2. Presence of insecure and tampered VM images in the VM image repository. Probable
causes: (a) lack of access control to the VM image repository; (b) lack of mechanisms
to verify the integrity of the images, e.g., digitally signed image.

Privilege Escalation Attacks

• Attackers exploit vulnerabilities to gain higher-level privileges on a VM or hypervisor.

11.10 SECURITY RISKS POSED BY SHARED IMAGES

1. Introduction
• Image sharing in cloud computing, especially in IaaS cloud delivery models, poses
significant security risks.
• Example: In AWS EC2, users can choose Amazon Machine Images (AMIs) via:
o Quick Start (official, pre-configured images).
o Community AMIs (user-shared images).

Dr. Sampada K S, Associate professor CSE RNSIT pg. 14

BCS601 Cloud Computing Module-4

• Problem: Many users, especially beginners, use public/shared AMIs without verifying
their security.
• Even trusted cloud providers cannot prevent all risks from shared images.

2. How Are Amazon Machine Images (AMIs) Created?

• Users can create AMIs by:
1. Starting from a running system.
2. Modifying an existing AMI.
3. Using a VM image and copying the file system to S3 (bundling process).
• Steps in Bundling Process:
1. Create an image.
2. Compress & encrypt the image.
3. Split image into multiple segments and upload to Amazon S3.
• Tools used for AMI creation:
o ec2-bundle-image: Used for loopback file system images (data transferred in
blocks).
o ec2-bundle-volume: Used for bundling a running system (copies files
recursively).

3. Security Risks Found in Shared AMIs

A. Vulnerability Study on AWS AMIs
• A six-month security study (Nov 2010 - May 2011) analyzed 5,303 AMIs (from 8,448
Linux & 1,202 Windows AMIs).
• Findings:
o Many AMIs contained sensitive data (credentials, private keys).
o Critical software vulnerabilities were present in most images.
o Old, outdated AMIs increased security risks.
• Breakdown of Vulnerabilities:
o 98% of Windows AMIs (249 out of 253) had critical vulnerabilities.
o 58% of Linux AMIs (2,005 out of 3,432) had critical vulnerabilities.
o Average number of vulnerabilities per AMI:
▪ Windows: 46
▪ Linux: 11
o Outdated AMIs:
▪ 145 Windows AMIs were 2+ years old.
▪ 1,197 Linux AMIs were 2+ years old.

B. Three Key Security Risks in Shared AMIs

1. Backdoors & Leftover Credentials
✓ 22% of scanned Linux AMIs contained credentials allowing remote login.
✓ Identified:
• 100 passwords.
• 995 SSH keys.
• 90 cases with both passwords & SSH keys exposed.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 15

BCS601 Cloud Computing Module-4

➢ Attack Vectors:
1. SSH Key Backdoors
o AWS stores user’s public SSH key in ~/.ssh/authorized_keys.
o Malicious AMI creators can leave their own SSH keys → They can log into
any instance using that image.
2. Password-Based Authentication
o If SSH password authentication is enabled, AMI creators may leave their
passwords.
o Attackers can extract password hashes and crack them using "John the
Ripper" (a password-cracking tool).
Preventive Measures:
• Always revoke existing SSH keys & add new ones.
• Disable password-based login & enforce key-based authentication.
• Run cloud-init scripts to regenerate host SSH keys.

2. Unsolicited Connections & Data Leaks

Attack Vectors:
• Outgoing connections from compromised AMIs may leak:
o Instance IP address.
o System logs (/var/log/syslog).
o Login events, web requests, and user activity.
• Example:
o Audit found Linux instances with modified syslog daemons forwarding logs
to an external server.
o Some connections are legitimate (software updates), but others may be
malicious.
Preventive Measures:
• Monitor outgoing network traffic for suspicious activity.
• Restrict unauthorized external connections using firewall rules.
• Use intrusion detection systems (IDS) to detect malicious activity.

3. Malware & Trojan Infections

Malware types found in AMIs:
• Trojan-Spy (variant 50112) → Keylogging, data theft, process monitoring.
• Trojan-Agent (variant 173287) → Stealing stored passwords from Firefox.
• Virus-infected Windows AMIs detected via ClamAV malware scanner.
Preventive Measures:
• Scan AMIs for malware before launching.
• Avoid public AMIs from unknown sources.
• Use official AMIs or create custom images with verified software.

C. Risks for AMI Creators (Privacy Concerns)

Even AMI creators face security risks:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 16

BCS601 Cloud Computing Module-4

1. Sensitive files (e.g., AWS API keys) may be exposed.

2. Malicious users can extract private information like:
o API keys (pk-xxxx.pem, cert-xxxx.pem) → Can be used to start AWS
instances under the creator’s account.
o SSH private keys (id_rsa, id_dsa) → Often not password-protected.
o IP addresses & user data logs (lastlog, lastb).
o Browser history & shell history (.bash_history).
3. Deleted files can be recovered if not properly erased.
Case Study:
• 612 AMIs contained shell history files (.bash_history, .sh_history).
• 160,000 command history lines analyzed → 74 credentials found in logs.
Preventive Measures:
• Wipe sensitive data before sharing AMIs.
• Use tools like shred, scrub, zerofree, or wipe to erase deleted files securely.
• Never store API keys in an AMI.

4. Best Practices for Secure AMI Usage

A. For AMI Users
• Avoid public/shared AMIs unless verified from a trusted source.
• Scan AMIs for vulnerabilities using tools like Nessus or ClamAV.
• Reset passwords & SSH keys immediately after launching a new instance.
• Disable password authentication & enforce key-based login.
• Monitor outgoing network traffic for unusual connections.
• Regularly update OS & installed software to patch security vulnerabilities.
B. For AMI Creators
• Remove API keys, SSH keys, browser & shell history before publishing an AMI.
• Ensure AMI is fully patched before sharing.
• Use encryption tools for sensitive files.
• Perform a deep scan for malware before distributing the AMI.
• Scrub deleted files to prevent unauthorized recovery.

11.11 SECURITY RISKS POSED BY A MANAGEMENT OS

1. Introduction

Dr. Sampada K S, Associate professor CSE RNSIT pg. 17

BCS601 Cloud Computing Module-4

• Virtualization is often considered more secure because a hypervisor is smaller and

easier to analyze than a traditional operating system.
• Example: Xen Hypervisor
o Contains ~60,000 lines of code (significantly fewer than a traditional OS).
• Virtualization strengthens security by enforcing strong isolation between VMs.
• However, the hypervisor still depends on a Management OS (Dom0) for:
o VM creation & administration.
o Storage & network operations.
o Device driver support & live migration.
• Key issue: Management OS is part of the Trusted Computing Base (TCB) and can
introduce security risks.

2. Understanding the Trusted Computing Base (TCB)

• TCB includes:
1. Hardware.
2. Hypervisor (Xen in this case).
3. Management OS (Dom0).
• TCB security is critical because a compromised TCB affects the entire cloud
system.
• Example of TCB vulnerabilities:
o A study found 21 out of 23 attacks targeted Dom0.
o 11 attacks exploited buffer overflow vulnerabilities in guest OS.
o 8 attacks were Denial of Service (DoS) attacks.

3. Security Risks of Dom0 (Management OS)

• Dom0 has full control over the system and can:
o Create new VMs.
o Modify kernel settings of guest VMs.
o Manage storage and networking operations.
• Attack Vectors:
o A malicious Dom0 can compromise guest VMs during:
1. VM creation.
2. VM execution.

A. Security Risks During VM Creation

Dom0 is responsible for setting up new VMs.
A compromised Dom0 can introduce backdoors or malicious modifications during VM
creation.
• Steps in VM Creation:
1. Allocate memory in Dom0 & load guest OS kernel.
2. Allocate memory for new VM & map memory pages.
3. Set up page tables for VM (memory mapping).
4. Launch the VM.
• Possible Malicious Actions by Dom0:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 18

BCS601 Cloud Computing Module-4

o Refuse to start the VM (Denial-of-Service (DoS) attack).

o Modify guest OS kernel to allow remote access.
o Set incorrect page tables → Compromise memory integrity.
o Retain foreign mapping access → Spy on the VM while it runs.

B. Security Risks During VM Execution

Dom0 continues interacting with running VMs.
A compromised Dom0 can eavesdrop on VM activities.
• How Dom0 interacts with guest VMs:
o Dom0 provides network and storage access to guest VMs.
o Uses "split drivers" (frontend in guest VM, backend in Dom0) to handle I/O
operations.
o Exposes guest VMs to potential threats.
• Potential Attacks:
o Eavesdropping on data transfers (network traffic, disk storage).
o Extracting cryptographic keys from guest VMs.
o Blocking or modifying access to XenStore (configuration storage).

4. Protecting Confidentiality and Integrity in Dom0

Dom0 security vulnerabilities can be exploited by attackers.
Solution: Limit Dom0's power and enforce strict security controls.
A. Secure Memory and CPU Access
• Dom0 should not directly access guest VM memory.
• Encrypt memory pages before allowing Dom0 access.
• Hypervisor should verify memory integrity after Dom0 access.
B. Secure Network and Storage Access
• All communication between guest VMs and Dom0 should be encrypted.
• TLS is not enough – Dom0 can still extract cryptographic keys from VM memory.
• Guest VMs should store sensitive data remotely (not in Dom0-managed storage).

5. Mitigation Strategies for Dom0 Security Risks

Hypervisor should restrict Dom0's privileges to prevent malicious activities.
Introduce security checks for critical hypercalls (privileged operations by Dom0).
New hypercalls to protect guest VM integrity:
Security Concern Solution
Virtual CPU protection Encrypt CPU registers when saving/restoring VM state.
Memory protection Encrypt memory pages before giving access to Dom0.
Integrity checks Hypervisor should verify VM integrity after every Dom0 access.
Restrict access to XenStore to prevent malicious configuration changes.
Monitor Dom0 activity to detect suspicious behavior.

6. Performance Overhead of Security Enhancements

Dr. Sampada K S, Associate professor CSE RNSIT pg. 19

BCS601 Cloud Computing Module-4

Security measures increase system overhead.

Study Results:
• Domain Build Time: Increased by 1.7x – 2.3x.
• Domain Save Time: Increased by 1.3x – 1.5x.
• Domain Restore Time: Increased by 1.7x – 1.9x.
• Trade-off: Better security comes with some performance cost.

11.12 Xoar – Breaking the Monolithic Design of the Trusted Computing Base (TCB)
1. Introduction
• Xoar is a modified version of Xen designed to enhance system security.
• Security model assumptions:
o System is professionally managed.
o Only system administrators have privileged access.
o Administrators are trusted and do not have incentives to violate user trust.
• Sources of Security Threats:
o Malicious guest VMs attempting to compromise:
▪ Data integrity.
▪ Confidentiality of other guest VMs.
▪ Guest VM execution processes.
o Bugs in initialization code of the management VM.
• Key Innovation:
o Xoar follows microkernel design principles to increase security.
o Unlike Xen, Xoar is modular, explicitly defining exposure risks.

2. Design Principles of Xoar

• Modularity increases security and reduces attack surface.
• Each component has limited privileges, reducing risk exposure.
Design Goals
1. Maintain the functionality of Xen.
2. Ensure transparency with existing management and VM interfaces.
3. Tightly control privileges – each component should only have the minimum required
privileges.
4. Minimize component interfaces – reduce possible attack vectors.
5. Eliminate unnecessary sharing.
6. Explicitly define sharing to enable proper logging and auditing.
7. Reduce attack exposure window – minimize the time components are active.
Goal: Break the monolithic Trusted Computing Base (TCB) design used in Xen while
keeping performance overhead minimal.

3. Understanding the Xoar Component Architecture

• Traditional Xen Issues:
o Large TCB → Increased attack surface.
o Persistent runtime components → More opportunities for exploitation.
• Xoar Solution:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 20

BCS601 Cloud Computing Module-4

o Redesigns Xen into modular components.

o Classifies components into four types:
1. Permanent – Always active.
2. Self-Destructing – Used only during boot, then removed.
3. Restarted on Request – Loaded only when needed.
4. Restarted on Timer – Periodically restarted for security.
5. Types of Components in Xoar

A. Permanent Components
XenStore-State – Maintains the state of the system.
Critical component → Must be hardened against attacks.
B. Self-Destructing Components (Used during boot, then removed)
PCIBack – Virtualizes access to the PCI bus configuration.
Bootstrapper – Coordinates hardware initialization and booting.
Removed before any user VM starts → Reduces security risks.
C. Components Restarted on Request (Loaded only when needed)
XenStore-Logic – Manages system state changes.
Toolstack – Handles VM management requests.
Builder – Creates and initializes guest VMs.
Minimizes exposure time to attacks.
D. Components Restarted on Timer (Periodically restarted for security)
BlkBack – Exports physical storage drivers.
NetBack – Exports network drivers.
Restarts periodically to ensure security freshness.

5. Reducing Attack Surface with Xoar

• Xoar reduces attack surface by separating privileges.
• Key differences from Xen:
o Traditional Xen:
▪ Monolithic – All components run continuously.
▪ Large TCB → Higher risk of compromise.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 21

BCS601 Cloud Computing Module-4

o Xoar:
▪ Modular – Components load only when needed.
▪ Minimized TCB → Lower risk.
Key Security Enhancements
Most privileged components (PCIBack & Bootstrapper) are removed after booting.
Builder (VM initialization) is small – Only 13,000 lines of code.
XenStore is split into two parts:
• XenStore-Logic → Handles changes.
• XenStore-State → Maintains records & includes a small monitor module for security
checks.

•
Guest VMs only share essential services (Figure 11.6).
Users can choose to share service VMs only with their own VMs (tagging system).
Benefit: Reduces security risks by restricting unnecessary interactions between
components.

6. Secure Auditing and Logging in Xoar

Audit logs ensure accountability & traceability.
Every VM action (start, stop, delete, restart) is recorded.
Audit logs are stored on a separate secure server (not accessible from the main system).
Append-only logging mechanism prevents tampering.
Why this is important?
• Traditional Xen does not track VM actions securely.
• Xoar prevents attackers from covering their tracks.

7. Enhancing Security with Snapshots

Problem: Rebooting a VM to ensure security is too slow.
Solution: Use Snapshots instead of full reboots.
Service VMs take a snapshot when ready to process a request.
Snapshots of components are taken:
• Immediately after initialization.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 22

BCS601 Cloud Computing Module-4

• Before interacting with other components/guest VMs.

Implemented using "Copy-on-Write" (COW) mechanism.
Why this matters?
• Ensures VMs return to a known good state without full reboot overhead.
• Prevents persistence of malware or unauthorized modifications.

8. Comparison: Xoar vs. Xen Security

Feature Xen Xoar
TCB Size Large, monolithic Modular, reduced size
VM Boot Process Runs continuously Self-destructing components
Service Sharing Shared among all VMs Users can restrict sharing
Audit Logging Limited tracking Secure, append-only logs
Recovery Method Full reboot Fast snapshot recovery
Attack Surface Large (more active components) Smaller (only active when needed)

11.13 Trusted Hypervisor (Terra)

1. Introduction
• Terra is a trusted hypervisor designed to enhance security beyond traditional
hypervisors like Xen.
• Key Innovations in Terra’s Design:
1. Supports both traditional and closed-box OS abstractions.
2. Allows applications to build customized software stacks.
3. Provides strong security guarantees like attestation & trusted paths.

2. Terra's Security Features

A. Support for Both Open-Box and Closed-Box Platforms
• Open-Box Platform: Traditional OS abstraction that allows user access &
modifications.
• Closed-Box Platform:
o Highly secure environment – users cannot inspect or modify system
contents.
o Used in applications requiring high security, e.g., financial transactions,
electronic voting.
o Provides information assurance (IA):
▪ Integrity: Ensures data remains unaltered.
▪ Availability: Ensures system uptime.
▪ Confidentiality: Protects sensitive data.
▪ Authenticity & Non-repudiation: Verifies identities & prevents denial
of actions.
B. Support for Attestation and Trusted Paths
Attestation:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 23

BCS601 Cloud Computing Module-4

• Applications can prove their trustworthiness to remote entities using cryptographic

mechanisms.
Trusted Paths:
• Ensures users are interacting with the correct VM.
• Prevents man-in-the-middle attacks from malicious VMs.
C. Strong Hypervisor Isolation & Access Controls
• Hypervisor operates at the highest privilege level.
• Administrators have no root access → prevents unauthorized changes.
• The Management VM is distinct from Guest VMs:
o Controls number of guest VMs running.
o Manages resource allocation (CPU, memory, disk usage).
o Restricts access to I/O devices.
D. Challenges in Trusted Hypervisor Security
• Device drivers pose a major security risk:
o Large codebase → more vulnerabilities.
o Many are poorly written to accommodate hardware features quickly.
• Malicious I/O devices can exploit Direct Memory Access (DMA) to modify the
kernel.
• Solution:
o Restrict driver access to sensitive information.
o Implement hardware protection mechanisms.

11.14 Mobile Devices and Cloud Security

1. Importance of Mobile Security in the Cloud
• Mobile devices are critical to cloud computing, as they interact with cloud services
for:
o Data access & storage.
o Application execution & computing tasks.
• Security Challenges for Mobile Devices:
1. Confidentiality → Prevent unauthorized access to data.
2. Integrity → Detect unauthorized modifications.
3. Availability → Ensure users can access cloud resources.
4. Non-repudiation → Ensure a sender cannot deny sending a message.

2. Mobile Device Technology Stack

Four Layers of a Mobile Device:
1. Hardware
2. Firmware
3. Operating System (OS)
4. Applications
Security-specific hardware/firmware stores:
• Encryption keys.
• Certificates & credentials.
• Other sensitive data.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 24

BCS601 Cloud Computing Module-4

Security Risk:
• Baseband processors (telephony services) operate outside mobile OS control.
• Attackers can exploit firmware vulnerabilities.

3. Unique Security Risks for Mobile Devices

A. Higher Exposure to Threats
Mobile devices are more vulnerable than stationary systems due to:
• Frequent internet access (WiFi & cellular networks).
• Easy app installations from third-party stores.
• Untrusted networks for communication.
• Weaker authentication methods (short passcodes).
• Location services enable tracking & targeted attacks.
B. Common Mobile Security Threats
Key Mobile Threats:
1. Mobile malware (viruses, spyware, Trojans).
2. Data loss due to theft or disposal.
3. Unauthorized access to sensitive data.
4. Electronic eavesdropping (interception of communications).
5. Electronic tracking via GPS & location services.
6. Unrestricted access to sensitive data by third-party apps.

4. Mobile Security Risks Impacting the Cloud

Threats to Cloud Infrastructure from Mobile Devices:
• Ransomware-infected mobile files can migrate to cloud backups.
• Cloud data leaks due to compromised mobile devices.
• Weak authentication allows unauthorized cloud access.
Common Causes of Mobile Cloud Security Issues:
1. Loss of device → Access control vulnerabilities (e.g., smudge attacks).
2. Lack of encryption for cloud data in transit.
3. Unpatched software & jailbroken devices bypass security.
4. Malicious apps bypassing access controls.
5. Misconfigured GPS & location services → unauthorized tracking.
6. Acceptance of fake mobility profiles (man-in-the-middle attacks).

5. Enterprise Mobile Management (EMM) Solutions

EMM Services Include:
1. Mobile Device Management (MDM)
2. Mobile Application Management (MAM)
Key Security Policies for Mobile-Cloud Security:
Storage Protection:
• Use device encryption & application-level encryption.
• Enable remote wipe for stolen/lost devices.
Data Transmission Security:

Dr. Sampada K S, Associate professor CSE RNSIT pg. 25

BCS601 Cloud Computing Module-4

• Use TLS (Transport Layer Security) for communication.

Application Security:
• Use sandboxing to isolate applications & prevent data leaks.
Device Integrity Checks:
• Verify secure boot process.
• Ensure OS & applications are regularly updated.
Access Control & Authentication:
• Enforce multi-factor authentication.
• Restrict cloud access to authorized devices only.
Auditing & Monitoring:
• Log all device and application activities.
• Implement automated compliance checks.
Policy Enforcement:
• Automated alerts for security violations.

6. Case Study: Microsoft Cloud MDM Portal

Example: Mobile Device Management for Microsoft Outlook
• Requires users to:
1. Download Microsoft Community Portal App.
2. Authenticate using mobile OS lockscreen.
3. Encrypt all device-stored data.
• Administrators manage policies via a web-based cloud MDM portal.
Key Takeaway:
• Enforcing strong mobile security measures is essential to protect cloud resources.

7. Summary
A. Trusted Hypervisor (Terra)
• Provides higher security guarantees than traditional hypervisors.
• Supports custom security levels per application (Open-box & Closed-box).
• Implements trusted paths & attestation to verify system integrity.
• Prevents root access by administrators to secure the hypervisor.
• Reduces device driver security risks using hardware protection mechanisms.
B. Mobile Cloud Security
Mobile devices introduce new cloud security challenges.
• Common threats include: malware, stolen data, unauthorized access, tracking, & fake
profiles.
• Cloud security risks from mobile devices include data leakage, ransomware
infections, & authentication bypass.
• Enterprise Mobile Management (EMM) helps enforce security policies,
encryption, & access control.
• Best practices include: device encryption, TLS security, authentication enforcement,
& automated monitoring.
• Securing mobile-cloud interactions is critical for overall cloud security.

Dr. Sampada K S, Associate professor CSE RNSIT pg. 26

BCS601 Cloud Computing Module-4

Dr. Sampada K S, Associate professor CSE RNSIT pg. 27