ISO/IEC 21878:2018

INTERNATIONAL ISO/IEC
STANDARD 21878
First edition
2018-11
Information technology — Security
techniques — Security guidelines
for design and implementation of
virtualized servers
Technologies de l'information — Techniques de sécurité — Lignes
directrices pour la conception et l’implémentation sécurisées des
serveurs virtualisés
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
5 Overview of server virtualization . 3
5.1 Types of server virtualization . 3
5.2 Components of a VS . 3
5.3 Technical considerations . 4
5.3.1 General. 4
5.3.2 Exclusions . 4
6 Overview of security threats and risks . 5
6.1 General . 5
6.2 Common threats . 5
6.3 VS-specific risks . 6
6.3.1 General. 6
6.3.2 VM risks . 6
6.3.3 Hypervisor risks . 7
6.3.4 Operational risks related to implementation . 8
6.3.5 Cloud Services risks . 8
7 Recommendations for secure VS lifecycle . 9
7.1 General . 9
7.2 Initial preparation phase . 9
7.3 Planning and design phase .10
7.4 Implementation phase .10
7.5 Disposition phase .10
8 Planning and design phase: security considerations .10
8.1 General .10
8.2 Security considerations and satisfying requirements .11
9 Implementation phase: security checklist .11
9.1 General .11
9.2 Security checklist and vulnerability exposure .12
Annex A (informative) Risk assessment for VSs .14
Annex B (informative) Guidelines for implementing security checklist items in Table 2 .17
Bibliography .22
© ISO/IEC 2018 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO/IEC 2018 – All rights reserved

Introduction
Data centre infrastructures are rapidly becoming virtualized due to increasing deployment of
virtualized servers (VSs) for cloud computing services and for internal IT services. Since VSs are
compute engines hosting many business-critical applications, they are key resources to be protected
in virtualized data centre infrastructure. As VSs are becoming mainstream in typical data centre
infrastructure setups, the secure design and implementation of VSs forms an important element in the
overall security strategy.
The purpose of this document is to provide security guidelines for the design and implementation of VSs.
The motivation for this document is the global trend in enterprises and government agencies deploying
server virtualization technologies within their internal IT infrastructure as well as the use of VSs by
cloud service providers. Hence the target audience is any organization using and/or providing VSs.
The intended goal of this document is to facilitate informed decisions with respect to architecting VS
configurations. Such design and implementation configuration is expected to assure the appropriate
protection for all virtual machines (VMs) and the application workloads running in them in the entire
virtualized infrastructure of the organization.
© ISO/IEC 2018 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 21878:2018(E)
Information technology — Security techniques —
Security guidelines for design and implementation of
virtualized servers
1 Scope
This document specifies security guidelines for the design and implementation of VSs. Design
considerations focusing on identifying and mitigating risks, and implementation recommendations
with respect to typical VSs are covered in this document.
This document is not applicable to: (see also 5.3.2 Exclusions)
— desktop, OS, network, and storage virtualization; and
— vendor attestation.
This document is intended to benefit any organization using and/or providing VSs.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 17788, Information technology — Cloud computing — Overview and vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 17788 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org
3.1
domain
information domain
collection or cluster of virtual machines (3.7) hosted in one or more VSs
3.2
guest operating system
guest OS
operating system that runs within a virtual machine (3.7)
3.3
host operating system
host OS
operating system onto which virtualization software (hypervisor) is installed
Note 1 to entry: Host OS is an optional component of a virtualized server.
© ISO/IEC 2018 – All rights reserved 1

3.4
hypervisor
computer software that creates and runs one or more virtual machines (3.7)
3.5
management subsystem
component of a VS that enables administrators to configure the VS components
3.6
hardware
physical resources including processors, memory, devices, and associated firmware
3.7
virtual machine
VM
software-defined complete execution stack consisting of virtualized hardware (3.6), operating system
(guest OS), and applications
3.8
virtualized server
VS
physical host on which a hypervisor (3.4) is installed to enable execution of multiple virtual machines (3.7)
3.9
virtualized server administrator
VS administrator
person with rights and responsibilities to configure and manage VS components
3.10
virtual machine manager
VMM
all software that enables VMs to run on a virtualized platform which includes the hypervisor, service
VMs, virtual and physical device drivers
3.11
golden image
golden VM image
master copy of disk image of a VM or server with a specific configuration
4 Symbols and abbreviated terms
API Application programming interface
CLI Command line interface
COBIT 5 Control objectives for information and related technologies
CSC Cloud service customer
CSP Cloud service provider
IT Information technology
NFV Network function virtualization
OASIS Organization for the advancement of structured information systems
OS Operating system
2 © ISO/IEC 2018 – All rights reserved

PII Personally identifiable information
SDN Software-defined networking,
SSD Solid state drive
VLAN Virtual local area network
5 Overview of server virtualization
5.1 Types of server virtualization
Server virtualization is the abstraction of the underlying hardware resources to enable multiple
computing stacks (consisting of an OS, middleware and applications) to be run on a single physical host.
A VS is commonly classified along two perspectives.
The first perspective addresses full virtualization versus para-virtualization.
— Full virtualization: The guest OS is unaware that it is in a virtualized platform. The hypervisor
exposes the interface of a hardware device that is physically available to the VM and for which
drivers are available for guest OS, and it completely emulates the behaviour of that device. Emulation
allows the programs running in VMs to use the VM OS drivers that were designed to interact with
the emulated device without installing any special driver or tool specified by the hypervisor vendor.
— Para-virtualization: In this implementation, the hypervisor exposes a device that does not
physically exist, which is just software only, and presents a lightweight interface. However, this
scenario calls for having special drivers in the VM, requiring modification to the guest OS which
becomes para-virtualized-aware. This approach is intended to increase the performance level
of the applications running in the VM, compared to the full emulation approach adopted in full
virtualization.
The second perspective is based on the platform on which the hypervisor is installed. There are two
types of hypervisors:
— Type 1 hypervisors, also known as bare-metal hypervisors, are installed directly over computer
hardware, with no need for an underlying host OS.
— Type 2 hypervisors are hosted on top of a host OS. Type 2 hypervisors are started like a regular
software application before any VMs can be run and controlled.
5.2 Components of a VS
Server virtualization in the context of this document relates to a VS that implements virtualized
hardware components on server-class hardware. It creates a virtualized hardware environment
(virtual machines or VMs) for each instance of a guest OS permitting these environments to execute
concurrently while maintaining the appearance of isolation and exclusive control over assigned
computing resources. Each VM instance supports applications such as file servers, web servers, and
mail servers. Server virtualization can also support client OSs in a virtual desktop or thin-client
environment.
© ISO/IEC 2018 – All rights reserved 3

Virtual Virtual Virtual
machine machine machine
…
Guest OS Guest OS Guest OS
Management
Subsystem
Hypervisor
Host OS (Oponal)
Hardware
Figure 1 — Functional components of a VS
A VS comprises the following functional components as illustrated in Figure 1:
— a hypervisor;
— virtual machine(s);
— hardware;
— host OS (optional);
— other components such as management subsystem(s) for the VS administrator to configure and
manage the VS.
In general, for server virtualization products that are installed onto “bare metal,” the entire set of
installed components constitutes the VS, and the hardware constitutes the platform. Also for products
that are hosted by or integrated into a commercial off-the-shelf (COTS) OS, the components installed
expressly for implementing and supporting virtualization are in the VS, and the platform comprises of
the hardware and host OS.
5.3 Technical considerations
5.3.1 General
This document’s recommendations are applicable to both perspectives of server virtualization as
described in 5.1. From this viewpoint, the security guidelines in this document can be replicated across
a larger scale (for example, in environments with thousands of VS and more).
5.3.2 Exclusions
5.3.2.1 Vendor attestation
A manufacturer or vendor of a product can claim an attestation of conformance to a standard.
4 © ISO/IEC 2018 – All rights reserved

This document provides guidance regarding the design and implementation of existing products and
makes no specific requirements on the virtualization or associated products mentioned.
5.3.2.2 Operating environment
There are specific conditions that are assumed to exist in the operational environment where VS is
deployed and hence not addressed in this document. These assumptions include both practical realities
in the development of the VS security requirements and the essential environmental conditions on the
use of the VS.
— Physical security: Physical security should be commensurate with the value of the VS and the data
it contains.
— Platform integrity: The platform has not been compromised prior to installation of the VS.
— Trusted administrators: VS administrators are trusted to follow and apply all administrator
guidance.
6 Overview of security threats and risks
6.1 General
The threats and risks in a virtualized infrastructure (where the computing nodes are predominantly
VSs) can be classified into two types:
— Common threats: Threats common to all types of IT infrastructures (virtualized or non-virtualized);
— VS-specific risks: Risks that impact the confidentiality, integrity and availability of VSs.
6.2 Common threats
The following threats are commonly faced in virtualization setups in data centre infrastructures or
cloud computing environments, but not specific to just for VSs technology per se.
— Administrator error: An administrator can unintentionally install or configure the VS incorrectly,
resulting in ineffective security mechanisms.
— Data leakage: If it is possible for data to leak between domains when prohibited by policy, then an
adversary on one domain or network can obtain data from another domain. Such cross-domain data
leakage can, for example, cause classified information, corporate proprietary information, or PII
data to be made accessible to unauthorized entities.
— Insecure network configuration: The VS is itself a node of a larger enterprise network and hence
insecure network location and insecure host-level protection can have an impact on all the software
and applications running in it.
— Platform compromise: The hosting of untrusted or malicious domains by the VS can compromise
the security and integrity of the platform on which the VS executes.
— Poor cryptography key management: When the keys of the cryptographic applications are stored
in insecure locations, the security of encrypted data can easily be compromised.
— Third-party software: Vulnerabilities in third-party software used as a VS component (e.g., device
drivers) can compromise the security of an entire VS.
— Unauthorized access: A user can gain unauthorized access to the VS data and VS executable code.
A malicious user, process, or external IT entity can masquerade as an authorized entity in order to
gain unauthorized access to VS data or VS resources.
© ISO/IEC 2018 – All rights reserved 5

— Unauthorized modification: Malware running on the physical host can undetectably modify
VS components while the components are in execution mode or at rest. Likewise, malicious code
running within a VM can modify VS components.
— Unauthorized update: A malicious program can gain administrative privileges to perform an
unauthorized update that can compromise the integrity of one or more VS functions.
— VMM compromise: Failure of security mechanisms can lead to unauthorized intrusion into or
modification of the VMM or bypass of the VMM altogether.
— Weak cryptography: A threat of weak cryptography can arise if the VMM does not provide sufficient
entropy to support security-related features that depend on entropy to implement cryptographic
algorithms.
6.3 VS-specific risks
6.3.1 General
VS-specific risks are examined in further detail here. Moving to a virtualized environment brings a
unique set of risks not present in traditional IT environment. These risks include:
— VM risks;
— hypervisor risks;
— operational risks related to implementation;
— cloud services risks.
6.3.2 VM risks
The use of VMs can either introduce new and unique security risks or lead to more significant impacts
for particular known risks. Consequently, as part of assessing the risks of virtualization, the following
should be considered:
— VM sprawl: Uncontrolled proliferation of VMs can lead to an unmanageable condition of unpatched
and unaccounted for machines. In a traditional IT environment, physical servers are procured. This
requirement enforces effective controls, because change requests should be created and approved
before hardware and software can be acquired and connected to the data centre. In the case of
virtualized environments, however, VMs can be allocated quickly, self-provisioned, or moved
between physical servers, bypassing the conventional change management process. Without an
effective control process in place, VMs and other virtual systems with unknown configurations can
quickly proliferate, consuming resources, degrading overall system performance, and increasing
liability and risk of exposure. Because these machines are typically not readily detectable or visible,
they cannot be effectively monitored or tracked for the application of security patches or effectively
investigated when a security incident occur.
— Sensitive data within a VM: Data confidentiality within VMs can be easily compromised, because
data can easily be transported and tampered with. Although VM images and snapshots provide a
way to deploy or restore virtual systems quickly and efficiently across multiple physical servers,
this capability means that copies of images and snapshots can be removed from a data centre easily.
This removal includes current memory contents, which are not intended to be stored on the storage
devices themselves. Therefore, in a virtualized environment, it is no longer possible to assure that
sensitive data such as system password files is safe from unauthorized personnel. This sensitive
information and the VM containing it can be moved easily, making it possible to compromise a
VM and reintroduce it into the system later. Without proper controls, security loopholes can exist
through the inadvertent capture, storage, and deployment of sensitive information, including rogue
virtual instances of critical services. Potential hackers or disgruntled staff can gain access and insert
malicious code into VM images and snapshots, which can then be rapidly deployed throughout the
environment, resulting in its compromise.
6 © ISO/IEC 2018 – All rights reserved

— Security of offline and dormant VMs: Dormant and offline VMs can eventually deviate so far
from a current security baseline that simply powering them on introduces massive security
vulnerabilities. Dormant or offline VMs can easily be overlooked and left out of the execution of
important security procedures. For example, it is likely that a dormant VM is not updated with
the latest security patches. As a result, when the VM is run again, it can be exposed to the latest
vulnerabilities. Similarly, dormant VMs can also lack up-to-date access control policy or be excluded
from essential security monitoring functions, which can cause security loopholes in the virtualized
environment. Critical infrastructure, management, and security services are increasingly packaged
and delivered as virtual appliances. These appliances require proper classification and treatment to
prevent rogue instances of non-compliant policies and configurations. In addition, if these appliances
are not limited to specific clusters of physical hosts or storage, exposure to risk can increase.
— Security of pre-configured (golden image) VM/active VMs: Virtual machines existing as files
on a virtualization platform can easily be transported via physical means or through a network.
This can lead to unauthorized access, resulting in machine configuration changes or viral payload
injection into the platform’s virtual disks. Unauthorized access through malicious interception can
compromise these VM images. Often, golden VM images are made, making it easy to deploy cloned
copies and to compromise the integrity of the virtualized environment.
— Lack of visibility into and control over virtual networks: Software-defined virtual networks
can cause network security breaches, because traffic over virtual networks cannot be visible to
security protection devices on the physical network. Traditional IT infrastructure network traffic
is monitored and secured as data flows across actual routers, switches, and firewalls. On a virtual
network, this can become unmanageable unless the traffic is explicitly redirected to physical or
virtual appliances for monitoring. Virtual network configuration can be modified with relative
ease; this capability can cause conflicts with actual physical network security policies.
— Resource exhaustion: Uncontrolled physical resource consumption by virtual processes can
lead to reduced availability. Resource-intensive software tends to exhaust resources in a physical
server when it is implemented in multiple VMs. For example, anti-virus and other security software
interrupt every call to disk or memory in order to monitor and prevent security incidents such as
hacking or viruses. When anti-virus software runs simultaneously in different VMs on the same
physical server, it can potentially consume the host resource pool. Similarly, automated OS patches
on a large group of VMs can have the same effect.
6.3.3 Hypervisor risks
A risk factor unique to virtual environments is the hypervisor. The 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 are related
to the use of hypervisor:
— Securing the hypervisor: It 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.
— A hypervisor can control all aspects of VM operation, so it is a natural target of malicious
attacks. Securing a hypervisor is vital, yet more complex than it seems. In an attack known as
“hyper-jacking,” malware that has penetrated one VM can attack the hypervisor. When a guest
VM attempts this attack, it is often called a “guest VM escape,” because the guest VM breaks out
of its isolated environment and attacks the host hypervisor. Once compromised, the hypervisor
can be used as an attack platform to compromise guest VMs hosted by it or other hypervisors
with which it can be able to interact.
— All hypervisors in common use include a very rich set of remote management API and hence their
attack surfaces are increased. Calling tools/scripts/applications not adequately implementing
© ISO/IEC 2018 – All rights reserved 7

identity and access control, especially if a hypervisor uses locally managed service accounts,
present greater risks.
— Unauthorized access to hypervisor Administrative access controls to the hypervisor can be
insufficient to protect against potential hacker attacks.
— The hypervisor can be accessed using a local (host level) authentication scheme or enterprise
level authentication scheme. Local authentication schemes especially those using passwords
can provide only weak authentication and cannot support robust enterprise security policies
and associated authentication schemes.
— Hypervisors in a data centre can be managed individually or centrally through an enterprise
virtualization management software. In the latter approach, if the management software
communicates with hypervisor without adequate integrity and network level protections,
attackers can exploit this situation to gain unauthorized administrative control to multiple
hypervisor hosts.
6.3.4 Operational risks related to implementation
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 can be affected or ignored, while newly introduced features or functions can expose
the environment to additional risks. The following are the security risks related to changes in operation
procedures.
— Account or service hijacking through the self-service portal: Portal vulnerabilities can lead to
privilege escalation attacks. A self-service portal is typically used to delegate specific parts of virtual
infrastructure provisioning and management to assigned self-service administrators. Liberal use of
self-service portals in cloud computing services increases susceptibility to security risks, including
account or service hijacking.
— Workloads of different trust levels located on the same server: Ensure that there is sufficient
security segregation of workloads on a physical host. Enterprises can attempt to segregate VMs
of different trust levels on separate host machines. However, that effort is effective only if there is
effective implementation of systems and data categorization, as well as implementation of adequate
network, security, and management controls. VMs of lower trust levels typically have weaker
security controls than VMs of higher trust levels. Those VMs can therefore be easier to compromise,
potentially providing a stepping-stone to higher-risk, more sensitive VMs on the same host. It is
important to have consistency in the levels of protection for VMs of different trust levels across
physical and virtual environments. In short, hosting VMs of different trust levels on the same host
tends to reduce overall security for all components to that of the least-protected component.
6.3.5 Cloud Services risks
Enterprise IT personnel can interact with virtualization technologies when they are using cloud
services from CSPs. In such cases, it can introduce additional risk factors, including the following:
— Risk due to cloud service provider APIs: A hybrid (private/public) cloud virtualization
implementation can pose security risks due to account/authentication federation. CSPs expose a set
of software interfaces or APIs that an enterprise can use to manage and interact with cloud services.
Such interfaces when not designed properly to protect against accidental and malicious attempts to
circumvent enterprise policies, can pose additional risks.
— Use of VMs within cloud services: Many CSPs offer services that are based on VM functionality.
As outlined in ISO/IEC 19941, the security requirements and the responsibilities for implementing
these requirements vary depending on the cloud service capabilities type. For example, in an
infrastructure cloud capabilities type of cloud service, the CSC can be responsible for configuring
and implementing various aspects of VM security (and in some instances, hypervisor security),
whereas some of this responsibility can fall to the CSP in the case of a platform cloud capabilities
type of cloud service.
8 © ISO/IEC 2018 – All rights reserved

— General cloud services security: When securing VMs in a cloud environment, other aspects of
security should also be considered. Further information on this topic can be found in ISO/IEC 19086-
4, ISO/IEC 19941, ISO/IEC 27017 and ISO/IEC 27018.
7 Recommendations for secure VS lifecycle
7.1 General
The objectives of secure VS design and implementation are to assure the confidentiality, integrity
and availability of information processed and stored in the virtual hosts. Secure deployment of VSs
requires several strategic tasks to be carried out in all the four typical phases of deployment, i.e., initial
preparation, planning and design, implementation and disposition. These tasks are described in 7.2 to
7.5. In addition, Clause 8 provides security issues for consideration, and Clause 9 provides a checklist
for the implementation of security of VSs.
When an organization embarks on a server virtualization initiative, it should ensure that its
information security governance framework also applies to its virtualized IT systems and services.
Delivering enterprise stakeholder value through virtualization initiatives requires good governance
and management of IT assets. Organizations that choose to virtualize should opt for a comprehensive
framework, such as COBIT 5, that enables them to meet their technology goals and deliver value.
An integral part of security governance framework is the risk assessment process. The risk assessment
process in the context of a virtualized infrastructure consists of identifying the risks (see Clause 6),
estimating the likelihood of their occurrence and assessing their impact in order to establish appropriate
controls to address them before implementation. ISO/IEC 27001 and ISO/IEC 27005 provide more
details on a process that can be used or adapted by enterprises of various sizes and complexities. Some
of the key elements to be considered when performing a risk assessment for virtualized infrastructure
can be found in Annex A.
An organization should establish policies and procedures that include an audit program geared to
virtual IT systems. Roles and responsibilities of system administrators and users should be clearly
defined and documented. An organization should govern a virtualization initiative by evaluating,
directing, and monitoring every step in the process. In this context, IT managers should assure that
their teams follow virtualization policies and procedures holistically across the enterprise.
7.2 Initial preparation phase
During the initial phase, an organization should identify virtualization needs, providing an overall vision
for how virtualization solutions support its mission; creating a high-level strategy for implementing
virtualization solutions; developing virtualization policy and identifying platforms and applications
that can be virtualized; and specifying business and functional requirements. The preparation work for
the design and the implementation of VS security involves the following stages:
— asset identification;
— requirements collection;
— review of requirements;
— evaluation of technical options and constraints;
— evaluation of existing designs and implementations with respect to security requirements.
ISO/IEC 27033-2 provides more details on how these five stages provide inputs to the design
and implementation of network security; however, these stages are also applicable to the design,
implementation and disposition of VS security.
© ISO/IEC 2018 – All rights reserved 9

7.3 Planning and design phase
During the planning and design phase, an organization should provide necessary guidance for specifying
and evaluating the technical characteristics of the virtualization solution and related components,
including authentication methods and cryptographic mechanisms to protect communications. Major
considerations include selection of virtualization software including the security functionality of the
hypervisor and its assurance level, storage system, network topology, bandwidth availability and
deployment environment (cloud service or on premises). In particular, the assurance is required for
addressing all categories of risk in 6.3.3 and 6.3.5 as applicable to the deployment environment. As
an example, the set of certified hardware platforms on which the targeted hypervisor can be run and
the hardware support for virtualization by those platforms are key factors in reducing the runtime
vulnerabilities of the hypervisor. The design should also take into account the appropriate logical
segregation of instances that contain sensitive data.
The management consoles or their equivalent that are part of hypervisor design should support secure
communication protocols. Separate authentication should be established for application/server, guest
OS, hypervisor, and host OS to provide different layers of security and protection. Access control policies
for VS and VMs should be formulated. An organization should also define and document processes for
handling incidents that involve virtualization solutions.
Security considerations for planning and design phase are described in 8.2.
7.4 Implementation phase
During implementation, an organization should assure that sound security practices are established
through extensive assessment of the vulnerability of the virtualization components. The underlying
virtualization platform should be hardened using vendor-provided guidelines and/or third-party tools.
In a virtualized environment, robust key management is essential to access control and proof of
ownership for both data and keys. Role-based access policies should be enforced to enable segregation
of duties, thereby facilitating proof of governance. Proper data governance measures are required to
identify, track, and control where data instances containing sensitive assets reside at any given time.
The hypervisor should have introspection capabilities to monitor VM behaviours and configuration
capabilities to enforce VM operations for conformance to chosen security policies. Proper encryption
of VM files is required to significantly reduce the risk associated with unauthorized user access to
physical servers and storage containing sensitive data. Implementation plan should include tasks such
as initial and on-going configuration review and security testing for side channel vulnerabilities so
that data leakage and unauthorized disclosure of sensitive data are prevented. Automated tools for
timely patching of hypervisor vulnerabilities and monitoring of critical configuration files need to be
considered at this phase.
A security checklist for implementation phase is described in 9.2.
7.5 Disposition phase
The consideration for the disposition phase should begin early in the lifecycle for the secure deployment
of VSs. During the disposition phase, tasks should be clearly defined as regards sanitizing media
before disposition. The VM retirement process should prevent data leakage and breaches, including
shredding or revocation of keys associated with encrypted VMs. Periodic internal and external audits
of the virtualized environment facilitates early identification and mitigation of weaknesses and
vulnerabilities.
8 Planning and design phase: security considerations
8.1 General
The security considerations that enable the recommendations to be carried out for planning and design
phase (7.3) are given in Table 1. A brief description of each security consideration is also given in the table.
10 © ISO/IEC 2018 – All rights reserved

8.2 Security considerations and satisfying requirements
Table 1 — Security considerations (Planning and design phase)
No. Security consideration Description
1 Can/Is the VM be isolated? As basic functionality, the VMM should support a security policy
that mandates no information transfer between VMs. Configure VMs
such that each executes in its own space and does not need to share
resources and data with other VMs resident in the VS.
2 Is the integrity of the VMM in Integrity is a core security objective for VS. To achieve system integrity,
the VS taken care of? the integrity of each VMM component should be established and
maintained. This objective concerns only the integrity of the VS —
not the integrity of software running inside of VMs or of the physical
platform. The overall objective is to assure the integrity of critical
components of a VS. Ensure that VMM is not modified or bypassed so
that its ability to enforce isolation of VMs is not compromised.
3 Is the integrity of the platform The integrity of the VMM depends on the integrity of the hardware
taken care of? and software on which the VMM relies. Although the VS does not have
complete control over the integrity of the platform, the VS should as
much as possible try to assure that no users or software hosted by the
VS is capable of undermining the integrity of the platform. Ensure the
integrity of the hardware (and optionally the host OS) on which the
VS components are installed, since if the integrity of the platform is
compromised, the entire VS can be compromised.
4 Is the access control for Only authorized administrators should exercise management
management functions in the VS funct
...