© 2010 VMware, Inc.
VMware, Inc.
ESXi Server 3.5 and VirtualCenter 2.5
Security Target
Evaluation Assurance Level: EAL4+
Document Version: 0.7
Prepared for: Prepared by:
VMware, Inc. Corsec Security, Inc.
3401 Hillview Ave
Palo Alto, CA 94304
10340 Democracy Lane, Suite 201
Fairfax, VA 22030
Phone: (650) 475-5000 Phone: (703) 267-6050
http://www.vmware.com http://www.corsec.com
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 2 of 65
© 2010 VMware, Inc.
Table of Contents
TABLE OF CONTENTS ............................................................................................................................................2
1 SECURITY TARGET INTRODUCTION........................................................................................................4
1.1 PURPOSE.........................................................................................................................................................4
1.2 SECURITY TARGET AND TOE REFERENCES....................................................................................................5
1.3 PRODUCT OVERVIEW......................................................................................................................................5
1.3.1ESXi Server............................................................................................................................................................5
1.3.2VirtualCenter.........................................................................................................................................................5
1.4 TOE OVERVIEW .............................................................................................................................................6
1.4.1Physical Scope.......................................................................................................................................................6
1.4.2Logical Scope ........................................................................................................................................................8
1.4.3Product Physical/Logical Features and Functionality not included in the TOE.................................................11
1.5 TOE DESCRIPTION .......................................................................................................................................12
1.5.1Brief Description of the Components of the TOE ................................................................................................12
1.5.2TOE Environment................................................................................................................................................15
2 CONFORMANCE CLAIMS............................................................................................................................16
3 SECURITY PROBLEM DEFINITION ..........................................................................................................17
3.1 THREATS TO SECURITY.................................................................................................................................17
3.2 ORGANIZATIONAL SECURITY POLICIES ........................................................................................................18
3.3 ASSUMPTIONS ..............................................................................................................................................18
4 SECURITY OBJECTIVES ..............................................................................................................................19
4.1 SECURITY OBJECTIVES FOR THE TOE...........................................................................................................19
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ...................................................................19
4.2.1IT Security Objectives..........................................................................................................................................19
4.2.2Non-IT Security Objectives..................................................................................................................................20
5 EXTENDED COMPONENTS DEFINITION ................................................................................................21
5.1 EXTENDED TOE SECURITY FUNCTIONAL COMPONENTS ..............................................................................21
5.1.1Class FDP: User Data Protection.......................................................................................................................22
5.1.2Class FIA: Identification and authentication ......................................................................................................24
5.1.3Class EXT_VDS: Virtual machine domain separation........................................................................................25
5.2 EXTENDED TOE SECURITY ASSURANCE COMPONENTS ...............................................................................26
6 SECURITY REQUIREMENTS.......................................................................................................................27
6.1.1Conventions.........................................................................................................................................................27
6.2 SECURITY FUNCTIONAL REQUIREMENTS......................................................................................................27
6.2.1Class FAU: Security Audit...................................................................................................................................29
6.2.2Class FCS: Cryptographic Support.....................................................................................................................31
Class FDP: User Data Protection...............................................................................................................................32
6.2.3Class FIA: Identification and Authentication......................................................................................................37
6.2.4Class FMT: Security Management ......................................................................................................................38
6.2.5Class FPT: Protection of the TSF .......................................................................................................................42
6.2.6Class EXT_VDS: Virtual Machine Domain Separation ......................................................................................43
6.3 SECURITY ASSURANCE REQUIREMENTS .......................................................................................................44
7 TOE SUMMARY SPECIFICATION..............................................................................................................45
7.1 TOE SECURITY FUNCTIONS..........................................................................................................................45
7.1.1Security Audit ......................................................................................................................................................46
7.1.2Cryptographic Support........................................................................................................................................47
7.1.3User Data Protection...........................................................................................................................................47
7.1.4Identification and Authentication ........................................................................................................................49
7.1.5Security Management ..........................................................................................................................................49
7.1.6Protection of the TSF...........................................................................................................................................51
7.1.7Virtual Machine Domain Separation...................................................................................................................51
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 3 of 65
© 2010 VMware, Inc.
8 RATIONALE.....................................................................................................................................................53
8.1 CONFORMANCE CLAIMS RATIONALE ...........................................................................................................53
8.2 SECURITY OBJECTIVES RATIONALE..............................................................................................................53
8.2.1Security Objectives Rationale Relating to Threats ..............................................................................................53
8.2.2Security Objectives Rationale Relating to Policies..............................................................................................56
8.2.3Security Objectives Rationale Relating to Assumptions ......................................................................................56
8.3 RATIONALE FOR EXTENDED SECURITY FUNCTIONAL REQUIREMENTS .........................................................57
8.4 RATIONALE FOR EXTENDED TOE SECURITY ASSURANCE REQUIREMENTS..................................................58
8.5 SECURITY REQUIREMENTS RATIONALE........................................................................................................58
8.5.1Rationale for Security Functional Requirements of the TOE Objectives.............................................................59
8.5.2Security Assurance Requirements Rationale .......................................................................................................62
8.5.3Dependency Rationale.........................................................................................................................................62
9 ACRONYMS......................................................................................................................................................64
Table of Figures
FIGURE 1 – PHYSICAL TOE BOUNDARY.........................................................................................................................8
FIGURE 2 – DEPLOYMENT CONFIGURATION OF THE TOE.............................................................................................12
FIGURE 3 – EXT_FDP_VC_ETC EXPORT OF VIRTUALCENTER DATA FAMILY DECOMPOSITION................................22
FIGURE 4 – EXT_FDP_VC_ITC IMPORT OF VIRTUALCENTER DATA FAMILY DECOMPOSITION .................................22
FIGURE 5 – EXT_FIA_VC_LOGIN VIRTUALCENTER USER LOGIN REQUEST FAMILY DECOMPOSITION ......................24
FIGURE 6 – EXT_VDS_VMM ESXI VIRTUAL MACHINE DOMAIN SEPARATION FAMILY DECOMPOSITION ...................25
Table of Tables
TABLE 1 – ST AND TOE REFERENCES............................................................................................................................5
TABLE 2 – COMPONENTS OF THE TOE ...........................................................................................................................7
TABLE 3 – CC AND PP CONFORMANCE ........................................................................................................................16
TABLE 4 – THREATS .....................................................................................................................................................17
TABLE 5 – ASSUMPTIONS .............................................................................................................................................18
TABLE 6 – SECURITY OBJECTIVES FOR THE TOE .........................................................................................................19
TABLE 7 – IT SECURITY OBJECTIVES ...........................................................................................................................20
TABLE 8 – NON-IT SECURITY OBJECTIVES...................................................................................................................20
TABLE 9 – EXTENDED TOE SECURITY FUNCTIONAL REQUIREMENTS..........................................................................21
TABLE 10 – TOE SECURITY FUNCTIONAL REQUIREMENTS ..........................................................................................27
TABLE 11 – AUDITABLE EVENTS ON ESXI SERVER ..........................................................................................................29
TABLE 12 – CRYPTOGRAPHIC OPERATIONS..................................................................................................................31
TABLE 13 – FMT_MSA.1(B) – SECURITY ATTRIBUTES, ACTIONS, AND ROLES..................................................................38
TABLE 14 – FMT_MSA.3(B) - ROLES AND OBJECTS/INFORMATION............................................................................40
TABLE 15 – ASSURANCE REQUIREMENTS.....................................................................................................................44
TABLE 16 – MAPPING OF TOE SECURITY FUNCTIONS TO SECURITY FUNCTIONAL REQUIREMENTS.............................45
TABLE 17 – AUDIT RECORD CONTENTS .......................................................................................................................46
TABLE 18 – RELATIONSHIP OF SECURITY THREATS TO OBJECTIVES ............................................................................53
TABLE 19 – THREATS:OBJECTIVES MAPPING...............................................................................................................53
TABLE 20 – ASSUMPTIONS:OBJECTIVES MAPPING .......................................................................................................56
TABLE 21 – RELATIONSHIP OF SECURITY REQUIREMENTS TO OBJECTIVES ..................................................................58
TABLE 22 – OBJECTIVES:SFRS MAPPING.....................................................................................................................59
TABLE 23 – FUNCTIONAL REQUIREMENTS DEPENDENCIES ..........................................................................................62
TABLE 24 – ACRONYMS ...............................................................................................................................................64
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 4 of 65
© 2010 VMware, Inc.
1 Security Target Introduction
This section identifies the Security Target (ST), Target of Evaluation (TOE), and the ST organization. The Target of
Evaluation is VMware ESXi Server 3.5 and VirtualCenter 2.5, and will hereafter be referred to as the TOE
throughout this document. The TOE is a system which can provide multiple virtual machines (VMs) on industry
standard x86-compatible hardware platform and allows the management of these virtual machines.
The TOE components are undergoing name changes. In September 2008, VMware announced name changes for
one of the TOE components included in this evaluation: “VMware ESXi Server” was renamed to “VMware ESXi”,
“VMware VirtualCenter Server” was renamed “VMware vCenter Server”, and “VMware Update Manager” was
renamed “VMware vCenter Update Manager”. Most current web pages, electronic media, and new literature have
adopted the new name changes; however, text contained in the TOE components and TOE literature have not fully
implemented the name changes.
1.1 Purpose
This ST provides contains the following sections to provide mapping of the Security Environment to the Security
Requirements that the TOE meets in order to remove, diminish or mitigate the defined threats:
 Security Target Introduction(Section 1) – Provides a brief summary of the ST contents and describes the
organization of other sections within this document. It also provides an overview of the TOE security
functions and describes the physical and logical scope for the TOE, as well as the ST and TOE references.
 Conformance Claims (Section 2) – Provides the identification of any Common Criteria (CC), ST Protection
Profile (PP), and Evaluation Assurance Level (EAL) package claims. It also identifies whether the ST
contains extended security requirements.
 Security Problem Definition (Section 3) – Describes the threats, organizational security policies, and
assumptions that pertain to the TOE and its environment.
 Security Objectives (Section 4) – Identifies the security objectives that are satisfied by the TOE and its
environment.
 Extended Components Definition (Section 5) – Identifies new components (extended Security Functional
Requirements (SFRs) and extended Security Assurance Requirements (SARs)) that are not included in CC
Part 2 or CC Part 3.
 Security Requirements (Section 6) – Presents the SFRs and SARs met by the TOE.
 TOE Summary Specification (Section 7) – Describes the security functions provided by the TOE that satisfy
the security functional requirements and objectives.
 Rationale (Section 8) - Presents the rationale for the security objectives, requirements, and SFR
dependencies as to their consistency, completeness, and suitability.
 Acronyms (Section 9) – Defines the acronyms used within this ST.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 5 of 65
© 2010 VMware, Inc.
1.2 Security Target and TOE References
Table 1 – ST and TOE References
ST Title VMware, Inc. ESXi Server 3.5 and VirtualCenter 2.5 Security Target
ST Version Version 0.7
ST Author
Justin Yu
ST Publication Date 02/09/2010
TOE Reference VMware ESXi Server 3.5 and VirtualCenter 2.5
1.3 Product Overview
1.3.1 ESXi Server
ESXi is a “bare metal” hypervisor, meaning it installs directly on top of the physical server and partitions it into
multiple virtual machines that can run simultaneously, sharing the physical resources of the underlying server. Each
virtual machine represents a complete system, with processors, memory, networking, storage and BIOS1
, and can
run an unmodified operating system and applications. ESXi is the latest hypervisor architecture from VMware. It
has an ultra-thin architecture with no reliance on a general-purpose OS2
, yet still offers all the same functionality and
performance of VMware ESX.
1.3.2 VirtualCenter
VMware VirtualCenter delivers centralized management, operational automation, resource optimization and high
availability to IT3
environments. Virtualization-based distributed services equip the data center with unprecedented
levels of responsiveness, serviceability, efficiency and reliability. VirtualCenter delivers the highest levels of
simplicity, efficiency, security and reliability required to manage virtualized IT environment of any size.
VirtualCenter uses a database (called “VirtualCenter Database”) to store information about the configuration and
status of all ESX Server hosts under management and each of the host’s virtual machines. VirtualCenter Database
also stores management information for the ESX Server, including the following:
 Scheduled tasks: a list of activities and a means to schedule them
 Alarms: a means to create and modify a set of alarms that apply to an organizational structure and contain
triggering event and notification information
 Events: a list of all the events that occur in the VirtualCenter environment. Audit data are stored as events.
 Stores user and VirtualCenter object permissions
1
BIOS – Basic Input Output Signal
2
OS – Operating System
3
IT – Information Technology
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 6 of 65
© 2010 VMware, Inc.
VirtualCenter Database is implemented by installing 3rd
party DBMS4
products. Section 1.5.2 (TOE Environment)
lists the database products supported by VMware VirtualCenter, for the implementation of VirtualCenter Database.
The use of VirtualCenter also provides the following system management services:
 VMotion – Allows the migration of running virtual machines between physical servers without disruption to
end users.
 Distributed Resource Scheduler (DRS) – dynamically allocates and balances computing capacity across
collections of hardware resources aggregated into unified resource pools.
 VMware HA5
– High availability provided by VMware HA enables a broad-based and cost-effective
application failover that is independent of hardware and operating systems.
1.4 TOE Overview
This section primarily addresses the physical and logical components of the TOE included in the evaluation.
1.4.1 Physical Scope
The ESXi Server is a user-installable or OEM6
-embedded virtualization layer that runs directly on industry standard
x86-compatible hardware, allowing multiple virtual machines to be hosted on one physical server. The ESXi Server
abstracts processor, memory, storage, and networking resources to create virtual machines which can run a wide
variety of different Operating Systems. Each virtual machine acts as a physically separated guest and only
communicates with other virtual machines using networking protocols. VirtualCenter acts as a management
console, deploying, monitoring, and managing virtual machines that are distributed across multiple hosts running the
ESXi Server software. VMware Update Manager handles updates and patches for the TOE.
Figure 1 below illustrates the physical scope and the physical boundary of the overall solution and ties together all of
the components of the TOE and the constituents of the TOE Environment. Table 2 indicates which elements of the
product are included in the TOE boundary.
4
DBMS – Database Management System
5
HA – High Availability
6
OEM – Other Equipment Manufacturer
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 7 of 65
© 2010 VMware, Inc.
Table 2 – Components of the TOE
Component TOE TOE
Environment
VirtualCenter 2.5 Software (includes VirtualCenter Server, VirtualCenter agent, and Virtual
Infrastructure Client (VIC), VMotion, Distributed Resource Scheduler, VMware HA, Tomcat,
OpenSSL)

VMware Update Manager (VUM) v1.0 U4 Software (on the VirtualCenter machine) 
ESXi Server 3.5 software (includes virtual symmetric multiprocessing (SMP), OpenSSL) 
NTP
7
Client on Virtual Infrastructure Client 
NTP Client on ESXi Server 
NTP Server available to ESXi Server and VirtualCenter 
ESXi Server hardware (processor and adapters) including blade servers 
SAN
8
hardware and software to be used with ESXi Server in VM Storage Configurations 2 
VirtualCenter Hardware, operating system, and database 
Virtual Infrastructure Client hardware and operating system 
Operating systems and applications running in VMs 
Hardware, OS, and software (as identified in the previous sections) for remote workstations 
7
NTP – Network Time Protocol
8
SAN – Storage Area Network
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 8 of 65
© 2010 VMware, Inc.
Figure 1 – Physical TOE Boundary
The undefined acronyms that appear in Figure 1 are:
 DB – Database
 DCUI – Direct Console User Interface
 HTTP – HyperText Transfer Protocol
 HTTPS – Secure Hypertext Transfer Protocol
 ISP – Internet Service Provider
 SSL – Secure Sockets Layer
1.4.2 Logical Scope
The security functional requirements implemented by the TOE are usefully grouped under the following Security
Function Classes:
 Security Audit
 User Data Protection
 Cryptographic Support
 Identification and Authentication
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 9 of 65
© 2010 VMware, Inc.
 Security Management
 Protection of the TOE Security Functions (TSF)
 Virtual Machine Domain Separation
1.4.2.1 Security Audit
The auditing security function of the TOE is provided by both ESXi Server and VirtualCenter. Audit data collected
by the ESXi Server is stored in a flat file on the ESXi Server’s ramdisk or local storage depending on storage
configuration. Audit data collected by VirtualCenter is stored as events in the VirtualCenter Database. Each audit
record generated includes the date and time of the event, the type of event, the subject identity (if applicable), and
the outcome (success or failure) of the event. The identity of the virtual machine, the scheduled task, or alarm
identity will also be recorded, if applicable.
VirtualCenter provides the capability to review its audit records by reviewing the event logs stored on the
VirtualCenter Database. Only a VirtualCenter Administrator can view all the event logs. Audit events are viewed
through the Virtual Infrastructure Client under the event tab for each organizational object. The ESXi Server stores
its audit records in /var/log/messages and /var/log/vmware directories. Reviewing the audit records on the ESXi
Server is restricted to the ESXi Server System Administrator.
1.4.2.2 Cryptographic Support
The TOE protects the confidentiality and integrity of all data as it passes between the remote components of the
TOE, or from the TOE to another trusted IT product. The TOE achieves this by using OpenSSL which performs the
encryption and the decryption of data that is being passed.
The TOE implements CAVP-validated cryptographic algorithms to handle all cryptographic functions for the
encryption and the decryption of data.
1.4.2.3 User Data Protection
The TOE provides two distinct access control mechanisms. One is used for verifying access to objects under the
control of the ESXi Server by users logged into the ESXi Server and users who make requests on the ESXi Server
from the VirtualCenter. The other is used for verifying access to objects on the VirtualCenter by users logged into
VirtualCenter. Each access control mechanism is described below.
Note that for purposes of this ST, Administrative users are considered to be the users of the TOE. VM users
(individuals who access the guest operating system and applications within a virtual machine) are outside the scope
of the TOE and are not discussed any further here.
The VirtualCenter access control mechanism controls access to objects stored on the VirtualCenter, such as virtual
machines, and VM Groups. The VirtualCenter access control mechanism also controls access to file events, alarm,
and scheduled event information. This information is stored in the VirtualCenter Database. It should be noted that
the VirtualCenter access control mechanism is enforced when the VirtualCenter accesses the VirtualCenter data
stored in VirtualCenter Database. The VirtualCenter access control mechanism also controls access by a
VirtualCenter user to data and operations specific to the definition, configuration, and management of virtual
machines. ESXi Server-specific information is physically stored on the hosting ESXi Server, and is made available
to the VirtualCenter user via the VirtualCenter Agent installed on the ESXi Server.
The ESXi Server supports the roles of system administrator and VM administrator. Users of the system
administrator role have unrestricted access in the ESXi Server. Once an ESXi Server is placed under the
management of a VirtualCenter, requests from the VirtualCenter users are processed using the account, vpxuser,
which uses the system administrator role. From the local console or from the management interface, system
administrator or root user access requests are processed in a manner similar to Linux operating systems. They have
access to any ESXi or VM data on the system. In contrast, the VM administrators cannot modify the ESXi
configuration files or data. User access control for VM administrators is the standard user, /group, /and other access
control mechanism found in Linux operating systems.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 10 of 65
© 2010 VMware, Inc.
1.4.2.4 Identification and Authentication
When a user logs into ESXi Server, a user name and password are requested before any access is given. These
authentication credentials are compared with the authentication credentials stored on the ESXi Server in a shadow
file, where the password is hashed using Secure Hash Algorithm-1 (SHA-1). If the authentication credentials are
valid, access to the system is provided, with the privileges appropriate to the role assigned to that user. If the
credentials are not valid, the user is presented with another chance to provide valid credentials.
When a user logs into VirtualCenter, the user is presented with a login screen, requesting the VirtualCenter name or
IP9
address, the user name, and the user password. The user information is passed to the underlying Windows
operating system which verifies the user identity and password. If login is valid, the user at the Virtual
Infrastructure Client is presented with the Virtual Infrastructure Client interface denoting a successful login. If login
is invalid, a message is displayed, and the login window remains available for the user to retry.
When VMware Update Manager starts up, it authenticates with VirtualCenter. VUM does not access the ESXi
Server; rather the ESXi Server will always call VUM, thereby ensuring that only the VUM that is installed with the
TOE will be able to download updates and patches to the ESXi Server.
1.4.2.5 Security Management
The TOE ensures that the ability to modify user privileges on VirtualCenter objects is restricted to a VirtualCenter
Administrator, or to an administrator-defined role explicitly given the required permissions.
The TOE ensures that the ability to modify permissions of users on ESXi objects is restricted to system
administrators. The capability to modify permissions of users on objects is provided by functions of the ESXi
Server that are inherited from the customized Linux kernel which the ESXi Server leverages.
1.4.2.6 Protection of the TSF
The Protection of the TSF function provides the integrity and management of the mechanisms that provide the TSF.
Protection of the TOE from physical tampering is ensured by its environment. It is the responsibility of the
administrator to assure that physical connections made to the TOE remain intact and unmodified. The TOE protects
information as it is transmitted between remote components of the TOE by using OpenSSL. HTTP communications
between VUM and the ISP Server10
, and between VUM and the ESXi Server, are protected by signature
verification.
Non-bypassability of the TOE is provided by a combination of basic configuration and enforcement of security
policy rules. Each subject’s and user’s security privileges are separated. It is not possible to perform any actions on
the system without successfully authenticating. Once a user has been authenticated, the user is bound to the
appropriate roles and any privileges defined by the TOE access control. All access control rights are checked by the
TOE’s mechanisms and the TOE uses unique attributes for each user, then the TSF maintains separation between
different users. As an example, if a user without explicit permission tries to configure a virtual machine, the user
will not be able to save the changes.
1.4.2.7 Virtual Machine Domain Separation
The virtual machine separation security function of the TOE is provided by the ESXi Server component. The TOE
ensures that each virtual machine is isolated from any other virtual machines co-existing on the ESXi Server. This
isolation is provided at the virtualization layer of the ESXi Server. The virtualization layer of the ESXi Server
ensures that virtual machines are unable to directly interact with other virtual machines yet still allow for physical
resources to be shared among the existing virtual machines.
9
IP – Internet Protocol
10
This ISP server provides access to the servers for downloading patches and updates.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 11 of 65
© 2010 VMware, Inc.
The ESXi Server provides an idealized hardware environment and virtualization of underlying physical resources.
Each virtual machine runs its own operating system and applications: they cannot communicate to each other in
unauthorized ways, nor can they leak data.
1.4.3 Product Physical/Logical Features and Functionality not included in the
TOE
Each virtual machine can have users who are individuals using a virtual machine’s guest operating system and
applications that reside on the virtualized hardware of the virtual machine that is instantiated on an ESXi Server.
These users access the VM via a remote workstation called a Remote Console, using an Internet Protocol (IP)
address associated with the specific virtual machine. The VMs themselves, their operating systems, applications,
and users are outside the scope of the TOE. The claims of the TOE are relevant to the management, separation,
isolation, and protection of the virtual machine structures, and not of the functionality and actions that take place
within a VM, and as such do not address the security issues within each VM.
The following features of the system are excluded from the evaluation.
 Simple Network Management Protocol (SNMP), File Transfer Protocol (FTP), Telnet
 The use of any authentication method on ESXi Server other than the local password database
 VMware Software Development Kit (SDK) tools
 VMware Scripting Application Programming Interface (API) on the ESXi Server
 VMware Consolidated Backup
 Guest OS patch updates via Update Manager
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 12 of 65
© 2010 VMware, Inc.
1.5 TOE Description
The TOE Overview summarizes the usage and major security features of the TOE. The TOE Overview provides a
context for the TOE evaluation by identifying the TOE type, describing the product, and defining the specific
evaluated configuration.
This evaluation is of the VMware ESXi Server 3.5 and VirtualCenter 2.5. ESXi is a platform for hosting virtual
machines. It runs directly on industry standard x86-compatible hardware and abstracts the resources to provide
multiple virtual machines. VirtualCenter is a centralized management tool for one or more ESXi Servers.11
Figure 2 shows the details of the deployment configuration of the TOE:
Figure 2 – Deployment Configuration of the TOE
1.5.1 Brief Description of the Components of the TOE
1.5.1.1 VirtualCenter
VirtualCenter provides centralized management of ESXi Servers. Through VirtualCenter, an administrator can
configure an ESXi Server, which includes viewing and managing the networking, data storage, security settings,
user privileges and various object permissions. VirtualCenter also allows the provisioning of virtual machines on
the ESXi Server. For example, virtual machines can be created, configured, cloned and relocated. VirtualCenter
11
VirtualCenter also provides centralized management of VMware ESX Servers.
ESXi
Hardware
VirtualCenter
Windows OS
VM
Third Party
Products
Key
VMware
Products
VM VM
ESXi
Hardware
VM VM VM
ESXi
Hardware
VM VM VM
ESXi
Hardware
VM VM VM
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 13 of 65
© 2010 VMware, Inc.
communicates with the ESXi Server via the VirtualCenter agent located on the ESXi Server. The confidentiality
and integrity of this communication is protected using the Secure Sockets Layer protocol and, optionally,
certificates. SSL is provided using the OpenSSL embedded within VirtualCenter. The VirtualCenter's SSL
implementation uses algorithms that are CAVP-validated against FIPS12
requirement.
1.5.1.1.1 VirtualCenter Access Methods
VirtualCenter can be accessed by users via two different methods: by using the standalone Virtual Infrastructure
Client software, or by using the Virtual Infrastructure Web Access client via a web browser.
1.5.1.1.1.1 Virtual Infrastructure Client
Users connect to VirtualCenter via the Virtual Infrastructure Client either locally (on the same machine as
VirtualCenter) or remotely, from a workstation running the Virtual Infrastructure Client software. Communication
with the Virtual Infrastructure Client is protected using SSL.
1.5.1.1.1.2 Virtual Infrastructure Web Access Client
Users connect via the Virtual Infrastructure (VI) Web Access Client through a web browser. The VI Web Access
client provides a subset of the functionality provided by the Virtual Infrastructure Client. The VI Web Access client
interface is provided by a Tomcat servlet engine in VirtualCenter. Thus, the VI Web Access Client is a component
of VirtualCenter and a part of the TOE. The VI Web Access Client provides a subset of the functionality provided
by the Virtual Infrastructure Client. Communication between the Virtual Infrastructure Web Access Client and the
web browser is protected using HTTPS, as shown in Figure 1.
1.5.1.2 VMware Update Manager
The VMware Update Manager (VUM) provides automated patch management for the ESXi Server, and compares it
with a baseline set by the administrator. It then applies updates and patches to enforce compliance to mandated
patch standards. VUM is also able to automatically patch and update the Guest Operating Systems being run in the
Virtual Machines, but this is outside of the scope of this evaluation.
After performing a scan against the ESXi Server, VUM accesses VMware’s website to download keys and other
metadata about the patches via HTTPS. It then sends the key to an ISP server, which accesses the appropriate server
to retrieve updates. VUM then downloads the patches to be installed on the TOE via HTTP, and uses a certificate to
verify the signature on the downloaded binary, thereby ensuring that it is the correct one. VUM stores the binary
locally on the VirtualCenter machine. The ESXi Server then pulls the appropriate updates and patches from VUM’s
database via HTTP, using a key and signature to verify the downloaded binaries.13
1.5.1.3 ESXi Server
The ESXi Server is a user-installable or OEM-embedded virtualization layer that runs directly on industry standard
x86-compatible hardware, allowing multiple virtual machines to be hosted on one physical server. Virtual machines
are the containers in which guest operating systems run. By design, all VMware virtual machines are isolated from
one another. Virtual machine isolation is imperceptible to the guest operating system. Even a user with system
administrator privileges on a virtual machine’s guest operating system cannot breach this layer of isolation to access
another virtual machine without privileges explicitly granted by the ESXi system administrator. This isolation
enables multiple virtual machines to run securely while sharing hardware and ensures both their ability to access
hardware and their uninterrupted performance. The virtual Symmetric Multi-Processing feature enables a single
virtual machine to use multiple physical processor cores simultaneously. The number of virtual processors is
configurable for each virtual machine.
12
FIPS – Federal Information Processing Standard
13
It should be noted that the use of the VUM feature can result in modifications to the CC-configuration of the TOE.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 14 of 65
© 2010 VMware, Inc.
ESXi Server also provides robust virtual and virtualized networking. ESXi Server virtualizes the physical network
to which it is connected, allowing properly configured virtual machines to connect to and communicate via the
physical network as if they were directly connected to it. ESXi Server also implements virtual network switches,
called “vSwitches”. A vSwitch works much like a physical Ethernet switch – it detects which virtual machines and
physical network interfaces are logically connected to each of its virtual ports and uses that information to forward
traffic to the correct destination – but the vSwitch is implemented entirely in software as part of the ESXi Server.
ESXi vSwitches also implement VLAN14
s, which are an IEEE15
standard networking scheme with specific tagging
methods that allow routing of packets to only those ports that are part of the VLAN. The VLAN implementation in
ESXi Server allows the protection of a set of virtual machines from accidental or malicious intrusions.
ESXi Server uses a custom mini-HTTP server to support the ESXi landing page which allows the user to download
the Virtual Infrastructure Client, browse the host’s VM inventory and objects managed by the host, and links to
download remote management tools and user documentation. The confidentiality and integrity of this
communication, and communication with a client web browser and the ESXi mini-HTTP server is protected using
SSL, provided by OpenSSL.
The ESXi can also be accessed using a local console that is directly attached to the ESXi host. Only root users or the
users with system administrator role can access the ESXi host this way. The ESXi host provides the Direct Console
User Interface (DCUI), which is a BIOS-like, menu-driven user interface that is displayed only on the local console
of an ESXi Server. The DCUI is used for the initial configuration, viewing logs, restarting services and agents,
lockdown mode16
configuration, restarting server and resetting system defaults.
The ESXi Server can be installed in three distinct configurations.
 Installation Configuration 1: OEM: ESXi Server is pre-installed in flash-memory on a server purchased
from select OEMs.
 Installation Configuration 2: Installable Flash: ESXi Server is installed by the end-user in local flash-
memory.
 Installation Configuration 3: Installable Local Storage: ESXi Server is installed by the end-user on local
storage (such as a hard disk).
ESXi data can be stored in two different ways:
 VM Storage Configuration 1: Local Storage Only: ESXi Server is installed on local storage, and uses
local disk for storage for VM images and other VM data.
 VM Storage Configuration 2: ESXi Local/Virtual Machines on Storage Area Network (SAN) or Other
Supported Datastore: ESXi Server is installed on local storage, and Virtual machines are installed on a
SAN, NFS17
or iSCSI18
datastore.
In all configurations, the separation of virtual machine data and images is performed and managed by the ESXi
Server.
1.5.1.3.1 VirtualCenter Agent
14
VLAN – Virtual Local Area Network
15
IEEE – Institute of Electrical and Electronics Engineers
16
Lockdown mode – Enabling the lockdown mode disables remote access to the administrator account after the
VirtualCenter takes control of the ESXi Server. Lockdown mode is only available on ESXi Server.
17
NFS – Network File System
18
iSCSI – Internet Small Computer System Interface
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 15 of 65
© 2010 VMware, Inc.
The VirtualCenter Agent forwards requests for services from VirtualCenter users, when the ESXi Server is under the
management of a VirtualCenter. ESXi Server can only be managed by a single VirtualCenter. The requests from
VirtualCenter Agents are handled by the ESXi Server daemon in a manner similar to requests from users at the
console or browser interface.
1.5.2 TOE Environment
The VirtualCenter Server hardware must meet the following requirements:
 2.0 Gigahertz (GHz) or higher Intel or AMD x86 processor.
 2 Gigabytes (GB) RAM19
 560 Megabytes (MB) minimum free disk space, 2GB recommended20
.
 10/100 Ethernet adapter minimum
The VirtualCenter Server supports the following operating systems:
 Windows 2000 Server SP21
4 with Update Rollup 1
 Windows XP Pro SP2
 Windows 2003 Server SP1 (all releases except 64-bit)
 Windows 2003 Server R2
The VirtualCenter installer requires Internet Explorer 5.5 or higher in order to run.
The VirtualCenter Server supports the following databases:
 Microsoft SQL Server 2000 (SP4 only),
 Microsoft SQL Server 2000 Enterprise,
 Microsoft SQL Server 2005 Standard or Enterprise SP1 or SP2,
 Microsoft SQL Server 2005 Express SP2,
 Oracle 9i Release 2 Standard or Enterprise, or
 Oracle 10g Release 1 or Release 2 (versions 10.1.0.3.0 and higher only)
The Virtual Infrastructure Client hardware must meet the following requirements:
 266 Megahertz (MHz) or higher Intel or AMD x86 processor
 256MB RAM, 512 or higher recommended
 150MB free disk space
 10/100 Ethernet adapter
The Virtual Infrastructure Client is designed for the 32 bit versions of these operating systems:
 Windows 2000 Pro SP4
 Windows 2000 Server SP4 with Update Rollup 1
 Windows XP Pro SP2
 Windows 2003 Server SP1 (all releases except 64-bit)
19
RAM: Random Access Memory
20
Disk space requirements for VirtualCenter Server (including VUM) vary greatly as they are dependent factors
such as the number of ESX Servers and/or ESXi Servers managed, number of Virtual Machines managed, types of
Guest Operating System installed, and etc. VMware Update Manager Sizing Estimator on URL below can be used
to estimate disk space needed.
http://www.vmware.com/support/vi3/doc/vi3_vum_10_sizing_estimator.xls
21
SP – Service Pack/Service Package
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 16 of 65
© 2010 VMware, Inc.
 Windows 2003 Server R2
 Windows Vista Business
 Windows Vista Enterprise
The VI Web Access client is designed for these browsers:
 Windows: Internet Explorer 6.0 or higher, Netscape Navigator 7.0, Mozilla 1.X, Firefox 1.0.7 and higher
 Linux: Netscape Navigator 7.0 or later, Mozilla 1.x, Firefox 1.0.7 and higher
The ESXi Server hardware must meet the following requirements:
 OEM Configuration: One of the following servers:
o Dell 2950
o HP DL380 (Experimental support)
 Installable Configuration: At least two processors of one of the following types:
o 1500 MHz Intel Xeon and later, or AMD Opteron (32-bit mode) for ESXi and virtual SMP22
o 1500 MHz Intel Viiv or AMD A64 x2 dual core processors
 1GB RAM minimum
 One or more supported Ethernet controllers.
 One or more supported storage controllers
2 Conformance Claims
This section provides the identification for any CC, Protection Profile, and EAL package conformance claims.
Rationale is provided for any extensions or augmentations to the conformance claims. Rationale for CC and PP
conformance claims can be found in Section 8.1.
Table 3 – CC and PP Conformance
Common Criteria (CC)
Identification and
Conformance
Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2,
September 2007; CC Part 2 extended; CC Part 3 conformant; PP claim (none).
PP Identification
None
Evaluation Assurance
Level EAL4 (Augmented with Flaw Remediation (ALC_FLR.1))
22
SMP: Symmetric Multiprocessing
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 17 of 65
© 2010 VMware, Inc.
3 Security Problem Definition
This section describes the security aspects of the environment in which the TOE will be used and the manner in
which the TOE is expected to be deployed. It provides the statement of the TOE security environment, which
identifies and explains all:
 Known and presumed threats countered by either the TOE or by the security environment
 Organizational security policies with which the TOE must comply
 Assumptions about the secure usage of the TOE, including physical, personnel and connectivity aspects
3.1 Threats to Security
This section identifies the threats to the IT23
assets against which protection is required by the TOE or by the
security environment. One type of threat agent is an individual who is not authorized to use the TOE or the
protected network. Threat agents are assumed to:
 have public knowledge of how the TOE operates
 possess a low skill level
 have limited resources to alter TOE configuration settings
 have no physical access to the TOE
 possess a low level of motivation
 have a low attack potential
Other types of threat agents are:
 a processes running on a Virtual Machine that may cause tampering or interference in another VM’s
domain of execution,
 a process running on a Virtual Machine that may attempt to circumvent the operating mechanism of the
Virtual Networking scheme.
The IT assets requiring protection are the virtual machines running on the TOE. Removal, diminution and
mitigation of the threats are through the objectives identified in Section 4 - Security Objectives.
The following threats are applicable:
Table 4 – Threats
Name Description
T.COMINT An unauthorized individual may attempt to compromise the security of the data collected
and produced by the TOE by bypassing a security mechanism.
T.PRIVIL An unauthorized individual may gain access to the TOE and exploit system privileges to
gain access to TOE security functions and data.
T.VM A process running on one virtual machine might compromise the security of processes
running on other virtual machines.
23
IT – Information Technology
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 18 of 65
© 2010 VMware, Inc.
Name Description
T.VIRTUAL_NETWORK A process running on a virtual machine that attempts to deliver traffic to wrong VM or
external entity.
3.2 Organizational Security Policies
There are no Organization Security Policies.
3.3 Assumptions
This section describes the security aspects of the intended environment for the evaluated TOE. The operational
environment must be managed in accordance with assurance requirement documentation for delivery, operation, and
user guidance. The following specific conditions are required to ensure the security of the TOE and are assumed to
exist in an environment where this TOE is employed.
Table 5 – Assumptions
Name Description
A.DBMS The VirtualCenter database is configured so that it is only accessible to the VirtualCenter processes
and the VirtualCenter system administrator.
A.NOEVIL Users are non-hostile, appropriately trained, and follow all user guidance.
A.PHYSCL The ESXi Server and VirtualCenter components will be located within controlled access facilities
which will prevent unauthorized physical access. The Virtual Infrastructure Client component will only
connect to the server via the protected management network.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 19 of 65
© 2010 VMware, Inc.
4 Security Objectives
Security objectives are concise, abstract statements of the intended solution to the problem defined by the security
problem definition (see Section 3). The set of security objectives for a TOE form a high-level solution to the
security problem. This high-level solution is divided into two part-wise solutions: the security objectives for the
TOE, and the security objectives for the TOE’s operational environment. This section identifies the security
objectives for the TOE and its supporting environment.
4.1 Security Objectives for the TOE
The specific security objectives for the TOE are as follows:
Table 6 – Security Objectives for the TOE
Name Description
O.ACCESS The TOE must allow authorized users to access only appropriate TOE functions and data.
O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data,
ensuring that TOE users with the appropriate privileges, and only those TOE users, can exercise
such control.
O.AUDIT The TOE must gather audit records of actions on the TOE which may be indicative of misuse.
O.IDAUTH The TOE must be able to identify and authenticate users prior to allowing access to TOE
administrative functions and data.
O.SECURE The TOE must ensure the confidentiality and integrity of all System data as it passes between
remote components of the TOE.
O.VM The TOE must provide virtual machines with a domain of execution which is protected from
interference and tampering by virtual machines.
O.VLAN The TOE must ensure that network traffic traversing a vSwitch is only delivered to virtual machines
and physical interfaces that are part of the intended VLAN.
O.VSWITCH The TOE must ensure that network traffic traversing a vSwitch is only delivered to the intended
virtual machines and physical interfaces.
4.2 Security Objectives for the Operational Environment
4.2.1 IT Security Objectives
The following IT security objectives are to be satisfied by the environment:
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 20 of 65
© 2010 VMware, Inc.
Table 7 – IT Security Objectives
Name Description
OE.DBMS The IT Environment will only allow the VirtualCenter processes and the VirtualCenter system
administrator to access the VirtualCenter database.
OE.IDAUTH The IT Environment will provide reliable verification of the Virtual Infrastructure Client user
credentials.
OE.SEP The IT Environment will protect the TOE from external interference or tampering.
OE.TIME The IT Environment will provide reliable timestamps to the TOE.
4.2.2 Non-IT Security Objectives
The following non-IT environment security objectives are to be satisfied without imposing technical requirements
on the TOE. That is, they will not require the implementation of functions in the TOE hardware and/or software.
Thus, they will be satisfied largely through application of procedural or administrative measures.
Table 8 – Non-IT Security Objectives
Name Description
NOE.NOEVIL Users are non-hostile, appropriately trained, and follow all user guidance.
NOE.PHYSCL The ESXi Server and VirtualCenter components will be located within controlled access facilities
which will prevent unauthorized physical access. The Virtual Infrastructure Client component will
only connect to the server via the protected management network.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 21 of 65
© 2010 VMware, Inc.
5 Extended Components Definition
This section defines the extended SFRs and extended SARs met by the TOE. These requirements are presented
following the conventions identified in Section 6.1.1.
5.1 Extended TOE Security Functional Components
This section specifies the extended SFRs for the TOE. The extended SFRs are organized by class. Table 9
identifies all extended SFRs implemented by the TOE
Table 9 – Extended TOE Security Functional Requirements
Name Description
EXT_FDP_VC.ETC.1 Export of VirtualCenter data
EXT_FDP_VC_ITC.1 Import of VirtualCenter data
EXT_FIA_VC_LOGIN.1 VirtualCenter user login request
EXT_VDS_VMM.1 ESXi virtual machine domain separation
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 22 of 65
© 2010 VMware, Inc.
5.1.1 Class FDP: User Data Protection
Families in this class address the requirements for functions to establish and verify a claimed user identity. The
extended family “EXT_FDP_VC_ETC: Export of VirtualCenter data”, and “EXT_FDP_VC_ITC: Import of
VirtualCenter data” was modeled after FDP_ETC.1 and FDP_ITC.1, respectively.
5.1.1.1 Export of VirtualCenter data (EXT_FDP_VC_ETC)
Family Behavior
This family defines the behavior of the VirtualCenter when it exports VirtualCenter data to the VirtualCenter
database.
Figure 3 – EXT_FDP_VC_ETC Export of VirtualCenter Data Family decomposition
EXT_FDP_VC_ETC.1 Export of VirtualCenter data, defines the behavior of the VirtualCenter when exporting
VirtualCenter data to the VirtualCenter database. It was modeled after FDP_ETC.1.
EXT_FDP_VC_ETC.1 Export of VirtualCenter data
Hierarchical to: No other components
Dependencies: FDP_ACC.1(a)
This component will ensure that VirtualCenter data is exported to VirtualCenter from VirtualCenter database and
that the VirtualCenter Access Control Policy is enforced on VirtualCenter data that are exported.
EXT_FDP_VC_ETC.1.1 VirtualCenter shall enforce the VirtualCenter Access Control Policy when exporting
VirtualCenter data, controlled under the SFP, to the VirtualCenter database.
5.1.1.2 Import of VirtualCenter data (EXT_FDP_VC_ITC)
Family Behavior
This family defines the behavior of the VirtualCenter when it imports VirtualCenter data from the VirtualCenter
database.
Figure 4 – EXT_FDP_VC_ITC Import of VirtualCenter Data Family decomposition
EXT_FDP_VC_ITC.1 Import of VirtualCenter data, defines the behavior of the VirtualCenter when importing
VirtualCenter data from VirtualCenter database. It was modeled after FDP_ITC.1.
EXT_FDP_VC_ITC: Import of VirtualCenter data 1
EXT_FDP_VC_ETC: Export of VirtualCenter data 1
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 23 of 65
© 2010 VMware, Inc.
EXT_FDP_VC_ITC.1 Import of VirtualCenter data
Hierarchical to: No other components
Dependencies: FDP_ACC.1(a)
This component will ensure that VirtualCenter imports VirtualCenter data from the VirtualCenter database and that
the VirtualCenter Access Control Policy is enforced on VirtualCenter data that are imported.
EXT_FDP_VC_ITC.1.1 VirtualCenter shall enforce the VirtualCenter Access Control Policy when importing
VirtualCenter data, controlled under the SFP, from the VirtualCenter database.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 24 of 65
© 2010 VMware, Inc.
5.1.2 Class FIA: Identification and authentication
Families in this class address the requirements for functions to establish and verify a claimed user identity. The
extended family “EXT_FIA_VC_LOGIN: VirtualCenter user login request” was modeled after the other FIA SFRs.
5.1.2.1 VirtualCenter user login request (EXT_FIA_VC_LOGIN)
Family Behavior
This family defines the identification and authentication behavior of the VirtualCenter component of the TOE.
Component Leveling
Figure 5 – EXT_FIA_VC_LOGIN VirtualCenter user login request family decomposition
EXT_FIA_VC_LOGIN.1 VirtualCenter user login request, defines the behavior of the VirtualCenter component
when identifying and authenticating an administrative user. It was modeled after FIA_UAU.1 and FIA_UID.1.
EXT_FIA_VC_LOGIN.1 VirtualCenter user login request
Hierarchical to: No other components
Dependencies: None
This component will provide users the capability to identify and authenticate themselves to VirtualCenter, via a
credential authority stored in the Environment.
EXT_FIA_VC_LOGIN.1.1 VirtualCenter shall request identification and authentication from the
VirtualCenter environment for a VirtualCenter user, and receive notification of success, prior to granting
any other TSF-mediated actions on behalf of the user.
FIA _ _LOGIN: VirtualCenter user login request 1
EXT_ VC
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 25 of 65
© 2010 VMware, Inc.
5.1.3 Class EXT_VDS: Virtual machine domain separation
Virtual machine domain separation functions ensure that virtual machines cannot inappropriately or unintentionally
interact with or tamper with each other. The extended class "EXT_VDS: Virtual machine domain separation" was
modeled after the class FDP.
5.1.3.1 ESXi virtual machine domain separation (EXT_VDS_VMM)
Family Behavior
This family defines the non-interference requirements for VMs that are running simultaneously on an ESXi Server.
Component Leveling
Figure 6 – EXT_VDS_VMM ESXi virtual machine domain separation family decomposition
EXT_VDS_VMM.1 ESXi virtual machine domain separation ensures that VMs cannot interfere or tamper with each
other. The extended family "EXT_VDS_VMM: ESXi virtual machine domain separation" was modeled after the
other FDP SFRs.
EXT_VDS_VMM.1 ESXi virtual machine domain separation
Hierarchical to: No other components
Dependencies: None
This component will ensure that network traffic is only delivered to the intended recipients(s).
EXT_VDS_VMM.1.1 The TSF shall maintain a security domain for the execution of each virtual machine
that protects the virtual machine from interference and tampering by untrusted subjects or subjects from
outside the scope of the VM.
EXT_VDS_VMM.1.2 The TSF shall enforce separation between the security domains of VMs that the TSC24
24
TSC – TOE Scope of Control
EXT_VDS_VMM: ESXi virtual machine domain separation 1
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 26 of 65
© 2010 VMware, Inc.
5.2 Extended TOE Security Assurance Components
There are no extended TOE security assurance components.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 27 of 65
© 2010 VMware, Inc.
6 Security Requirements
This section defines the SFRs and SARs met by the TOE. These requirements are presented following the
conventions identified in Section 6.1.1.
6.1.1 Conventions
There are several font variations used within this ST. Selected presentation choices are discussed here to aid the
Security Target reader.
The CC allows for assignment, refinement, selection and iteration operations to be performed on security functional
requirements. All of these operations are used within this ST. These operations are performed as described in Parts
2 and 3 of the CC, and are shown as follows:
 Completed assignment statements are identified using [italicized text within brackets].
 Completed selection statements are identified using [large-font underlined italicized text within
brackets].
 Refinements are identified using large-font bold text. Any text removed is stricken (Example: TSF
Data) and should be considered as a refinement.
 Extended Functional and Assurance Requirements are identified using “EXT_” at the beginning of the short
name.
 Iterations are identified by appending a letter in parentheses following the component title. For example,
FAU_GEN.1(a) Audit Data Generation would be the first iteration and FAU_GEN.1(b) Audit Data
Generation would be the second iteration.
6.2 Security Functional Requirements
This section specifies the SFRs for the TOE. This section organizes the SFRs by CC class. Table 10 identifies all
SFRs implemented by the TOE and indicates the ST operations performed on each requirement.
Table 10 – TOE Security Functional Requirements
Name Description S A R I
FAU_GEN.1 Audit data generation  
FAU_SAR.1 Audit review  
FCS_COP.1 Cryptographic operation  
FDP_ACC.1(a) Subset access control (VirtualCenter)   
FDP_ACC.1(b) Subset access control (ESXi Server)    
FDP_ACF.1(a) Security attribute based access control (VirtualCenter)    
FDP_ACF.1(b) Security attribute based access control (ESXi Server)    
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 28 of 65
© 2010 VMware, Inc.
Name Description S A R I
FDP_IFC.2 Complete information flow control   
EXT_FDP_VC_ETC.1 Export of VirtualCenter data   
EXT_FDP_VC_ITC.1 Import of VirtualCenter data   
FDP_IFF.1 Simple security attributes   
FIA_UAU.2 User authentication before any action   
FIA_UID.2 User identification before any action   
EXT_FIA_VC_LOGIN.1 VirtualCenter user login request   
FMT_MSA.1(a) Management of security attributes (VirtualCenter)    
FMT_MSA.1(b) Management of security attributes (ESXi Server)    
FMT_MSA.1(c) Management of security attributes (Virtual Switch
Information Flow Control)
   
FMT_MSA.3(a) Static attribute initialization (VirtualCenter)    
FMT_MSA.3(b) Static attribute initialization(ESXi Server)    
FMT_MSA.3(c) Static attribute initialization (Virtual Switch Information
Flow Control)
   
FMT_SMF.1 Specification of management functions    
FMT_SMR.1(a) Security roles (VirtualCenter)    
FMT_SMR.1(b) Security roles (ESXi Server)    
FPT_ITC.1 Inter-TSF confidentiality during transmission    
FPT_ITT.1 Basic internal TSF data transfer protection    
EXT_VDS_VMM.1 ESXi virtual machine domain separation    
Note: S=Selection; A=Assignment; R=Refinement; I=Iteration
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 29 of 65
© 2010 VMware, Inc.
6.2.1 Class FAU: Security Audit
FAU_GEN.1 Audit Data Generation
Hierarchical to: No other components.
FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events:
 Start-up and shutdown of the audit functions;
 All auditable events, for the [not specified] level of audit; and
 [The events specified in the “Audit Event” column of Table 11].
FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
 Date and time of the event, type of event, subject identity (if applicable), and the outcome (success
or failure) of the event; and
 For each audit event type, based on the auditable event definitions of the functional components
included in the PP/ST, [the information specified in the “Additional Collected Information”
column of Table 11].
Dependencies: FPT_STM.1 Reliable time stamps
Table 11 – Auditable Events on ESXi Server
Audit Event Additional Collected
Information
Startup and shutdown of the Auditing functions <none>
All management operations performed on virtual machines
25
virtual machine
All changes to the configuration of alarms or scheduled task The alarm or scheduled task
All use of the identification and authentication mechanisms The user identity if provided
FAU_SAR.1 Audit review
Hierarchical to: No other components.
FAU_SAR.1.1
25
This audit event refers to management actions taken by an ESXi or VirtualCenter administrator via the ESXi or
VirtualCenter management interfaces; it does not refer to VM guest-OS administrator events which occur within the
guest-OS.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 30 of 65
© 2010 VMware, Inc.
The TSF shall provide [users who are granted access to the requested object by the Access Control Policy]
with the capability to read [all audit events] from the audit records.
FAU_SAR.1.2
The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
Dependencies: FAU_GEN.1 Audit data generation
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 31 of 65
© 2010 VMware, Inc.
6.2.2 Class FCS: Cryptographic Support
FCS_COP.1 Cryptographic operation
Hierarchical to: No other components.
FCS_COP.1.1
The TSF shall perform [the cryptographic operations listed in the Cryptographic Operations column of
Table 12] in accordance with a specified cryptographic algorithm [the cryptographic algorithms listed in
the Cryptographic Algorithm column of Table 12] and cryptographic key sizes [the cryptographic key sizes
listed in the Key Sizes (bits) column of Table 12] that meet the following: [the list of standards in the
Standards (Certificate #) column of Table 12].
Table 12 – Cryptographic Operations
Cryptographic
Operations
Cryptographic
Algorithm
Key Sizes (bits) Standard Certificate #
Symmetric encryption and
decryption
Triple-DES
26
(2-Key)
CBC
27 128 FIPS 46-3 CAVP (cert #902)
AES
28
(128, 256)
CBC
128, 256 FIPS 197
CAVP (cert #1271,
#1274)
Message Authentication HMAC
29
1024 FIPS 198 CAVP (cert #741)
Message Digest SHA-1 N/A
30
FIPS 180-3 CAVP (cert #1174)
Digital signature
verification of VPXA
bundle
RSA digital signature
1024, 2048,
3072, 4096
FIPS 186-2 CAVP (cert #612)
Digital signatures for
patch bundles (used by
VUM)
RSA digital signature
1024, 2048,
3072, 4096
FIPS 186-2 CAVP (cert #612)
Dependencies: N/A31
26
DES – Data Encryption Standard
27
CBC – Cipher Block Chaining
28
AES – Advanced Encryption Standard
29
HMAC – Hash-based Message Authentication Code
30
N/A – Not Applicable
31
FCS_CKM.1 and FCS_CKM.4 are not listed as dependencies, following the guidance of CCS Instruction #4,
version 1.0.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 32 of 65
© 2010 VMware, Inc.
Class FDP: User Data Protection
FDP_ACC.1(a) Subset access control (VirtualCenter)
Hierarchical to: No other components.
FDP_ACC.1.1(a)
The TSF shall enforce the [VirtualCenter Access Control Policy] on [
a. Subjects: processes acting on behalf of VirtualCenter users
b. Objects: virtual machine definition and configuration files; inventory data for virtual machines, folders,
datacenters, clusters, resource pools, networks, datastores, templates, and hosts; scheduled events, alarms,
events, and templates
c. Operations: all operations between the listed subjects and the listed objects].
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1(b) Subset access control (ESXi Server)
Hierarchical to: No other components.
FDP_ACC.1.1(b)
The TSF shall enforce the [ESXi Server Access Control Policy] on [
a. Subjects: processes acting on behalf of ESXi Server users
b. Objects: virtual machine definition and configuration files; ESXi Server configuration files; ESXi Server
audit logs
c. Operations: all operations between the listed subjects and the listed objects].
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACF.1(a) Security attribute based access control (VirtualCenter)
Hierarchical to: No other components.
FDP_ACF.1.1(a)
The TSF shall enforce the [VirtualCenter Access Control Policy] to objects based on the following: [
a. Subjects: Processes acting on behalf of users of VirtualCenter
b. Subject security attributes: User identity or User group(s), VC-role
c. Objects: virtual machine definition and configuration files; inventory data for virtual machines, folders,
datacenters, clusters, resource pools, networks, datastores, templates, and hosts; scheduled events, alarms,
tasks, and templates
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 33 of 65
© 2010 VMware, Inc.
d. Object attributes: A set of permission pairs (User identity or User Group, VC-role)].
FDP_ACF.1.2(a)
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed: [
1. Access is granted if the user is a member of the administrators group of the underlying Windows
operating system of VirtualCenter, also known as a VirtualCenter Administrator.
2. Access to perform a given activity on an object is allowed on VirtualCenter if there is a permission pair
associated with the object having a user identity component that matches the user identity of the subject,
and a VC-role allowing the activity requested by the subject.
3. Access to perform a given activity on an object is allowed on VirtualCenter if there is a permission pair
associated with the object having a user group component that matches a group to which the subject
belongs, and a VC-role allowing the activity requested by the subject.
4. If the user of the subject does not match the user identity of any permission pair associated with the
object, or the User identity is not a member of any group of any permission pair associated with the object,
or the VC-role of any such matching permission pair does not permit the activity requested by the user,
then access is denied32
].
FDP_ACF.1.3(a)
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [no
additional rules].
FDP_ACF.1.4(a)
The TSF shall explicitly deny access of subjects to objects based on the following rules: [no additional
rules].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1(b) Security attribute based access control (ESXi)
Hierarchical to: No other components.
FDP_ACF.1.1(b)
The TSF shall enforce the [ESXi Server Access Control Policy] to objects based on the following: [
a. Subjects: Processes acting on behalf of users of ESXi Server
b. Subject security attributes: User identity or User group(s), ESXi Server User role
c. Objects: virtual machine definition and configuration files; ESXi Server configuration files, ESXi Server
audit logs
32
All VirtualCenter objects are contained within an object hierarchy. Newly created objects inherit the permissions
of the parent object. When an object is moved within the hierarchy, the object loses its previous permissions and
assumes the permission settings of the new parent object.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 34 of 65
© 2010 VMware, Inc.
d. Object attributes: User identity of object owner, object group, read/write/execute permissions for
owner/group/other].
FDP_ACF.1.2(b)
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects of the ESXi Server is allowed: [
1. Access is granted if the ESXi Server role is system administrator.
2. Access is granted if the ESXi Server role is not system administrator and the user id is the user id of the
object owner and the requested access is allowed for the owner of the object.
3. Access is granted if the ESXi Server role is not system administrator and the user belongs to the group of
the object and the requested access is allowed for members of the object’s group.
4. Access is granted if the ESXi Server role is not system administrator and the requested access is allowed
for anyone.
5. If the user is a VM administrator and the requested action is register or unregister33
a VM, then the user
must have read, write, and execute access to the VM’s configuration file for the operation to be allowed.
6. If the user is a VM administrator and the requested action is a power operation on a VM, then the user
must have execute access to the VM’s configuration file for the operation to be allowed].
FDP_ACF.1.3(b)
The TSF shall explicitly authorize access of subjects to objects or operations of the ESXi Server
based on the following additional rules: [no additional rules].
FDP_ACF.1.4(b)
The TSF shall explicitly deny access of subjects to objects of the ESXi Server based on the
following rules: [no additional rules].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_IFC.2 Complete information flow control
Hierarchical to: FDP_IFC.1 Subset information flow control
FDP_IFC.2.1
The TSF of the ESXi Server shall enforce the [virtual switch information flow control SFP34
] on [
a. Subjects: physical network interfaces and VM virtual network interfaces
b. Information: network data packets]
33
“Register” refers to the act of associating a VM with an ESXi Server. “Unregister” refers to the act of
disassociating a VM from an ESXi Server.
34
SFP – Security Functional Policy
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 35 of 65
© 2010 VMware, Inc.
and all operations that cause that information to flow to and from subjects covered by the SFP.
FDP_IFC.2.2
The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any
subject in the TOE are covered by an information flow control SFP.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFF.1 Simple security attributes
Hierarchical to: No other components.
FDP_IFF.1.1
The TSF of the ESXi Server shall enforce the [virtual switch information flow control SFP] based on
the following types of subject and information security attributes: [
a. Subjects: physical network interfaces and VM virtual network interfaces
b. Subject security attributes: interface identifier, VLAN identifier (if applicable)
c. Information: network data packets
d. Information security attributes: source identifier, destination identifier].
FDP_IFF.1.2
The TSF shall permit an information flow between a controlled subject and controlled information via a
controlled operation if the following rules hold: [if the data packet originates from a recognized and
authorized source, indicated by the source identifier as defined in this SFP, and is addressed to a
recognized and authorized destination, indicated by the destination identifier as defined in this SFP, then
allow the information flow, otherwise deny the information flow].
FDP_IFF.1.3
The TSF shall enforce no additional information flow control SFP rules.
FDP_IFF.1.4
The TSF shall explicitly authorize an information flow based on no additional information flow
control SFP rules.
FDP_IFF.1.5
The TSF shall explicitly deny an information flow based on no additional information flow
control SFP rules.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
EXT_FDP_VC_ETC.1 Export of VirtualCenter data
Hierarchical to: No other components.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 36 of 65
© 2010 VMware, Inc.
EXT_FDP_VC_ETC.1.1
VirtualCenter shall enforce the VirtualCenter Access Control Policy when exporting VirtualCenter data,
controlled under the SFP, to the VirtualCenter database.
Dependencies: FDP_ACC.1(a) Subset access control (VirtualCenter)
EXT_FDP_VC_ITC.1 Import of VirtualCenter data
Hierarchical to: No other components.
EXT_FDP_VC_ITC.1.1
VirtualCenter shall enforce the VirtualCenter Access Control Policy when importing VirtualCenter data,
controlled under the SFP, from the VirtualCenter database.
Dependencies: FDP_ACC.1(a) Subset access control (VirtualCenter)
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 37 of 65
© 2010 VMware, Inc.
6.2.3 Class FIA: Identification and Authentication
FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
FIA_UAU.2.1
The TSF shall require each ESXi Server user to be successfully authenticated before allowing any other
TSF-mediated actions on behalf of that user.
Dependencies: FIA_UID.1 Timing of identification
FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
FIA_UID.2.1
The TSF shall require each ESXi Server user to be successfully identified before allowing any other
TSF-mediated actions on behalf of that user.
Dependencies: No dependencies
EXT_FIA_VC_LOGIN.1 VirtualCenter user login request
Hierarchical to: No other components.
EXT_FIA_VC_LOGIN.1.1
VirtualCenter shall request identification and authentication from the VirtualCenter environment for a
VirtualCenter user, and receive notification of success, prior to granting any other TSF-mediated actions on
behalf of the user.
Dependencies: No dependencies
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 38 of 65
© 2010 VMware, Inc.
6.2.4 Class FMT: Security Management
FMT_MSA.1(a) Management of security attributes (VirtualCenter)
Hierarchical to: No other components.
FMT_MSA.1.1(a)
The TSF shall enforce the [VirtualCenter Access Control Policy] to restrict the ability to [change_default,
modify, delete] the security attributes [a set of permission pairs (User identity or User Group, VC-role)
and all objects in the VirtualCenter: virtual machine definition and configuration files; inventory data for
virtual machines, folders, datacenters, clusters, resource pools, networks, datastores, templates, and hosts;
scheduled events, alarms, tasks, and template] to [VirtualCenter Administrators and Administrator defined
roles ].
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MSA.1(b) Management of security attributes (ESXi Server)
Hierarchical to: No other components.
FMT_MSA.1.1(b)
The TSF shall enforce the [ESXi Server Access Control Policy] to restrict the ability to [modify, delete,
[add]] the security attributes [For ESXi Server users: user id; user groups; ESXi Server User Role; For
ESXi Server objects: object owner; object group; object read, write, and execute permissions of security
attributes] to [the roles as defined in Table 13].
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
Table 13 – FMT_MSA.1(b) – Security Attributes, Actions, and Roles
Action Attribute Role
Modify Read, write, and execute permissions on
objects
System Administrator or VM Administrator
Add, Delete, Modify User identity of object owner, object group System Administrator
Add, Delete, Modify Object group  VM Administrator: may change the
group of the file to any group the owner
is a member of
 System Administrator: may change the
group arbitrarily
Add, Delete, Modify User identity, User Group, ESXi Server
User Role
System Administrator
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 39 of 65
© 2010 VMware, Inc.
FMT_MSA.1(c) Management of security attributes (Virtual Switch Information Flow
Control)
Hierarchical to: No other components.
FMT_MSA.1.1(c)
The TSF shall enforce the [Virtual Switch Information Flow Control SFP] to restrict the ability to [add,
modify, delete] the security attributes [interface identifier, VLAN identifier] to [System Administrators].
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MSA.3(a) Static attribute initialization (VirtualCenter)
Hierarchical to: No other components.
FMT_MSA.3.1(a)
The TSF shall enforce the [VirtualCenter Access Control Policy] to provide [restrictive] default values
for security attributes that are used to enforce the VirtualCenter Access Control Policy SFP.
FMT_MSA.3.2(a)
The TSF shall allow the [VirtualCenter Administrators and Administrator defined roles] to specify
alternative initial values to override the default values when an object or information is created on
VirtualCenter.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3(b) Static attribute initialization (ESXi Server)
Hierarchical to: No other components.
FMT_MSA.3.1(b)
The TSF shall enforce the [ESXi Server Access Control Policy] to provide [restrictive] default values for
security attributes that are used to enforce the ESXi Server Access Control Policy SFP.
FMT_MSA.3.2(b)
The TSF shall allow the [System Administrator and VM administrator(s)] to specify alternative initial
values to override the default values when an object or information is created on the ESXi Server, as
described in Table 14.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 40 of 65
© 2010 VMware, Inc.
Table 14 – FMT_MSA.3(b) - Roles and Objects/Information
Role Type of Object or Information
System Administrator Any
VM Administrator(s) Objects they create
FMT_MSA.3(c) Static attribute initialization (Virtual Switch Information Flow Control)
Hierarchical to: No other components.
FMT_MSA.3.1(c)
The TSF shall enforce the [Virtual Switch Information Flow Control Policy] to provide [restrictive] default
values for security attributes that are used to enforce the Virtual Switch Information Flow Control SFP.
FMT_MSA.3.2(c)
The TSF shall allow the [System Administrators] to specify alternative initial values to override the default
values when a Virtual Switch is created on the ESXi Server.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
FMT_SMF.1.1
The TSF shall be capable of performing the following security management functions: [
1. Adding, deleting, or modifying the object permissions associated with a user or group on VirtualCenter
2. Adding, deleting, or modifying user or group membership on the ESXi Server
3. Modification of permissions associated with an object on the ESXi Server
4. Functions to create, modify, or delete virtual machines
5. Power operations on a virtual machine].
Dependencies: No Dependencies
FMT_SMR.1(a) Security roles (VirtualCenter)
Hierarchical to: No other components.
FMT_SMR.1.1
The TSF shall maintain the roles for VirutalCenter users [VirtualCenter Administrators and
VirutalCenter Administrator defined roles].
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 41 of 65
© 2010 VMware, Inc.
FMT_SMR.1.2
The TSF shall be able to associate VirtualCenter users with the above mentioned roles.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1 (b) Security roles (ESXi Server)
Hierarchical to: No other components.
FMT_SMR.1.1
The TSF shall maintain the roles for ESXi Server users [VM Administrator and System
Administrator].
FMT_SMR.1.2
The TSF shall be able to associate ESXi Server users with the above mentioned roles.
Dependencies: FIA_UID.1 Timing of identification
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 42 of 65
© 2010 VMware, Inc.
6.2.5 Class FPT: Protection of the TSF
FPT_ITT.1 Basic internal TSF data transfer protection
Hierarchical to: No other components.
FPT_ITT.1.1
The TSF shall protect TSF data from [disclosure, modification] when it is transmitted between
separate parts of the TOE.
Dependencies: No dependencies
FPT_ITC.1 Inter-TSF confidentiality during transmission
Hierarchical to: No other components.
FPT_ITC.1.1
The TSF shall protect all TSF data transmitted from the TSF to a remote trusted IT product from
unauthorized disclosure during transmission.
Dependencies: No dependencies
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 43 of 65
© 2010 VMware, Inc.
6.2.6 Class EXT_VDS: Virtual Machine Domain Separation
EXT_VDS_VMM.1 ESXi virtual machine domain separation
Hierarchical to: No other components
EXT_VDS_VMM.1.1
The TSF shall maintain a security domain for the execution of each virtual machine that protects the virtual
machine from interference and tampering by untrusted subjects or subjects from outside the scope of the
VM.
EXT_VDS_VMM.1.2
The TSF shall enforce separation between the security domains of VMs that the TOE controls.
Dependencies: No dependencies
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 44 of 65
© 2010 VMware, Inc.
6.3 Security Assurance Requirements
This section defines the assurance requirements for the TOE. Assurance requirements are taken from the CC Part 3
and are EAL4 augmented with ALC_FLR.1. Table 15 – Assurance Requirements summarizes the requirements.
Table 15 – Assurance Requirements
Assurance Requirements
Class ALC : Life Cycle Support ALC_CMC.4 Production support, acceptance procedures and automation
ALC_CMS.4 Problem tracking CM
35
Coverage
ALC_DEL.1 Delivery Procedures
ALC_DVS.1 Identification of security measures
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
ALC_FLR.1 Basic Flaw Remediation
Class ADV: Development ADV_ARC.1 Security Architecture Description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3 Basic modular design
Class AGD: Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Class ATE: Tests ATE_COV.2 Analysis of coverage
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing – sample
ATE_DPT.2 Testing: security enforcing modules
Class AVA: Vulnerability assessment AVA_VAN.3 Focused Vulnerability analysis
35
CM – Configuration Management
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 45 of 65
© 2010 VMware, Inc.
7 TOE Summary Specification
This section presents information to detail how the TOE meets the functional requirements described in previous
sections of this ST.
7.1 TOE Security Functions
Each of the security requirements and the associated descriptions correspond to the security functions. Hence, each
function is described by how it specifically satisfies each of its related requirements. This serves to both describe
the security functions and rationalize that the security functions satisfy the necessary requirements.
Table 16 – Mapping of TOE Security Functions to Security Functional Requirements
TOE Security
Function
SFR Description
Security Audit
FAU_GEN.1 Audit Data Generation
FAU_SAR.1 Audit review
Cryptographic
Support
FCS_COP.1 Cryptographic operation
User Data Protection
FDP_ACC.1(a) Subset access control (VirtualCenter)
FDP_ACC.1(b) Subset access control (ESXi Server)
FDP_ACF.1(a) Security attribute based access control
(VirtualCenter)
FDP_ACF.1(b) Security attribute based access control (ESXi
Server)
FDP_IFC.2 Complete information flow control
FDP_IFF.1 Simple security attributes
EXT_FDP_VC_ETC.1 Export of VirtualCenter data
EXT_FDP_VC_ITC.1 Import of VirtualCenter data
Identification and
Authentication
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
EXT_FIA_VC_LOGIN.1 VirtualCenter user login request
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 46 of 65
© 2010 VMware, Inc.
TOE Security
Function
SFR Description
Security
Management
FMT_MSA.1(a) Management of security attributes
(VirtualCenter)
FMT_MSA.1(b) Management of security attributes (ESXi
Server)
FMT_MSA.1(c) Management of security attributes (Virtual
Switch Information Flow Control)
FMT_MSA.3(a) Static attribute initialisation (VirtualCenter)
FMT_MSA.3(b) Static attribute initialisation (ESXi Server)
FMT_MSA.3(c) Static attribute initialization (Virtual Switch
Information Flow Control)
FMT_SMF.1 Specification of management functions
FMT_SMR.1(a) Security roles (VirtualCenter)
FMT_SMR.1(b) Security roles (ESXi Server)
Protection of the
TSF
FPT_ITT.1 Basic internal TSF data transfer protection
FPT_ITC.1 Inter-TSF confidentiality during transmission
Virtual Machine
Domain Separation
EXT_VDS_VMM.1 ESXi virtual machine domain separation
7.1.1 Security Audit
The auditing security function of the TOE is provided by both ESXi Server and VirtualCenter. Audit data collected
by the ESXi Server is stored in a flat file on the ESXi Server. Audit data collected by VirtualCenter is stored as
events on the VirtualCenter Database.
The TOE audit records contain the following information:
Table 17 – Audit Record Contents
Field Content
Timestamp Date and time of the event
Class Type of event
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 47 of 65
© 2010 VMware, Inc.
Field Content
Source Subject identity
Event State Outcome
Each audit record generated includes the date and time of the event, type of event, subject identity, and the outcome
(success or failure) of the event, and virtual machine, scheduled task, or alarm identity if applicable. For invalid
identification attempts, the identity of the user name supplied is also recorded. These audit records are stored as
events, and are managed by the VirtualCenter Access Control Policy. They are stored on the VirtualCenter
Database.
VirtualCenter provides the capability to review its audit records by reviewing the event logs stored on the
VirtualCenter Database. Event logs are associated with objects, and access to the event logs is determined by access
to the object associated with the event log. Users who can access a particular VM or VM Group can access the
event logs for that organizational grouping. Audit events are viewed through the Virtual Infrastructure Client under
the event tab for each organizational object.
ESXi Server audit records are stored in a flat file on the ESXi Server. They are stored in /var/log/messages and
/var/log/vmware directories. Reviewing the audit records on the ESXi Server is restricted to the ESXi System
Administrator.
TOE Security Functional Requirements Satisfied: FAU_GEN.1, FAU_SAR.1
7.1.2 Cryptographic Support
The TOE protects the confidentiality and integrity of all data as it passes between the remote components of the
TOE, or from the TOE to another trusted IT product. The TOE achieves this by using OpenSSL which performs the
encryption and the decryption of data that is being passed.
The TOE implements CAVP-validated cryptographic algorithms to handle all cryptographic functions for the
encryption and the decryption of data.
TOE Security Functional Requirements Satisfied: FCS_COP.1
7.1.3 User Data Protection
The TOE provides two distinct access control mechanisms. One is used for verifying access to objects under the
control of ESXi Server by users logged into ESXi Server and users who make requests on ESXi Server from the
VirtualCenter, and another for verifying access to objects on the VirtualCenter by users logged into the
VirtualCenter. Each access control mechanism is described below.
VM users (individuals who access the guest operating system and applications within a virtual machine) access
data, operations, and files within the scope of the VM, and this access control is determined by the access control
methods of the guest operating system and its applications. Such access control is outside the scope of the TOE and
is not discussed any further here. Furthermore, VM Administration tasks that can be performed from within the VM
are also outside the scope of the TOE, as they do not impact the operation or data of the TOE.
7.1.3.1 VirtualCenter Access Control Policy
The VirtualCenter access control mechanism controls access to objects stored on VirtualCenter, such as virtual
machines, and VM Groups. The VirtualCenter access control mechanism also controls access to files containing
templates as well as event, alarm, and scheduled event information. This information is stored in the VirtualCenter
Database. It should be noted that the VirtualCenter access control mechanism is enforced when the VirtualCenter
accesses the VirtualCenter data stored in VirtualCenter Database. The VirtualCenter access control mechanism also
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 48 of 65
© 2010 VMware, Inc.
controls access by a VirtualCenter user to data and operations specific to the definition, configuration, and
management of virtual machines. ESXi Server-specific information is physically stored on the hosting ESXi Server,
and is made available to the VirtualCenter user via the VirtualCenter Agents installed on the ESXi Server.
TOE users on VirtualCenter are administrators who have been assigned to one of two roles categories:
VirtualCenter Administrator and Administrator-defined roles. Subjects are processes acting on behalf of the logged-
in user, and have user identities and may belong to one or more groups, identified by a group identity.
When a VirtualCenter user requests an operation to be performed on a particular object, the access control security
function first determines if the user is a VirtualCenter Administrator by virtue of being a member of the operating
system’s administrator group. If so, access is granted. If not, the access control security function determines if the
user’s role(s) for the object contain permissions sufficient for performing the requested operation on the requested
object on behalf of the requesting user.
The security attributes for subjects on VirtualCenter are user identity, group membership, and role (VirtualCenter
Administrator or Limited access user). For objects stored on VirtualCenter, the security attributes are sets of
permission pairs consisting of user identity or group and VirtualCenter role. When a subject requests access to such
an object, the subject user identity or group is compared with the user identity and group identity for each
permission pair of the requested object until either a match is found or the object permission pair set is exhausted. A
match is determined if the user identity of the subject matches the user identity of the object or the user identity of
the subject is a member of the group of the object and the requested operation is allowed for the VirtualCenter-role
of a matching permission pair. If a match is found, the requested access is granted. If no match is found the access
request is denied.
7.1.3.2 ESXi Server Access Control Policy
When an ESXi Server is first placed under VirtualCenter control, the root user or user account with admin privileges
password for the ESXi Server must be supplied. At that time, a new password for the vpxuser account is generated
to use in all future transactions between the ESXi Server and VirtualCenter.
When a user wants to perform tasks on data that is stored in an ESXi Server managed by the VirtualCenter, the same
access control checks described above are performed on the VirtualCenter. If the requested access is permitted, then
a request, along with the password for the vpxuser account described above, is passed to the VirtualCenter Agent on
the ESXi Server, by the VirtualCenter. Note that when a user possesses multiple roles or permissions, the access
control security function uses any of the associated roles or permissions pertaining to the user that will satisfy the
request of the operation and grant access to be allowed. However, if the user does not possess the required
permissions from any of the user’s associated roles or permissions, then access is denied.
The ESXi Server access control mechanism controls access by subjects logged into the ESXi Server, and by subjects
requesting services from the managing VirtualCenter, to objects stored on the ESXi Server. These objects include
data and operations specific to the definition, configuration, and management of virtual machines as well as system
logs, which contain audit data.
The ESXi Server supports the two roles: system administrator and VM administrator. The users with the system
administrator role have unrestricted access in the ESXi, whereas the users with the VM administrator role may be
controlled by group membership or by user identity. The ESXi is designed so that the same access control
mechanisms can be used for direct ESXi users who log into the ESXi Server via the service console or the
management interface, and for indirect ESXi users who access the ESXi Server from the VirtualCenter. Once an
ESXi Server is place under the management of a VirtualCenter, requests from the VirtualCenter users are processed
using the vpxuser account. The vpxuser account is set up granting access to all VM configuration files (.vmx files).
From the console, system administrator or root user access requests are processed in a manner similar to that
employed by most Linux operating systems: they have access to any ESXi or VM data on the system. The VM
administrators cannot access ESXi Server configuration files or data. User access control for VM administrators is
the standard “user/group/other” access control mechanism found in Linux operating systems. If the user identity of
the subject is the owner of the object operation and the requested access type is allowed for the object owner, then
access is granted. If a group the user belongs to matches the group of the object and the requested access type is
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 49 of 65
© 2010 VMware, Inc.
allowed for the group, access is granted. For other users, if the access requested is allowed for “others,” then access
is granted. Otherwise, access is denied.
7.1.3.3 Virtual Switch Information Flow Control Policy
The ESXi Server implements vSwitches and VLANs, both of which are configurable by authorized administrators.
Each virtual machine that is configured for networking is logically connected to a vSwitch by the ESXi Server. The
vSwitch provides functionality identical to that of a hardware Ethernet switch, although the implementation is solely
in software: the source and destination identifiers of network data packets entering the vSwitch via any of its virtual
interfaces (which can be connected either to physical network interfaces, virtual machine virtual network interfaces,
or other vSwitches) are analyzed and the packet is delivered only to the appropriate virtual interface – the vSwitch
will not deliver packets to unintended virtual interfaces. Administrators can also configure VLANs on a vSwitch. A
vSwitch VLAN will create a virtual network within the vSwitch that allows specified virtual interfaces to
communicate only with other specified virtual interfaces – traffic addressed to or from interfaces which are not part
of the VLAN will not be delivered by the vSwitch.
TOE Security Functional Requirements Satisfied: FDP_ACC.1(a), FDP_ACC.1(b), FDP_ACF.1(a),
FDP_ACF.1(b), FDP_IFC.2, FDP_IFF, EXT_FDP_VC_ETC.1, EXT_FDP_VC_ITC.1
7.1.4 Identification and Authentication
When a user logs into the ESXi Server, a user name and password are requested before any access is given. These
authentication credentials are compared with the authentication credentials stored on the ESXi Server in a shadow
file, where the password is hashed using SHA-1. If the authentication credentials are valid, access to the system is
provided, with the privileges appropriate to the role assigned to that user. If the credentials are not valid, the user is
presented with another chance to provide valid credentials. Failed and successful user login events are captured in
the system logs.
When a user logs into VirtualCenter they are presented with a login screen, requesting the VirtualCenter name or IP
address, the user name, and the user password. The user information is passed to the underlying Windows operating
system which verifies the user identity and password. If login is valid, the user at the Virtual Infrastructure Client is
presented with the Virtual Infrastructure Client interface denoting a successful login. If login is invalid, a message
is displayed, and the login window remains available for the user to retry.
When VMware Update Manager starts up, it authenticates with VirtualCenter. VUM does not access the ESXi
Server; rather, the ESXi Server will always call VUM, thereby ensuring that only the VUM that is installed with the
TOE will be able to download updates and patches to the ESXi Server.
TOE Security Functional Requirements Satisfied: FIA_UAU.2, FIA_UID.2, EXT_FIA_VC_LOGIN.1
7.1.5 Security Management
The ESXi supports the two roles: system administrator and VM administrator. The system administrator role can be
assigned to three different kinds of user accounts. These are:
1. root – The system administrator role is implemented using the root account of the underlying Linux
operating system. Users log into the root account and give the root password in order to use this role.
2. individual user – It is also possible to assign a system administrator role to an individual user account. For
example, an account name of jsmith can be assigned to a role of system administrator, thus making that
particular individual user (e.g. John Smith) a System Administrator on the ESXi Server. Assigning the
system administrator role to different user accounts (rather than root account alone) helps in maintaining
security through traceability.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 50 of 65
© 2010 VMware, Inc.
3. vpxuser – The vpxuser account is used by the VirtualCenter when it manages activities for the connected
ESXi Server. The vpxuser account is initially created when the VirtualCenter adds the ESXi Server as one
of its managed hosts for the first time.
It should be noted that the VirtualCenter supplies the username and password for either the root account or the user
account with a system administrator role, when adding the ESXi Server for the first time. When this authentication
with the ESXi Server is successful, a special account called vpxuser is created on the ESXi Server along with a
vpxuser password known only to the VirtualCenter and the specific ESXi Server. This login account (vpxuser
account) and password (vpxuser password) are used for all subsequent connections between the ESXi Server and the
VirtualCenter.
No users on the ESXi Server or the VirtualCenter, other than the VirtualCenter administrator, have access to the
vpxuser passwords stored in the VirtualCenter database. These users are fully subject to the access control rules.
Below are a few important characteristics of the vpxuser password.
 The vpxuser password is machine generated.
 The vpxuser password is stored in encrypted form. It is never exposed in plain text.
 There is no way to change the vpxuser password manually.
 The vpxuser password for each ESXi Server under the management of a VirtualCenter is unique for that
ESXi Server. Thus, it is a one to many relationships: A single VirtualCenter machine possessing many
(and unique) vpxuser passwords for all the ESXi Servers it manages.
VM administrators are administrators of individual VMs on the ESXi Server. VM administrators can access the
VMs by directly logging into the ESXi Server or through the VirtualCenter. The VirtualCenter uses the vpxuser
account and password to gain access to the ESXi Server and process the requests on behalf of the VM
administrators.
The TOE ensures that the ability to modify permissions of users on ESXi objects is restricted to ESXi System
Administrators. The capability to modify permissions of users on objects is provided by functions of the ESXi that
are inherited from the customized Linux kernel which the ESXi leverages. These operations include chmod, group
management functions, and user account management functions. Only System Administrators can change the object
owner of a file. However, the owner of a file may change the group of the file to any group of which that owner is a
member. The System Administrator may change the group arbitrarily. The ESXi defaults for access permission are
controlled by the umask setting. The default value can only be changed by an ESXi System Administrator.
The TOE provides security management functions that address the management of security attributes for ESXi
Server (role, user ID for subjects, and owner, group, and r,w,x permissions for owner, object group, and other for
objects) and VirtualCenter (user identity role permission pairs for both subjects and objects). In addition, the TOE
provides security management functions for the creation, deletion, registration, modification, and power operations36
on virtual machines.
The VirtualCenter supports two categories of roles: VirtualCenter Administrator and Administrator defined roles.
The VirtualCenter Administrator is implemented by membership in the “administrators” group of the underlying
36
“Power operations” on a virtual machine refers to the act of starting, stopping, or suspending a virtual machine in
a manner which simulates the application or removal of “virtual power” to or from the VM. For example, if a
“power off” event is initiated the VM’s OS might receive notice from the virtual power supply that the virtual power
button has been pressed – this allows the VM’s OS to take whatever steps are necessary to safely shut down before
and to inform the virtual power supply when it is ready for full power-off. This behavior simulates the behavior of
an OS installed on a physical machine.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 51 of 65
© 2010 VMware, Inc.
Windows OS. Users log in using their username and password, and are automatically in this role by virtue of their
membership in the administrators group.
In the CC-evaluated configuration, all administrators using the Virtual Infrastructure Client connect to the TOE via
the controlled and protected management network (as assumed in A.PHYSCL), and the TOE environment is
configured only to allow TOE administration from this network. This ensures that administrative traffic is protected
in transit between the Virtual Infrastructure Client and the ESXi Server or VirtualCenter.
TOE Security Functional Requirements Satisfied: FMT_MSA.1(a), FMT_MSA.1(b), FMT_MSA.1(c),
FMT_MSA.3(a), FMT_MSA.3(b), FMT_SMF.1, FMT_SMR.1(a), FMT_SMR.1(b)
7.1.6 Protection of the TSF
The Protection of the TSF function provides the integrity and management of the mechanisms that provide the TSF.
Protection of the TOE from physical tampering is ensured by its environment. It is the responsibility of the
administrator to assure that physical connections made to the TOE remain intact and unmodified. The TOE protects
information as it is transmitted between remote components of the TOE by protecting the information using
OpenSSL. HTTP communications between VUM and the ISP Server, and between VUM and ESXi, are protected
by signature verification.
Non-bypassability of the TOE is provided by a combination of basic configuration and enforcement of security
policy rules. Each subject’s and user’s security privileges are separated. It is not possible to perform any actions on
the system without successfully authenticating. Once a user has been authenticated, the user is bound to the
appropriate roles and any privileges defined by the TOE access control. All access control rights are checked by the
TOE’s mechanisms and the TOE uses unique attributes for each user, then the TSF maintains separation between
different users. As an example, if a user without explicit permission tries to configure a virtual machine, the user
will not be able to save the changes.
TOE Security Functional Requirements Satisfied: FPT_ITT.1, FPT_ITC.1,
7.1.7 Virtual Machine Domain Separation
The virtual machine separation security function of the TOE is provided by the ESXi Server component. The TOE
ensures that each virtual machine is isolated from any other virtual machines co-existing on ESXi Server. This
isolation is provided at the virtualization layer of ESXi Server. The virtualization layer of ESXi Server ensures that
virtual machines are unable to directly interact with other virtual machines yet still allow for physical resources to be
shared among the existing virtual machines.
The ESXi Server provides an idealized hardware environment and virtualization of underlying physical resources.
Each virtual machine runs its own operating system and applications: they cannot communicate to each other in
unacceptable/unauthorized ways, nor can they leak data. The following mechanisms ensure this:
 Shared memory: The memory allocation mechanisms prevent the sharing of writable memory. Each VM is
assigned memory that belongs exclusively to it.
 Read-only Memory: Multiple VMs may require the same OS or application images, and in these cases, the
memory locations are shared, but in a read-only mode. This effectively saves memory without providing a
communication channel between VMs.
 Communication between VMs through network connections can be permitted or prevented as desired.
These networking mechanisms are similar to those used to connect separate physical machines.
Each virtual machine appears to run on its own processor, fully isolated from other virtual machines with its own
registers, buffers, and other control structures. Most instructions are directly executed on the physical processor,
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 52 of 65
© 2010 VMware, Inc.
allowing compute-intensive workloads to run at near-native speed. Memory appears contiguous to each virtual
machine, but instead, noncontiguous physical pages are remapped efficiently and presented transparently to each
virtual machine.
TOE Security Functional Requirements Satisfied: EXT_VDS_VMM.1
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 53 of 65
© 2010 VMware, Inc.
8 Rationale
8.1 Conformance Claims Rationale
There are no protection profile conformance claims for this security target.
8.2 Security Objectives Rationale
This section provides a rationale for the existence of each threat, policy statement, and assumption that compose the
Security Target. Table 18 and sections 8.2.1, 8.2.2, and 8.2.3 demonstrate the mappings between the threats,
polices, and assumptions to the security objectives is complete. The following discussion provides detailed evidence
of coverage for each threat, policy, and assumption.
Table 18 – Relationship of Security Threats to Objectives
Objectives
Threats,
Assumptions
TOE Objectives Environmental
Objectives
IT Non-IT
O.ADMIN
O.AUDIT
O.IDAUTH
O.ACCESS
O.SECURE
O.VM
O.VLAN
O.VSWITCH
OE.DBMS
OE.IDAUTH
OE.TIME
OE.SEP
NOE.NOEVIL
NOE.PHYSCL
Threats
T.VM  
T.COMINT       
T.PRIVIL       
T.VIRTUAL_NETWORK  
Assumpti
ons
A.DBMS 
A.NOEVIL 
A.PHYSCL 
8.2.1 Security Objectives Rationale Relating to Threats
Table 19 – Threats:Objectives Mapping
Threats Objectives Rationale
T.VM
A process running on one virtual
machine might compromise the
security of processes running on
other virtual machines.
O.VM
The TOE must provide virtual
machines with a domain of execution
which is protected from interference
and tampering by virtual machines.
This threat is mitigated by the O.VM
objective which makes information on
the unavailability or poor performance
of IP networks and servers available
to administrators in a timely and clear
manner. This allows the
administrators to take action to limit
the impact of current problems and
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 54 of 65
© 2010 VMware, Inc.
Threats Objectives Rationale
avoid future problems.
OE.SEP
The IT Environment will protect the
TOE from external interference or
tampering.
The OE.SEP mitigates this threat by
requiring that the IT environment
protect the TOE from interference that
would prevent it from performing its
functions.
T.COMINT
An unauthorized individual may
attempt to compromise the
security of the data collected and
produced by the TOE by
bypassing a security mechanism.
O.ADMIN
The TOE must include a set of
functions that allow efficient
management of its functions and data,
ensuring that TOE users with the
appropriate privileges, and only those
TOE users, can exercise such control.
The O.ADMIN objective requires that
only authorized users are able to
manage the security attributes of the
TOE.
O.AUDIT
The TOE must gather audit records of
actions on the TOE which may be
indicative of misuse.
The O.AUDIT objective provides
defense in depth, by requiring the
recording and availability of audit
records for review by an authorized
operator of the TOE.
O.IDAUTH
The TOE must be able to identify and
authenticate users prior to allowing
access to TOE administrative
functions and data.
The O.IDAUTH objective, supported
by the OE.IDAUTH objective, requires
that the TOE, with support from the
environment, must be able to identify
and authenticate operators prior to
allowing access to TOE functions and
data.
O.SECURE
The TOE must ensure the
confidentiality and integrity of all
System data as it passes between
remote components of the TOE.
The O.SECURE objective ensures
that TOE data is protected when
transmitted between remote
components of the TOE.
OE.IDAUTH
The IT Environment will provide
reliable verification of the Virtual
Infrastructure Client user credentials.
The O.IDAUTH objective, supported
by the OE.IDAUTH objective, requires
that the TOE, with support from the
environment, must be able to identify
and authenticate operators prior to
allowing access to TOE functions and
data.
OE.TIME
The IT Environment will provide
reliable timestamps to the TOE.
The OE.TIME objective supports
these objectives by providing for
reliable timestamps to be used by the
TOE.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 55 of 65
© 2010 VMware, Inc.
Threats Objectives Rationale
OE.SEP
The IT Environment will protect the
TOE from external interference or
tampering.
The OE.SEP objective also supports
these objectives by requiring that the
IT environment protect the TOE from
interference that would prevent it from
performing its functions.
T.PRIVIL
An unauthorized individual may
gain access to the TOE and
exploit system privileges to gain
access to TOE security functions
and data.
O.ACCESS
The TOE must allow authorized users
to access only appropriate TOE
functions and data.
The O.ACCESS objective provides
that all access is compliant with the
TSP
37
.
O.ADMIN
The TOE must include a set of
functions that allow efficient
management of its functions and data,
ensuring that TOE users with the
appropriate privileges, and only those
TOE users, can exercise such control.
The O.ADMIN objective ensures that
only TOE operators with appropriate
privileges can manage the functions
and data of the TOE.
O.AUDIT
The TOE must gather audit records of
actions on the TOE which may be
indicative of misuse.
The O.AUDIT objective provides
defense in depth, by requiring the
recording and availability of audit
records for review by an authorized
operator of the TOE.
O.IDAUTH
The TOE must be able to identify and
authenticate users prior to allowing
access to TOE administrative
functions and data.
This threat is primarily diminished by
the O.IDAUTH objective, supported by
the OE.IDAUTH objective, which
requires that the TOE, with support
from the environment, must be able to
identify and authenticate operators
prior to allowing access to TOE
functions and data.
OE.IDAUTH
The IT Environment will provide
reliable verification of the Virtual
Infrastructure Client user credentials.
This threat is primarily diminished by
the O.IDAUTH objective, supported by
the OE.IDAUTH objective, which
requires that the TOE, with support
from the environment, must be able to
identify and authenticate operators
prior to allowing access to TOE
functions and data.
OE.TIME
The IT Environment will provide
The OE.TIME objective supports
these objectives by providing for
reliable timestamps to be used by the
37
TSP: TOE Security Policy
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 56 of 65
© 2010 VMware, Inc.
Threats Objectives Rationale
reliable timestamps to the TOE. TOE.
OE.SEP
The IT Environment will protect the
TOE from external interference or
tampering.
The OE.SEP objective also supports
these objectives by requiring that the
IT environment protect the TOE from
interference that would prevent it from
performing its functions.
T.VIRTUAL_NETWORK
Traffic intended for a VM or an
external entity might be delivered
to the wrong VM or external entity.
O.VLAN
The TOE must ensure that network
traffic traversing a vSwitch is only
delivered to virtual machines and
physical interfaces that are part of the
intended VLAN.
O.VLAN requires that the vSwitch
must deliver network traffic only to
virtual machines and/or physical
interfaces that have been grouped
into the intended VLAN.
O.VSWITCH
The TOE must ensure that network
traffic traversing a vSwitch is only
delivered to the intended virtual
machines and physical interfaces.
O.VSWITCH requires that the vSwitch
must deliver network traffic only to the
virtual machines and/or physical
interfaces for which it is intended.
Every Threat is mapped to one or more Objectives in the table above. This complete mapping demonstrates that the
defined security objectives counter all defined threats.
8.2.2 Security Objectives Rationale Relating to Policies
There are no Organization Security Policies.
8.2.3 Security Objectives Rationale Relating to Assumptions
Table 20 – Assumptions:Objectives Mapping
Assumptions Objectives Rationale
A.DBMS
The VirtualCenter database is
configured so that it is only
accessible to the VirtualCenter
processes and the VirtualCenter
system administrator.
OE.DBMS
The IT Environment will only allow the
VirtualCenter processes and the
VirtualCenter system administrator to
access the VirtualCenter database.
The OE.DBMS objective ensures that
there cannot be any unauthorized
individual compromising the security
of the TOE data by gaining access to
the VirtualCenter DBMS.
A.NOEVIL
Users are non-hostile,
appropriately trained, and follow all
user guidance.
NOE.NOEVIL
Users are non-hostile, appropriately
trained, and follow all user guidance.
The NOE.NOEVIL objective ensures
that operators are non-hostile,
appropriately trained, and follow all
operator guidance.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 57 of 65
© 2010 VMware, Inc.
Assumptions Objectives Rationale
A.PHYSCL
The ESXi Server and
VirtualCenter components will be
located within controlled access
facilities which will prevent
unauthorized physical access.
The Virtual Infrastructure Client
component will only connect to the
server via the protected
management network.
NOE.PHYSCL
The ESXi Server and VirtualCenter
components will be located within
controlled access facilities which will
prevent unauthorized physical access.
The Virtual Infrastructure Client
component will only connect to the
server via the protected management
network.
The NOE.PHYSCL objective requires
that the ESXi Server and
VirtualCenter components will be
located within controlled access
facilities which will prevent
unauthorized physical access, and
that the VI Client component will only
connect to the server via the protected
management network.
Every assumption is mapped to one or more Objectives in the table above. This complete mapping demonstrates
that the defined security objectives uphold all defined assumptions.
8.3 Rationale for Extended Security Functional Requirements
The TOE contains the following explicitly stated security functional requirements:
 EXT_FDP_VC_ETC.1
 EXT_FDP_VC_ITC.1
 EXT_FIA_VC_LOGIN.1
 EXT_VDS_VMM.1
EXT_FDP_VC_ETC.1 was explicitly stated because there is a transfer of TOE data between VirtualCenter (TOE
component) and the VirtualCenter database (IT Environmental component). VirtualCenter stores TOE data such as
scheduled tasks, alarms, events, and permissions in the VirtualCenter database. EXT_FDP_VC_ETC.1 addresses
the export of VirtualCenter data to the VirtualCenter database.
EXT_FDP_VC_ITC.1 was explicitly stated because there is a transfer of TOE data between VirtualCenter (TOE
component) and the VirtualCenter database. VirtualCenter accesses TOE data such as scheduled tasks, alarms,
events, and permissions that are stored in the VirtualCenter database. EXT_FDP_VC_ITC.1 addresses the import of
VirtualCenter data from the VirtualCenter database.
EXT_FIA_VC_LOGIN.1 was explicitly stated because authentication and identification of VirtualCenter users is
performed by the TOE Environment, and not by the TOE. This explicit requirement was written to make the link
between the I&A provided by the environment, and the actions that VirtualCenter takes to ensure that only identified
and authenticated users can access the TOE via VirtualCenter, because there is no CC requirement that can quite do
this. This requirement is based in part on FIA_UAU.1 and FIA_UID.1.
The SFR family “Virtual machine domain separation” was created to specifically address the separation of virtual
machines from each other when running within the TOE, as opposed to separation of the TOE’s domain of
execution from outside entities. The SFR in this family has no dependencies since the stated requirement embodies
all necessary security functions. This requirement exhibits functionality that can easily be documented in the ADV
assurance evidence and thus does not require any additional Assurance Documentation.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 58 of 65
© 2010 VMware, Inc.
8.4 Rationale for Extended TOE Security Assurance Requirements
There are no extended TOE security assurance requirements.
8.5 Security Requirements Rationale
The following discussion provides detailed evidence of coverage for each security objective.
Table 21 – Relationship of Security Requirements to Objectives
Objectives
Requirements
TOE
O.ADMIN
O.AUDIT
O.IDAUTH
O.ACCESS
O.SECURE
O.VM
O.VLAN
O.VSWITCH
TOE
FAU_GEN.1 
FAU_SAR.1 
FCS_COP.1 
FDP_ACC.1(a) 
FDP_ACC.1(b) 
FDP_ACF.1(a) 
FDP_ACF.1(b) 
FDP_IFC.2  
FDP_IFF.1  
EXT_FDP_VC_ETC.1 
EXT_FDP_VC_ITC.1 
FIA_UAU.2  
FIA_UID.2  
EXT_FIA_VC_LOGIN.1  
FMT_MSA.1(a) 
FMT_MSA.1(b) 
FMT_MSA.1(c) 
FMT_MSA.3(a) 
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 59 of 65
© 2010 VMware, Inc.
Objectives
Requirements
TOE
O.ADMIN
O.AUDIT
O.IDAUTH
O.ACCESS
O.SECURE
O.VM
O.VLAN
O.VSWITCH
FMT_MSA.3(b) 
FMT_MSA.3(c) 
FMT_SMF.1 
FMT_SMR.1(a)  
FMT_SMR.1(b)  
FPT_ITT.1 
FPT_ITC.1 
EXT_VDS_VMM.1 
8.5.1 Rationale for Security Functional Requirements of the TOE Objectives
Table 22 – Objectives:SFRs Mapping
Objective
Requirements Addressing the
Objective Rationale
O.ACCESS
The TOE must allow authorized
users to access only appropriate
TOE functions and data.
FDP_ACC.1(a)
Subset access control (VirtualCenter)
All access control requests must be
checked for compliance with the TSP
before execution.
FDP_ACC.1(b)
Subset access control (ESXi Server)
FDP_ACF.1(a)
Security attribute based access
control (VirtualCenter)
FDP_ACF.1(b)
Security attribute based access
control (ESXi Server)
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 60 of 65
© 2010 VMware, Inc.
Objective
Requirements Addressing the
Objective Rationale
EXT_FDP_VC_ETC.1
Export of VirtualCenter data
EXT_FDP_VC_ITC.1
Import of VirtualCenter data
FIA_UAU.2
User authentication before any action
The TOE will not give any access to a
user until the TOE has identified
(FIA_UID.2) and authenticated
(FIA_UAU.2).
FIA_UID.2
User identification before any action
EXT_FIA_VC_LOGIN.1
VirtualCenter user login request
For VirtualCenter the TOE requires
support from the TOE environment to
verify the user credentials.
O.ADMIN
The TOE must include a set of
functions that allow efficient
management of its functions and
data, ensuring that TOE users with
the appropriate privileges, and
only those TOE users, can
exercise such control.
FMT_MSA.1(a)
Management of security attributes
(VirtualCenter)
Only the roles defined in FMT_SMR.1
are given the right to modify or set
defaults for TOE security attributes.
FMT_MSA.1(b)
Management of security attributes
(ESXi Server)
FMT_MSA.1(c)
Management of security attributes
(Virtual Switch Information Flow
Control SFP)
FMT_MSA.3(a)
Static attribute initialisation
(VirtualCenter)
FMT_MSA.3(b)
Static attribute initialisation (ESXi
Server)
FMT_MSA.3(c)
Static attribute initialization (Virtual
Switch Information Flow Control)
FMT_SMF.1
Specification of management
functions
Mechanisms exist to enforce the rules
specified in FMT_MSA.1(a),
FMT_MSA.1(b), FMT_MSA.3(a), and
FMT_MSA.3(b).
FMT_SMR.1(a) The TOE defines a set of roles
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 61 of 65
© 2010 VMware, Inc.
Objective
Requirements Addressing the
Objective Rationale
Security roles (VirtualCenter) supported by VirtualCenter.
FMT_SMR.1(b)
Security roles (ESXi Server)
The TOE defines a set of roles
supported by ESXi Server.
O.AUDIT
The TOE must gather audit
records of actions on the TOE
which may be indicative of misuse.
FAU_GEN.1
Audit data generation
Security-relevant events must be
audited by the TOE.
FAU_SAR.1
Audit review
The TOE must provide the ability to
review the audit trail of the system.
FPT_STM.1 The TOE must provide the ability to
ensure reliable time stamps when
generating audit records.
O.IDAUTH
The TOE must be able to identify
and authenticate users prior to
allowing access to TOE
administrative functions and data.
FIA_UAU.2
User authentication before any action
The TOE will not give any security
sensitive access to a user until the
user has been identified (FIA_UID.2)
and authenticated (FIA_UAU.2).
FIA_UID.2
User identification before any action
EXT_FIA_VC_LOGIN.1
VirtualCenter user login request
For VirtualCenter the TOE requires
support from the TOE environment to
verify the user credentials.
FMT_SMR.1(a)
Security roles (VirtualCenter)
The TOE must be able to recognize
the different user roles that exist for
the TOE.
FMT_SMR.1(b)
Security roles (ESXi Server)
The TOE must be able to recognize
the different user roles that exist for
the TOE.
O.SECURE
The TOE must ensure the
confidentiality and integrity of all
System data as it passes between
remote components of the TOE.
FCS_COP.1
Cryptographic Operation
The TOE protects the confidentiality of
information for data transmitted
between the TOE components and
also for data transmitted between the
TOE and another trusted IT product,
by applying data encryption.
FPT_ITC.1
Inter-TSF confidentiality during
transmission
The TOE shall protect all TOE data
transmitted from the TOE to another
trusted IT product from unauthorized
disclosure during transmission
FPT_ITT.1
Basic internal TSF data transfer
protection
The System must protect the
confidentiality of information during
transmission to a remote component
of the TOE.
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 62 of 65
© 2010 VMware, Inc.
Objective
Requirements Addressing the
Objective Rationale
O.VM
The TOE must provide virtual
machines with a domain of
execution which is protected from
interference and tampering by
virtual machines.
EXT_VDS_VMM.1
Virtual machine domain separation
The TOE must isolate each virtual
machine by providing a domain of
execution which is protected from
interference and tampering by virtual
machines.
O.VLAN
The TOE must ensure that
network traffic traversing a vSwitch
is only delivered to virtual
machines and physical interfaces
that are part of the intended VLAN.
FDP_IFC.2
Complete information flow control
All data transmitted from or to a VM or
a physical interface associated with a
vSwitch will only be delivered to the
intended destination.
O.VSWITCH
The TOE must ensure that
network traffic traversing a vSwitch
is only delivered to the intended
virtual machines and physical
interfaces.
FDP_IFF.1
Simple security attributes
8.5.2 Security Assurance Requirements Rationale
EAL4, augmented with ALC_FLR.1 was chosen to provide a moderate to high level of assurance that is consistent
with good commercial practices. The chosen assurance level is appropriate with the threats defined for the
environment. At EAL4+, the TOE will have an undergone an independent vulnerability analysis demonstrating
resistance to penetration attackers with a low attack potential.
8.5.3 Dependency Rationale
This ST does satisfy all the requirement dependencies of the Common Criteria. Table 23 lists each requirement to
which the TOE claims conformance with a dependency and indicates whether the dependent requirement was
included. As the table indicates, all dependencies have been met.
Table 23 – Functional Requirements Dependencies
SFR Dependencies Dependency
Met
Rationale
EXT_FDP_VC_ETC.1 FDP_ACC.1(a) 
EXT_FDP_VC_ITC.1 FDP_ACC.1(a) 
EXT_FIA_VC_LOGIN.1 None N/A
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 63 of 65
© 2010 VMware, Inc.
SFR Dependencies Dependency
Met
Rationale
EXT_VDS.VMM.1 None N/A
FAU_GEN.1 FPT_STM.1 
FPT_STM.1 is not included because
time stamps are provided by the
environment. An environmental
objective states that the TOE will
receive reliable time stamps.
FAU_SAR.1 FAU_GEN.1 
FCS_COP.1 N/A N/A
FCS_CKM.1 and FCS_CKM.4 are
not included, following the guidance
of CCS Instruction #4, version 1.0.
FDP_ACC.1(a) FDP_ACF.1(a) 
FDP_ACC.1(b) FDP_ACF.1(b) 
FDP_ACF.1(a)
FDP_ACC.1(a)
FMT_MSA.3(a)

FDP_ACF.1(b)
FDP_ACC.1(b)
FMT_MSA.3(b)

FDP_IFC.2 FDP_IFF.1 
FDP_IFF.1
FDP_IFC.1
FMT_MSA.3
 Met by FDP_IFC.2, which is
hierarchical to FDP_IFC.1
FIA_UAU.2 FIA_UID.1
 Met by FIA_UID.2, which is
hierarchical to FIA_UID.1
FMT_MSA.1(a)
FDP_ACC.1(a)
FMT_SMR.1(a)
FMT_SMF.1(a)

FMT_MSA.1(b)
FDP_ACC.1(b)
FMT_SMR.1(b)
FMT_SMF.1(b)

FMT_MSA.1(c)
FPT_IFC.1
FMT_SMR.1(b)
FMT_SMF.1(c)

FMT_MSA.3(a)
FMT_MSA.1(a)
FMT_SMR.1(a)

FMT_MSA.3(b)
FMT_MSA.1(b)
FMT_SMR.1(b)

FMT_MSA.3(c)
FMT_MSA.1(c)
FMT_SMR.1(b)

FMT_SMR.1(a) FIA_UID.1 
FMT_SMR.1(b) FIA_UID.1 
FPT_ITC.1 None N/A
FPT_ITT.1 None N/A
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 64 of 65
© 2010 VMware, Inc.
9 Acronyms
Table 24 – Acronyms
Acronym Definition
API Application Programming Interface
BIOS Basic Input Output Signal
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
CC Common Criteria
CM Configuration Management
DB Database
DBMS Database Management System
DCUI Direct Console User Interface
DES Data Encryption Standard
DRS Distributed Resource Scheduler
EAL Evaluation Assurance Level
ESXi ESX Embedded
FIPS Federal Information Processing Standard
FTP File Transfer Protocol
GB Gigabyte
GHZ Gigahertz
HA High Availability
HMAC Hash-based Message Authentication Code
HTTPS Hypertext Transfer Protocol Secure
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
iSCSI Internet Small Computer System Interface
IT Information Technology
MB Megabytes
N/A Not Applicable
NFS Network File System
NTP Network Time Protocol
OEM Other Equipment Manufacturer
OS Operating System
PP Protection Profile
RAM Random Access Memory
SAN Storage Area Network
Security Target, Version 0.7 February 9, 2010
VMware ESXi Server 3.5 and VirtualCenter 2.5 Page 65 of 65
© 2010 VMware, Inc.
SAR Security Assurance Requirement
SDK Software Development Kit
SFP Security Functional Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SMP Symmetric Multiprocessing
SNMP Simple Network Management Protocol
SP Service Pack/Service Package
SQL Structured Query Language
SSL Secure Sockets Layer
ST Security Target
TOE Target of Evaluation
TSF TOE Security Function
TSP TOE Security Policy
VC VirtualCenter
VI Virtual Infrastructure
VIC Virtual Infrastructure Client
VLAN Virtual Local Area Network
VM Virtual Machine
VUM VMware Update Manager