Risk Analysis and Mitigation in Virtualized Environments

EAI Endorsed Transactions on
Risk Analysis and Mitigation in virtualized environment
02 -04 2015 | Volume 1 | Issue __ | e_
EAI Endorsed Transactions
On Risk Analysis and Mitigation in Virtualized Environments
Editorial
1
Risk Analysis and Mitigation in Virtualized Environments
Abstract
Virtualization technology is extensively used across almost all IT departments today as it allows you
to increase your network capacity without significantly increasing your capital investment. But with
the advent of virtualization, you might ask whether your current security investments are still valid.
Will proven strategies continue to work? If they do, are they just as effective? What about all the tools
you have invested in? Perhaps the best way to answer these questions is to consider the changes that
virtualization will bring and how it impacts the core of your information technology. The objective of
this paper is to outline a risk analysis and discuss about mitigation techniques in such virtualized
environments.
1.0 Introduction
Virtualization has made a dramatic impact in a
very short time on IT and networking and has
already delivered huge cost savings and return
on investment to enterprise data centers and
cloud service providers. Typically, the drivers
for machine virtualization, including
multitenancy, are better server utilization, data
center consolidation, and relative ease and speed
of provisioning. Cloud service providers can
achieve higher density, which translates into
better margins. Enterprises can use
virtualization to shrink capital expenditures on
server hardware as well as to increase
operational efficiency.
Server virtualization is the masking of server
resources, including the number and identity of
individual physical servers, processors, and
operating systems, from server users. The server
administrator uses a software application to
divide one physical server into multiple isolated
virtual environments. The virtual environments
are sometimes called virtual private servers, but
they are also known as guests, instances,
containers or emulations.
Virtualization brings significant value to
business managers and engineers attempting to
keep pace with business pressure for additional
servers. It enables maximum use of hardware
resources while introducing an increased
flexibility in how organizations design and
implement new solutions. However, it also
introduces new security concerns. Until
recently, organizations had to leverage security
controls not specifically designed to protect
virtual environments.
As enterprises embark on their virtualization
journeys, it is critical to review existing
processes and develop strategies to address
security risks across physical and virtual
environments in order to ensure compliance and
security visibility in the data center. In that view
the objective of this paper is stress on the
analysis and mitigation of common risks
observed in virtual environments.
In the next section we shall discuss the overview
of a virtualization technology, section 3 shall
discuss architecture of server virtualization and
then section 4 emphasizes in identifying the
risks in virtual environment, finally section 5
will discuss risk assessment and mitigation
techniques in the virtual environment.

Siddharth Coontoor
2
2.0 Overview of Virtualization
Technology
Server virtualization allows multiple operating
systems and applications to run concurrently on
a single hardware. The OSs run independent of
each other in isolated environments (the VMs).
A virtualization layer is required to run on the
computer’s OSs as an application or service to
create multiple VM environments. OSs and
applications running in a VM can access the
CPU, memory, and disk and network resources
that are similar to a physical computer.
Figure 1: Virtual Server
The virtual server divides physical resources
into virtual resources called virtual machines as
seen in Figure 1. In this way virtualization adds
a layer of abstraction between two layers in that
computer system. The layer of abstraction is a
software layer between the hardware and the
guest operating systems. The layer acts as a
resource manager to enable the sharing of
processing power and memory. This software is
called a virtual machine monitor (VMM) or
hypervisor. VMMs virtualise the hardware of a
physical machine and partition it into multiple,
logically separated VMs. The VMM monitors
everything that happens inside a VM, and it
enforces resource management policies on the
VM. Multiple operating systems (OSs) can
coexist on the same virtual machine in isolation
from one another and can operate
simultaneously on a single server.
Virtualization in a distributed environment is the
basis for grid computing and cloud computing
supplying a computing infrastructure as a utility,
on-demand service. Virtualization can be
categorised into three areas:
Storage virtualization — Virtualizes the
physical storage from multiple network storage
devices so that they appear to be a single storage
device. In general, ‘virtualization’ refers to
server virtualization.
Network virtualization — Combines
computing resources in a network by splitting
the available bandwidth into independent
channels that can be assigned to a particular
server or device in real time.
Server virtualization — Hides the physical
nature of server resources, including the number
and identity of individual servers, processors
and OSs from the software running on them.
The term workload is increasingly used to
describe the a vast array of virtualized
resources. For example, a virtual machine is a
type of workload. While VMs are the
predominant virtualization technology
implemented today, there are a number of other
workloads to consider, including application,
desktop, network, and storage virtualization
models.
3.0 Architecture of Server
Virtualization Technology and
Identification of critical assets
Server virtualization allows multiple operating
systems and applications to run concurrently on
a single hardware. The OSs run independent of
each other in isolated environments (the VMs).
A virtualization layer is required to run on the
computer’s OSs as an application or service to
create multiple VM environments. OSs and
applications running in a VM can access the
CPU, memory, and disk and network resources
that are similar to a physical computer.
Figure 2: Server Virtualization Architecture

3
Figure 2 shows architecture of server
virtualization. As seen in the figure there are
four major components in the virtualization
technology, they are as follows:
 Physical hardware - Physical machine on
which the VM environments reside. The
number of VMs that can be supported on a
single physical machine depends on the
hardware configuration and specifications.
 Operating system Layer - Primary OS on
the physical machine. The virtualization
layer resides on this OS.
 Virtualization layer - Virtualization
software that co-ordinates with the host OSs
for requests from VMs regarding CPU time,
physical memory, disk read and write,
network input/output (I/O), etc. The
virtualization software is called hypervisor.
 Virtual machine - Independent and isolated
environment created by the virtualization
software. OSs can run VMs independent of
each other.
 Guest operating systems - The OSs
installed on VMs. These run on the host OS.
Virtualization technology allows multiple
VMs with heterogeneous guest OSs to run in
isolation, side by side on the same physical
machine. The VMs have their own virtual
hardware (e.g., CPU, RAM, disks, network
cards) on which the guest OSs and
applications are loaded. The guest OSs
perform consistently, irrespective of the
physical components.
The virtualization software mentioned earlier is
known as the hypervisor. The hypervisor plays
an important role in virtualization technology.
Figure 3: View of Hypervisor
It intercepts the hardware resource requests
from the virtual machines that reside on it and
translates the requests to a format that can be
understood by the physical hardware. Similarly,
the requests from the physical hardware are
translated by the hypervisor so that the virtual
machines can understand. This way the
hypervisor decouples the VMs from the physical
hosts by introducing a layer of abstraction
between the VMs and the physical hardware
layer.
Based on the architecture of the virtualized
server and the services it would provide, it
would be essential to identify critical assets
whose working is important to the business.
Similar to traditional risk assessment
approaches, the first step is to identify the assets
that are important to business. Nest step, would
be to identify the risks associated with these
assets and their associated vulnerabilities.
The critical assets in a virtualized environment
are as follows:
 Physical server
 Host Operating System
 Hypervisor
 Hypervisor Management tools and API
 Virtual Machines
 Network
 Storage
4.0 Identifying Risk in Virtualized
Environments
While virtualization may provide a number
functional and operational benefits, moving to a
virtual environment doesn’t alleviate the risks
which existed on the physical systems, and may
also introduce new and unique risks. Therefore
as a part of risk assessment, it is important to
identify the virtualization server as an important
asset and take into consideration risks associated
with it. The following are the most common
risks associated with a virtualized servers

Siddharth Coontoor
4
identified by virtualization vendors and stake
holders.
Risk 1 - VM Sprawl
Uncontrolled proliferation of VMs can lead to
an unmanageable condition of unpatched and
unaccounted for machines.
Risk 2 - Sensitive Data within a VM
Data confidentiality within VMs can be easily
compromised, because data can be easily
transported and tampered with.
Risk 3 - Resource Exhaustion
Uncontrolled physical resource consumption by
virtual processes can lead to reduced
availability.
A risk factor unique to virtual environments is
the hypervisor. Hypervisor is the software
and/or firmware responsible for hosting and
managing VMs. It provides a single point of
access into the virtual environment and is also
potentially a single point of failure. A
misconfigured hypervisor can result in a single
point of compromise of the security of all its
hosted components. It does not matter how
individual VMs are hardened a compromised
hypervisor can override those controls and
provide a convenient single point of
unauthorized access to all the VMs. The
following security risks related to the use of
hypervisor should be considered by those
planning to use or currently using virtual
technologies:
Risk 4 - Hypervisor Security
Hypervisor security is the process of ensuring
that the hypervisor, the software that enables
virtualization, is secure throughout its life cycle,
including development, implementation,
provisioning, and management.
Risk 5 - Unauthorized Access to Hypervisor
Administrative access controls to the hypervisor
may not be adequate to protect against potential
hacker attacks.
Compared to traditional IT environments,
virtualization of IT systems inevitably leads to
changes in operational procedures. As a result,
some common defence in depth practices used
in securing physical servers may be affected or
ignored, while newly introduced features or
functions may expose the environment to
additional risks. The following security risks
related to changes in operation procedures
should be considered:
Risk 6 - Account or Service Hijacking
Through the Self-Service Portal
Portal vulnerabilities can lead to privilege
escalation attacks.
Risk 7 - Workloads of Different Trust Levels
Located on the Same Server
Ensure that there is sufficient security
segregation of workloads on a physical host.
Some enterprise infocom personnel may elect to
apply virtualization technologies through
outsourcing services from cloud service
providers. In such cases, it may be necessary to
consider additional risk factors, including the
following.
Risk 8 - Risk Due to Cloud Service Provider
APIs
A hybrid (private/public) cloud virtualization
implementation can pose security risks due to
account/authentication federation.
5.0 Risk Assessment and
Mitigation
Once risks have been identified as in the above
section, it is important that a risk table be
maintained for the risks related to the virtualized
server as shown in Appendix A1.
The risk table maintains details about the risk
like Risk name, description, relevant security
aspect(confidentiality, integrity, availability),
risk governance area, vulnerabilities that lead to
this risk, affected assets.

5
The risk table helps enlist vulnerabilities
associated to that risk. Based on the risk the risk
table for each risk is as follows:
Risk name VM Sprawl
Relevant Security
Aspect
Confidentiality/Integrity/Av
ailability
Relevant Security
Governance Risk Area
Architectural and
configuration risk
Vulnerabilities
associated with the risk
 Proper policy and
control processes to
manage VM lifecycle
do not exist.
 Placement / zoning
policies or enforcement
of where a dormant VM
can instantiate or reside
do not exist.
 A discovery tool for
identification of
unauthorized VMs does
not exist.
Affected Assets VM
Risk name Sensitive Data Within a VM
Relevant Security
Aspect
Risk to confidentiality and
integrity
Relevant Security
Configuration risk
Vulnerabilities
 VM images and
snapshots are not
treated the same way
as the sensitive data
they contain. They
are not protected
from unauthorized
access, modification,
duplication, and
replacement
 Policies and procedures
to restrict storage of
VM images and
snapshots do not exist,
including:
Formal change
management processes
that govern image
creation, security,
distribution, storage,
use, retirement, and
destruction
Monitoring and control
of stored images and
snapshots, including
activities logging
Affected Assets VM & Storage
Risk name Resource Exhaustion
Relevant Security
Aspect
Risk to availability
Relevant Security
Architectural and hypervisor
software risk
Vulnerabilities
 Servers can be
burdened by
concurrent
execution of
resource-intensive
software such as
anti- virus software
on multiple VMs.
 Simultaneous
automated
operating system
patches on a group
of VMs can create
an enormous excess
strain on a common
storage resource.
Affected Assets VM
Risk name Hypervisor Security
Relevant Security
Aspect
Risk to confidentiality,
integrity, and availability
Relevant Security
software risk
Vulnerabilities
 Hypervisor
configuration may
not be hardened to
reduce areas of
vulnerability, such
as unused services.
 Vendor-
recommended best
practices have not
been adopted.
 Unused physical
hardware devices
are connected, and
clipboard / file-
sharing services are
not disabled.
 Vendor security
bulletins / alerts are
not implemented
promptly.
 Hypervisor self-
integrity checks (or
the equivalent) are

Siddharth Coontoor
6
not conducted upon
boot-up.
 Ongoing
monitoring,
including analysis
of hypervisor logs,
does not occur.
 The attack surface
is further increased
through
uncontrolled use of
hypervisor
management APIs
by IT / DevOps
tools and scripts
and other
infrastructure
technologies.
Affected Assets Hypervisor
Risk name Unauthorized Access to
Hypervisor
Relevant Security
Aspect
Relevant Security
Architectural, hypervisor
software, and configuration
risk
Vulnerabilities
 Access to the
virtualization layer
is not restricted as
with any sensitive
OS (i.e., using
console access
restricted by
firewalls).
 The hypervisor may
not support role-
based access
control of
administrative
responsibilities.
 Additional third-
party tools designed
to provide tight
administrative
control are not
deployed.
 Separate
authentication is not
used to restrict
access.
 Hypervisor
management APIs /
CLIs are not
adequately
protected.
 A separate
“management
LAN” is not
deployed to manage
access to
hypervisors.
 Remote
management of
hypervisors is not
disabled.
 Administrative
interfaces are
accidentally
exposed through
network
configuration errors
and lack of change
management
procedures.
Affected Assets Hypervisor, Management
tools and API
Risk name Account or Service
Hijacking Through the Self-
Service Portal
Relevant Security
Aspect
confined to the designated
virtual environment
Relevant Security
software risk
Vulnerabilities
 Strong authentication
control is lacking.
 Policy governing the
creation and use of self-
service portals does not
exist.
 Policy-based self-
service portal
management is not used.
 Unauthorized activity is
not proactively
monitored.
 Account management
(e.g., password reset
sent in clear text) is
“relaxed.”
Affected Assets Applications, VMs, and
virtualization platform

7
Risk name Workloads of Different
Trust Levels Located on the
Same Server
Relevant Security
Aspect
Relevant Security
Architectural and
configuration risk
Vulnerabilities
 VMs of different trust-
levels are hosted on or
migrated to the same
physical server (host).
 Physical or logical
software-defined
networks for VMs of
different trust levels are
not segregated.
 Physical and virtual
firewalls are not
deployed to isolate
groups of VMs from
other hosted groups, for
example, production
from development
systems or development
from other cloud-
resident systems.
 Virtual desktop
workloads are not
isolated from rest of the
physical data center.
 Administrative
separation of duties may
not be implemented,
allowing unauthorized
changes or accidental
misconfiguration that
violates the logical
zoning.
Affected Assets VMs on physical server
Risk name Risk due to Cloud Service
Provider API
Relevant Security
Aspect
Relevant Security
Architectural and
configuration risk
Vulnerabilities
 The cloud service
provider’s API set is not
secured.
 Data transmitted or
stored in the cloud is
not protected by
encryption.
 Strong authentication /
access control is not
implemented for
external systems.
 Identity and credential
federation, such as
Active Directory
services or another
LDAPv3 directory, is
not used. Traffic is not
transmitted via a private
/ out-of-band encrypted
channel that is separate
from normal internal
traffic.
 Security, compliance,
and governance controls
and monitoring are not
consistently enabled.
Affected Assets Security of Hybrid
Environment
The risk table helps enlist the vulnerabilities
associated with each risk scenario based upon
which the impact and likelihood can be derived
that would finally form a risk matrix.
As vulnerabilities are enlisted and risk
calculated for them, suitably mitigation
techniques for these vulnerabilities can be
derived which would help calculate the residual
risk.
The likelihood rating is provided in Appendix
A2, which provides the rating notation for
creating risk matrix. Similarly Appendix A3
provides impact rating for CIA compromise and
Appendix A4 provides risk matrix defining the
risk levels.
The risk evaluation is based on the likelihood of
a particular vulnerability being exploited and the
impact it would have on the business.

Siddharth Coontoor
8
Vulnerability Likelihood
(See
Appendix A2)
Impact Due
to
Confidentialit
y
Compromise
(See
Appendix A2)
Impact Due
to
Integrity
Compromis
e (See
Appendix
A2)
Impact Due
to
Availability
Compromis
e (See
Appendix
A2)
Evalu
ate
Risk
Level
(See
Appen
dix
A3)
Risk
Treatment
Control to be
implemented
Evaluate
Residual
Risk
Level
(See
Appendix
A3)
Type of Risk: 1 – VM Sprawl
Asset exposed to risk: VM
Lack of effective
control process to
manage VM lifecycle
Low Low Low Low 1 Put effective
policies,
guidelines, and
processes in place
to govern and
control VM
lifecycle
management,
including self-
service and
automated scripts /
DevOps tools.
Lack of placement / zoning
policies or enforcement
of where a dormant VM
can instantiate or reside
Low Low Low Low
1
Lack of discovery tool to
identify unauthorized VMs
Low Low Low Low 1
Type of Risk: 2 – Sensitive Data in VM
Asset exposed to risk: VM and Storage
VM images and snapshots
are not treated in the same
way as the sensitive data.
Medium High High Low 4 Encrypt data stored
on virtual and
cloud servers to
make it unreadable.
Develop policies to
restrict storage of
VM images and
snapshots.
1
Policies and processes are
not in place to control
storage of VM images and
snapshots.
Low High High Low 3 1
Type of Risk: 3 – Resource Exhaustion
Asset exposed to risk: VM
Servers are burdened by
concurrent execution of
resource-intensive software.
High Low Low High 5 Implement
operating
procedure that
detects VMs that
are throttled due
to resource
exhaustion and
puts a remedy in
place instantly.
2
Simultaneous OS automated
patching on a group of VMs
causes enormous access strain
on a common storage
resource.
Medium Low Low High
4 2
Type of Risk: 4 – Hypervisor Security
Asset exposed to risk: Hypervisor
Configuration of
hypervisor may not be
hardened to reduce areas
of vulnerabilities.
Medium Medium Low Medium
3 Harden the
hypervisor’s
configuration to
reduce areas of
vulnerability.
Put vendor-
provided best
practices in place
where applicable.
2
Vendor- recommended best
practices are not adopted.
Low Low Low Low 1
Unused physical hardware
devices are connected.
Clipboard / file-sharing
services are not disabled.
Low Low Low Low
1

9
(See Appendix
A2)
Impact Due to
Confidentialit
y Compromise
(See Appendix
A2))
Impact Due
to
Integrity
Compromis
e (See
Appendix
A2)
Impact Due
to
Availabiliy
Compromis
e (See
Appendix
A2)
Evaluate
Risk
Level
(See
Appendix
A3)
Risk
Treatment
Control to
be
implemente
d
Evaluate
Residual
Risk
Level
(See
Appendix
A3)
Vendor security bulletins
/alerts are not subscribed
to. Security updates are
not implemented
promptly
Low Low Low Low
1 Disconnect
unused
physical
hardware
devices and
disable
clipboard or
file-sharing
services.
Use a
hypervisor
integrity
monitoring
technology,
for example,
Intel Trusted
Platform
Module/Trust
ed Execution
Technology.
Self-integrity checks or
equivalence are not
conducted upon boot-
up to confirm whether
or not hypervisor has
been compromised.
Low Low Low Low
1
Ongoing monitoring
including
analysis of hypervisor
logs does not occur.
Medium Low Low Low
2 1
Attack surface is further
increased through
uncontrolled use of
hypervisor management
APIs by IT/DevOps tools
and scripts and other
infrastructure
technologies.
Medium Medium Medium Medium
3 2
Type of Risk: 5 – Unauthorized Access to hypervisor
Asset exposed to risk: Hypervisor and Management Tools
Access to virtualization
layer is not restricted as
with any sensitive OS.
High High Medium Medium
5 Restrict
access to the
virtualization
layer by
firewalls that
restrict
console
access.
Evaluate
implemented
role based
access control
policies in
order to
ensure that
they are
functionally
correct.
Deploy a
separate
“management
LAN” to
manage
access to
hypervisors.
3
Hypervisor may not
support role-based access
control.
Low Low Low Low 1
Additional third-party
tools that provide tight
administrative control are
not deployed.
Low Low Low Low
1
A separate authentication
is
not used to restrict access.
Low Medium Medium Low 2 1
Hypervisor management
APIs/CLIs are not
adequately protected.
Low Medium Low Low 2 1
Separate LAN
authentication is not used
to restrict access.
Medium High Low Low 4 2
Remote hypervisor
management is not
disabled.
Low High Low High 3 1

Siddharth Coontoor
10
(See
Appendix A2)
Impact Due to
Confidentiality
Compromise
(See Appendix
A2))
Impact Due
to
Integrity
Compromis
e (See
Appendix
A2)
Impact Due to
Availabiliy
Compromise
(See
Appendix
A2)
Evalu
ate
Risk
Level
(See
Appe
ndix
A3)
Risk
Treatment
Control to
be
implemente
d
Evaluate
Residual
Risk
Level
(See
Appendix
A3)
Administrative interfaces
are accidentally exposed
through network
configuration errors and
lack of change of
management procedures
Low Medium Medium Medium
2 Deploy a
separate
“management
LAN” to
manage
access to
hypervisors.
1
Type of Risk: 6 – Account or Service Hijacking through Self- Service Portal
Asset exposed to risk: Privileged access to applications, VM, and Virtualization Platform
Strong authentication
control is lacking.
Low High High Medium 3 Use
administrative
controls
selectively,
based on
users’ roles
and needs.
Enforce
secure
management
of accounts,
identities, and
credentials.
2
Policy governing creation
and use of self-service
portals is lacking.
Low Low Low Low 1
Policy-based management
of self-service portal is not
used.
Low Low Low Low 1
Proactive monitoring of
unauthorized activity does
not occur.
Low Low Low Low 1
Account management is
“relaxed” (e.g., password
reset sent in clear text)
Low High High Low 3 2
Type of Risk: 7 – Workload of Different Trust Levels Located on the Same Server (Commingling of Data)
Asset exposed to risk: VMs in the same physical server
Different VM trust levels
are hosted on to the same
physical server.
High High Medium Low 5 Carefully
design and
implement
access from
each trust
level to
physical and
virtual
management
and security
systems.
Implement
policies and
processes to
categorize
systems and
data
according to
different
security
classifications
.
3
Physical/logical s/w defined-
n/w for VMs of different
trust levels are not separated.
High High Low Low
5 3
Physical and virtual
firewalls
are not deployed to isolate
groups of VMs from other
hosted groups.
Medium Medium Low Low
3 2
Virtual desktop workloads
are not isolated from the
rest..
Low Low Low Low 1
Administrative separation
of duties may not be
implemented, allowing
unauthorized changes or
accidental
misconfiguration that
violates logical zoning.
Low Low High High
3 1

11
The Risk matrix once created, risk evaluation
can be performed and given a point in the scale
of 1-5 as seen in Appendix 3. The risk can also
be mitigated by providing a remediation
technique in "Risk Treatment control to be
implement" and accordingly the risk evaluation
can be done again after mitigation as residual
risk.
Above is the Risk evaluation along with
mitigation techniques for all the risks discussed.
6.0 Conclusion
Inside a cloud, it is difficult to identify where
data is stored and how it is segregated. This lack
of visibility and the ability to control, audit, and
verify poses a number of security and
compliance concerns for IT personnel, end-
users, and regulators. While the cloud
community is still grappling with these
emerging risks, virtualization technologies are
continuing to be rapidly innovated. To manage
such a dynamic risk environment, organizations
(See Appendix
A2)
Impact Due to
Confidentiality
Compromise
(See Appendix
A2))
Impact Due to
Integrity
Compromise
(See
Appendix
A2)
Impact Due to
Availabiliy
Compromise
(See
Appendix
A2)
Eva
luat
e
Ris
k
Lev
el
(See
Ap
pen
dix
A3)
Risk
Treatment
Control to
be
implemente
d
Evaluate
Residual
Risk
Level
(See
Appendix
A3)
Type of Risk: 8 – Risk Due to CSP API)
Asset exposed to risk: Security of the hybrid environment
Cloud service provider API
set is not secured.
Medium Medium Low Low 3 Implement
strong
authentication
and granular
access control
with
encrypted
transmission.
Transmit
Active
Directory
traffic via a
private / out-
of-band
encrypted
channel that is
separate from
normal
Internet traffic
if it is used
across the
Internet.
2
Data transmission is not
protected by encryption.
Low High Low Low 3 2
Strong authentication/
access control is not
implemented for external
systems.
Low Medium Medium Low 2 1
Active Directory traffic is
not transmitted via a
private/out- of- band
encrypted channel
(separated from normal
internal traffic)
Low High High Low
3 2
Identity federation is not
used.
Low Low High Low 3 1
Security, compliance, and
governance controls and
monitoring are not
consistently enabled.
Low Medium Medium Medium 3 1

Siddharth Coontoor
12
should put effective governance and risk
management processes and controls in place to
continually monitor and proactively mitigate the
evolving risks.
7.0 Appendix
A1: Risk Table
Risk name
Relevant Security
Aspect
Confidentiality/Integrity/Av
ailability
Relevant Security
Configuration/Architectural/
Operational
Vulnerabilities
Affected Assets VM/Hypervisor/Network/O
S/Applications/Physical
Server
A2: Likelihood Rating for Vulnerability
Likelihood Rating Evaluation Criteria
High Relevant security control
not in place
Medium Relevant security control in
place but not effective
Low Relevant security control in
place and effective
A3: Impact Rating for CIA Compromise
Impact Rating Evaluation Criteria
High Significant Business
Impact to the enterprise
Medium There is tangible or
intangible loss to
enterprise.
Low There is insignificant loss
due to minor inconvenience
in business operations.
A4: Risk Matrix showing the defined risk
levels
Impact
Likelihood Low Medium High
Low 1
(Insignificant)
2
(Minor)
3
(Medium)
Medium 2
(Minor)
3
(Medium)
4
(High)
High 3
(Medium)
4
(High)
5
(Very
High)
References
[1] http://resources.infosecinstitute.com/chapter-10-
virtualization-security/
[2] https://www.vmware.com/files/pdf/partners/security/mcafe
e-key-security-ent-arch-wp.ion
[3] http://www.isaca.org/Journal/archives/2011/Volume-
1/Pages/Auditing-Security-Risks-in-Virtual-IT-
Systems.aspx
[4] http://www.symantec.com/content/en/us/enterprise/media/s
ecurity_response/whitepapers/threats_to_virtual_environm
ents.pdf
[5] https://www.pcisecuritystandards.org/documents/Virtualiz
ation_InfoSupp_v2.pdf
[6] https://www.vmware.com/pdf/virtualization_consideration
s.pdf
[7] https://downloads.cloudsecurityalliance.org/whitepapers/B
est_Practices_for%20_Mitigating_Risks_Virtual_Environ
ments_April2015_4-1-15_GLM5.pdf

Risk Analysis and Mitigation in Virtualized Environments

Recommended

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Risk Analysis and Mitigation in Virtualized Environments (20)

Recently uploaded (20)

Risk Analysis and Mitigation in Virtualized Environments