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

associated with the risk 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

associated with the risk 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

associated with the risk 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

Risk to confidentiality,

integrity, and availability

Relevant Security


Architectural, hypervisor

software, and configuration

risk

Vulnerabilities

associated with the risk 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

associated with the risk 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

associated with the risk 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

associated with the risk

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)

Evaluate 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)

Evaluate 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)

Evaluate Risk

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

associated with the risk

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

https://www.vmware.com/pdf/virtualization_considerations.pdf

https://www.vmware.com/pdf/virtualization_considerations.pdf