Protection Profile for Virtualization

Version: 1.1.1
2021-08-19
National Information Assurance Partnership

Revision History

Contents

1 Introduction

1.1 Overview

1.3 Compliant Targets of Evaluation

1.3.1 TOE Boundary

Figure 1: Virtualization System and Platform

1.3.2 Requirements Met by the Platform

1.3.3 Scope of Certification

1.3.4 Product and Platform Equivalence

1.4 Use Cases

2 Conformance Claims

Conformance Statement

A Security Target must claim exact conformance to this Protection Profile, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module with this PP.

• PP-Module for Client Virtualization Systems, Version 1.1
• PP-Module for Server Virtualization Systems, Version 1.1

CC Conformance Claims

This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].

PP Claims

This PP does not claim conformance to any other PP.

Package Claims

This PP is Functional Package for TLS-conformant. This PP is Functional Package for Secure Shell-conformant.

3 Security Problem Description

3.1 Threats

T.DATA_LEAKAGE

It is a fundamental property of VMs that the domains encapsulated by different VMs remain separate unless data sharing is permitted by policy. For this reason, all Virtualization Systems shall support a policy that prohibits information transfer between VMs.

It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, or through virtual or physical network components under the control of the VS. When VMs are configured as such, it shall not be possible for data to leak between domains, neither by the express efforts of software or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM or other VS components.

If it is possible for data to leak between domains when prohibited by policy, then an adversary on one domain or network can obtain data from another domain. Such cross-domain data leakage can, for example, cause classified information, corporate proprietary information, or personally identifiable information to be made accessible to unauthorized entities.

T.UNAUTHORIZED_UPDATE

It is common for attackers to target outdated versions of software containing known flaws. This means it is extremely important to update VS software as soon as possible when updates are available. But the source of the updates and the updates themselves must be trusted. If an attacker can write their own update containing malicious code they can take control of the VS.

T.UNAUTHORIZED_MODIFICATION

System integrity is a core security objective for Virtualization Systems. To achieve system integrity, the integrity of each VMM component must be established and maintained. Malware running on the platform must not be able to undetectably modify VS components while the system is running or at rest. Likewise, malicious code running within a virtual machine must not be able to modify Virtualization System components.

T.USER_ERROR

If a Virtualization System is capable of simultaneously displaying VMs of different domains to the same user at the same time, there is always the chance that the user will become confused and unintentionally leak information between domains. This is especially likely if VMs belonging to different domains are indistinguishable. Malicious code may also attempt to interfere with the user’s ability to distinguish between domains. The VS must take measures to minimize the likelihood of such confusion.

T.3P_SOFTWARE

In some VS implementations, functions critical to the security of the TOE are by necessity performed by software not produced by the virtualization vendor. Such software may include physical device drivers, and even non-TOE entities such as Host Operating Systems. Since this software has the same or similar privilege level as the VS, vulnerabilities can be exploited by an adversary to compromise the VS and VMs. Where possible, the VS should mitigate the results of potential vulnerabilities or malicious content in third-party code on which it relies. For example, physical device drivers (potentially the Host OS) could be encapsulated within VMs in order to limit the effects of compromise.

T.VMM_COMPROMISE

The VS is designed to provide the appearance of exclusivity to the VMs and is designed to separate or isolate their functions except where specifically shared. Failure of security mechanisms could lead to unauthorized intrusion into or modification of the VMM, or bypass of the VMM altogether, by non-TOE software, such as that running in Guest or Helper VMs or on the host platform. This must be prevented to avoid compromising the VS.

T.PLATFORM_COMPROMISE

The VS must be capable of protecting the platform from threats that originate within VMs and operational networks connected to the VS. The hosting of untrusted—even malicious—domains by the VS cannot be permitted to compromise the security and integrity of the platform on which the VS executes. If an attacker can access the underlying platform in a manner not controlled by the VMM, the attacker might be able to modify system firmware or software—compromising both the VS and the underlying platform.

T.UNAUTHORIZED_ACCESS

Functions performed by the management layer include VM configuration, virtualized network configuration, allocation of physical resources, and reporting. Only certain authorized system users (administrators) are allowed to exercise management functions or obtain sensitive information from the TOE.

Virtualization Systems are often managed remotely over communication networks. Members of these networks can be both geographically and logically separated from each other, and pass through a variety of other systems which may be under the control of an adversary, and offer the opportunity for communications to be compromised. An adversary with access to an open management network could inject commands into the management infrastructure or extract sensitive information. This would provide an adversary with administrator privilege on the platform, and administrative control over the VMs and virtual network connections. The adversary could also gain access to the management network by hijacking the management network channel.

T.WEAK_CRYPTO

To the extent that VMs appear isolated within the VS, a threat of weak cryptography may arise if the VMM does not provide good entropy to support security-related features that depend on entropy to implement cryptographic algorithms. For example, a random number generator keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. Good random numbers are essential to implementing strong cryptography. Cryptography implemented using poor random numbers can be defeated by a sophisticated adversary. Such defeat can result in the compromise of Guest VM data and credentials, and of VS data and credentials, and can enable unauthorized access to the VS or VMs.

T.UNPATCHED_SOFTWARE

Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.

T.MISCONFIGURATION

The VS may be misconfigured, which could impact its functioning and security. This misconfiguration could be due to an administrative error or the use of faulty configuration data.

T.DENIAL_OF_SERVICE

A VM may block others from system resources (e.g., system memory, persistent storage, and processing time) via a resource exhaustion attack.

3.2 Assumptions

A.PLATFORM_INTEGRITY

The platform has not been compromised prior to installation of the VS.

A.PHYSICAL

Physical security commensurate with the value of the TOE and the data it contains is assumed to be provided by the environment.

A.TRUSTED_ADMIN

TOE Administrators are trusted to follow and apply all administrator guidance.

A.NON_MALICIOUS_USER

The user of the VS is not willfully negligent or hostile, and uses the VS in compliance with the applied enterprise security policy and guidance. At the same time, malicious applications could act as the user, so requirements which confine malicious applications are still in scope.

3.3 Organizational Security Policies

4 Security Objectives

4.1 Security Objectives for the TOE

O.VM_ISOLATION

VMs are the fundamental subject of the system. The VMM is responsible for applying the system security policy (SSP) to the VM and all resources. As basic functionality, the VMM must support a security policy that mandates no information transfer between VMs.

The VMM must support the necessary mechanisms to isolate the resources of all VMs. The VMM partitions a platform's physical resources for use by the supported virtual environments. Depending on customer requirements, a VM may need a completely isolated environment with exclusive access to system resources or share some of its resources with other VMs. It must be possible to enforce a security policy that prohibits the transfer of data between VMs through shared devices. When the platform security policy allows the sharing of resources across VM boundaries, the VMM must ensure that all access to those resources is consistent with the policy. The VMM may delegate the responsibility for the mediation of resource sharing to select Service VMs; however in doing so, it remains responsible for mediating access to the Service VMs, and each Service VM must mediate all access to any shared resource that has been delegated to it in accordance with the SSP.

Both virtual and physical devices are resources requiring access control. The VMM must enforce access control in accordance with system security policy. Physical devices are platform devices with access mediated via the VMM per the O.VMM_Integrity objective. Virtual devices may include virtual storage devices and virtual network devices. Some of the access control restrictions must be enforced internal to Service VMs, as may be the case for isolating virtual networks. VMMs may also expose purely virtual interfaces. These are VMM specific, and while they are not analogous to a physical device, they are also subject to access control.

The VMM must support the mechanisms to isolate all resources associated with virtual networks and to limit a VM's access to only those virtual networks for which it has been configured. The VMM must also support the mechanisms to control the configurations of virtual networks according to the SSP.

O.VMM_INTEGRITY

Integrity is a core security objective for Virtualization Systems. To achieve system integrity, the integrity of each VMM component must be established and maintained. This objective concerns only the integrity of the VS—not the integrity of software running inside of Guest VMs or of the physical platform. The overall objective is to ensure the integrity of critical components of a VS.

Initial integrity of a VS can be established through mechanisms such as a digitally signed installation or update package, or through integrity measurements made at launch. Integrity is maintained in a running system by careful protection of the VMM from untrusted users and software. For example, it must not be possible for software running within a Guest VM to exploit a vulnerability in a device or hypercall interface and gain control of the VMM. The vendor must release patches for vulnerabilities as soon as practicable after discovery.

O.PLATFORM_INTEGRITY

The integrity of the VMM depends on the integrity of the hardware and software on which the VMM relies. Although the VS does not have complete control over the integrity of the platform, the VS should as much as possible try to ensure that no users or software hosted by the VS can undermine the integrity of the platform.

O.DOMAIN_INTEGRITY

While the VS is not responsible for the contents or correct functioning of software that runs within Guest VMs, it is responsible for ensuring that the correct functioning of the software within a Guest VM is not interfered with by other VMs.

O.MANAGEMENT_ACCESS

VMM management functions include VM configuration, virtualized network configuration, allocation of physical resources, and reporting. Only authorized users (administrators) may exercise management functions.

Because of the privileges exercised by the VMM management functions, it must not be possible for the VMM’s management components to be compromised without administrator notification. This means that unauthorized users cannot be permitted access to the management functions, and the management components must not be interfered with by Guest VMs or unprivileged users on other networks—including operational networks connected to the TOE.

VMMs include a set of management functions that collectively allow administrators to configure and manage the VMM, as well as configure Guest VMs. These management functions are specific to the VS and are distinct from any other management functions that might exist for the internal management of any given Guest VM. These VMM management functions are privileged, with the security of the entire system relying on their proper use. The VMM management functions can be classified into different categories and the policy for their use and the impact to security may vary accordingly.

The management functions are distributed throughout the VMM (within the VMM and Service VMs). The VMM must support the necessary mechanisms to enable the control of all management functions according to the system security policy. When a management function is distributed among multiple Service VMs, the VMs must be protected using the security mechanisms of the Hypervisor and any Service VMs involved to ensure that the intent of the system security policy is not compromised. Additionally, since hypercalls permit Guest VMs to invoke the Hypervisor, and often allow the passing of data to the Hypervisor, it is important that the hypercall interface is well-guarded and that all parameters be validated.

The VMM maintains configuration data for every VM on the system. This configuration data, whether of Service or Guest VMs, must be protected. The mechanisms used to establish, modify and verify configuration data are part of the VS management functions and must be protected as such. The proper internal configuration of Service VMs that provide critical security functions can also greatly impact VS security. These configurations must also be protected. Internal configuration of Guest VMs should not impact overall VS security. The overall goal is to ensure that the VMM, including the environments internal to Service VMs, is properly configured and that all Guest VM configurations are maintained consistent with the system security policy throughout their lifecycle.

Virtualization Systems are often managed remotely. For example, an administrator can remotely update virtualization software, start and shut down VMs, and manage virtualized network connections. If a console is required, it could be run on a separate machine or it could itself run in a VM. When performing remote management, an administrator must communicate with a privileged management agent over a network. Communications with the management infrastructure must be protected from Guest VMs and operational networks.

O.PATCHED_SOFTWARE

The VS must be updated and patched when needed in order to prevent the potential compromise of the VMM, as well as the networks and VMs that it hosts. Identifying and applying needed updates must be a normal part of the operating procedure to ensure that patches are applied in a timely and thorough manner. In order to facilitate this, the VS must support standards and protocols that help enhance the manageability of the VS as an IT product, enabling it to be integrated as part of a manageable network (e.g., reporting current patch level and patchability).

O.VM_ENTROPY

VMs must have access to good entropy sources to support security-related features that implement cryptographic algorithms. For example, in order to function as members of operational networks, VMs must be able to communicate securely with other network entities—whether virtual or physical. They must therefore have access to sources of good entropy to support that secure communication.

O.AUDIT

An audit log must be created that captures accesses to the objects the TOE protects. The log of these accesses, or audit events, must be protected from modification, unauthorized access, and destruction. The audit log must be sufficiently detailed to indicate the date and time of the event, the identify of the user, the type of event, and the success or failure of the event.

O.CORRECTLY_APPLIED_CONFIGURATION

The TOE must not apply configurations that violate the current security policy.

The TOE must correctly apply configurations and policies to a newly created Guest VM, as well as to existing Guest VMs when applicable configuration or policy changes are made. All changes to configuration and to policy must conform to the existing security policy. Similarly, changes made to the configuration of the TOE itself must not violate the existing security policy.

O.RESOURCE_ALLOCATION

The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.

4.2 Security Objectives for the Operational Environment

OE.CONFIG

TOE administrators will configure the VS correctly to create the intended security policy.

OE.PHYSICAL

Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment.

OE.TRUSTED_ADMIN

TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner.

OE.NON_MALICIOUS_USER

Users are trusted to not be willfully negligent or hostile and use the VS in compliance with the applied enterprise security policy and guidance.

4.3 Security Objectives Rationale

5 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): Is used to add details to a requirement (including replacing an assignment with a more restrictive selection) or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
• Selection (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
• Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
• Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 Security Functional Requirements

5.1.1 Auditable Events for Mandatory SFRs

5.1.2 Security Audit (FAU)

5.1.3 Cryptographic Support (FCS)

                                    # Input: PT, IV, Key
                                    for i = 1 to 1000:
                                        if i == 1:
                                            CT[1] = AES-CBC-Encrypt(Key, IV, PT)
                                            PT = IV
                                        else:
                                            CT[i] = AES-CBC-Encrypt(Key, PT)
                                            PT = CT[i-1]
                                

5.1.4 User Data Protection (FDP)

5.1.5 Identification and Authentication (FIA)

5.1.6 Security Management (FMT)

5.1.7 Protection of the TSF (FPT)

5.1.8 TOE Access Banner (FTA)

5.1.9 Trusted Path/Channel (FTP)

5.1.10 TOE Security Functional Requirements Rationale

The following rationale provides justification for each security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:

Table 4: SFR Rationale

Objective	Addressed by	Rationale
O.VM_​ISOLATION	FAU_GEN.1	Audit events can report attempts to breach isolation.
	FCS_CKM_EXT.4	Requires cryptographic key destruction to protect domain data in shared storage.
	FDP_PPR_EXT.1	Requires support for reducing attack surface through disabling access to unneeded physical platform resources.
	FDP_RIP_EXT.1	Ensures that domain data is cleared from memory before memory is re-allocated.
	FDP_RIP_EXT.2	Ensures that domain data is cleared from physical storage upon re-allocation of the storage.
	FDP_VMS_EXT.1	Ensures that authorized data transfers between VMs are done securely.
	FDP_VNC_EXT.1	Ensures that network traffic is visible only to VMs configured to be that network.
	FPT_DVD_EXT.1	Ensures that VMs can access only those virtual devices that they are configured to access.
	FPT_EEM_EXT.1	Requires that the TOE use security mechanisms supported by the physical platform.
	FPT_HAS_EXT.1	Requires that the TOE use platform-supported virtualization assists to reduce attack surface.
	FPT_VDP_EXT.1	Requires validation of parameter data passed to the hardware abstraction by untrusted VMs.
	FPT_VIV_EXT.1	Ensures that untrusted VMs cannot invoke privileged code without proper hypervisor mediation.
O.VMM_​INTEGRITY	FAU_GEN.1	Audit events can report potential integrity breaches and attempts.
	FCS_CKM.1	Requires generation of asymmetric keys for protection of integrity measures.
	FCS_COP.1	Ensures proper functioning of cryptographic algorithms used to protect data integrity.
	FCS_RBG_EXT.1	Requires that the TOE has access to high-quality entropy for cryptographic purposes.
	FDP_PPR_EXT.1	Requires support for reducing attack surface through disabling access to unneeded physical platform resources.
	FDP_VMS_EXT.1	Ensures that authorized data transfers between VMs are done securely.
	FDP_VNC_EXT.1	Ensures that network traffic is visible only to VMs configured to be that network.
	FPT_DDI_EXT.1	Requires that physical device drivers be isolated other parts of the TOE and from one another (optional).
	FPT_EEM_EXT.1	Requires that the TOE use security mechanisms supported by the physical platform.
	FPT_HAS_EXT.1	Requires that the TOE use platform-supported virtualization assists to reduce attack surface.
	FPT_HCL_EXT.1	Requires that Hypercall parameters be validated.
	FPT_ML_EXT.1	Requires measured launch of the platform and VMM (objective).
	FPT_VDP_EXT.1	Requires validation of parameter data passed to the hardware abstraction by untrusted VMs.
	FPT_VIV_EXT.1	Ensures that untrusted VMs cannot invoke privileged code without proper hypervisor mediation.
O.PLATFORM_​INTEGRITY	FDP_HBI_EXT.1	Requires that the TOE use platform-supported mechanisms for access to physical devices.
	FDP_PPR_EXT.1	Requires support for reducing attack surface through disabling access to unneeded physical platform resources.
	FDP_VMS_EXT.1	Ensures that authorized data transfers between VMs are done securely.
	FDP_VNC_EXT.1	Ensures that network traffic is visible only to VMs configured to be that network.
	FPT_DVD_EXT.1	Ensures that VMs cannot access virtual devices that they are not configured to access.
	FPT_EEM_EXT.1	Requires that the TOE use security mechanisms supported by the physical platform.
	FPT_HAS_EXT.1	Requires that the TOE use platform-supported virtualization assists to reduce attack surface.
	FPT_HCL_EXT.1	Requires that Hypercall parameters be validated.
	FPT_ML_EXT.1	Requires measured launch of the platform and VMM (objective).
	FPT_VDP_EXT.1	Requires validation of parameter data passed to the hardware abstraction by untrusted VMs.
	FPT_VIV_EXT.1	Ensures that untrusted VMs cannot invoke privileged code without proper hypervisor mediation.
O.DOMAIN_​INTEGRITY	FCS_CKM_EXT.4	Requires cryptographic key destruction to protect domain data in shared storage.
	FCS_ENT_EXT.1	Requires that domains have access to high-quality entropy for cryptographic purposes.
	FCS_RBG_EXT.1	Requires that the TOE has access to high-quality entropy for cryptographic purposes.
	FDP_RIP_EXT.1	Ensures that domain data is cleared from memory before memory is re-allocated to another domain.
	FDP_RIP_EXT.2	Ensures that domain data is cleared from physical storage upon re-allocation of the storage to another domain.
	FDP_VMS_EXT.1	Ensures that authorized data transfers between domains are done securely.
	FDP_VNC_EXT.1	Ensures that network traffic is visible only to VMs configured to be that network.
	FPT_EEM_EXT.1	Requires that the TOE use security mechanisms supported by the physical platform.
	FPT_GVI_EXT.1	Requires that the TOE support Guest VM measurements and integrity checks (optional).
	FPT_HAS_EXT.1	Requires that the TOE use platform-supported virtualization assists to reduce attack surface.
	FPT_INT_EXT.1	Requires that the TOE support introspection into Guest VMs (optional).
	FPT_RDM_EXT.1	Requires support for rules for switching removable media between domains to reduce the chance of data spillage.
	FPT_VDP_EXT.1	Requires validation of parameter data passed to the hardware abstraction by untrusted VMs.
	FTP_UIF_EXT.1	Ensures that users are able to determine the domain with the current input focus.
	FTP_UIF_EXT.2	Ensures that users can know the identity of any VM that they can access.
O.MANAGEMENT_​ACCESS	FAU_GEN.1	Audit events report attempts to access the management subsystem.
	FCS_CKM.1	Requires generation of asymmetric keys for trusted communications channels.
	FCS_CKM.2	Requires establishment of cryptographic keys for trusted communications channels.
	FCS_COP.1	Ensures proper functioning of cryptographic algorithms used to implement access controls.
	FCS_HTTPS_EXT.1	Ensures that HTTPS trusted communications channels are implemented properly.
	FCS_IPSEC_EXT.1	Ensures that IPsec trusted communications channels are implemented properly.
	FCS_RBG_EXT.1	Requires that the TOE has access to high-quality entropy for cryptographic purposes.
	FIA_AFL_EXT.1	Requires that the TOE detect failed authentication attempts for Administrator access.
	FIA_PMG_EXT.1	Ensures that password-based administrator login is properly implemented.
	FIA_UAU.5	Ensures that strong mechanisms are used for Administrator authentication.
	FIA_UIA_EXT.1	Requires that Administrators be successfully authenticated before performing management functions.
	FIA_X509_EXT.1	Ensures that certificate validation is implemented properly.
	FIA_X509_EXT.2	Ensures that certificate-based authentication is implemented properly.t functions.
	FMT_SMO_EXT.1	Requires that the TOE support having separate management and operational networks.
	FTP_ITC_EXT.1	Ensures that trusted communications channels are implemented using good cryptography.
	FTP_TRP.1	Ensures that certain communications use a trusted path.
O.PATCHED_​SOFTWARE	FPT_IDV_EXT.1	Requires support for software identification labels (optional).
	FPT_TUD_EXT.1	Requires support for product updates.
	FPT_TUD_EXT.2	Specifies requirements for certificate-based code signing for update.
O.VM_​ENTROPY	FCS_ENT_EXT.1	Requires that domains have access to high-quality entropy for cryptographic purposes.
	FCS_RBG_EXT.1	Requires that the TOE has access to high-quality entropy for cryptographic purposes.
O.AUDIT	FAU_ARP.1	Requires support for automatic responses to audit events (optional).
	FAU_GEN.1	Requires reporting of audit events.
	FAU_SAA.1	Requires support for rules for indicating security violations based on audit events (optional).
	FAU_SAR.1	Requires support for Administrator review of audit records.
	FAU_STG.1	Requires protection of stored audit records.
	FAU_STG_EXT.1	Requires support for protected transmission of audit records off the TOE.
O.CORRECTLY_​APPLIED_​CONFIGURATION	FDP_VMS_EXT.1	Ensures that data sharing between VMs is turned off by default.
O.RESOURCE_​ALLOCATION	FCS_CKM_EXT.4	Requires cryptographic key destruction to ensure residual data in shared storage is unrecoverable.
	FDP_RIP_EXT.1	Ensures that domain data is cleared from memory before memory is re-allocated.
	FDP_RIP_EXT.2	Ensures that domain data is cleared from storage upon re-allocation of the storage.

5.2 Security Assurance Requirements

5.2.1 Class ASE: Security Target Evaluation

5.2.2 Class ADV: Development

5.2.3 Class AGD: Guidance Documents

• instructions to successfully install the TOE in that environment; and
• instructions to manage the security of the TOE as a product and as a component of the larger operational environment.

5.2.4 Class ALC: Life-Cycle Support

5.2.5 Class ATE: Tests

5.2.6 Class AVA: Vulnerability Assessment

Appendix A - Optional Requirements

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Strictly Optional Requirements

A.1.2 Security Audit (FAU)

A.1.3 Protection of the TSF (FPT)

A.2 Objective Requirements

A.2.1 Auditable Events for Objective Requirements

A.2.2 Protection of the TSF (FPT)