DRAFT

          VIRTUAL COMPUTING

SECURITY TECHNICAL IMPLEMENTATION GUIDE

            Version 1, Release 0.1




      ...
VIRTUAL COMPUTING V1R0.1, DRAFT                                             DISA Field Security Operations
13 April 2007  ...
VIRTUAL COMPUTING V1R0.1, DRAFT                                                                                     DISA F...
VIRTUAL COMPUTING V1R0.1, DRAFT                                                                               DISA Field S...
LIST OF TABLES

TABLE 1.1. VULNERABILITY SEVERITY CODE DEFINITIONS .......................3


                            ...
This page is intentionally left blank.
1.   INTRODUCTION

A core mission for the Defense Information Systems Agency (DISA) Field Security Operations
(FSO) is to ...
This document contains a set of principles and guidelines that serve as the basis for establishing
Virtual Computing envir...
1.5 Vulnerability Severity Code Definitions

   Category I              Vulnerabilities that allow an attacker immediate a...
This page is intentionally left blank.
2.   SERVER VIRTUALIZATION

2.1 Introduction

The term virtualization refers to the method of disconnecting the operating ...
AMD's is Pacifica. These extensions address the parts of x86 that are difficult to virtualize,
providing additional suppor...
The Type II VMM runs as an application on a host operating system and relies on the host
operating system for memory manag...
Virtualization allows multiple virtual machines, with heterogeneous operating systems to run in
isolation, side-by-side on...
Microsoft’s Virtual Server is different from Virtual PC in that, instead of being designed for
simplicity of use for the d...
networks and machines. For instance, minor releases of VMware ESX Server are typically
released every 9-12 months, with an...
2.8 Product Specific Checklists

There are specific product dependent settings and controls that will need to be configure...
This page is intentionally left blank.
3.   VIRTUALIZATION SERVER CONFIGURATION

3.1 Virtualization Server Management

Virtualization servers will be configured ...
Users should create a master image for each guest operating system to be deployed in the virtual
server environment. For i...
production guest virtual machines. Partitioning the master installations keeps the images isolated
from system, applicatio...
Management applications provide central administration and connectivity to virtualization server
farms. VMware provides Vi...
Virtual Machine Tools

Virtualization server products provide an optional set of virtualization platform extensions to its...
function is still active. Therefore, transferring text objects, such as a password from one
clipboard to another, in any d...
Inaccurate time causes other inaccuracies within the virtualization environment, which may
include event logs, domain sync...
assigning the MAC address to specific personnel or identifying machines by Ethernet location or
port number. All these app...
hosts that the virtual machine has run on. If no history was maintained for each virtual machine,
this can make it very di...
NOTE: The following findings will be open after the UNIX SRR is run against the ESX Server
      operating system. The exe...
Virtual Machine Creation

The default location for virtual machine files is the home directory of the user that created th...
Virtual Machine Permissions

Access to a virtual machine is based on the permissions granted to the virtual machines
confi...
Antivirus

The virtualization server will have antivirus and anti-spyware applications installed. These
applications consu...
To properly create virtual machines within the virtualization server environment, a minimal list
of requirements will be d...
•   (VCGEN0186: CAT II) The IAO/SA will ensure all virtual machines have logging enabled
    for troubleshooting and audit...
Setting the minimum and maximum memory and CPU resources requires some planning for
multiple virtual machines on the same ...
NOTE: This is not applicable to Vmware VMotioned virtual machines.

The DHCP server is useful when virtual machines are co...
Figure 3-2. Bridged Network

•   (VCGEN0196: CAT II) The IAO/SA will ensure all virtual machines bridged to the external
 ...
•   (VCGEN0198: CAT II) The IAO/SA will ensure NAT networking is not implemented in a
    production environment.

NOTE: T...
MAC Addresses

Every Ethernet network interface card, whether physical or virtual, has a unique identifier
assigned to it ...
3.5.2   Virtual Hard Drive Disk Types

Virtual hard disks provide storage for virtual machines. Within the virtual machine...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...
Upcoming SlideShare
Loading in...5
×

Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...

4,265

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,265
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
52
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Http://iase.disa.mil/stigs/draft-stigs/Virtual-Computing-STIG ...

  1. 1. DRAFT VIRTUAL COMPUTING SECURITY TECHNICAL IMPLEMENTATION GUIDE Version 1, Release 0.1 13 April 2007 Developed by DISA for the DoD UNCLASSIFIED
  2. 2. VIRTUAL COMPUTING V1R0.1, DRAFT DISA Field Security Operations 13 April 2007 Developed by DISA for the DoD This page is intentionally left blank. ii UNCLASSIFIED
  3. 3. VIRTUAL COMPUTING V1R0.1, DRAFT DISA Field Security Operations 13 April 2007 Developed by DISA for the DoD TABLE OF CONTENTS 1. INTRODUCTION......................................................................................................................1 1.1 Background............................................................................................................................1 1.2 Authority................................................................................................................................1 1.3 Scope......................................................................................................................................1 1.4 Writing Conventions..............................................................................................................2 1.5 Vulnerability Severity Code Definitions..............................................................................3 1.6 DISA Information Assurance Vulnerability Management (IAVM).....................................3 1.7 STIG Distribution.................................................................................................................3 1.8 Document Revisions.............................................................................................................3 2. SERVER VIRTUALIZATION.................................................................................................5 2.1 Introduction............................................................................................................................5 2.2 Classical Virtualization..........................................................................................................5 2.3 Software Virtualization..........................................................................................................6 2.4 Virtual Machines...................................................................................................................7 2.5 Virtualization Vendors...........................................................................................................8 2.6 Virtualization Support...........................................................................................................9 2.7 Patch Management.................................................................................................................9 2.8 Product Specific Checklists................................................................................................11 3. VIRTUALIZATION SERVER CONFIGURATION...........................................................13 3.1 Virtualization Server Management......................................................................................13 3.1.1 Master Images...............................................................................................................13 Managing Virtualization Servers and Virtual Machines......................................................15 Virtualization Server Authentication....................................................................................16 Virtual Machine Tools..........................................................................................................17 Time Synchronization...........................................................................................................18 Deleting Virtual Machine Files............................................................................................19 Virtual Machine Owners.......................................................................................................19 Snapshots..............................................................................................................................20 Moving Virtual Machines.....................................................................................................20 Logging and Auditing...........................................................................................................21 3.2 Virtualization Server Operating System Configuration......................................................21 Virtual Machine Creation.....................................................................................................23 Virtual Machine Permissions................................................................................................24 Antivirus...............................................................................................................................25 3.3 Guest Operating System Configuration...............................................................................25 Guest OS Selection...............................................................................................................26 Guest OS Logging................................................................................................................26 Controlling Guest Resource Usage.......................................................................................27 3.4 Virtualization Server Networking........................................................................................28 Networking Configurations..................................................................................................29 MAC Addresses....................................................................................................................32 3.5 Virtual Machine Hard Drive Disk Management ................................................................32 ii UNCLASSIFIED
  4. 4. VIRTUAL COMPUTING V1R0.1, DRAFT DISA Field Security Operations 13 April 2007 Developed by DISA for the DoD 3.5.1 Sharing and Moving Virtual Machine Files.................................................................32 3.5.2 Virtual Hard Drive Disk Types.....................................................................................33 3.6 Virtualization Server Backup and Recovery.......................................................................35 3.5.3 Traditional Backups......................................................................................................36 3.5.4 Flat-File Backups .........................................................................................................37 3.5.5 Snapshot Backups.........................................................................................................37 4. VMWARE ESX SERVER CONFIGURATION...................................................................39 4.1 VMware ESX Server ..........................................................................................................39 4.1.1 Service Console ...........................................................................................................41 4.1.2 Setuid and Setgid Applications.....................................................................................42 4.1.3 Memory Requirements.................................................................................................43 4.1.4 Disks and Partitions......................................................................................................43 4.1.5 Managing VMDK Files................................................................................................45 4.1.6 Renaming and Moving Virtual Machines.....................................................................47 4.1.7 Logging and Auditing...................................................................................................48 4.1.8 VirtualCenter................................................................................................................49 4.2 ESX Server Networking......................................................................................................58 4.2.1 Physical and Virtual Network Adapters.......................................................................58 4.2.2 Virtual Switches ...........................................................................................................62 4.2.3 VLANS.........................................................................................................................65 4.2.4 VLAN Modes...............................................................................................................65 4.2.5 Bonded Network Adapters...........................................................................................70 4.2.6 Bonded Modes..............................................................................................................71 4.6.7 ESX Server Beacon Monitoring ...............................................................................72 4.2.7 ESX TCP/IP Ports.........................................................................................................73 4.3 SNMP..................................................................................................................................74 APPENDIX A. RELATED PUBLICATIONS.............................................................75 APPENDIX B. PRODUCT VMM TYPES...................................................................76 iii UNCLASSIFIED
  5. 5. LIST OF TABLES TABLE 1.1. VULNERABILITY SEVERITY CODE DEFINITIONS .......................3 TABLE OF FIGURES FIGURE 2-1. TYPE I VMM............................................................................................6 FIGURE 2-2. TYPE II VMM..........................................................................................7 FIGURE 3-1. MASTER INSTALLATION IMAGE....................................................14 FIGURE 3-2. BRIDGED NETWORK...........................................................................30 FIGURE 3-3. NAT NETWORK.....................................................................................30 FIGURE 3-4. HOST-ONLY NETWORK.....................................................................31 FIGURE 3-5. FIXED DISK............................................................................................33 FIGURE 4-1. ESX SERVER ARCHITECTURE.........................................................41 FIGURE 4-2. VMFS WITH REDO DISK FILE..........................................................45 FIGURE 4-3. VIRTUALCENTER INTERFACE........................................................50 FIGURE 4-4.VIRTUALCENTER PORTS...................................................................57 FIGURE 4-5. ESX SERVER WITH TWO NETWORK ADAPTERS.......................58 FIGURE 4-6. PROMISCUOUS MODE........................................................................60 FIGURE 4-7. MULTIPLE VIRTUAL NETWORK ADAPTERS.............................62 FIGURE 4-8. VIRTUAL ETHERNET NETWORK....................................................63 FIGURE 4-9. VMOTION TECHNOLOGY.................................................................65 FIGURE 4-10. EST MODE.............................................................................................66 FIGURE 4-11. VST MODE............................................................................................68 FIGURE 4-12. VGT MODE............................................................................................70 FIGURE 4-13. BONDED NETWORK ADAPTERS....................................................71
  6. 6. This page is intentionally left blank.
  7. 7. 1. INTRODUCTION A core mission for the Defense Information Systems Agency (DISA) Field Security Operations (FSO) is to secure Department of Defense (DoD) Computing systems. The processes and procedures outlined in this Security Technical Information Guide (STIG), when applied, will decrease the risk of unauthorized disclosure of sensitive information. Security is clearly still one of the biggest concerns for our DoD customers (i.e., the war fighter). The intent of this STIG is to include security considerations and to provide an acceptable level of risk for information being transmitted. 1.1 Background This STIG was developed to enhance the confidentiality, integrity, and availability of sensitive DoD Automated Information Systems (AIS). Virtual Computing infrastructures must provide secure, available, and reliable data for all customers. This document will assist sites in meeting the minimum requirements, standards, controls, and options that must be in place for secure Virtual Computing environments. 1.2 Authority DoD Directive 8500.1 requires that “all IA and IA-enabled IT products incorporated into DoD information systems shall be configured in accordance with DoD-approved security configuration guidelines” and tasks DISA to “develop and provide security configuration guidance for IA and IA-enabled IT products in coordination with Director, NSA.” This document is provided under the authority of DoD Directive 8500.1. The use of the principles and guidelines in this STIG will provide an environment that meets or exceeds the security requirements of DoD systems operating at the Mission Assurance Category (MAC) II Sensitive level, containing sensitive information. It should be noted that Field Security Operations (FSO) support for the STIGs, Checklists, and Tools is only available to DoD Customers. 1.3 Scope The requirements set forth in this document will assist Information Assurance Managers (IAM), Information Assurance Officers (IAO/SA), Network Security Officers (NSO), and System Administrators (SA) in support of protecting DoD Virtual Computing systems. The Information Operations Condition (INFOCON) for the DoD recommends actions during periods when a heightened defensive posture is required to protect DoD computer networks from attack. The IAO will ensure compliance with the security requirements of the current INFOCON level and will modify security requirements to comply with this guidance. Password length and complexity given throughout this document must be adjusted as needed to comply with INFOCON guidance.
  8. 8. This document contains a set of principles and guidelines that serve as the basis for establishing Virtual Computing environments within the DoD. There are many virtual server products available as commercial off the shelf products. This STIG will focus on virtual server products with specific guidance for the ESX Server. Since many products utilize the virtual server within their names, the term virtualization server will be used to refer to any virtual server product. The policy portions of this STIG are relevant to all virtual servers or applications connected to either the DoD Unclassified (But Sensitive) Internet Protocol Router Network (NIPRNet) or Secret Internet Protocol Router Network (SIPRNet). 1.4 Writing Conventions Throughout this document, statements are written using words such as “will” and “should.” The following paragraphs are intended to clarify how these STIG statements are to be interpreted. A reference that uses “will” indicates mandatory compliance. All requirements of this kind will also be documented in the italicized policy statements in bullet format, which follow the topic paragraph. This makes all “will” statements easier to locate and interpret from the context of the topic. The IAO will adhere to the instruction as written. Each policy bullet includes the STIG Identifier (SDID) in parentheses that precedes the policy text and references the corresponding vulnerability check in the SRR Checklist and Vulnerability Management System (VMS). An example of this will be as follows: "(G111: CAT II)." If the item presently does not have an STIGID, or the STIGID is being developed, it will contain a preliminary severity code and "N/A" (i.e., "[N/A: CAT III]"). Throughout the document accountability is directed to the IAO to “ensure” a task is carried out or monitored. These tasks may be carried out by the IAO or delegated to someone else as a responsibility or duty. A reference to “should” indicates a recommendation that further enhances the security posture of the site. These recommended actions will be documented in the text paragraphs but not in the italicized policy bullets. All reasonable attempts to meet this criterion will be made.
  9. 9. 1.5 Vulnerability Severity Code Definitions Category I Vulnerabilities that allow an attacker immediate access into a machine, allow superuser access, or bypass a firewall. Virtual Computing Application: Vulnerabilities that may result in malicious attacks on virtual infrastructure resources or services. Attacks may include but are not limited to the Blue Pill, SubVirt, Trojan, DOS, and executing potentially malicious actions. Category II Vulnerabilities that provide information that have a high potential of giving access to an intruder. Virtual Computing Application: Vulnerabilities that may result in unauthorized users accessing and modifying virtual infrastructure resources or services. Category III Vulnerabilities that provide information that potentially could lead to compromise. Virtual Computing Application: Vulnerabilities that may result in unauthorized users viewing or possibly accessing virtual infrastructure resources or services. Table 1.1. Vulnerability Severity Code Definitions 1.6 DISA Information Assurance Vulnerability Management (IAVM) The DoD has mandated that all IAVMs are received and acted on by all commands, agencies, and organizations within the DoD. The IAVM process provides notification of these vulnerabilities and alerts require that each of these organizations take appropriate actions in accordance with the issued alert. IAVM notifications can be accessed at the Joint Task Force -Global Network Operations (JTF-GNO) web site: https://www.jtfgno.mil. 1.7 STIG Distribution Parties within the DoD and Federal Government's computing environments can obtain the applicable STIG from the Information Assurance Support Environment (IASE) web site. This site contains the latest copies of any STIG, as well as checklists, scripts, and other related security information. The NIPRNet URL for the IASE site is http://iase.disa.mil/. 1.8 Document Revisions Comments or proposed revisions to this document should be sent via e-mail to fso_spt@disa.mil. DISA FSO will coordinate all change requests with the relevant DOD organizations before inclusion in this document.
  10. 10. This page is intentionally left blank.
  11. 11. 2. SERVER VIRTUALIZATION 2.1 Introduction The term virtualization refers to the method of disconnecting the operating system from the physical server hardware and inserting a “virtualization layer” between the two. The virtualization layer presents a defined collection of virtual hardware to the virtual machine’s operating system and acts as mediator between the virtual “guest” operating system and the host computer running the virtualization software. 2.2 Classical Virtualization The need to virtualize unmodified x86 operating systems has given rise to software techniques that go beyond the classical trap and-emulate Virtual Machine Monitor (VMM). A VMM is the piece of software that provides the abstraction of a virtual machine. The software VMMs have enabled widespread use of x86 virtual machines to offer server consolidation, fault containment, security, and resource management. A particular VMM implementation style, trap-and-emulate, was so accepted in 1974 that it was considered the only practical method for virtualization. Although other methods were available, confusion resulted over the years to equate “virtualizability” with the VMM implementation of trap-and-emulate. In order to clarify the “virtualizability” definition, the term classically virtualizable is used to describe an architecture that is purely trap-and-emulate. As a result, the x86 is not classically virtualizable or trap-and-emulated. However, it is virtualizable by the Popek and Goldberg’s requirements using the essential requirements. The Popek and Goldberg virtualization requirements are a set of sufficient conditions for computer architecture to efficiently support system virtualization. They were introduced by Gerald J. Popek and Robert P. Goldberg in their 1974 article "Formal Requirements for Virtualizable Third Generation Architectures". Popek and Goldberg’s 1974 paper establishes three essential characteristics for system software to be considered a VMM: - Equivalence: a program running under the VMM should exhibit a behavior essentially identical to that demonstrated when running on the original machine directly. - Resource control: the VMM must be in complete control of the virtualized resources. - Efficiency: a statistically dominant fraction of machine instructions must be executed without VMM intervention. Recent architectural changes have enabled the classical virtualization of the x86 architecture. This is accomplished through AMD’s SVM and Intel’s VT. This is referred to as hardware- assisted VMM (hardware VMM as opposed to the software VMM). Hardware can provide explicit support for virtualization. CPU vendors are adding hardware virtualization assistance to their products. Intel's name for these extensions is Vanderpool and
  12. 12. AMD's is Pacifica. These extensions address the parts of x86 that are difficult to virtualize, providing additional support to the virtualization layer. This provides for simpler virtualization code and a higher performance. 2.3 Software Virtualization Software virtualization is possible through the use of the hypervisor or VMM. A VMM is software for a computer system that creates representations of physical hardware to a guest virtual machine. These representations provide users with the appearance of direct access to the real machine environment. These representations are referred to as virtual machines. The VMM or hypervisor allows these virtual machines to share resources with each other. Resources that are shared may be memory, disk space, CPU, etc. Virtualizing an operating system requires that all the instructions must be executed by either software, hardware, or a combination of both. These combinations create different types of VMMs. The amount of software and hardware execution of processor instructions determines what type of VMM it is. The three types of VMMs are Type I, Type II, and Hybrid, which is a combination of Type I and II. Appendix B lists the virtualization products and their associated VMM types. The Type I VMM runs on directly on the machine hardware. A Type I VMM is an operating system or kernel that has mechanisms to support virtual machines. It must perform scheduling and resource allocation for all virtual machines in the system and requires drivers and hardware peripherals. Processors must comply with several virtualization requirements to support a Type I VMM. First, the execution of non-privileged instructions must be equivalent in both privileged and user mode. Second, there must be a method to protect the real system and any other virtual machines from the active virtual machine. Figure 2-1 illustrates a Type I VMM. Virtual Machine 1 Virtual Machine 2 Virtual Machine 3 Applications Applications Applications Operating Operating Operating System System System Virtual Virtual Virtual Hardware Hardware Hardware Virtualization Layer X86 Architecture Hardware Figure 2-1. Type I VMM
  13. 13. The Type II VMM runs as an application on a host operating system and relies on the host operating system for memory management, processor scheduling, resource allocation, and hardware drivers. Processors must meet all the Type I VMM requirements as well as several host operating system requirements. Once such host operating system requirement is a mechanism to allow the VMM to run the virtual machine as a sub-process. Figure 2-2 illustrates the Type II VMM. Virtual Machine 1 Virtual Machine 2 Virtual Machine 3 Applications Applications Applications Operating Operating Operating System System System Virtual Virtual Virtual Hardware Hardware Hardware Virtualization Layer Host Operating System Kernel X86 Architecture Hardware Figure 2-2. Type II VMM A Hybrid VMM (HVM) has all the advantages of normal VMMs and avoids the penalties of purely software based VMMs. An HVM is functionally equivalent to the real machine. The difference between an HVM and a VMM is that the HVM treats the privileged mode of hardware as a software construct, whereas the normal VMM may directly execute some privileged instructions. Also, with the HVM all non-privileged instructions are executed directly on the processor. The HVM has less strict processor requirements than the VMM in two ways. First, the HVM does not have to execute non-sensitive privileged instructions because they are all emulated in software. Because of this software emulation, the HVM does not need to map the most privileged processor mode into another processor privilege level. This increased interpretation execution usually lowers the performance of an HVM relative to a VMM. 2.4 Virtual Machines While virtualization has been a part of the IT landscape for decades, it was only until recently that companies delivered the benefits of virtualization to industry-standard x86-based platforms. A key benefit of virtualization is the ability to run multiple operating systems on a single physical system and share the underlying hardware resources.
  14. 14. Virtualization allows multiple virtual machines, with heterogeneous operating systems to run in isolation, side-by-side on the same physical machine. Each virtual machine has its own set of virtual hardware (CPU, RAM, disks, network cards) upon which an operating system and applications are loaded. The virtual machine operating system sees a consistent, normalized set of hardware regardless of the actual physical hardware components. Virtual machines have many benefits such as encapsulation, isolation, and partitioning. Virtual machines are encapsulated into files, making it possible to rapidly save, copy, and provision a virtual machine. Fully configured systems, applications, operating systems, and virtual hardware may be moved, within seconds, from one physical server to another for zero- downtime maintenance and continuous workload consolidation. Virtual machines are completely isolated from the host machine and other virtual machines. If a virtual machine crashes, all others are unaffected. Data does not leak across virtual machines and applications can only communicate over configured network connections. Partitioning multiple applications and operating systems can be supported within a single physical system. Servers can be consolidated into virtual machines on either a scale-up or scale- out architecture. Computing resources are treated as a uniform pool which is allocated to virtual machines in a controlled manner; however, they could undermine the security architecture as well. 2.5 Virtualization Vendors The virtualization industry is currently dominated by two main players: VMware, who has been in the virtualization market since 1998, and Microsoft, who has released VirtualPC and Virtual Server products. VMware is available in several versions including VMware Workstation, VMware Server, and ESX Server. Microsoft has the Virtual PC and Virtual Server available. VMware and Microsoft virtualization products have different backgrounds. VMware products have been commercially available for the x86 platform since 1998. VMware is in the third and fourth generation of products for the ESX Server and Virtual Server products. Microsoft purchased their virtualization product from Connectix. Microsoft’s current version, Microsoft Virtual Server 2005 R2, was released in November 2005. VMware ESX Server is VMware’s enterprise-class product. The most notable difference between ESX Server and VMware Server/Workstation is that ESX Server does not run on a standard “hosted” operating system. Both VMware Server and Workstation are “hosted” solutions in that they require a host operating system to be installed on the hardware prior to loading the VMware product. ESX Server is loaded directly onto the hardware and has its own microkernel operating system. VMware Server and ESX Server are licensed based on the number of processors in the host server computer. Microsoft’s Virtual PC is designed to provide an optimal experience for a desktop user who wants to run one or more additional desktop operating systems on a single computer. The user interface is fairly simple, and there is extensive integration between the host operating system running on the physical computer and the guest operating systems running in virtual machines.
  15. 15. Microsoft’s Virtual Server is different from Virtual PC in that, instead of being designed for simplicity of use for the desktop user, it provides features that support the more complex requirements of enterprise server applications and administration. Virtual Server includes additional features that support greater manageability, scalability, and extensibility. These are important aspects of server management that are not appropriate to the intended uses of Virtual PC. 2.6 Virtualization Support Virtualization requires support for the host operating system, the virtualization software, and the virtualized guest operating system. Support for the host and guest operating system may vary depending on the vendor chosen. For instance, VMware products support more host and guest operating systems than do Microsoft products. VMware’s Virtual Server has the largest matrix of supported host and guest operating systems. VMware’s Virtual Server may have Linux or Microsoft host and guest operating systems. Microsoft Virtual Server 2005 R2 currently supports only Microsoft operating systems for the host. The guest operating systems may be Microsoft operating systems and some Linux distributions. The host operating system support from vendors depends on the virtualization platform. Microsoft Virtual Server 2005 R2 only installs on top of a Microsoft operating system. Therefore, the support is no different than the support received from Microsoft on a normal server installation. However, VMware Virtual Server may be installed on a Linux or Microsoft host operating system. The host operating system would be under the same level of support as if there was no virtualization software installed. The ESX Server runs on its own hypervisor/kernel as the host operating system, which is supported by the VMware technical support. • (VCGEN0100: CAT II) The IAO/SA will ensure the virtualization server host operating system is supported and/or approved by the virtualization server vendor. The guest operating systems on the host operating system must be supported by the virtualization software. Guest operating systems will need to be approved by the virtualization vendor so that if problems are encountered with the guest operating system, the virtualization vendor can assist with the resolution. Unsupported guest virtual machines create problems since no documentation or support is available from the virtualization vendor. • (VCGEN0102: CAT II) The IAO/SA will ensure the virtualization software supports the installed guest operating systems within the virtualization environment. 2.7 Patch Management Patch Management is an important part of maintaining a secure and stable environment. Virtualization server administrators will subscribe to virtualization vendor security notices, updates, and patches to ensure that all new vulnerabilities are known. New patches and updates should be reviewed for both the host and guest operating systems before moving them into a production environment. All patches will be tested first in a development environment and any issues or special precautions will be documented, as a patch could technically disable all virtual
  16. 16. networks and machines. For instance, minor releases of VMware ESX Server are typically released every 9-12 months, with an occasional maintenance release in between. When a VMware releases a patch or update, it is always accompanied with an installation script. Running the installation script will perform the proper actions to apply the patch. If the patch updates the kernel of the Service Console or the VMkernel, there is a good chance a reboot will be necessary for the changes to take effect. Some patches may only require a service to be restarted. Also, test and development virtual machines will be located on separate physical virtualization servers. Placing test and development virtual machines on a separate physical virtualization server ensures that any hardware issues with the test and development virtualization server does not affect live production virtual machines. This separation will enhance the availability of the production servers. • (VCGEN0103: CAT III) The IAO/SA will subscribe to virtualization server vendor security, patches, and update notifications. • (VCGEN0104: CAT II) The IAO/SA will ensure all patches for the virtualization server are tested in a development environment before installing them on the production virtualization servers. • (VCGEN0105: CAT II) The IAO/SA will ensure the virtualization software is at the latest patch level. • (VCGEN0106: CAT II) The IAO/SA will ensure all test and development virtual machines are not located on the same physical virtualization server as the production virtual machines. Virtual machines create a condition where they may be on, off, or suspended. The requirement that machines be on in a conventional approach to patch management, virus and vulnerability scanning, and machine configuration creates an issue in the virtual world. Virtual machines can appear and disappear from the network sporadically. Conventional networks can “anneal” new machines into a known good configuration state very quickly. However, converging virtual machines to a known good state is more challenging since the state may change quickly. For instance, a vulnerable machine can appear briefly and either become infected or reappear in a vulnerable state at a later time. Therefore, vulnerable virtual machines may become infected with a virus and never be detected since the virtual machine may be offline. Suspended and off virtual machines should be patched regularly to ensure patches are up to date. Virtual machines that are on will be kept current with the operating system patches per the appropriate OS STIG. • (VCGEN0107: CAT II) The IAO/SA will ensure all off and suspended guest virtual machines are at the latest patch level for the guest operating system.
  17. 17. 2.8 Product Specific Checklists There are specific product dependent settings and controls that will need to be configured to ensure the secure configuration of the virtualization servers. Because these controls do not apply to every virtual server product, the specifics are documented in the associated product specific companion checklist. • (VCGEN0108: CAT II) The IAO/SA will ensure the virtualization product is configured in accordance with the product specific companion checklist.
  18. 18. This page is intentionally left blank.
  19. 19. 3. VIRTUALIZATION SERVER CONFIGURATION 3.1 Virtualization Server Management Virtualization servers will be configured and managed to provide confidentiality, integrity, and availability. There are several areas that should be addressed when deploying virtual machines within a virtualization server. These areas include managing master images, authentication, time synchronization, virtual machine moves, owners, deletions, snapshots, and auditing. These areas are discussed below. 3.1.1 Master Images Virtual machines are similar to physical machines in that deployment is made easier when using a set of master installation images. Regardless of what physical hardware the virtual server is installed on, the hardware platform presented to the guest operating systems usually does not change. Virtual servers simplify this by removing the hardware dependency, resulting in less master installations and fewer images to manage. A master installation is a completely configured operating system installation that is up-to-date on service packs and security fixes. Master installations typically contain the support applications such as antivirus software, management agents, or backup software. Master installations can be deployed to new servers, greatly reducing the time, cost, and likelihood of errors when deploying multiple servers simultaneously. Master images are created from using operating system CD-ROMs or ISO images of the operating system. ISO operating system images reduce the time in deploying virtual servers since the media is readily available as a file on the hard drive. The other reason for ISO operating system images is it maps easily to the virtual CD-ROM drive of the guest machine once the guest machine is running. One drawback to ISO images is the space required to keep them. ISO images consume a lot of disk space since they are not compressed when they are created. Unauthorized access to the ISO operating system images could potentially allow these images to be corrupted or altered in some way. As a result, access to the ISO operating system images will be restricted to authorized users only. • (VCGEN0109: CAT II) The IAO/SA will ensure ISO images are restricted to authorized users only. Since ISO operating system images are typically large files, transferring these ISO operating system images over the network may cause corruption to the files. There are simple ways to check the integrity of the file on both the source and destination system using the MD5 algorithm. Users will verify all ISO operating system images on the virtual server before utilizing the ISO operating system image for virtual machines. For Linux systems, use the “md5sum filename”. For windows, there are several free utilities which include http://winmd5sum.solidblue.biz. It has a compare feature integrated. • (VCGEN0110: CAT II) The IAO/SA will ensure all ISO images that are moved are verified for integrity by using the md5sum utility.
  20. 20. Users should create a master image for each guest operating system to be deployed in the virtual server environment. For instance, create one master image for Windows 2003 Standard, Windows 2003 Enterprise, and RedHat Enterprise Linux 4, etc. Master images are primarily used for server provisioning. Server build processes that would normally take several steps for each new operating system can easily be rolled up into a master image. Master images reduce the amount of time from the server provisioning process. Figure 3-1 illustrates the master image installation process. Figure 3-1. Master Installation Image Utilizing master installation images can also help keep a networked environment secure. Maintaining approved master images reduces the likelihood that a new server is infected on the network. While deploying new guest virtual machines from master images will not completely eliminate all security risks, it does provide a baseline configuration for new guest virtual machines. The final major benefit of master installation images is that they provide a standardized platform for your server environment. As images are deployed from the master image, administrators will not need to worry about whether a specific registry hack was applied, or whether the password is the same. NOTE: It is strongly recommended that all guest virtual machines are configured from the appropriate master images for the OS. The strategies used to store your master installation images will directly impact the deployment scenarios. The master images will be stored in a separate partition (NTFS, VMFS, etc) from the
  21. 21. production guest virtual machines. Partitioning the master installations keeps the images isolated from system, application, and user files. This isolation helps protect the disk space used by the Linux kernel and various applications. Files cannot grow across partitions. Another advantage is that if a bad spot develops on the hard drive, the risk to the data is reduced as is recovery time. Furthermore, separate master installation partitions provide the ability to set up certain directories as read-only filesystems. Lastly, master installations will be restricted to authorized users only. If these images were compromised, all future guest installations could be corrupt or contain malicious code. Master installation images will be restricted to only users that are administering and/or creating guest virtual machines. • (VCGEN0112: CAT III) The IAO/SA will ensure all master installation images are stored on a separate partition. • (VCGEN0114: CAT II) The IAO/SA will ensure all master installation images are restricted to authorized users. Managing Virtualization Servers and Virtual Machines The two major vendors, VMware and Microsoft offer several ways to manage a virtualization server. The ways include a web-based management interface, command line, virtual server management console, and management applications designed for the virtualization server. Each method to manage virtualization servers is described below. A web-based management interface is used to manage a single virtualization server or virtual machine at a time. The web-based management interface is used for monitoring and managing the majority of administrative tasks. The web-based management interface for virtualization server platforms will have all management traffic encrypted with an approved FIPS 140-2 encryption algorithm (SSLv3/TLSv1), providing confidentiality. Virtualization servers or virtual machines may also be administered through the command line. Accessing the command line give much more granular control and options to the administrator for configuring the virtualization servers or virtual machines. Also, the command line is faster than the web-based management interface since all communication is in ASCII text. All remote virtualization server and virtual machine connections for command line configurations will use an encrypted channel. Telnet, ftp, and other clear text protocols will not be used since commands sent in the clear may be sniffed by unauthorized users. Most virtualization server products provide a virtual machine remote management console (VMRC) utility. This VMRC displays the virtualization server or machine in a window where users may interact with the virtualization server or virtual machine as they would with a physical computer. This traffic needs to be encrypted as well, since commands sent over this remote console could be seen by unauthorized users. Furthermore, VMRC sessions will be configured to timeout after 15 minutes of inactivity. Virtual machines will timeout if the user is at the console, remotely connected via RDP, etc. Therefore, all virtual machine remote console sessions will timeout after 15 minutes of inactivity to protect against sessions remaining open indefinitely, and potentially giving access to unauthorized users.
  22. 22. Management applications provide central administration and connectivity to virtualization server farms. VMware provides VirtualCenter as a management application to manage both VMware Virtual Server and ESX Server hosts running virtual machines. Microsoft recently introduced a management pack add-on to its Microsoft Operations Manager (MOM) solution to help manage and monitor virtual environments. All traffic from the virtualization management application to the virtualization servers will be encrypted if technically possible to ensure that unauthorized users are not able to see or modify this traffic. • (VCGEN0118: CAT II) The IAO/SA will ensure all web-based management (SSLv3/TLSv1), remote console (SSH, SFTP, etc.), and VMRC traffic to virtualization servers or virtual machines are encrypted with an approved FIPS 140-2 algorithm. • (VCGEN0120: CAT II) The IAO/SA will ensure all VMRC traffic with the virtualization server or virtual machines are configured with an idle timeout value of 15 minutes or less. Virtualization Server Authentication Virtualization servers will be configured to secure the virtualization server system and users. Passwords will be created IAW the policy outlined in DoDI 8500.2, IA controls IAIA-1, and IAIA-2. Passwords are susceptible to compromise while in transit, at rest, and at the server console by unauthorized users. Virtualization servers will ensure all passwords at rest are encrypted, and virtualization server passwords are masked. Virtualization server remote management tools will be configured to prevent anonymous logons, guest logons, and lockout users after three unsuccessful attempts. Locking out users after three unsuccessful attempts make is less likely that password attacks will occur on the virtual system. • (VCGEN0122: CAT II) The IAO/SA will ensure all passwords are created and maintained in accordance with the policy outlined in DoDI 8500.2, IA Controls IAIA-1, and IAIA-2. Passwords will be 9 characters in length with a character mix of upper case letters, lower case letters, numbers, and special characters, including at least two of each (e.g., DemPa3*2!). –Caveat: Password length may vary depending on the INFOCON level. • (VCGEN0124: CAT II) The IAO/SA will ensure all stored passwords at rest are encrypted. • (VCGEN0126: CAT II) The IAO/SA will ensure the maximum number of unsuccessful logons is configured to three by the virtualization server.
  23. 23. Virtual Machine Tools Virtualization server products provide an optional set of virtualization platform extensions to its virtual machines in packages. For instance, VMware has an extension known as VMware Tools, and Microsoft Virtual Server has an extension known as Virtual Machine Additions. These tools contain a set of optimized, guest operating system-specific drivers and services designed to enhance performance of virtual machines and add integrated features. Although virtual machines can operate without these tools, it is highly recommended that these tools are installed into supported guest operating systems to optimize not only overall performance of the virtual machine, but the usability and manageability. These packages are not automatically installed into guest operating systems. Virtual machine tools provide a set of system services in addition to the optimized drivers in a component referred to as the virtual server service or the guest service. These services provide such features as including a “heartbeat” signal, time synchronization, optimized drivers, and automated scripts. These services are only available if the virtual machine tools are installed and the service is running. Some virtual machine tools, such as VMware Tools, include clipboard integration for virtual machines. Accessing the virtual machine via the Virtual Machine Remote Console (VMRC) application enables data to be exchanged between the virtual machine and the machine running the VMRC using the clipboard’s cut, copy, and paste operations. The clipboard copy operation can transfer only text, not files or streams. In a windows environment, where the guest virtual machine and the VMRC machine are both running windows, the normal windows clipboard functions are available between the two computers across the VMRC boundary. When exchanging clipboard data with the virtual machine running a Linux-based operating system, the Linux-based operating system must be running X windows as clipboard integration does not work with Linux-based operating systems running in command-line mode (runlevel 3). The clipboard copy operation within the VMRC has a vulnerability that needs to be addressed. To enable the clipboard function requires a check of the clipboard, and a reboot of the virtual machine. If the virtual machine is not rebooted, this functionality will not work. When the clipboard feature is turned on and working, the direction of the clipboard content transfer is the same as the direction of the focus change between virtual machine and host operating systems and vice versa. However, when the host operating system clipboard is empty and the focus is moved to the virtual machine clipboard, the virtual machine clipboard is not cleared and left with its current content. Now, when the focus is returned back to the host operating system clipboard, the empty clipboard is now filled with the content of the virtual machine clipboard. Thus the host operating system clipboard is failing to keep itself erased, and its previously cleared content is re-filled from the virtual machine. This behavior may re-fill the host operating system’s clipboard with data that was intentionally erased (like password or credit card number). This behavior does not happen when the process is started from the virtual machine clipboard. So, the issue is only when the process starts from the host operating side. Several security issues arise as a result of this behavior this clipboard behavior. The first is that the administrator might turn on the clipboard transfer and use it. However, deselecting the clipboard check box will not turn off the function, since a reboot is required. So, the clipboard
  24. 24. function is still active. Therefore, transferring text objects, such as a password from one clipboard to another, in any direction between the virtual machine and the host operating system is possible. Secondly, this breaks the virtual machine isolation. This may cause information leakage and potentially infect other operating systems if the text is a string that can be run as a command or URL. As a result, all clipboard capabilities will be disabled within the virtual machine. • (VCGEN0128: CAT II) The IAO/SA will ensure virtual machine tool’s clipboard functions (cut, copy and paste) are disabled within all virtual machines. Virtual machine tools provide the capability to pass string values to the virtual machine from the host virtual server through a scripting language such as Perl, Windows batch file, Linux Bash shell, etc. The strings must be placed into the virtual machine configuration file and its value must be added to a new line and be set to a relevant string value. Once the virtual machine is booted, a special command can be used inside the virtual machine’s guest operating system to obtain the value. For instance, a VMware script can run inside the virtual machine to execute a command-line to obtain the value: VMwareService –cmd machine.id.get where machine.id = “Jupiter 172.16.100.12”. This string would change the hostname and IP address of the virtual machine. Passing strings to the virtual machine via the virtual machine configuration file will be disabled since this too breaks the virtual machine isolation, and potentially incorrect parameters may be passed causing a denial of service. • (VCGEN0130: CAT II) The IAO/SA will ensure passing strings to the virtual machine from the virtualization server are disabled. Time Synchronization Generally speaking, PC-based operating systems keep track of time by counting timer interrupts or ticks. When the operating system starts up, it reads the current time to the nearest second from the computer's battery-backed (CMOS) real time clock or queries a network time server to obtain a more precise time. To update the time from that point on, the operating system sets up one of the computer's hardware timekeeping devices to interrupt periodically at a known rate (i.e., 100 or 1000 times per second). The operating system then fields these interruptions and keeps a count to determine how much time has passed. Supporting this form of timekeeping accurately in a virtual machine is difficult. Virtual machines share their underlying hardware with the virtualization server operating system. Other applications and other virtual machines may also be running on the same virtualization server. Thus, at the moment a virtual machine should generate a virtual timer interrupt, it may not actually be running. In fact, the virtual machine may not get a chance to run again until it has accumulated a backlog of many timer interrupts. In addition, even if a virtual machine is running at the moment when one of its virtual timer interrupts is due, the virtual machine may not check for the interrupt at that moment and deliver it to the guest operating system on time. As a result, the accuracy of time within the virtualization environment is problematic due to this timer interrupt. Sometimes the time drift may be dramatic such as a loss of 5-10 minutes.
  25. 25. Inaccurate time causes other inaccuracies within the virtualization environment, which may include event logs, domain synchronization, session timeouts, etc. Virtual machine time synchronization may be achieved through an external time source or through the virtualization server operating system. Configuring time synchronization for virtual machines to an external source keeps the virtual machines in synchronization with the rest of the network. However, the external time source is not aware of the unusual clock behavior of virtual machines. Therefore, it does not synchronize accurately. As a result, synchronizing the virtual machine with the virtualization server is the preferred method for time synchronization. NOTE: Do not enable both virtual machine tools time synchronization and non-virtual machine clock synchronization software since they will run without knowledge of each other, causing problems. • (VCGEN0132: CAT II) The IAO/SA will ensure all virtual machines are time synchronized with the virtualization server or an approved authoritative time server. The virtualization server operating system will require time synchronization to an authoritative time server to maintain accurate time. Most environments will have a centralized time server already configured for the network. Time servers are configured in the /etc/ntp.conf file on UNIX systems. Once they are configured with an atomic clock, the ntpd daemon should be configured to start at the runlevels 3, 4, and 5. Windows servers are configured via the command line using the net time /setsntp:clock.isc.org. The w32time service will need to be configured to start after the change. • (VCGEN0134: CAT II) The IAO/SA will ensure the virtualization server is time synchronized to an approved authoritative time server. Deleting Virtual Machine Files Deleting virtual machines is more involved than simply selecting remove or delete from the web console. Simply removing the virtual machine from the virtualization server will not delete the virtual machine configuration files. The virtual hard disk files and several configuration files may still reside on the system. The administrator must know the location of the virtual hard disk, virtual machine configuration files, and networking files. All these files or settings must be deleted for the virtual machine to be removed from the system. If virtual configuration files are not properly removed, then residual data will be left on the system. This residual data may be viewed by unauthorized users. • (VCGEN0136: CAT III) The IAO/SA will ensure all virtual machine files no longer in use are deleted and purged from the network. Virtual Machine Owners In traditional computing environments, servers were usually assigned to various personnel for administration. For instance, the data server was administered by the database administrator; the domain controller was maintained by the network administrator, etc. Other methods include
  26. 26. assigning the MAC address to specific personnel or identifying machines by Ethernet location or port number. All these approaches are impractical in the virtual machine environment. In the virtual environment, virtual machines may be moved or have MAC addresses that may change. This mobility makes it difficult to establish who owns the virtual machine running on a particular host. Also, virtual machines may have static or dynamic MAC addresses. The conventional assignment methods become impractical for virtual machines. Therefore, a policy will need to be implemented to identify and assign virtual machines to the appropriate personnel. • (VCGEN0138: CAT III) The IAO/SA has a policy and procedure in place to identify and assign virtual machines to the appropriate personnel. Snapshots Traditionally, a physical server’s lifetime can be envisioned as a straight line where the current state of the machine is a static point forward as software executes, configuration changes made, and software is installed. In a virtual environment the virtual machine state is more akin to a tree, where at any point the execution can fork of into N different branches. These different branches are the multiple instances of the virtual machine running or existing at any point in time. Branches are caused by undo-able disks and checkpoint features that allow virtual machines to be rolled back to previous states in their execution. This execution model conflicts with the assumptions of patch management and maintenance that rely on monotonic forward progress. Rolling back a virtual machine can re-expose patched vulnerabilities, re-enable previously disabled accounts or passwords, remove log files of a machine, use previously retired encryption keys, and change firewalls to expose vulnerabilities. Rolling back virtual machines can also reintroduce malicious code, and protocols reusing TCP sequence numbers that had been previously removed, which could allow TCP hijacking attacks. A subtler issue with rolling back virtual machines is an attackers memory of what has been seen cannot be erased. For instance, a one-time password transmitted in the clear will be seen by the attacker and replayed at a moment of their choice. Therefore, virtual machine rollbacks will be performed when the virtual machine is off or disconnected from the network. • (VCGEN0142: CAT II) The IAO/SA will ensure any rollback of a production virtual machine to a previous state is performed while the virtual machine is off or disconnected from the network. NOTE: This does not apply to snapshot backups. • (VCGEN0144: CAT II) The IAO/SA will ensure virtual machines log files are saved for auditing purposes before any virtual machine rollback occurs. Moving Virtual Machines Virtual machines provide mobility similar to a normal file. This portability gives rise to a host of security problems. In the virtual machine world, the trusted computing base consists of all the
  27. 27. hosts that the virtual machine has run on. If no history was maintained for each virtual machine, this can make it very difficult to figure out how far a security compromise has extended if the virtual machine has been moved several times. For instance, if a file server has been compromised, any virtual machine that was on the server may have been compromised by an attacker. Determining which virtual machines were exposed can be difficult. Another issue is porting a virtual machine from an employee’s workstation to the production environment. From a theft perspective, virtual machines are easy to copy and move to a person’s USB drive, portable hard drive, etc. An insider could potentially move the organization’s entire data center on any type of removable media that had sufficient space. • (VCGEN0148: CAT III) The IAO/SA will ensure virtual machines have a log file detailing when the virtual machine was moved from one physical server to another, and who authorized the move. • (VCGEN0150: CAT II) The IAO/SA will ensure all virtual machines are not removed from the site unless it has been approved by the IAO/SA. Logging and Auditing Virtualization server sends information about events that occur in the application to the logging daemon or event log. Each event has a unique identifier to track various events with automation tools. The types of events that are sent to the log file include any changes to a virtual machine’s power state, when a virtual machine is powered on or off, suspended or resumed, the addition or removal of virtual machines from the inventory, and the deletion of a virtual machine from the virtualization server system. These events are important for auditing purposes so any unusual power state changes may be reviewed at a later date. • (VCGEN0152: CAT II) The IAO/SA will ensure the virtualization server logs all virtual machine power states, suspends, resumes, deletions, and inventory changes. • (VCGEN0154: CAT II) The IAO/SA will ensure the virtualization server logs are reviewed daily for any anomalies. • (VCGEN0156: CAT III) The IAO/SA will ensure log files for all virtualization servers are stored online for 30 days and offline for 1 year. 3.2 Virtualization Server Operating System Configuration Managing the virtualization server is possible through web-based access, SNMP, SSH, Application Programming Interfaces (API) interfaces, etc. The virtualization server host operating system is vulnerable to attack depending on the operating system utilized. Therefore, the virtualization server will be configured according to the appropriate operating STIG. • (VCGEN0158: CAT II) The IAO will ensure the virtualization server is configured in accordance with the appropriate operating STIG.
  28. 28. NOTE: The following findings will be open after the UNIX SRR is run against the ESX Server operating system. The executable stack GEN003540 will not be applicable. However, the GEN006640 may be closed by installing Symantec Antivirus software available at the JTG-GNO site. - Executable Stack GEN003540 (CAT II) OPEN FINDING DESCRIPTION GEN003540: The SA will ensure the executable stack is disabled. SYSTEM CONFIGURATION: VMWare 3.0.1 does not support this configuration. The kernel has executable stack enabled. - Virus Protection GEN006640 (CAT I) OPEN FINDING DESCRIPTION GEN006640: An approved DOD virus scan program in not used and/or updated. SYSTEM CONFIGURATION: Unable to install McAfee Virus scan command-line tool on VMware ESX. Some of the prerequisite filesets for this product conflict with the versions required by VMware Operating System filesets. Once the virtualization server is configured and operating, unnecessary services need to be disabled. Utilizing unnecessary services opens up ports and vulnerabilities that may be exploited to gain access to the server. Furthermore, these unnecessary services consume CPU cycles and memory. Within the virtualization environment where resources are shared, resources should be preserved if possible. For instance, running screen savers on the host or virtual machines consumes a lot of CPU. All unnecessary services will be disabled on the virtualization server. • (VCGEN0160: CAT III) The IAO/SA will ensure the virtualization server has all unnecessary services or daemons disabled. The virtualization server will have a group structure design that allows the staff to manage the virtual machines they own. Those personnel should have individual logins so that there is an audit trail in the event of problems. The virtualization server may utilize an external directory server (Active Directory, LDAP, etc.) for authentication of virtualization server administrators and virtual machine administrators. Virtual machine users will not have virtualization server logins, since there is no inherent need. Virtualization server users will be created for personnel who will be creating or administering those virtual machines. Virtualization server users who create, access, and modify virtual machines will not have the additional administrative privileges of the root user. • (VCGEN0162: CAT II) The IAO/SA will ensure the virtualization server is configured with a user and group structure for administering all virtual machines.
  29. 29. Virtual Machine Creation The default location for virtual machine files is the home directory of the user that created the virtual machine. Home directories will not be used for storing virtual machine files. Home directories are used for user’s files, not a virtual machine that could be used by many users. Users will create and store virtual machines in a central directory structure to ensure permissions, users, and files are created to share the virtual machines. • (VCGEN0164: CAT II) The IAO/SA will ensure virtual machine files are not stored in the users’ home directory. Virtual machines by default typically run as the user who created the virtual machine. This implies that the user must have rights to the virtual machine’s files. These rights can easily be configured by assigning them to the directory. Running the virtual machine as the creator of the virtual machine is the default configuration. However, the virtual machine may be powered off when the user logs off. Powering off a virtual machine due to the owner logging off while it is in use could have unforeseen consequences to applications or system users. As a result, the virtual machine will be configured to run as a system user to ensure the virtual machine is always available. • (VCGEN0165: CAT II) The IAO/SA will ensure virtual machines are configured to run as local system accounts, not individual user accounts. NOTE: The ESX Server virtual machines run as root, and not the user who created it. Any user with access to the virtualization server has the ability to create a virtual machine or virtual disk file on the virtualization server. The number of users that should be allowed to access and create virtual machines should be limited. Without any controls in place, a user may accidentally consume too much disk space on the host server or add an un-patched virtual machine that could expose other virtual machines or physical machines on the same network. Therefore, users will be restricted on the virtualization server with only the necessary permissions to administer their virtual machines. • (VCGEN0166: CAT II) The IAO/SA will ensure only authorized users have access to the virtualization server to create virtual machines or virtual hard disks. With the creation of virtual machines, the actual virtual topology becomes increasingly complex. The topology changes when a virtual machine is created, added to a virtual switch or port group, moved to another virtualization server, etc. With the dynamic nature of the virtualization environment, administrators of the virtualization environment will maintain up to date documentation all virtual machines, virtual switches, IP addresses, MAC addresses, etc. This documentation will give a baseline to administrators to use when designing and troubleshooting virtual networking, machines, and other issues with the virtual infrastructure. • (VCGEN0168: CAT II) The IAO/SA will have up to date documentation of all virtual machines running on all physical servers detailing the IP addresses, MAC addresses, virtual switches, virtual operating systems, and virtual applications.
  30. 30. Virtual Machine Permissions Access to a virtual machine is based on the permissions granted to the virtual machines configuration file. Specific permissions let users’ access virtual machines in different ways. These access methods include browsing, interacting, configuring, and administering virtual machines. Browsing a virtual machine connects users to the console displaying only the virtual machine’s power state. The virtual machine display is blank, even if the virtual machine is running. Interaction with the virtual machine is not permitted. To browse a virtual machine, users need read permission for the virtual machines configuration files on a Windows host, or read (r) permission on a Linux host. Interacting with a virtual machine lets users change its power state (power on or off, suspend, or resume) and connect or disconnect removable devices. However, changes to the virtual machine’s configuration file are not permitted. Among other restrictions, this means no changes may be made to the virtual hardware. To interact with a virtual machine, users must have read and execute permission for the virtual machines configuration files on a Windows host, and read and execute (r and x) permissions on a Linux host. Configuring a virtual machine lets you add and remove virtual hardware from the virtual machine. To configure a virtual machine, user’s must have read and write permissions for the virtual machine’s configuration file and virtual machine resources (such as a physical disk or certain devices) on a Windows host, or read and write (r and w) permissions on a Linux host. Virtual machine administrators will need user permissions to connect, interact, and configure a virtual machine. For virtual machine administrators to configure the virtual machine through the remote console, the user must have read, write and execute access to that virtual machine’s configuration file. • (VCGEN0170: CAT II) The IAO/SA will ensure only authorized virtual machine administrators have read and execute access to the virtual machine’s configuration file and directories. Some virtualization servers by default create virtual machines as private virtual machines. When a virtual machine is private, it appears in the inventory of the console of the user who created it. The virtual machine does not appear in the inventory of consoles for other users connected to the host. Other users cannot browse to the virtual machine and add it to the inventory. If the virtual machine is made private after it has been created, it disappears from other users’ inventories. • (VCGEN0174: CAT II) The IAO/SA will ensure all virtual machines are configured as private so unauthorized users cannot browse other virtual machines. NOTE: This is not applicable to the ESX Server platform.
  31. 31. Antivirus The virtualization server will have antivirus and anti-spyware applications installed. These applications consume many resources during their scans. If too many resources are allocated to the anti-virus scan, the virtualization server may deny resources to the virtual machines potentially causing a denial of service. Therefore, all real-time anti-virus or anti-spyware protection scans will run at non-peak times. Non-peak times will be determined by the site based on their performance baselines and activity. Furthermore, administrators will disable anti-virus real-time scanning on virtual hard disks and virtual memory files. These are the files that contain your virtual machine’s virtual disk and virtual memory. When a virtual machine is active and running, the virtual machine process regularly reads and writes to those files. If your anti-virus' real-time scanner has to scan every read and write, it can slow down the effective performance of the virtual machine. Therefore, to prevent any potential availability issues due to performance bottlenecks, virtual machine hard drive disks and memory files will be excluded from real-time scans. • (VCGEN0176: CAT III) The IAO/SA will ensure the virtual server has anti-virus and anti- spyware scans scheduled to run at non-peak times. • (VCGEN0178: CAT III) The IAO/SA will ensure the virtual server is not configured to scan virtual machine hard disks and memory for viruses and spyware. Creating new virtual machines is as easy as copying a file. Copying files is a quick and efficient way to rollout new virtual machines. Virtual machines can grow at an explosive rate and really tax the security systems of an organization. Many administrative tasks that may be automated, but some upgrades and patches require manual tools. For instance, virtual machines may need to be patched, scanned, and purged in response to a virus or worm attack on the network. Therefore, to protect against potential virus and spyware infections, all off and suspended virtual machines will have the latest up to date anti-virus software and signatures. • (VCGEN0180: CAT II) The IAO/SA will ensure all virtual machines in the power state of off or suspend will have the latest up to date anti- virus software and signatures. NOTE: This does not apply to snapshot backups. 3.3 Guest Operating System Configuration Guest operating systems are configured and installed within virtual machines on the virtualization server. Depending on the virtualization server, the number of hosts may vary. For instance, the ESX Server may host up to 128 virtual machines at one time. Guest operating systems may require different resources depending on the server function. A database or email server will require more resources than a basic Windows Domain Controller. Therefore, proper planning is required to determine what servers will be built within the virtualization server environment.
  32. 32. To properly create virtual machines within the virtualization server environment, a minimal list of requirements will be determined. These requirements are the amount of memory, amount of required disk space, the networking card assignment, required media, and proper disk mode to be used. • (VCGEN0182: CAT II) The IAO/SA will ensure virtual machine requirements are documented before creating virtual machines within the virtualization server environment. These requirements include amount of memory, amount of required disk space, networking card assignment, required media, and the proper disk mode. Guest OS Selection All guest operating systems must be supported by the virtualization server product. Virtualization servers present physical hardware through a virtualized “layer.” While this hardware is presented as “generic” hardware, it still requires specific drivers and functionality, just as a physical server needs drivers. Virtualization servers provide drivers for its virtual hardware for a number of operating systems that it supports. In general, unsupported guest operating systems will run slower than supported operating systems with the guest enhancement software installed. There will usually be performance and usability issues when attempting to access virtual machines that have unsupported guest operating system installed using the virtualization platform’s native remote control technology, such as virtual machine remote console. This is primarily due to the lack of optimized keyboard, mouse, and video drivers in the guest operating system usually supplied by the guest enhancement software package. Selecting the correct guest operating system for each virtual machine is important. Virtualization servers optimize certain internal configurations on the basis of this selection. For this reason, it is important to set the guest operating system correctly. The correct guest operating selection can greatly aid the operating system chosen and may cause significant performance degradation if there is a mismatch between the selection and the operating system actually running in the virtual machine. The performance degradation may be similar to running an unsupported operating system. Selecting the wrong guest operating system is not likely to cause a virtual machine to run incorrectly, but it could degrade the virtual machine’s performance. • (VCGEN0184: CAT III) The IAO/SA will ensure all virtual machine’s guest operating selection correctly matches the operating system installed. Guest OS Logging Virtual machines may log troubleshooting information into a virtual machine log file stored in the client operating system. Normal, non-root, or non-administrator users and processes in the virtual machine may abuse this logging and cause large amounts of data to be logged. Over time, a log file can consume the file system space designated for the client operating system and cause a denial of service attack. Therefore, rotating logs is critical to prevent file system problems. Also, the virtualization vendor may not offer technical support without virtual machine logging enabled.
  33. 33. • (VCGEN0186: CAT II) The IAO/SA will ensure all virtual machines have logging enabled for troubleshooting and auditing purposes. Controlling Guest Resource Usage Guest virtual machines are allocated hardware resources based on minimums, maximums, and shares. Resources allocated to virtual machines may be memory space, CPU time, network bandwidth, and disk bandwidth. The minimum and maximum resource settings within virtualization server are absolutes values, whereas shares are used to give preference to a guest operating system when a resource is scarce. Virtual machines will disable CPU intensive processes since they will directly impact the virtualization server performance and may potentially cause resources to be scarce. Scarce resources are distributed based on availability and priorities assigned to virtual machines. To ensure all virtual machines have sufficient and available resources, screen savers and hibernation within the virtual machines will be disabled. • (VCGEN0188: CAT III) The IAO/SA will ensure guest operating systems have screen savers disabled. • (VCGEN0190: CAT III) The IAO/SA will ensure guest operating systems have hibernation disabled. Memory minimum and maximum resource settings are specific for each virtual machine. To illustrate settings, a virtual machine may have the maximum memory of 384MB and the minimum to 0MB. This means that the virtual machine may never have more than 384 MB of physical memory or less than 0MB of physical memory. Assuming this virtual machine is idle and other virtual machines require access to physical memory, this virtual machines memory can be redistributed to other active virtual machines all the way down to 0MB. The reported memory to the guest (384MB) is not physical memory but instead swapped memory. To guarantee that the a virtual machine has a certain amount of physical memory at all times, a higher minimum will need to be set other than 0MB. Minimum and maximum resource settings are applicable to the CPU as well on the virtual machine. CPU or processor resources can be set to the minimum and maximum of 0 and 100% (the default is min 0 and max 100%). For instance, setting the minimum CPU to 10% will allocate the virtual machine 10% processor. However, the drawback to this configuration is that the virtual machine may be idle, and the processor has reserved 10% for just this virtual machine. Conversely, setting the maximum amount of processor utilization on any virtual machine limits the virtual machine even though it might require more processor time. If the virtual machine needs more processing time and cannot get more, then the virtual machine will take longer to complete its tasks. This is basically “processor throttling” at the host level for that virtual machine. The key to understanding resources is the consequences of setting maximums and minimums. Minimums guarantee a specific amount of a resource to the virtual machine but deny that much of the resource to other virtual machines. Maximums deny the virtual machine a portion of a resource while allowing other virtual machines more access to that resource.
  34. 34. Setting the minimum and maximum memory and CPU resources requires some planning for multiple virtual machines on the same virtual server. If one virtual machine has been set to the minimum CPU or memory that the virtual server has available, and then the other virtual machines will not be able to function. If virtualization server is unable to guarantee a virtual machine’s specified minimum percentage, it will not allow the virtual machine to power on. • (VCGEN0192: CAT II) The IAO/SA will ensure all minimum resource settings for memory and CPU for each virtual machine does not equal the total physical amount available. 3.4 Virtualization Server Networking Virtual networks are used to connect virtual machines to internal or external networks. Virtual network components are utilized to connect virtual machines to internal and external networks. These network components include bridges, NAT, host-only, virtual switches, virtual DHCP server, and virtual network adapters. With these components, virtual servers may offer three types of network configurations. These configurations are bridged, Network Address Translation (NAT), and host-only networking. In order to facilitate communication a virtual switch, a virtual network adapter, and optionally a virtual DHCP server are utilized. Depending on the product the number of virtual network adapters assigned to each virtual machine may vary, but the maximum is usually four per virtual machine. Each network component is described below. The bridged network configuration allows a virtual machine to access a physical network that the virtualization server is connected to. The virtualization server does not necessarily need to be participating on the network. This is analogous to thinking of the virtual network adapter in the virtual machine being connected to the physical Ethernet adapter in the virtualization server. The NAT network configuration enables communication between virtual machines and the external network. Using a NAT device becomes advantageous when there is a limited amount of IP addresses available on the physical network and those IP addresses are being used by the physical servers. The host-only network configuration creates a virtual Ethernet LAN on the virtualization server that allows communication between the virtualization server and virtual machines on that virtualization server. By default, the host virtual adapter is not connected to any external network. A virtual switch is similar to a physical switch in that is connects networking components together. A virtual switch can be connected to the physical network or it can be completely virtual and therefore isolated from the outside network. Depending on the virtualization server operating system the number of virtual switches that can be created varies. • (VCGEN0194: CAT II) The IAO/SA will ensure virtual switches not in use are deleted or disabled.
  35. 35. NOTE: This is not applicable to Vmware VMotioned virtual machines. The DHCP server is useful when virtual machines are configured to use host-only or NAT configurations. The DHCP server provides a range of IP addresses to virtual machines that are not bridged to an external network. Using the virtual DHCP server is much faster than using an external one since the addresses will be retrieved at bus speed. The virtual network adapter is added to each virtual machine for connectivity to internal and external networks. Typically, the maximum number of virtual network adapters allowed per virtual machine is four. Networking Configurations There are three types of networking configurations that may be implemented within a virtualization server. These types are bridged networking, NAT networking, and host-only networking. In each of these configurations, a Windows host operating system may connect an unlimited number of virtual devices to a virtual switch, while a Linux host operating system can only connect up to 32 devices. The bridged network configuration allows a virtual machine to access a physical network that the virtualization server is connected to. Bridged networking is the easiest way to connect a virtual machine to the external LAN. With bridged networking, the virtual machine has two-way communication on the LAN. This means it can access other equipment on the network and it can be accessed by other devices on the network. Each virtual machine that is configured to use bridged networking must be assigned a unique IP address. Figure 3-2 illustrates a bridged network. Virtual Server Virtual Machine 1 Virtual Network Adapter Virtual Machine 2 Virtual Network Physical Network Adapter LAN Adapter Virtual Switch Virtual Machine 3 Virtual Network Adapter
  36. 36. Figure 3-2. Bridged Network • (VCGEN0196: CAT II) The IAO/SA will ensure all virtual machines bridged to the external network have a valid external network IP address. NAT networking allows the virtual machine to transcend the private network and communicate with the external LAN. NAT is a good choice if IP addresses are scarce on the external network. When using this type of networking, the guest operating system does not have an IP address on the external network. Instead, a private network is setup on the virtualization server and the guest operating system receives an internal IP address from the virtual DHCP server. The virtual machines then communicate with a router node, the NAT device, which passes network data between one or more virtual machines and external networks. Communication across the NAT device is recorded in translation table and the traffic is then funneled back to the correct destination. Figure 3-3 illustrates a NAT network. Virtual Server Virtual Machine 1 NAT Module Virtual Network Adapter Virtual Machine 2 Virtual Switch Virtual Network Physical Adapter Network LAN Adapter Virtual Machine 3 Virtual DHCP Server Virtual Network Virtual Network Adapter Adapter Figure 3-3. NAT Network The NAT Service used in some virtualization products have been exploited by buffer overflows. These buffer overflows allow an attacker to execute arbitrary code with the privileges of the NAT service and potentially cause a denial of service. When a virtual machine is using NAT networking, a malicious guest virtual machine could potentially use a specific NAT networking configuration to execute unwanted code on the host virtualization server. Upgrading to the latest version of software should fix the vulnerability.
  37. 37. • (VCGEN0198: CAT II) The IAO/SA will ensure NAT networking is not implemented in a production environment. NOTE: This does not apply to the ESX Server. Host-only networking provides a network connection between the virtualization server and the virtual machines located on that server. It uses a virtual network adapter that is visible only to the virtualization server. The entire network is virtual and isolated from everything on the outside of the virtualization server. Only the virtual machines on the virtualization server and the virtualization network adapter are connected to a private TCP/IP network. Communication also is possible between the virtual machines since IP addresses may be provided by the virtual DHCP server. Figure 3-4 illustrates a Host-Only networking. Virtual Server Virtual Machine 1 No connection to physical network Virtual Network Adapter Virtual Machine 2 Virtual Switch Virtual Network Physical Adapter Network LAN Adapter Virtual Machine 3 Virtual DHCP Server Virtual Network Virtual Network Adapter Adapter Figure 3-4. Host-Only Network Some virtualization server products such as VMware Virtual Server include utilities for troubleshooting virtual networks. These tools are used to sniff packets from the virtual machines virtual network adapters. These tools will only be accessible to the administrator of the host virtualization server, since these tools could expose information about databases, users, passwords, records, etc. Restricting access to these tools to the administrator or root user of the virtualization server provides some level of protection against unauthorized use. Furthermore, these tools should be used only when troubleshooting a virtual infrastructure problem. • (VCGEN0200: CAT II) The IAO/SA will ensure all virtualization server packet sniffing utilities are restricted to only the administrator or root user of the virtualization server.
  38. 38. MAC Addresses Every Ethernet network interface card, whether physical or virtual, has a unique identifier assigned to it know as the media access control or MAC address. Ethernet MAC addresses are typically shown as a string of 12 hexadecimal digits. The first six digits identify the vendor ID or the manufacturer of the card and are known as the Organizational Unique Identifier (OUI). The OUI prefixes are assigned to organizations by the IEEE. The last six digits are assigned by the manufacturer of the card and are known as the burned-in address. The MAC address of the virtual network adapter will be unique and whether it is dynamic or static. For instance, the MAC address 00:09:6B:BF:6D:31, the OUI would be 00:09:6B, which is IBM. Virtualization vendors do not manufacture any physical network adapters, however, they do provide virtual ones. For instance, VMware has two OUIs. The first VMware OUI is for automatically generated MAC addresses, and the second VMware OUI is used for MAC addresses that are manually set. Once the virtual MAC address has been generated it becomes static, unless the virtual machine is moved to a different location. For instance, a virtual MAC address could change if the virtual machine has a different path on the same server or moved to a different virtualization server. MAC addresses are saved in the configuration file of the virtual machine. The MAC address of powered-off virtual machines is not checked against running or suspended virtual machines. Therefore it is possible that when a virtual machine is powered on again, it can get a different MAC address. • (VCGEN0202: CAT III) The IAO/SA will ensure all dynamic or static MAC addresses of all virtual network adapters are unique. 3.5 Virtual Machine Hard Drive Disk Management 3.5.1 Sharing and Moving Virtual Machine Files As virtual machines replace real hardware they can undermine the security architecture of many organizations which often assume predictable and controlled change number of hosts, host configurations, hosts location, etc. Some useful mechanisms that virtual machines provide are copying or sharing virtual machine hard disks. Copying or sharing virtual machine hard disks can be done over networks and removable media. Typically, test and development virtual machines will be moved and updated more frequently than production virtual machines. There will be a policy in place to restrict the copying and sharing of production virtual machines over networks and removable media to ensure that administrators do not give unauthorized users access to the virtual machine files. • (VCGEN0204: CAT III) The IAO/SA will have a policy in place to restrict copying or sharing virtual machine files over networks and removable media. NOTE: This does not apply to snapshot backups, disaster recovery virtual machines, and virtual machines in a cluster.
  39. 39. 3.5.2 Virtual Hard Drive Disk Types Virtual hard disks provide storage for virtual machines. Within the virtual machine, the virtual hard disk is represented as a physical disk and is used by the virtual machine as if it were a physical disk. Technically, the virtual hard disk is a file that resides on a physical disk that the virtual server can access. On the physical disk, the virtual hard disk file is stored as a .vhd, .vmdk, etc. The virtualization server may create a virtual hard disk on any storage that the host file system can access including IDE, SCSI, RAID, SAN, NAS, and so forth. The virtual machine accesses the virtualized IDE/SCSI device and the VMM maps that to the physical device access. Virtual machines can access virtual hard disks on any storage topology, including SAN and NAS configurations, supported by the underlying virtualization server. Virtual hard disk drives support additional features and functionality that are not usually available with physical hard disk drives. These features are available through the use of different virtual hard disks. A virtual hard disk drive may exist as a fixed disk, dynamic disk, differencing disk, or a raw disk. Additionally, virtual hard disk drives may be configured with a redo or undo log file that alters the persistence behavior of the drive. Each of the hard disk drive types are discussed below. A fixed disk is a virtual hard disk drive that most closely resembles a physical hard disk drive. The fixed disk is represented by a fixed-extent file residing on the virtualization server. When a fixed disk is created, the file is sized immediately to its maximum size, consuming an equal amount of storage from the virtualization server. The file on the virtualization server will always remain the size it was originally given. Fixed disks will typically provide better performance than dynamic disks because there is no overhead due to growth. Fixed virtual disks will be allocated according to the space requirements for the server. These virtual disk sizes will be verified for integrity. Figure 3-5 illustrates a fixed disk 10GB Total File Size 3GB 7GB Data Empty Space Figure 3-5. Fixed Disk • (VCGEN0206: CAT III) The IAO/SA will ensure all fixed virtual hard disk drives are allocated according to the space required by the documented virtual machine requirements. A dynamic disk is a virtual disk drive that begins as a sparse file, consuming only the amount of storage from the virtualization server that is needed, and grows as new data is written to the virtual hard disk drive. When the dynamic disk is created, the maximum size of the disk is

×