, Private, And Hybrid Clouds:

Public Clouds (4.1.1.2)

A public cloud is a cloud service available over the internet for anyone who pays for it. These clouds are
owned and managed by companies like Google (GAE), Amazon (AWS), Microsoft (Azure), IBM, and
Salesforce.
They allow users to create and use virtual machines (VMs) through an online interface. You only pay for
what you use, making it flexible and cost-effective for running applications and services.

Private Clouds (4.1.1.3)

A private cloud is used only by one organization. It is set up within the company’s own network (intranet)
and is not open to the public.
The company owns and controls it, allowing for more security, customization, and control. It gives
employees or partners a flexible way to run services securely within the organization.

Hybrid Clouds (4.1.1.4)

A hybrid cloud combines both public and private clouds. For example, a company may mostly use a private
cloud but borrow extra computing power from a public cloud when needed.
An example is IBM’s Research Compute Cloud (RC2), which connects private cloud resources across its
global research centers.
Hybrid clouds offer a balance — some flexibility and cost-saving from public clouds, and some control and
security from private clouds.
Here is a simplified version of the content from sections 4.1.3 to 4.1.4.2, rewritten in clear and easy-to-
understand language:

4.1.3 Infrastructure-as-a-Service (IaaS)

Cloud computing offers three types of services:

1. Infrastructure as a Service (IaaS)

2. Platform as a Service (PaaS)

3. Software as a Service (SaaS)

These services are offered over the Internet using a pay-as-you-go model, which means you pay only for
what you use. These are called cloud service models and are provided through agreements called SLAs
(Service Level Agreements). SLAs ensure things like availability, performance, and security.

All three models use the infrastructure provided by cloud service providers and let users access services
through the internet:

• SaaS: Directly used by clients through special applications (like email or document tools).

• PaaS: Manages billing, job handling, and monitoring for developers.

• IaaS: Provides basic resources like storage, computing power, and file systems.

4.1.3.1 What is IaaS (Infrastructure as a Service)?

IaaS gives users access to virtual machines, storage, and networking over the cloud. Think of it as renting
the basic building blocks of a computer system.

• Users can choose their own operating system and run their own applications.

• They do not control the underlying hardware or cloud infrastructure.

• However, they do have control over the OS, storage, applications, and some network settings.

IaaS includes services like:

• Storage as a Service

• Compute Instances as a Service

• Networking/Communication as a Service

Example:
Amazon's EC2 (Elastic Compute Cloud) and S3 (Simple Storage Service) allow users to run virtual servers
and store data. These are part of a Virtual Private Cloud (VPC) setup, where multiple users can access
resources securely.

Some IaaS providers are:

• GoGrid
 • FlexiScale

• Aneka

Table 4.1 (not shown here) gives more details about the IaaS services offered by five major providers. For
more examples, refer to cloud computing books mentioned as [10,18].

4.1.4 Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS)

SaaS and PaaS are built on top of IaaS. Here’s how it works:

• IaaS provides basic resources (infrastructure).

• PaaS provides a platform to build and manage apps using IaaS.

• SaaS provides the final application that users can access through the internet.

4.1.4.1 What is PaaS (Platform as a Service)?

PaaS is used by developers who want to create, test, and run applications without worrying about
managing the underlying hardware.

• It provides a complete environment including an OS, runtime libraries, and other tools.

• Developers can use Java, Python, .NET, and other programming languages to build apps.

• The user does not control the infrastructure, only the application development process.

Benefits of PaaS:

• Developers from different locations can collaborate on the same platform.

• Third-party companies can offer tools for software management, integration, and monitoring.

Table 4.2 (not shown) gives a comparison of PaaS offerings from five major providers. More information is
given in Chapter 6 and Section 4.4 of the textbook.

4.1.4.2 What is SaaS (Software as a Service)?

SaaS is the final software product delivered to users through a web browser. These applications are built
using tools from PaaS and run on infrastructure provided by IaaS.

• Users don’t have to buy or install any hardware or software.

• Everything runs on the cloud provider’s servers.

• This saves money for both users and providers.

Examples of SaaS:

• Google Gmail and Google Docs

• Microsoft SharePoint
 • Salesforce.com CRM software

These applications are used by many small and large businesses daily.

Some companies, like Google and Microsoft, offer a full set of IaaS and PaaS services along with SaaS.
Others, like Amazon and GoGrid, only provide IaaS and rely on third parties (e.g., Manjrasoft) to offer
platforms and application development tools.

Example 4.3 (not shown) describes how three real-world companies—HTC, media organizations, and
business firms—use cloud-based applications successfully.
Data-Center Interconnection Networks

Describe the interconnection network design of large-scale cloud data centers.

Write a short note on the global exchange of cloud resources and its implications.

4.2.2 Data-Center Interconnection Networks (Simplified)

A key part of a data center’s design is how the servers are connected through a network. This
interconnection network must meet five main requirements:

• Low latency (fast response time)

• High bandwidth (fast data transfer)

• Low cost

• Support for MPI (Message Passing Interface) communication

• Fault tolerance (ability to handle failures)

The network should support point-to-point (between two servers) and collective (group) communication
patterns. Let’s look at the specific points below:

4.2.2.1 Application Traffic Support

• The network must support all MPI communication patterns, both one-to-one and one-to-many.

• It should have high bisection bandwidth, meaning it can handle heavy traffic across the entire
network.

• For example, one-to-many communication is used when one server acts as a master and others as
slaves (e.g., for accessing distributed files).

• The network should also support MapReduce operations efficiently, which are used in big data
applications (explained in Chapter 7).

• In short, the network must handle different types of data flows based on the needs of various user
applications.

4.2.2.2 Network Expandability

• As more servers are added to a data center (thousands or even more), the network should be easy
to expand.

• The network should support load balancing and data movement between servers efficiently.

• Common expandable topologies include fat-tree and crossbar networks which can be built using
low-cost Ethernet switches.

• However, designing for a large number of servers can be difficult.

Data-Center Containers:

• Modern data centers use server containers, which are large boxes filled with hundreds or
thousands of servers.

• Each container is a modular unit that can be plugged in with power, internet connection, and
cooling.

• These containers reduce the cost and complexity of setting up data centers.

• The network backbone (main connection line) is set up first and then connected to individual
containers.

• Multiple containers are connected through external switches and cables.

4.2.2.3 Fault Tolerance and Graceful Degradation

• The network must be able to handle failures of links or switches.

• There should be multiple paths between any two servers so that if one path fails, the data can go
another way.

• Data and computations are often duplicated (replicated) across servers to handle server failures.
The same idea should be used for network connections.

Redundancy:

• Use both hardware and software redundancy to protect against failures.

• The software should detect broken links and reroute packets automatically.

• This should happen transparently, without interrupting services.

Graceful Degradation:

• If some network parts fail, the system should continue running smoothly instead of crashing.

• Use hot-swappable components (that can be replaced without shutting down the system).

• There should be no single point of failure—no single part whose failure will bring down the whole
system.

Hierarchical Network Design:

• Networks are often designed in two layers:

o Lower layer connects directly to the servers.

o Upper layer connects different groups of servers (sub-clusters).

• This structure fits well with the container-based design of modern data centers.

4.2.2.4 Switch-centric Data-Center Design

There are two main ways to design a data center’s network:

1. Switch-centric Design

• Uses switches to connect servers.

• Servers do not need any changes.

• Simple to implement since the networking is handled by the switches, not the servers.

2. Server-centric Design

• Involves modifying the server's operating system to handle traffic.

• Special software (drivers) is installed on the servers to help manage network connections.

• Still uses switches, but servers take on more responsibilities in routing traffic.
A Generic Cloud Architecture

4.3.1.3 A Simple View of Cloud Architecture

Figure 4.14 (not shown here) shows how a cloud system is built with security in mind. Think of the
Internet cloud as a giant group of servers working together. These servers can be turned on or off as
needed to run web services or applications using data center resources.

The cloud system is created dynamically. This means servers, software, and databases are added or
removed automatically based on user requests. These servers can be real physical machines or virtual
machines (VMs).

How It Works:

• Users request services through a user interface.

• A provisioning tool then sets up the servers and software needed to provide that service.

• The cloud also includes distributed storage systems to manage and store large amounts of data.

• The data centers that power the cloud are usually owned by cloud providers (like Amazon, Google,
or Microsoft), not the users.

What Users See:

• Users don’t need to know how the system works behind the scenes.

• In the cloud, software is provided as a service (SaaS).

• Users trust the cloud to safely store and manage huge amounts of data.

• A distributed file system is used to process and access this data efficiently.

What’s Included in the Cloud:

A cloud system usually includes:

• Storage Area Networks (SANs)

• Databases

• Firewalls and Security Devices

• APIs (so developers can interact with the cloud)

• Monitoring and Metering Tools to track usage and performance

Software Infrastructure Responsibilities:

The software that runs the cloud must:

 • Manage all resources automatically

• Detect when servers join or leave the system

• Perform needed setup or cleanup actions without user involvement

Cloud Data Centers:

• Companies like Google and Microsoft have built many data centers around the world.

• Each data center may have thousands of servers.

• Data centers are built in cost-efficient locations, often near hydroelectric power sources, to reduce
electricity and cooling costs.

• When building cloud systems, providers focus more on cost-efficiency and reliability than just
speed.

Cloud Types and Trends:

• Private clouds (used within one organization) are easier to manage.

• Public clouds (used by anyone who pays) are easier to access.

• The current trend is toward hybrid clouds, which mix private and public clouds.

o This allows apps to go beyond one organization’s network.

o You need to learn how to set up private clouds and how to connect to public clouds.
Layered Cloud Architectural Development

4.3.2 Layered Cloud Architecture (Made Simple)

Cloud architecture is built in three layers:

1. Infrastructure Layer (supports IaaS – Infrastructure as a Service)

2. Platform Layer (supports PaaS – Platform as a Service)

3. Application Layer (supports SaaS – Software as a Service)

This structure is shown in Figure 4.15 (not shown here). These layers are made possible through
virtualization and standardization of hardware and software, meaning the resources can be shared and
managed efficiently.

Cloud services—whether public, private, or hybrid—are delivered to users through the Internet or intranet
using this layered setup.

1. Infrastructure Layer (Bottom Layer - IaaS)

• This layer includes virtual machines, storage, and networking.

• These resources are virtualized so users can get what they need quickly and flexibly.

• It automates resource allocation and helps in managing the system efficiently.

• IaaS providers like Amazon EC2 offer these basic building blocks.

2. Platform Layer (Middle Layer - PaaS)

• Built on top of the infrastructure layer.

• Provides software tools and environments where users can:

o Develop their applications

o Test how the apps work

o Monitor performance

• This layer guarantees:

o Scalability (it can grow with demand)

o Dependability (it works reliably)

o Security

• It acts like a "middleware", connecting the infrastructure to the applications.

3. Application Layer (Top Layer - SaaS)

• Built on top of the platform layer.

 • Contains ready-to-use software applications, such as:

o Document processing

o Information retrieval

o Calendars

o Authentication systems

• Businesses also use this layer for:

o Marketing and sales

o CRM (Customer Relationship Management)

o Finance and transactions

o Supply chain management

Layers May Overlap

• Some applications use resources from more than one layer.

• Even though the layers are built from the bottom up, they often work together depending on the
service.

Example:

• Amazon EC2 (IaaS) offers virtual machines and manages them for users.

• Salesforce.com (SaaS) does everything—from hardware to platform and user-ready applications like
CRM. It also provides tools for developers to build and manage their own apps.Market-Oriented
Cloud Architecture
4.3.2.1 Market-Oriented Cloud Architecture (Simplified)

As more users rely on cloud computing for their needs, they expect a certain quality of service (QoS) to be
maintained. This is to make sure their work runs smoothly and meets their business goals.

To meet these expectations, cloud providers create agreements called Service Level Agreements (SLAs)
with each user. These SLAs define what level of service (like speed, uptime, etc.) the user can expect. Each
user may have different requirements, so the cloud provider must manage resources accordingly.

Why Traditional Systems Don’t Work

Old, system-focused methods of managing cloud resources are not enough to handle modern demands.
Instead, a market-oriented approach is needed. This approach works like a marketplace where:

• Resources are supplied and consumed based on demand

• Prices may vary, encouraging fair use and better resource allocation

• Consumers and providers both benefit — users get better prices, and providers balance usage
effectively

Figure 4.16 (not shown here) shows a high-level structure of this market-based cloud system. It includes
the following components:

1. Users or Brokers

• Users (or their representatives called brokers) send service requests from anywhere in the world to
the cloud/data center.

2. SLA Resource Allocator

• Acts as a middleman between the user and the cloud system.

• Manages requests and ensures the terms of the SLA are followed.

This component includes several smaller systems working together:

1. Service Request Examiner

• Reads each request to understand what kind of service is needed.

• Checks if there are enough resources available.

• Rejects requests if too many are submitted or if it would overload the system.

• Uses data from:

o VM Monitor: Tells which virtual machines (VMs) are available.

o Service Request Monitor: Tells how much work is currently being done.
 2. Pricing Mechanism

• Decides how much to charge for each request.

• Pricing depends on:

o Time of request (peak vs. off-peak hours)

o Fixed or changing prices

o Supply and demand of resources

3. Accounting Mechanism

• Keeps track of how much resources each user consumes.

• Helps calculate the final cost to the user.

• Saves historical data:

o Improve future decisions

o Support other systems like Admission Control and Request Examiner

4. VM Monitor

• Monitors virtual machines (VMs) to check their availability and how much resources they
are using.

5. Dispatcher

• Once a request is approved, the dispatcher starts the task on the selected VM.

6. Service Request Monitor

• Tracks the progress of running service requests.

• Ensures everything is running smoothly.

• A single physical machine can run multiple VMs at the same time.

• Each VM can:

o Be started or stopped as needed

o Run different operating systems (e.g., Linux, Windows) independently

• VMs are isolated, so they don't affect each other even though they share the same physical server.
GOOGLE APP ENGINE (GAE)

In 2008, Google launched Google App Engine (GAE). It is a Platform as a Service (PaaS) that allows users to
build and run web applications that automatically scale depending on the number of users.

GAE lets users run their apps on Google’s powerful infrastructure, which is connected to their search
engine operations.

4.4.2.2 GAE Architecture

Figure 4.20 (not shown here) shows the structure of the Google Cloud Platform.

The important parts include:

• GFS – stores huge amounts of data.

• MapReduce – helps in building applications that process big data.

• Chubby – provides lock services needed for distributed applications.

• BigTable – helps store and access structured (organized) data.

These tools work together to allow Google and other developers to build powerful cloud applications. All
applications built with GAE run in Google’s tightly controlled data centers, which include thousands of
servers organized into clusters.

Although Google runs many cloud apps, its core cloud system is private, so external users can’t use the
actual infrastructure directly. However, they can use GAE to build apps, which will then run on Google’s
systems.

GAE handles all the hardware, software, and server maintenance, so developers can focus only on coding
their applications.

GAE works like web application frameworks such as ASP, J2EE, or JSP. It currently supports Python, Java,
and Ruby programming languages.

GAE is ideal for creating dynamic web applications and offers full support for common web technologies.

4.4.2.3 Functional Modules of GAE

GAE has five main parts (components) that work together to support web app development:

a. Datastore

• Stores structured data (organized like objects or database entries).

• Based on BigTable.

• Ensures secure and distributed data storage.

b. Application Runtime Environment

• Runs the apps built by users.

 • Scales up when user demand increases.

• Supports Python and Java programming languages.

c. Software Development Kit (SDK)

• Used by developers to build and test apps locally before uploading.

• Helps with development and testing.

d. Administration Console

• A tool to manage the app lifecycle (build, update, monitor apps).

• Not used for managing physical servers or resources.

e. Web Service Infrastructure

• Offers special interfaces (APIs) to manage storage and network use.

• Makes app development and usage more flexible.

Google offers GAE for free to all users with a Gmail account. You can sign up using your Gmail ID, download
the SDK, and start developing apps in Python or Java.

GAE is not an IaaS platform like Amazon AWS, which provides both Infrastructure as a Service (IaaS) and
Platform as a Service (PaaS). Instead, GAE is only a PaaS. This means developers can build and run apps
without worrying about the infrastructure.

Similarly, Microsoft Azure provides a platform for apps using .NET tools.

In GAE, the cloud provider (Google) handles everything related to infrastructure, such as servers,
networking, and scaling. The developer only focuses on app development.

4.4.2.4 GAE Applications

Famous apps built using Google infrastructure include:

• Google Search

• Gmail

• Google Docs

• Google Earth

These apps can support millions of users at once, and users interact with them using simple web
interfaces.

Third-party developers can also use GAE to build their own cloud-based web apps.

All these apps run in Google’s data centers, which are made of clusters of servers. Each cluster can:

• Run different apps

• Use services like GFS, MapReduce, and BigTable

 • Run multiple servers for multiple tasks

GAE also includes a storage service, which allows apps to store data in Google’s systems. This service allows
data to be saved permanently, and users can:

• Query (search) the data

• Sort it

• Run simple transactions (like in databases)

Another useful feature is that apps built on GAE can use Google services like Gmail for user authentication
(login). This means developers don’t have to build their own login systems. They can just allow users to log
in with their Google accounts, and even send emails through the app using Gmail APIs.
Sure! Here’s a simplified explanation of the section 11.5 CLOUD DATA ENCRYPTION, with all concepts
included and rewritten in easier language:

11.5 Cloud Data Encryption (Simplified)

Governments, companies, and people often worry if it’s safe to store sensitive information (like personal or
financial data) on public cloud platforms. The basic solution to this problem is encryption, which turns
readable data into secret code that can only be unlocked with a special key.

Cloud Providers and Encryption

Cloud service providers like Amazon Web Services (AWS) now offer encryption services. AWS provides
something called Key Management Service (KMS) to help users create and manage encryption keys. These
keys are used to lock (encrypt) and unlock (decrypt) the user’s data. KMS works with other AWS services
like:

• EBS (Elastic Block Store)

• S3 (Simple Storage Service)
• RDS (Relational Database Service)
• Redshift, Elastic Transcoder, and WorkMail.

AWS also offers an Encryption SDK, which is a set of tools developers can use to add encryption to their
applications.

Background in Cryptography

Many important research papers have laid the foundation for data encryption:

• The famous RSA encryption method (from a key paper in the 1970s).
• In 1999, Pascal Paillier introduced a new idea based on composite residuosity, which involves
working with a number that is very hard to factor into primes (n = p × q).
• This method allows homomorphic encryption — which lets us do calculations on encrypted data
without ever decrypting it.
• A major advancement came in 2009, when Craig Gentry created a method for Fully Homomorphic
Encryption (FHE) during his PhD at Stanford. FHE allows any type of computation on encrypted
data.
Homomorphic Encryption: Computing on Encrypted Data

When data is encrypted, it’s safe in storage. But when you want to process it, you normally have to decrypt
it first — this opens a security risk.

So, the big question is: Can we do operations on data without decrypting it first?

Homomorphic encryption is a special type of encryption where:

• The encrypted data can be used directly in calculations (like addition, multiplication, etc.).
• The result of those operations, when decrypted, gives the same result as if the operations were done
on the original data.

This means you don’t need to decrypt the data to work with it — keeping it secure the whole time.

This idea comes from math: A homomorphism is a special function that keeps structure
between two systems. In encryption:

• f(x) is the encryption,

• f⁻¹(x) is the decryption,
• You can do operations on f(x), then decrypt, and get the correct result.

Although homomorphic encryption works in theory, it is not practical yet. It is very slow:

• One early version took 6 minutes to process a batch.

• Later versions reduced that to around 1 second, but it’s still much slower than working on normal
(unencrypted) data.

Searching Encrypted Databases

People often send search queries to large databases stored in the cloud. These queries might involve
arithmetic or logic (like finding numbers greater than X, etc.).

But here’s the problem: if the database is encrypted:

• Standard search methods won’t work well.

• For example, if an entire column is encrypted, the database must scan the whole column to answer a
query like “find all values greater than 100.”
• That’s because most encryption methods don’t keep the order of the data — so sorting or indexing
(e.g., using B-trees) can’t be used.

Order-Preserving Encryption (OPE)

To solve this, there is a special method called Order Preserving Encryption (OPE). It:

• Encrypts numbers in such a way that if x > y, then Encrypt(x) > Encrypt(y).
• This keeps the order of numbers, even after encryption.

How it works:

• It maps a small set of numbers (say from 1 to M) into a much larger set (say 1 to N, where N >> M).
• This mapping is done in a random but ordered way using a mathematical tool called the Negative
Hypergeometric Distribution.
• To encrypt a number, the algorithm performs a binary search over the value range using a secret key
and selects the encrypted value based on the sampling method.

This way:

• The function that encrypts the data keeps the order of the original values.
• This allows efficient range queries on encrypted data.

A better version can combine:

• A normal encryption key (Kₑₙcᵣʸₚₜ),

• An order-preserving hash function using another key (Kₕ),
• Then the final encrypted result will be: Encrypt(Kₑₙcᵣʸₚₜ, x) || Hash(Kₕ, x).
Searchable Symmetric Encryption (SSE)

Another important technique is Searchable Symmetric Encryption (SSE).

Imagine you store an encrypted database on a cloud, and keep only the key with yourself. When you want to
search:

1. You encrypt your query using the key.

2. Send the encrypted query to the server.
3. The server returns the encrypted result.
4. You decrypt the result using your key.

This method protects your data and queries. The only thing that might leak is patterns (like if you repeat the
same search), but not the actual data or query values.

A powerful SSE method was proposed in [86] to support:

• Boolean searches (AND, OR, etc.),

• It scales well for very large databases,
• Works with all types of data (including text),
• Offers controlled leakage (you know what is being revealed and how much).

Later, this method was improved to handle more advanced queries like:

• Range queries
• Substring matches
• Wildcard searches
• Phrase matches ([168]).

Insider Threats in Private Clouds

What if you store your data in a private cloud instead of a public one?

While external attackers can be blocked with strong firewalls, there’s still a risk from insiders — people who
already have access, like staff or administrators.
These insiders might:

• Look at log files to find which parts of the database are accessed frequently (hot spots),
• Copy selected pieces of data,
• Use the data for malicious purposes.

To protect against insiders, cloud systems should implement access control rings:

• Give each staff member access to only specific parts of the database.
• Limit what they can see and do.

Summary (Key Points)

• Encryption protects cloud data from unauthorized access.

• AWS KMS and SDK help manage encryption.
• Homomorphic encryption allows computations on encrypted data but is still slow.
• OPE enables range queries by preserving order in encrypted data.
• SSE allows safe searching in encrypted databases.
• Insider threats can be reduced using layered access control.

Let me know if you’d like this as a PDF, diagram, or with visual examples!
Sure! Here’s the full rewritten version of Section A11.8: Virtual Machine Security, using simple language
while keeping all key concepts intact:

A11.8 Virtual Machine Security (Simplified)

In the traditional setup:

• The hypervisor controls the hardware directly and can offer security services to the VMs.
• Security can be managed in two ways:
1. By the hypervisor itself (Figure 11.3A),
2. Or by a separate, dedicated VM that provides security functions (Figure 11.3B).

A key requirement is a secure Trusted Computing Base (TCB). If the TCB is compromised, the whole
system’s security is at risk.

Studies of systems like Xen and vBlades (in Sections 10.5 and 10.10) show that:

• VMs are better isolated from each other compared to traditional operating system processes.
• The hypervisor controls sensitive operations, like memory, disk, and network access, ensuring
separation between VMs.

Hypervisors are:

• Simpler and more organized than full operating systems.

• Easier to secure and less likely to have bugs or loopholes.

Intrusion Detection and Prevention in VMs

Several VM-based security tools have been developed:

• Intrusion Detection Systems (IDS) like Livewire and Siren use VMs to:
o Detect intrusions
o Isolate threats
o Inspect VM states
o Intercept (trap) dangerous operations
• Intrusion Prevention Systems (IPS) like:
o SVFS
o NetTop
o IntroVirt

These tools help stop attacks before they happen.

• Terra is another system that uses a trusted hypervisor to divide resources securely among VMs.

These systems take advantage of three VM features:

1. Isolation – Keeping VMs separate.

2. Inspection – Checking the VM’s current state.
3. Interposition – The hypervisor can trap and simulate sensitive operations done by guest VMs.
 Types of Security Threats Identified by NIST

A. Hypervisor-Based Threats

1. Resource Starvation / Denial of Service (DoS)

o Happens when:
▪ VMs are poorly configured.
▪ A rogue VM breaks the resource limits and takes more than allowed.
2. Side-Channel Attacks
 o A malicious VM tries to spy on another VM under the same hypervisor.
o Causes include:
▪ Poor network isolation between VMs.
▪ Packet inspection tools not handling high-speed traffic (e.g., video).
▪ Use of outdated or insecure VM images.
3. Buffer Overflow Attacks
o Attackers exploit bugs in code to overflow memory and execute harmful actions.

B. VM-Based Threats

1. Rogue or Insecure VMs

o Attackers may:
▪ Launch unsafe VM instances.
▪ Perform admin-level actions without permission.
o Cause: Weak access controls for actions like starting, stopping, or suspending VMs.
2. Tampered or Unsafe VM Images
o The VM image repository might have:
▪ Insecure VM images.
▪ Images that have been modified (tampered).
o Causes:
▪ Lack of access control for the repository.
▪ No way to check image integrity (like using digital signatures).
Security Risks from Shared Images

Even if we fully trust a cloud service provider, there are still risks that many users ignore or underestimate.
One major risk is image sharing, especially in the Infrastructure as a Service (IaaS) cloud model. For
example, Amazon Web Services (AWS) allows users to choose Amazon Machine Images (AMIs) from
Quick Start or Community AMI menus in the EC2 service. These options are attractive to first-time or less
experienced users.

How an AMI is Created

To create an AMI, we can:

• Start from a running system,

• Use an existing AMI, or
• Use a virtual machine image and copy its file system to Amazon S3.

This process is called bundling

How to Use an AMI

To use an image, a user must:

• Specify resources,
• Provide login credentials,
• Set up firewall rules,
• Choose a region (as explained in Section 2.3).

After the image is started, the user gets a public DNS address and can access the virtual machine (VM):

• Linux systems: via SSH at port 22

• Windows systems: via Remote Desktop at port 3389

Research Study on AMI Security

A study was done from Nov 2010 to May 2011 analyzing over 5,000 AMIs available publicly on Amazon. It
showed that many AMIs still had undeleted files, recoverable credentials, private keys, and other sensitive
data. These could be accessed using common tools with very little effort.

Amazon’s Security Team was informed and took quick action.

Details of the Study

Out of 8,448 Linux AMIs and 1,202 Windows AMIs, the researchers were able to audit:

Vulnerabilities Found
 • Windows AMIs:
o 98% (249 out of 253) had critical security issues
o Average 46 vulnerabilities per AMI
• Linux AMIs:
o 58% (2005 out of 3432) had critical issues
o Average 11 vulnerabilities per AMI

Some AMIs were very old:

• Windows: 145 (2+ yrs), 38 (3+ yrs), 2 (4+ yrs)

• Linux: 1197 (2+ yrs), 364 (3+ yrs), 106 (4+ yrs)

Three Main Security Risks

1. Backdoors & Leftover Credentials

• 22% of Linux AMIs allowed remote login with old credentials.

• Found: 100 passwords, 995 SSH keys, 90 with both

This happens because:

• The authorized_keys file may still contain the creator’s public key.
• If password login is allowed, the AMI may keep the creator’s password.
• These passwords can be cracked using tools like John the Ripper (link).

Also, cloud-init script is sometimes missing. This script:

• Regenerates SSH host keys at boot

• If skipped, many VMs share the same host key
• This can lead to Man-in-the-Middle (MitM) attacks

2. Unsolicited Connections

Some AMIs made unauthorized outgoing connections, leaking:

• IP addresses
• System logs, like login events in /var/log

This info is usually admin-only.

Two Linux AMIs had a modified syslog daemon that forwarded such data to an external attacker.

Some connections (e.g., for software updates) are legitimate, making it hard to tell good from bad ones.

3. Malware
Using ClamAV (a tool with 850,000+ malware signatures from clamav.net), they found:

• Two Windows AMIs infected:

o Trojan-Spy (variant 50112):
o Trojan-Agent (variant 173287)

Risks for Image Creators

The creators of shared AMIs also face risks:

• Private keys, IPs, browser history, shell history, and deleted files can be recovered.
• API keys (like AWS APT keys) could be used by attackers to run cloud services for free, at the
creator’s expense.

Recovering User Information

Using the lastlog or lastb databases, attackers found.

If users send data (e.g., passwords, credit card numbers) using HTTP GET, these can be stored in server logs
and easily exploited.

If DNS passwords are exposed, attackers can redirect website traffic.

Recovering Deleted Files

Deleted files are not really erased unless overwritten.

Without special tools, these files can be easily recovered.

If an AMI is created using block-level tools, unused disk space (marked as “free”) may still contain old files.

The study used extundelete and was able to recover data from 98% of AMIs.

The number of recovered files ranged from 6 to 40,000.

Here is a simplified version of Section 4.6.4.1: Reputation System Design Options, with all key points
included:

4.6.4.1 Reputation System Design Options (Simplified)

Figure 4.36 shows different ways to design reputation systems. A reputation is what people think about the
honesty, reliability, or behavior of someone or something. It could apply to a person, an agent, a product, or
a service. Reputation is usually based on the shared opinion of many users or owners.

Reputation systems have been used for a long time in peer-to-peer (P2P) networks, multi-agent systems, and
e-commerce platforms.

When applying reputation systems to cloud services, we need a structured design based on specific goals
and how the system is managed. The reputation system types shown in Figure 4.36 can also be used to
protect cloud applications.

Two Main Types of Reputation Systems:

1. Centralized Systems:
o A single authority or server manages the entire reputation system.
o Easier to design and control.
o But requires a strong and reliable server.
2. Distributed Systems:
o No single control center; instead, multiple nodes manage reputation together.
o Harder to build but more scalable (can handle growth) and more reliable (can keep working if
one part fails).

Second-Level Classification – Based on What They Evaluate:

• User-Oriented Reputation Systems:

o Focus on individual users or agents.
o Most P2P reputation systems fall into this category.
• Resource-Oriented Reputation Systems:
o Used in data centers.
o These systems evaluate the reputation of the entire resource site, like a cloud service or
product.

Examples of Real-World Reputation Systems:

• Commercial centralized systems:

o Used by companies like eBay, Google, and Amazon.
 o Evaluate the reputation of sellers or services.
• Academic distributed systems:
o Created mainly for research and P2P networks:
▪ Aberer and Despotovic’s model – for trust management in P2P networks.
▪ Eigentrust (Stanford University) – uses a trust matrix to manage reputation.
▪ PeerTrust (Georgia Tech) – supports e-commerce.
▪ PowerTrust (University of Southern California) – based on Power Law patterns in
internet traffic.
▪ QoS-based Ranking System (Vu et al.) – ranks P2P transactions based on Quality of
Service.

This simplified version preserves all the important points while using clearer and more straightforward
language. Let me know if you want a diagram or summary of Figure 4.36 too.
Here’s a simplified version of Section 11.12: XOAR – Breaking the Monolithic Design of the TCB, with all
key concepts included:

11.12 XOAR – Breaking the Monolithic Design of the Trusted Computing Base (TCB)

Xoar is a modified version of the Xen hypervisor, designed to improve system security.

Security Assumptions:

• The system is managed by trusted administrators.

• Admins don’t have any reason or interest in violating users’ trust.
• Main security threats come from:
o Malicious guest virtual machines (VMs) trying to:
▪ Access or damage other guest VMs’ data.
▪ Exploit vulnerabilities in other guest VMs.
o Bugs in the system’s initialization code (in the management VM).

Key Design of Xoar:

Xoar is built using microkernel principles.

• It is modular, meaning the system is divided into small, isolated components.

Design Goals of Xoar:

1. Keep all features of Xen.

2. Be compatible with existing management tools and VM interfaces.
3. Limit privileges – Each part only has the rights it absolutely needs.
4. Shrink interfaces – Smaller interfaces make it harder for attackers to exploit.
5. Avoid sharing between components unless necessary. If sharing is needed, it must be made clear and
auditable.
6. Limit runtime – Reduce how long each part of the system is active, to shrink the attack window.

These principles aim to break the traditional monolithic design of Xen’s TCB, which is large and complex.

Although this may slightly affect performance, the goal is to minimize this impact.
Types of Components in Xoar (see Figure 11.5):

1. Permanent Components:
o XenStore-State: Stores the complete state of the system.
2. Self-Destructing Components (used only during boot, destroyed before VMs start):
o PCIBack: Manages access to PCI hardware.
o Bootstrapper: Handles the system boot process.
3. Components Restarted on Request:
o XenStore-Logic
o ToolStack: Handles VM creation and management.
o Builder: Starts guest VMs. (Very small, ~13,000 lines of code.)
4. Components Restarted on Timer (to provide drivers):
o BlkBack: Exports to physical storage driver (uses udev rules).
o NetBack: Exports the physical network driver.

Key Security Features:

• XenStore is split into two parts:

o XenStore-State: Contains the data and handles access control.
o XenStore-Logic: Handles processing requests.
• Guest VMs only share access to:
o Builder
o XenStore-State
o XenStore-Logic
Snapshots Instead of Reboots:

• Rebooting ensures a VM starts in a safe state, but it’s slow.

• Xoar uses snapshots to avoid long reboot times:
o Each service VM takes a snapshot when ready to handle requests.
o All system components are snapshotted after they’re initialized and before they talk to other
services or VMs.
o Snapshots use copy-on-write, so data isn’t changed directly—this helps preserve the system
state.