@@ -311,57 +311,56 @@
2 Conformance Claim
3 Security Problem Definition
-
3.1 Threats
- 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.
+ 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
+ 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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
+ A VM may block others from system resources (e.g., system memory, persistent storage, and processing time) via a resource exhaustion attack.
- 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.
+ 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.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.
+ 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.
+ 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.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.
+ 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.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.
+ 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.UNPATCHED_SOFTWARE
-
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
+ Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.
+ 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.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.
+ 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.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.
+ 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.
@@ -370,7 +369,7 @@ 3.2 Assumptions
- 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.
+ 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.
- A.PHYSICAL
-
@@ -378,7 +377,7 @@
3.2 Assumptions
- A.PLATFORM_INTEGRITY
-
- The platform has not been compromised prior to installation of the VS.
+ The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
-
@@ -398,23 +397,23 @@
4.1 Se
- 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.
+ 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.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.
+ 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.
+ 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).
+ 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.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.
+ 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.RESOURCE_ALLOCATION
-
@@ -422,7 +421,7 @@
4.1 Se
- 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.
+ 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.VM_ENTROPY
-
@@ -430,7 +429,7 @@
4.1 Se
- 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.
+ 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.
@@ -439,11 +438,11 @@ OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
+ TOE administrators will configure the VS correctly to create the intended security policy.
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.
+ Users are trusted to not be willfully negligent or hostile and use the VS in compliance with the applied enterprise security policy and guidance.
OE.PHYSICAL
@@ -465,13 +464,13 @@ 4.3 Security Objectives Rationale<
Threat, Assumption, or OSP Security Objectives Rationale
- T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE.
+ T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE.
- T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
+ T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
- O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
+ O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult.
@@ -480,16 +479,16 @@ 4.3 Security Objectives Rationale<
T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations.
- T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running.
+ T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running.
T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner.
- T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
+ T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
- O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
+ O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code.
@@ -498,13 +497,13 @@ 4.3 Security Objectives Rationale<
T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available.
- T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another.
+ T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another.
- T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
+ T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
- O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
+ O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms.
@@ -584,13 +583,13 @@ FAU_GEN.1 Audit Data Generation
- Application Note: The ST author can include other auditable events directly in Table t-audit-mandatory; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.
+ Application Note: The ST author can include other auditable events directly in Table t-audit-mandatory; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and Table t-audit-sel-based should be included in the ST if the associated SFRs and selections are included.
- The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.
+ The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM's hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM's hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
The following table contains the events enumerated in the auditable events table for the TLS Functional Package. Inclusion of these events in the ST is subject to selection above, inclusion of the corresponding SFRs in the ST, and support in the FP as represented by a selection in the table below.
@@ -753,7 +752,7 @@ FAU_STG_EXT.1 Off-Loading of Audit Data
FAU_STG_EXT.1.2
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full.
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records ], [assignment: other action ]]when the local storage space for audit data is full.
Application Note: An external log server, if available, might be used as alternative storage space in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the new audit data to an external IT entity’.
@@ -820,7 +819,7 @@ FCS_CKM.1 Cryptographic Key Generation
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
+ ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
@@ -1264,7 +1263,7 @@ FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
+ ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
].
@@ -1428,13 +1427,13 @@ FCS_ENT_EXT.1 Entropy for Virtual Machines
The TSF shall provide independent entropy across multiple VMs.
- Application Note: This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide pass-through access to entropy sources provided by the host platform.
+ Application Note: This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or 3) pass-through access to a hardware entropy source (including a source of random numbers). In all cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a VM-unaware guest would use.
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or 3) pass-through access to a hardware entropy source (including a source of random numbers). In all cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a VM-unaware guest would use.
- The ST author should select “Hypercall interface” if the TSF provides an API function through which guest-resident software can obtain entropy or random numbers. The ST author should select “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through which it can obtain entropy or random numbers. Such an interface could present a virtualized real device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or random number source on the platform. The ST author should select all items that are appropriate.
+ The ST author should select “Hypercall interface” if the TSF provides an API function through which guest-resident software can obtain entropy or random numbers. The ST author should select “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through which it can obtain entropy or random numbers. Such an interface could present a virtualized real device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality of entropy provided to another VM on the same platform.
@@ -1450,7 +1449,7 @@ FCS_ENT_EXT.1 Entropy for Virtual Machines
TSS
- The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and how to access the interface to acquire entropy or random numbers. The evaluator shall verify that the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by another.
+ The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and how to access the interface to acquire entropy or random numbers. The evaluator shall verify that the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by another.
Tests
@@ -1458,10 +1457,10 @@ FCS_ENT_EXT.1 Entropy for Virtual Machines
The evaluator shall perform the following tests:
-
- Test FCS_ENT_EXT.1.2:1: The evaluator shall invoke entropy from each Guest VM. The evaluator shall verify that each VM acquires values from the interface.
+ Test FCS_ENT_EXT.1.2:1: The evaluator shall invoke entropy from each Guest VM. The evaluator shall verify that each VM acquires values from the interface.
-
- Test FCS_ENT_EXT.1.2:2: The evaluator shall invoke entropy from multiple VMs as nearly simultaneously as practicable. The evaluator shall verify that the entropy used in one VM is not identical to that invoked from the other VMs.
+ Test FCS_ENT_EXT.1.2:2: The evaluator shall invoke entropy from multiple VMs as nearly simultaneously as practicable. The evaluator shall verify that the entropy used in one VM is not identical to that invoked from the other VMs.
@@ -1530,9 +1529,9 @@ FDP_HBI_EXT.1 Hardware-Based Isolation Mechanisms
FDP_HBI_EXT.1.1
- The TSF shall use[selection: no mechanism, list of platform-provided, hardware-based mechanisms ]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, physical devices to which the VMM allows Guest VMs physical access ].
+ The TSF shall use[selection: no mechanism, [assignment: list of platform-provided, hardware-based mechanisms ]]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, [assignment: physical devices to which the VMM allows Guest VMs physical access ]].
- Application Note: The TSF must use available hardware-based isolation mechanisms to constrain VMs when VMs have direct access to physical devices. “Direct access” in this context means that the VM can read or write device memory or access device I/O ports without the VMM being able to intercept and validate every transaction.
+ Application Note: The TSF must use available hardware-based isolation mechanisms to constrain VMs when VMs have direct access to physical devices. “Direct access” in this context means that the VM can read or write device memory or access device I/O ports without the VMM being able to intercept and validate every transaction.
@@ -1562,7 +1561,7 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.1
- The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:[assignment: list of physical platform resources the VMM isable to control access to].
+ The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:[assignment: list of physical platform resources the VMM isable to control access to].
@@ -1570,7 +1569,7 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.2
- The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, list of physical platform resources to which access is explicitly denied ].
+ The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, [assignment: list of physical platform resources to which access is explicitly denied ]].
@@ -1578,21 +1577,15 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.3
- The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, list of physical platform resources to which access is always allowed ].
+ The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, [assignment: list of physical platform resources to which access is always allowed ]].
Application Note: For purposes of this requirement, physical platform resources are divided into three categories:
- -
- those to which Guest OS access is configurable and moderated by the VMM
-
- -
- those to which the Guest OS is never allowed to have direct access, and
-
- -
- those to which the Guest OS is always allowed to have direct access.
-
+ - those to which Guest OS access is configurable and moderated by the VMM
+ - those to which the Guest OS is never allowed to have direct access, and
+ - those to which the Guest OS is always allowed to have direct access.
- For element 1, the ST author lists the physical platform resources that can be configured for Guest VM access by an administrator. For element 2, the ST author lists the physical platform resources to which Guest VMs may never be allowed direct access. If there are no such resources, the ST author selects "no physical platform resources." Likewise, any resources to which all Guest VMs automatically have access to are to be listed in the third element. If there are no such resources, then "no physical platform resources" is selected.
+ For element 1, the ST author lists the physical platform resources that can be configured for Guest VM access by an administrator. For element 2, the ST author lists the physical platform resources to which Guest VMs may never be allowed direct access. If there are no such resources, the ST author selects "no physical platform resources." Likewise, any resources to which all Guest VMs automatically have access to are to be listed in the third element. If there are no such resources, then "no physical platform resources" is selected.
@@ -1608,11 +1601,11 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
TSS
- The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to physical platform resources. This description shall cover all of the physical platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and how each physical platform resource that is controllable (that is, listed in the assignment statement in the first element) is identified to an Administrator.
+ The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to physical platform resources. This description shall cover all of the physical platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and how each physical platform resource that is controllable (that is, listed in the assignment statement in the first element) is identified to an Administrator.
- The evaluator shall ensure that the TSS describes how the Guest VM is associated with each physical resource, and how other Guest VMs cannot access a physical resource without being granted explicit access. For TOEs that implement a robust interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the TSS describes the possible operations or modes of access between a Guest VM's and physical platform resources.
+ The evaluator shall ensure that the TSS describes how the Guest VM is associated with each physical resource, and how other Guest VMs cannot access a physical resource without being granted explicit access. For TOEs that implement a robust interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the TSS describes the possible operations or modes of access between a Guest VM's and physical platform resources.
- If physical resources are listed in the second element, the evaluator shall examine the TSS and operational guidance to determine that there appears to be no way to configure those resources for access by a Guest VM. The evaluator shall document in the evaluation report their analysis of why the controls offered to configure access to physical resources can't be used to specify access to the resources identified in the second element (for example, if the interface offers a drop-down list of resources to assign, and the denied resources are not included on that list, that would be sufficient justification in the evaluation report).
+ If physical resources are listed in the second element, the evaluator shall examine the TSS and operational guidance to determine that there appears to be no way to configure those resources for access by a Guest VM. The evaluator shall document in the evaluation report their analysis of why the controls offered to configure access to physical resources can't be used to specify access to the resources identified in the second element (for example, if the interface offers a drop-down list of resources to assign, and the denied resources are not included on that list, that would be sufficient justification in the evaluation report).
Guidance
@@ -1623,19 +1616,19 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
-
- Test FDP_PPR_EXT.1.3:1: For each physical platform resource identified in the first element, the evaluator shall configure a Guest VM to have access to that resource and show that the Guest VM is able to successfully access that resource.
+ Test FDP_PPR_EXT.1.3:1: For each physical platform resource identified in the first element, the evaluator shall configure a Guest VM to have access to that resource and show that the Guest VM is able to successfully access that resource.
-
- Test FDP_PPR_EXT.1.3:2: For each physical platform resource identified in the first element, the evaluator shall configure the system such that a Guest VM does not have access to that resource and show that the Guest VM is unable to successfully access that resource.
+ Test FDP_PPR_EXT.1.3:2: For each physical platform resource identified in the first element, the evaluator shall configure the system such that a Guest VM does not have access to that resource and show that the Guest VM is unable to successfully access that resource.
-
Test FDP_PPR_EXT.1.3:3: [conditional]: For TOEs that have a robust control interface, the evaluator shall exercise each element of the interface as described in the TSS and the operational guidance to ensure that the behavior described in the operational guidance is exhibited.
-
- Test FDP_PPR_EXT.1.3:4: [conditional]: If the TOE explicitly denies access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource from a Guest VM and observe that access is denied.
+ Test FDP_PPR_EXT.1.3:4: [conditional]: If the TOE explicitly denies access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource from a Guest VM and observe that access is denied.
-
- Test FDP_PPR_EXT.1.3:5: [conditional]: If the TOE explicitly allows access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource from a Guest VM and observe that the access is allowed. If the operational guidance specifies that access is allowed simultaneously by more than one Guest VM, the evaluator shall attempt to access each resource listed from more than one Guest VM and show that access is allowed.
+ Test FDP_PPR_EXT.1.3:5: [conditional]: If the TOE explicitly allows access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource from a Guest VM and observe that the access is allowed. If the operational guidance specifies that access is allowed simultaneously by more than one Guest VM, the evaluator shall attempt to access each resource listed from more than one Guest VM and show that access is allowed.
@@ -1650,15 +1643,15 @@ FDP_RIP_EXT.1 Residual Information in Memory
FDP_RIP_EXT.1.1
- The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM.
+ The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM.
- Application Note: Physical memory must be zeroed before it is made accessible to a VM for general use by a Guest OS.
+ Application Note: Physical memory must be zeroed before it is made accessible to a VM for general use by a Guest OS.
- The purpose of this requirement is to ensure that a VM does not receive memory containing data previously used by another VM or the host.
+ The purpose of this requirement is to ensure that a VM does not receive memory containing data previously used by another VM or the host.
- “For general use” means for use by the Guest OS in its page tables for running applications or system software.
+ “For general use” means for use by the Guest OS in its page tables for running applications or system software.
- This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such as read-only OS pages or pages used for virtual device buffers.
+ This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such as read-only OS pages or pages used for virtual device buffers.
@@ -1674,7 +1667,7 @@ FDP_RIP_EXT.1 Residual Information in Memory
TSS
- The evaluator shall ensure that the TSS documents the process used for clearing physical memory prior to allocation to a Guest VM, providing details on when and how this is performed. Additionally, the evaluator shall ensure that the TSS documents the conditions under which physical memory is not cleared prior to allocation to a Guest VM, and describes when and how the memory is cleared.
+ The evaluator shall ensure that the TSS documents the process used for clearing physical memory prior to allocation to a Guest VM, providing details on when and how this is performed. Additionally, the evaluator shall ensure that the TSS documents the conditions under which physical memory is not cleared prior to allocation to a Guest VM, and describes when and how the memory is cleared.
@@ -1686,9 +1679,9 @@ FDP_RIP_EXT.2 Residual Information on Disk
FDP_RIP_EXT.2.1
- The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM.
+ The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM.
- Application Note: The purpose of this requirement is to ensure that a VM does not receive disk storage containing data previously used by another VM or by the host.
+ Application Note: The purpose of this requirement is to ensure that a VM does not receive disk storage containing data previously used by another VM or by the host.
Clearing of disk storage only upon deallocation does not meet this requirement.
@@ -1708,14 +1701,14 @@ FDP_RIP_EXT.2 Residual Information on Disk
TSS
- The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. Any file system format and metadata information needed by the evaluator to perform the below test shall be made available to the evaluator, but need not be published in the TSS.
+ The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. Any file system format and metadata information needed by the evaluator to perform the below test shall be made available to the evaluator, but need not be published in the TSS.
Tests
-
- Test FDP_RIP_EXT.2.1:1: On the host, the evaluator creates a file that is more than half the size of a connected physical storage device (or multiple files whose individual sizes add up to more than half the size of the storage media). This file (or files) shall be filled entirely with a non-zero value. Then, the file (or files) shall be released (freed for use but not cleared). Next, the evaluator (as a VS Administrator) creates a virtual disk at least that large on the same physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, scan through and check that all the non-metadata (as documented in the TSS) in the file corresponding to that virtual disk is set to zero.
+ Test FDP_RIP_EXT.2.1:1: On the host, the evaluator creates a file that is more than half the size of a connected physical storage device (or multiple files whose individual sizes add up to more than half the size of the storage media). This file (or files) shall be filled entirely with a non-zero value. Then, the file (or files) shall be released (freed for use but not cleared). Next, the evaluator (as a VS Administrator) creates a virtual disk at least that large on the same physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, scan through and check that all the non-metadata (as documented in the TSS) in the file corresponding to that virtual disk is set to zero.
@@ -1730,7 +1723,7 @@ FDP_VMS_EXT.1 VM Separation
FDP_VMS_EXT.1.1
- The VS shall provide the following mechanisms for transferring data between Guest VMs:[selection: no mechanism, virtual networking, other inter-VM data sharing mechanisms ].
+ The VS shall provide the following mechanisms for transferring data between Guest VMs:[selection: no mechanism, virtual networking, [assignment: other inter-VM data sharing mechanisms ]].
@@ -1754,11 +1747,11 @@ FDP_VMS_EXT.1 VM Separation
FDP_VMS_EXT.1.4
- The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1.
+ The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1.
- Application Note: The fundamental requirement of a Virtualization System is the ability to enforce separation between information domains implemented as Virtual Machines and Virtual Networks. The intent of this requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with this fundamental requirement in mind.
+ Application Note: The fundamental requirement of a Virtualization System is the ability to enforce separation between information domains implemented as Virtual Machines and Virtual Networks. The intent of this requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with this fundamental requirement in mind.
- The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” and identify all other mechanisms through which data can be transferred between Guest VMs.
+ The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” and identify all other mechanisms through which data can be transferred between Guest VMs.
Examples of non-network inter-VM sharing mechanisms are:
@@ -1769,9 +1762,9 @@ FDP_VMS_EXT.1 VM Separation
For data transfer mechanisms implemented in terms of Hypercall functions, FDP_VMS_EXT.1.3 is met if FPT_HCL_EXT.1.1 is met for those Hypercall functions (Hypercall function parameters are checked).
- For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable).
+ For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable).
- For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 is met (VM access to virtual networks is configurable).
+ For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 is met (VM access to virtual networks is configurable).
@@ -1811,9 +1804,7 @@ FDP_VMS_EXT.1 VM Separation
Test that communications can be passed between the VMs through the channel.
Create two new VMs, the first with the inter-VM communications channel currently being tested enabled, and the second with the inter-VM communications channel currently being tested disabled.
Test that communications cannot be passed between the VMs through the channel.
-
- As an Administrator, enable inter-VM communications between the VMs on the second VM.
-
+ As an Administrator, enable inter-VM communications between the VMs on the second VM.
Test that communications can be passed through the inter-VM channel.
As an Administrator again, disable inter-VM communications between the two VMs.
Test that communications can no longer be passed through the channel.
@@ -1842,9 +1833,9 @@ FDP_VNC_EXT.1 Virtual Networking Components
FDP_VNC_EXT.1.2
- The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment.
+ The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment.
- Application Note: Virtual networks must be separated from one another to provide isolation commensurate with that provided by physically separate networks. It must not be possible for data to cross between properly configured virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host.
+ Application Note: Virtual networks must be separated from one another to provide isolation commensurate with that provided by physically separate networks. It must not be possible for data to cross between properly configured virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host.
Unprivileged users must not be able to connect VMs to each other or to external networks.
@@ -1873,10 +1864,10 @@ FDP_VNC_EXT.1 Virtual Networking Components
-
- Test FDP_VNC_EXT.1.2:1: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a network component. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and attempt the same connection. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
+ Test FDP_VNC_EXT.1.2:1: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a network component. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and attempt the same connection. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
-
- Test FDP_VNC_EXT.1.2:2: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a physical network. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and make the same attempt. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
+ Test FDP_VNC_EXT.1.2:2: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a physical network. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and make the same attempt. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
@@ -1892,7 +1883,7 @@ FIA_AFL_EXT.1 Authentication Failure Handling
FIA_AFL_EXT.1.1
- The TSF shall detect when[selection: a positive integer number , an administrator configurable positive integer within a [assignment: range of acceptable values ]]unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using[selection: username and password, username and PIN].
+ The TSF shall detect when[selection: [assignment: a positive integer number ], an administrator configurable positive integer within a [assignment: range of acceptable values ]]unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using[selection: username and password, username and PIN].
@@ -1900,7 +1891,7 @@ FIA_AFL_EXT.1 Authentication Failure Handling
FIA_AFL_EXT.1.2
- When the defined number of unsuccessful authentication attempts has been met, the TSF shall:[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until [assignment: action to unlock ] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed]
+ When the defined number of unsuccessful authentication attempts has been met, the TSF shall:[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until [assignment: action to unlock ] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed]
Application Note: The action to be taken shall be populated in the selection of the ST and defined in the Administrator guidance.
@@ -1953,7 +1944,7 @@ FIA_PMG_EXT.1 Password Management
The TSF shall provide the following password management capabilities for administrative passwords:
-
- Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “& ”, “*”, “(“, “)”, other characters ]
+ Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “& ”, “*”, “(“, “)”, [assignment: other characters ]]
- Minimum password length shall be configurable
- Passwords of at least 15 characters in length shall be supported
@@ -2001,16 +1992,16 @@ FIA_UAU.5 Multiple Authentication Mechanisms
The TSF shall provide the following authentication mechanisms:[selection:
-
- [selection: local, directory-based] authentication based on username and password
+ [selection: local, directory-based] authentication based on username and password
-
authentication based on username and a PIN that releases an asymmetric key stored in OE-protected storage
-
- [selection: local, directory-based] authentication based on X.509 certificates
+ [selection: local, directory-based] authentication based on X.509 certificates
-
- [selection: local, directory-based] authentication based on an SSH public key credential
+ [selection: local, directory-based] authentication based on an SSH public key credential
]to support Administrator authentication.
@@ -2044,42 +2035,42 @@ FIA_UAU.5 Multiple Authentication Mechanisms
- If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a known username and password and conduct the following tests:
+ If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a known username and password and conduct the following tests:
-
- Test FIA_UAU.5.2:1: The evaluator will attempt to authenticate to the VS using the known username and password. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:1: The evaluator will attempt to authenticate to the VS using the known username and password. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:2: The evaluator will attempt to authenticate to the VS using the known username but an incorrect password. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:2: The evaluator will attempt to authenticate to the VS using the known username but an incorrect password. The evaluator will ensure that the authentication attempt is unsuccessful.
- If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for guidance on supported protected storage and will then configure the TOE or OE to establish a PIN which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware token, or isolated execution environment) with which the VS can interface. The evaluator will then conduct the following tests:
+ If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for guidance on supported protected storage and will then configure the TOE or OE to establish a PIN which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware token, or isolated execution environment) with which the VS can interface. The evaluator will then conduct the following tests:
-
- Test FIA_UAU.5.2:3: The evaluator will attempt to authenticate to the VS using the known user name and PIN. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:3: The evaluator will attempt to authenticate to the VS using the known user name and PIN. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:4: The evaluator will attempt to authenticate to the VS using the known user name but an incorrect PIN. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:4: The evaluator will attempt to authenticate to the VS using the known user name but an incorrect PIN. The evaluator will ensure that the authentication attempt is unsuccessful.
- If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the following tests:
+ If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the following tests:
-
- Test FIA_UAU.5.2:5: The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:5: The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:6: The evaluator will generate a second certificate identical to the first except for the public key and any values derived from the public key. The evaluator will attempt to authenticate to the VS with this certificate. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:6: The evaluator will generate a second certificate identical to the first except for the public key and any values derived from the public key. The evaluator will attempt to authenticate to the VS with this certificate. The evaluator will ensure that the authentication attempt is unsuccessful.
- If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote client. The evaluator shall provision the VS with the client public key for authentication over SSH, and conduct the following tests:
+ If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote client. The evaluator shall provision the VS with the client public key for authentication over SSH, and conduct the following tests:
-
- Test FIA_UAU.5.2:7: The evaluator will attempt to authenticate to the VS using a message signed by the client private key that corresponds to provisioned client public key. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:7: The evaluator will attempt to authenticate to the VS using a message signed by the client private key that corresponds to provisioned client public key. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:8: The evaluator will generate a second client key pair and will attempt to authenticate to the VS with the private key over SSH without first provisioning the VS to support the new key pair. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:8: The evaluator will generate a second client key pair and will attempt to authenticate to the VS with the private key over SSH without first provisioning the VS to support the new key pair. The evaluator will ensure that the authentication attempt is unsuccessful.
@@ -2128,7 +2119,7 @@ FMT_SMO_EXT.1 Separation of Management and Operational Networks
The TSF shall support the separation of management and operational network traffic through[selection: separate physical networks, separate logical networks, trusted channels as defined in FTP_ITC_EXT.1, data encryption using an algorithm specified in FCS_COP.1/UDE].
- Application Note: Management communications must be separate from user workload communications. Administrative network traffic—including communications between physical hosts concerning load balancing, audit data, VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, management traffic also includes VMs transmitted over management networks whether for backup, live migration, or deployment.
+ Application Note: Management communications must be separate from user workload communications. Administrative network traffic—including communications between physical hosts concerning load balancing, audit data, VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, management traffic also includes VMs transmitted over management networks whether for backup, live migration, or deployment.
“Separate physical networks” refers to using separate physical interfaces and cables to isolate management and operational networks from each other.
@@ -2157,16 +2148,14 @@ FMT_SMO_EXT.1 Separation of Management and Operational Networks
The evaluator shall examine the TSS to verify that it describes how management and operational traffic is separated.
Guidance
-
- The evaluator shall examine the operational guidance to verify that it details how to configure the VS to keep Management and Operational traffic separate.
-
+ The evaluator shall examine the operational guidance to verify that it details how to configure the VS to keep Management and Operational traffic separate.
Tests
The evaluator shall configure the TOE as documented in the guidance. If separation is logical, then the evaluator shall capture packets on the management network. If plaintext Guest network traffic is detected, the requirement is not met.
If separation uses trusted channels, then the evaluator shall capture packets on the network over which traffic is tunneled. If plaintext Guest network traffic is detected, the requirement is not met.
- If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the requirement is not met.
+ If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the requirement is not met.
@@ -2180,13 +2169,13 @@ FPT_DVD_EXT.1 Non-Existence of Disconnected Virtual Devices
FPT_DVD_EXT.1.1
- The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration.
+ The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration.
- Application Note: The virtualized hardware abstraction implemented by a particular VS might include the virtualized interfaces for many different devices. Sometimes these devices are not present in a particular instantiation of a VM. The interface for devices not present must not be accessible by the VM.
+ Application Note: The virtualized hardware abstraction implemented by a particular VS might include the virtualized interfaces for many different devices. Sometimes these devices are not present in a particular instantiation of a VM. The interface for devices not present must not be accessible by the VM.
Such interfaces include memory buffers, PCI Bus interfaces, and processor I/O ports.
- The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces.
+ The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces.
@@ -2200,7 +2189,7 @@ FPT_DVD_EXT.1 Non-Existence of Disconnected Virtual Devices
Tests
- The evaluator shall connect a device to a VM, then from within the guest scan the VM's devices to ensure that the connected device is present--using a device driver or other available means to scan the VM's I/O ports or PCI Bus interfaces. (The device's interface should be documented in the TSS under FPT_VDP_EXT.1.) The evaluator shall remove the device from the VM and run the scan again. This requirement is met if the device's interfaces are no longer present.
+ The evaluator shall connect a device to a VM, then from within the guest scan the VM's devices to ensure that the connected device is present--using a device driver or other available means to scan the VM's I/O ports or PCI Bus interfaces. (The device's interface should be documented in the TSS under FPT_VDP_EXT.1.) The evaluator shall remove the device from the VM and run the scan again. This requirement is met if the device's interfaces are no longer present.
@@ -2212,7 +2201,7 @@ FPT_EEM_EXT.1 Execution Environment Mitigations
FPT_EEM_EXT.1.1
- The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:[selection: Address space randomization, Memory execution protection (e.g., DEP), Stack buffer overflow protection, Heap corruption detection, other mechanisms , No mechanisms]
+ The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:[selection: Address space randomization, Memory execution protection (e.g., DEP), Stack buffer overflow protection, Heap corruption detection, [assignment: other mechanisms ], No mechanisms]
Application Note: Processor manufacturers, compiler developers, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Software can often take advantage of these mechanisms by using APIs provided by the operating system or by enabling the mechanism through compiler or linker options.
@@ -2246,7 +2235,7 @@ FPT_HAS_EXT.1 Hardware Assists
FPT_HAS_EXT.1.1
- The VMM shall use[assignment: list of hardware-based virtualization assists]to reduce or eliminate the need for binary translation.
+ The VMM shall use[assignment: list of hardware-based virtualization assists]to reduce or eliminate the need for binary translation.
@@ -2254,13 +2243,13 @@ FPT_HAS_EXT.1 Hardware Assists
FPT_HAS_EXT.1.2
- The VMM shall use[assignment: list of hardware-based virtualization memory-handling assists]to reduce or eliminate the need for shadow page tables.
+ The VMM shall use[assignment: list of hardware-based virtualization memory-handling assists]to reduce or eliminate the need for shadow page tables.
- Application Note: These hardware-assists help reduce the size and complexity of the VMM, and thus, of the trusted computing base, by eliminating or reducing the need for paravirtualization or binary translation. Paravirtualization involves modifying guest software so that instructions that cannot be properly virtualized are never executed on the physical processor.
+ Application Note: These hardware-assists help reduce the size and complexity of the VMM, and thus, of the trusted computing base, by eliminating or reducing the need for paravirtualization or binary translation. Paravirtualization involves modifying guest software so that instructions that cannot be properly virtualized are never executed on the physical processor.
- For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all platforms included in the ST that are used by the VMM to reduce or eliminate the need for software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is an acceptable assignment for platforms that do not require virtualization assists in order to eliminate the need for binary translation. This must be documented in the TSS.
+ For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all platforms included in the ST that are used by the VMM to reduce or eliminate the need for software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is an acceptable assignment for platforms that do not require virtualization assists in order to eliminate the need for binary translation. This must be documented in the TSS.
- For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. “None” is an acceptable assignment for platforms that do not require memory-handling assists in order to eliminate the need for shadow page tables. This must be documented in the TSS.
+ For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. “None” is an acceptable assignment for platforms that do not require memory-handling assists in order to eliminate the need for shadow page tables. This must be documented in the TSS.
@@ -2288,11 +2277,11 @@ FPT_HCL_EXT.1 Hypercall Controls
FPT_HCL_EXT.1.1
- The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface.
+ The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface.
- Application Note: The purpose of this requirement is to help ensure the integrity of the VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls.
+ Application Note: The purpose of this requirement is to help ensure the integrity of the VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls.
- A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. For example, a hypercall interface could be used to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest software, these interfaces constitute attack surface.
+ A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. For example, a hypercall interface could be used to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest software, these interfaces constitute attack surface.
There is no expectation that the evaluator will need to review source code in order to accomplish the evaluation activity.
@@ -2318,7 +2307,7 @@ FPT_HCL_EXT.1 Hypercall Controls
The evaluator shall perform the following test:
- For each hypercall interface documented in the TSS or proprietary TSS Annex, the evaluator shall attempt to invoke the function from within the VM using an invalid parameter (if any). If the VMM or VS crashes or generates an exception, or if no error is returned to the guest, then the test fails. If an error is returned to the guest, then the test succeeds.
+ For each hypercall interface documented in the TSS or proprietary TSS Annex, the evaluator shall attempt to invoke the function from within the VM using an invalid parameter (if any). If the VMM or VS crashes or generates an exception, or if no error is returned to the guest, then the test fails. If an error is returned to the guest, then the test succeeds.
@@ -2348,13 +2337,9 @@ FPT_RDM_EXT.1 Removable Devices and Media
For purposes of this requirement, an Information Domain is:
- -
- A VM or collection of VMs
-
+ - A VM or collection of VMs
- The Virtualization System
- -
- Host OS
-
+ - Host OS
- Management Subsystem
These requirements also apply to virtualized removable media—such as virtual CD drives that connect to ISO images—as well as physical media—such as CDROMs and USB flash drives. In the case of virtual CDROMs, virtual ejection of the virtual media is sufficient.
@@ -2387,7 +2372,7 @@ FPT_RDM_EXT.1 Removable Devices and Media
The evaluator shall perform the following test for each listed media or device:
-
- Test FPT_RDM_EXT.1.2:1: The evaluator shall configure two VMs that are members of different information domains, with the media or device connected to one of the VMs. The evaluator shall disconnect the media or device from the VM and connect it to the other VM. The evaluator shall verify that the action performed is consistent with the action assigned in the TSS.
+ Test FPT_RDM_EXT.1.2:1: The evaluator shall configure two VMs that are members of different information domains, with the media or device connected to one of the VMs. The evaluator shall disconnect the media or device from the VM and connect it to the other VM. The evaluator shall verify that the action performed is consistent with the action assigned in the TSS.
@@ -2482,7 +2467,7 @@ FPT_VDP_EXT.1 Virtual Device Parameters
FPT_VDP_EXT.1.1
- The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction.
+ The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction.
@@ -2490,9 +2475,9 @@ FPT_VDP_EXT.1 Virtual Device Parameters
FPT_VDP_EXT.1.2
- The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces.
+ The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces.
- Application Note: The purpose of this requirement is to ensure that the VMM is not vulnerable to compromise through the processing of malformed data passed to the virtual device interface from a Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual device interface is unique to the VS and the data comes from a virtual device driver supplied by the Virtualization Vendor.
+ Application Note: The purpose of this requirement is to ensure that the VMM is not vulnerable to compromise through the processing of malformed data passed to the virtual device interface from a Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual device interface is unique to the VS and the data comes from a virtual device driver supplied by the Virtualization Vendor.
@@ -2510,7 +2495,7 @@ FPT_VDP_EXT.1 Virtual Device Parameters
TSS
- The evaluator shall examine the TSS to ensure it lists all virtual devices accessible by the guest OS. The TSS, or a separate proprietary document, must also document all virtual device interfaces at the level of I/O ports or PCI Bus interfaces - including port numbers (absolute or relative to a base), port name, address range, and a description of legal input values.
+ The evaluator shall examine the TSS to ensure it lists all virtual devices accessible by the guest OS. The TSS, or a separate proprietary document, must also document all virtual device interfaces at the level of I/O ports or PCI Bus interfaces - including port numbers (absolute or relative to a base), port name, address range, and a description of legal input values.
The TSS must also describe the expected behavior of the interface when presented with illegal input values. This behavior must be deterministic and indicative of parameter checking by the TSF.
@@ -2532,7 +2517,7 @@ FPT_VIV_EXT.1 VMM Isolation from VMs
FPT_VIV_EXT.1.1
- The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform.
+ The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform.
@@ -2540,24 +2525,22 @@ FPT_VIV_EXT.1 VMM Isolation from VMs
FPT_VIV_EXT.1.2
- The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM.
+ The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM.
- Application Note: This requirement is intended to ensure that software running within a Guest VM cannot compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM software—whatever its privilege level—can crash the VS or the Platform, or breakout of its virtual hardware abstraction to gain execution on the platform, within or outside of the context of the VMM.
+ Application Note: This requirement is intended to ensure that software running within a Guest VM cannot compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM software—whatever its privilege level—can crash the VS or the Platform, or breakout of its virtual hardware abstraction to gain execution on the platform, within or outside of the context of the VMM.
- This requirement is not violated if software running within a VM can crash the Guest OS and there is no way for an attacker to gain execution in the VMM or outside of the virtualized domain.
+ This requirement is not violated if software running within a VM can crash the Guest OS and there is no way for an attacker to gain execution in the VMM or outside of the virtualized domain.
- FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and invoke privileged code on the Platform.
+ FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and invoke privileged code on the Platform.
At a minimum, the TSF should enforce the following:
- On the x86 platform, a virtual System Management Interrupt (SMI) cannot invoke platform System Management Mode (SMM).
- An attempt to update virtual firmware or virtual BIOS cannot cause physical platform firmware or physical platform BIOS to be modified.
- -
- An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified.
-
+ - An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified.
- Of the above, the first bullet does not apply to platforms that do not support SMM. The rationale behind the third bullet is that a firmware update of a single VM must not affect other VMs. So if multiple VMs share the same firmware image as part of a common hardware abstraction, then the update of a single machine’s BIOS must not be allowed to change the common abstraction. The virtual hardware abstraction is part of the VMM.
+ Of the above, the first bullet does not apply to platforms that do not support SMM. The rationale behind the third bullet is that a firmware update of a single VM must not affect other VMs. So if multiple VMs share the same firmware image as part of a common hardware abstraction, then the update of a single machine’s BIOS must not be allowed to change the common abstraction. The virtual hardware abstraction is part of the VMM.
@@ -2575,7 +2558,7 @@ FPT_VIV_EXT.1 VMM Isolation from VMs
TSS
- The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note.
+ The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note.
@@ -2625,7 +2608,7 @@ FTP_ITC_EXT.1 Trusted Channel Communications
audit servers (as required by FAU_STG_EXT.1), and
- [selection: remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module), separation of management and operational networks (if selected in FMT_SMO_EXT.1), other capabilities , no other capabilities]that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data.
+ [selection: remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module), separation of management and operational networks (if selected in FMT_SMO_EXT.1), [assignment: other capabilities ], no other capabilities]that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data.
Application Note: If the ST author selects either TLS or HTTPS, the TSF shall be validated against the Functional Package for TLS. This PP does not mandate that a product implement TLS with mutual authentication, but if the product includes the capability to perform TLS with mutual authentication, then mutual authentication must be included within the TOE boundary. The TLS Package requires that the X509 requirements be included by the PP, so selection of TLS or HTTPS causes FIA_X509_EXT.* to be selected.
@@ -2656,7 +2639,7 @@ FTP_ITC_EXT.1 Trusted Channel Communications
Tests
- The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.
+ The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.
@@ -2741,11 +2724,11 @@ FTP_UIF_EXT.1 User Interface: I/O Focus
FTP_UIF_EXT.1.1
- The TSF shall indicate to users which VM, if any, has the current input focus.
+ The TSF shall indicate to users which VM, if any, has the current input focus.
- Application Note: This requirement applies to all users—whether User or Administrator. In environments where multiple VMs run at the same time, the user must have a way of knowing which VM user input is directed to at any given moment. This is especially important in multiple-domain environments.
+ Application Note: This requirement applies to all users—whether User or Administrator. In environments where multiple VMs run at the same time, the user must have a way of knowing which VM user input is directed to at any given moment. This is especially important in multiple-domain environments.
- In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is considered to be a program, but this program still needs to know which VM it is sending input to; this would typically be accomplished through programmatic means.
+ In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is considered to be a program, but this program still needs to know which VM it is sending input to; this would typically be accomplished through programmatic means.
@@ -2767,7 +2750,7 @@ FTP_UIF_EXT.1 User Interface: I/O Focus
The evaluator shall ensure that the operational guidance specifies how the current input focus is indicated to the user.
Tests
- For each supported input device, the evaluator shall demonstrate that the input from each device listed in the TSS is directed to the VM that is indicated to have the input focus.
+ For each supported input device, the evaluator shall demonstrate that the input from each device listed in the TSS is directed to the VM that is indicated to have the input focus.
@@ -2779,11 +2762,11 @@ FTP_UIF_EXT.2 User Interface: Identification of VM
FTP_UIF_EXT.2.1
- The TSF shall support the unique identification of a VM’s output display to users.
+ The TSF shall support the unique identification of a VM’s output display to users.
- Application Note: In environments where a user has access to more than one VM at the same time, the user must be able to determine the identity of each VM displayed in order to avoid inadvertent cross-domain data entry.
+ Application Note: In environments where a user has access to more than one VM at the same time, the user must be able to determine the identity of each VM displayed in order to avoid inadvertent cross-domain data entry.
- There must be a mechanism for associating an identifier with a VM so that an application or program displaying the VM can identify the VM to users. This is generally indicated visually for human users (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API function). The identification must be unique to the VS, but does not need to be universally unique.
+ There must be a mechanism for associating an identifier with a VM so that an application or program displaying the VM can identify the VM to users. This is generally indicated visually for human users (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API function). The identification must be unique to the VS, but does not need to be universally unique.
@@ -2805,7 +2788,7 @@ FTP_UIF_EXT.2 User Interface: Identification of VM
The evaluator shall perform the following test:
- The evaluator shall attempt to create and start at least three Guest VMs on a single display device where the evaluator attempts to assign two of the VMs the same identifier. If the user interface displays different identifiers for each VM, then the requirement is met. Likewise, the requirement is met if the system refuses to create or start a VM when there is already a VM with the same identifier.
+ The evaluator shall attempt to create and start at least three Guest VMs on a single display device where the evaluator attempts to assign two of the VMs the same identifier. If the user interface displays different identifiers for each VM, then the requirement is met. Likewise, the requirement is met if the system refuses to create or start a VM when there is already a VM with the same identifier.
@@ -2873,7 +2856,7 @@ 5.1.9 TOE Security Functio
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_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.
@@ -2966,7 +2949,7 @@ 5.1.9 TOE Security Functio
FPT_HCL_EXT.1 Requires that Hypercall parameters be validated.
- FPT_ML_EXT.1 Requires measured launch of the platform and VMM (objective).
+ 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.
@@ -3018,7 +3001,7 @@ 5.1.9 TOE Security Functio
FPT_HCL_EXT.1 Requires that Hypercall parameters be validated.
- FPT_ML_EXT.1 Requires measured launch of the platform and VMM (objective).
+ 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.
@@ -3074,12 +3057,10 @@ 5.1.9 TOE Security Functio
- 5.2 Security Assurance Requirements
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
-
- This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section.
-
- After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+ 5.2 Security Assurance Requirements
+
+ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+
5.2.1 Class ASE: Security Target Evaluation
As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.
5.2.2 Class ADV: Development
@@ -3100,7 +3081,7 @@ Developer action elements:
The developer shall provide a tracing from the functional specification to the SFRs.
- Developer Note: As indicated in the introduction to this section, the functional specification is composed of the information contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
+ Note: As indicated in the introduction to this section, the functional specification is composed of the information contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
@@ -3151,7 +3132,17 @@ Evaluator action elements:
The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.
- Application Note: There are no specific evaluation activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 5.2, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.
+ Note: There are no specific evaluation activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 5.2, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.
+
+
+
+
@@ -3179,7 +3170,7 @@ Developer action elements:
The developer shall provide operational user guidance.
- Developer Note: Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluators will be checking for. This will provide the necessary information for the preparation of acceptable guidance.
+ Note: Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluators will be checking for. This will provide the necessary information for the preparation of acceptable guidance.
@@ -3189,7 +3180,7 @@ Content and presentation elements:
AGD_OPE.1.1C
- The operational user guidance shall describe what for each user role the authorized user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
+ The operational user guidance shall describe what for each user role the authorized user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
@@ -3197,7 +3188,7 @@ Content and presentation elements:
AGD_OPE.1.2C
- The operational user guidance shall describe, for each user role the authorized user, how to use the available interfaces provided by the TOE in a secure manner.
+ The operational user guidance shall describe, for each user role the authorized user, how to use the available interfaces provided by the TOE in a secure manner.
@@ -3205,7 +3196,7 @@ Content and presentation elements:
AGD_OPE.1.3C
- The operational user guidance shall describe, for each user role the authorized user, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
+ The operational user guidance shall describe, for each user role the authorized user, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
@@ -3213,7 +3204,7 @@ Content and presentation elements:
AGD_OPE.1.4C
- The operational user guidance shall, for each user role the authorized user, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
+ The operational user guidance shall, for each user role the authorized user, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
@@ -3229,7 +3220,7 @@ Content and presentation elements:
AGD_OPE.1.6C
- The operational user guidance shall, for each user role the authorized user, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.
+ The operational user guidance shall, for each user role the authorized user, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.
@@ -3257,7 +3248,7 @@ Evaluator action elements:
The operational guidance shall contain instructions for configuring the password characteristics, number of allowed authentication attempt failures, the lockout period times for inactivity, and the notice and consent warning that is to be provided when authenticating.
- The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile.
+ The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile.
The documentation shall describe the process for verifying updates to the TOE, either by checking the hash or by verifying a digital signature. The evaluator shall verify that this process includes the following steps:
@@ -3283,7 +3274,7 @@ Developer action elements:
The developer shall provide the TOE including its preparative procedures.
- Developer Note: As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.
+ Note: As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.
@@ -3329,7 +3320,7 @@ Evaluator action elements:
As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST.
- The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile.
+ The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile.
@@ -3426,7 +3417,7 @@ Evaluator action elements:
ALC_TSU_EXT.1 Timely Security Updates
- This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public.
+ This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public.
Developer action elements:
@@ -3452,7 +3443,7 @@ Content and presentation elements:
The description shall express the time window as the length of time, in days, between public disclosure of a vulnerability and the public availability of security updates to the TOE.
- Application Note: The total length of time may be presented as a summation of the periods of time that each party (e.g., TOE developer, hardware vendor) on the critical path consumes. The time period until public availability per deployment mechanism may differ; each is described.
+ Note: The total length of time may be presented as a summation of the periods of time that each party (e.g., TOE developer, hardware vendor) on the critical path consumes. The time period until public availability per deployment mechanism may differ; each is described.
@@ -3463,7 +3454,7 @@ Content and presentation elements:
The description shall include the mechanisms publicly available for reporting security issues pertaining to the TOE.
- Application Note: The reporting mechanism could include websites, email addresses, and a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).
+ Note: The reporting mechanism could include websites, email addresses, and a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).
@@ -3474,6 +3465,16 @@ Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
5.2.5 Class ATE: Tests
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements.
@@ -3610,7 +3611,7 @@ FAU_ARP.1 Security Audit Automatic Response
The TSF shall take[assignment: list of actions]upon detection of a potential security violation.
- Application Note: In certain cases, it may be useful for Virtualization Systems to perform automated responses to certain security events. An example may include halting a VM which has taken some action to violate a key system security policy. This may be especially useful with headless endpoints when there is no human user in the loop.
+ Application Note: In certain cases, it may be useful for Virtualization Systems to perform automated responses to certain security events. An example may include halting a VM which has taken some action to violate a key system security policy. This may be especially useful with headless endpoints when there is no human user in the loop.
The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
@@ -3683,9 +3684,9 @@ FPT_GVI_EXT.1 Guest VM Integrity
FPT_GVI_EXT.1.1
- The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment: list of Guest VM integrity mechanisms].
+ The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment: list of Guest VM integrity mechanisms].
- Application Note: The primary purpose of this requirement is to identify and describe the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion, though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. Importation for this requirement could include VM migration (live or otherwise), the importation of virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a trusted VM could have been modified during the migration or import/export process, or VMs could have been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a prudent measure to take. These integrity checks could be as thorough as making sure the entire VM exactly matches a previously known VM (by hash for example), or by simply checking certain configuration settings to ensure that the VM's configuration will not violate the security model of the VS.
+ Application Note: The primary purpose of this requirement is to identify and describe the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion, though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. Importation for this requirement could include VM migration (live or otherwise), the importation of virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a trusted VM could have been modified during the migration or import/export process, or VMs could have been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a prudent measure to take. These integrity checks could be as thorough as making sure the entire VM exactly matches a previously known VM (by hash for example), or by simply checking certain configuration settings to ensure that the VM's configuration will not violate the security model of the VS.
@@ -3701,7 +3702,7 @@ FPT_GVI_EXT.1 Guest VM Integrity
TSS
- For each mechanism listed in the assignment, the evaluator shall ensure that the TSS documents the mechanism, including how it verifies VM integrity, which set of Guest VMs it will check (all Guest VMs, only migrated VM s, etc.), when such checks occur (before VM startup, immediately following importation/migration, on demand, etc.), and which actions are taken if a VM fails the integrity check (or which range of actions are possible if the action is configurable).
+ For each mechanism listed in the assignment, the evaluator shall ensure that the TSS documents the mechanism, including how it verifies VM integrity, which set of Guest VMs it will check (all Guest VMs, only migrated VM s, etc.), when such checks occur (before VM startup, immediately following importation/migration, on demand, etc.), and which actions are taken if a VM fails the integrity check (or which range of actions are possible if the action is configurable).
@@ -3715,9 +3716,9 @@ FPT_DDI_EXT.1 Device Driver Isolation
FPT_DDI_EXT.1.1
- The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.
+ The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.
- Application Note: In order to function on physical hardware, the VMM must have access to the device drivers for the physical platform on which it runs. These drivers are often written by third parties, and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality of third party code that the virtualization vendor has no control over. By encapsulating these drivers within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
+ Application Note: In order to function on physical hardware, the VMM must have access to the device drivers for the physical platform on which it runs. These drivers are often written by third parties, and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality of third party code that the virtualization vendor has no control over. By encapsulating these drivers within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
@@ -3794,11 +3795,11 @@ FPT_INT_EXT.1 Support for Introspection
FPT_INT_EXT.1.1
- The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.
+ The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.
- Application Note: Introspection can be used to support malware and anomaly detection from outside of the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt to break out of the VM and compromise the VMM or other VMs.
+ Application Note: Introspection can be used to support malware and anomaly detection from outside of the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt to break out of the VM and compromise the VMM or other VMs.
- The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure the integrity of the malware detection/antivirus software. This capability can be implemented in the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained and does not introduce bugs into the VMM.
+ The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure the integrity of the malware detection/antivirus software. This capability can be implemented in the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained and does not introduce bugs into the VMM.
@@ -3814,7 +3815,7 @@ FPT_INT_EXT.1 Support for Introspection
TSS
- The evaluator shall examine the TSS documentation to verify that it describes the interface for VM introspection and whether the introspection is performed by the VMM or another VM.
+ The evaluator shall examine the TSS documentation to verify that it describes the interface for VM introspection and whether the introspection is performed by the VMM or another VM.
Guidance
The evaluator shall examine the operational guidance to ensure that it contains instructions for configuration of the introspection mechanism.
@@ -3828,7 +3829,7 @@ FPT_ML_EXT.1 Measured Launch of Platform and VMM
FPT_ML_EXT.1.1
- The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:[selection: Static executable images of the Management Subsystem, list of (static images of) Service VMs , list of configuration files , no other components]
+ The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:[selection: Static executable images of the Management Subsystem, [assignment: list of (static images of) Service VMs ], [assignment: list of configuration files ], no other components]
@@ -3838,9 +3839,9 @@ FPT_ML_EXT.1 Measured Launch of Platform and VMM
The TSF shall make the measurements selected in FPT_ML_EXT.1.1 available to the Management Subsystem.
- Application Note: A measured launch of the platform and VS demonstrates that the proper TOE software was loaded. A measured launch process employs verifiable integrity measurement mechanisms. For example, a VS may hash components such as the hypervisor, service VMs, or the Management Subsystem. A measured launch process only allows components to be executed after the measurement has been recorded. An example process may add each component’s hash before it is executed so that the final hash reflects the evidence of a component’s state prior to execution. The measurement may be verified as the system boots, but this is not required.
+ Application Note: A measured launch of the platform and VS demonstrates that the proper TOE software was loaded. A measured launch process employs verifiable integrity measurement mechanisms. For example, a VS may hash components such as the hypervisor, service VMs, or the Management Subsystem. A measured launch process only allows components to be executed after the measurement has been recorded. An example process may add each component’s hash before it is executed so that the final hash reflects the evidence of a component’s state prior to execution. The measurement may be verified as the system boots, but this is not required.
- The Platform is outside of the TOE. However, this requirement specifies that the VS must be capable of receiving Platform measurements if the Platform provides them. This requirement is requiring TOE support for Platform measurements if provided; it is not placing a requirement on the Platform to take such measurements.
+ The Platform is outside of the TOE. However, this requirement specifies that the VS must be capable of receiving Platform measurements if the Platform provides them. This requirement is requiring TOE support for Platform measurements if provided; it is not placing a requirement on the Platform to take such measurements.
If available, hardware should be used to store measurements in such a manner that they cannot be modified in any manner except to be extended. These measurements should be produced in a repeatable manner so that a third party can verify the measurements if given the inputs. Hardware devices, like Trusted Platform Modules (TPM), TrustZone, and MMU are some examples that may serve as foundations for storing and reporting measurements.
@@ -3867,7 +3868,7 @@ FPT_ML_EXT.1 Measured Launch of Platform and VMM
-
- Test FPT_ML_EXT.1.2:1: The evaluator shall start the VS, login as an Administrator, and verify that the measurements for the specified components are viewable in the Management Subsystem.
+ Test FPT_ML_EXT.1.2:1: The evaluator shall start the VS, login as an Administrator, and verify that the measurements for the specified components are viewable in the Management Subsystem.
@@ -3996,10 +3997,10 @@ FCS_IPSEC_EXT.1 IPsec Protocol
[selection:
-
- IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
+ IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
-
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
+ IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]
@@ -4024,13 +4025,13 @@ FCS_IPSEC_EXT.1 IPsec Protocol
The TSF shall ensure that[selection:
-
- IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
+ IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
-
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
+ IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
-
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
+ IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]
@@ -4090,7 +4091,7 @@ FCS_IPSEC_EXT.1 IPsec Protocol
FCS_IPSEC_EXT.1.12
- The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, other supported reference identifier types ]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.
+ The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, [assignment: other supported reference identifier types ]]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.
Application Note: The TOE must support at least one of the following identifier types: IP address, Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN). In the future, the TOE will be required to support all of these identifier types. The TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP versions supported by the TOE in general. The ST author may assign additional supported identifier types in the second selection.
@@ -4149,7 +4150,7 @@ FCS_IPSEC_EXT.1 IPsec Protocol
If the configuration of the IPsec behavior is from an environmental source, most notably a VPN gateway (e.g through receipt of required connection parameters from a VPN gateway), the evaluator shall ensure that the operational guidance contains any appropriate information for ensuring that this configuration can be properly applied.
- Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec functionality implemented totally or in part by the underlying OS platform. The behavior referenced here is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD from the client (e.g., enforcement of packet routing decisions).
+ Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec functionality implemented totally or in part by the underlying OS platform. The behavior referenced here is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD from the client (e.g., enforcement of packet routing decisions).
Tests
@@ -4604,7 +4605,7 @@ FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1
- The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, other uses ]
+ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, [assignment: other uses ]]
Application Note: This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital signature mechanism,” if "certificate-based authentication of the remote peer" is selected in FTP_ITC_EXT.1, or if "authentication based on X.509 certificates" is selected in FIA_UAU.5.1.
@@ -4837,7 +4838,7 @@ E.4 Specific Guidance f
E.5 Specific Guidance for Determining Platform Equivalence
- Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.
+ Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.
E.5.1 Hardware Platform Equivalence
@@ -4847,13 +4848,13 @@ E.5.1 Hardware Platf
Platforms with different processor architectures and instruction sets are not equivalent. This is probably not an issue because there is likely to be a different product model for different hardware environments.
- Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application.
+ Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified security functionality.
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
@@ -4909,19 +4910,19 @@ E.6 Level of Specificity
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
- Bare-Metal VS
+ Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the claimed equivalent configuration.
- VS with OS Support
+ VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
Appendix F - Acronyms
@@ -4951,12 +4952,6 @@ Appendix F - Acronyms
OE Operational Environment
-
- OS Guest Operating System
-
-
- OS Host Operating System
-
PP Protection Profile
@@ -4972,9 +4967,6 @@ Appendix F - Acronyms
SFR Security Functional Requirement
-
- SSP System Security Policy
-
ST Security Target
@@ -4990,15 +4982,6 @@ Appendix F - Acronyms
TSS TOE Summary Specification
-
- VM Virtual Machine
-
-
- VMM Virtual Machine Manager
-
-
- VS Virtualization System
-
Appendix G - Bibliography
TDs Applied
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
A.1.1Class: Security Audit (FAU)A.1.2Class: Protection of the TSF (FPT)A.2Objective Requirements
A.2.1Class: Protection of the TSF (FPT)A.3Implementation-dependent Requirements
Appendix B - Selection-based Requirements
@@ -678,7 +678,7 @@ 1.2.1 Common Criteria Terms
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.2.1 Common Criteria Terms
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.
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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
+ - 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.
- 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
- Package Claims
3 Security Problem Definition
-
3.1 Threats
- - 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
- - 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -759,17 +758,17 @@ 3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
-
Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+ Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
will be configured in a correct and secure manner. OE.NON_MALICIOUS_USER If the organization properly vets and trains users, it is expected that they will be non-malicious. A.PHYSICAL OE.PHYSICAL If the TOE is deployed in a location that has appropriate physical safeguards, it can be assumed
to be physically secure. A.PLATFORM_INTEGRITY OE.PHYSICAL If the underlying platform has not been compromised prior to installation of the TOE, its integrity
can be assumed to be intact. A.TRUSTED_ADMIN OE.TRUSTED_ADMIN Providing guidance to administrators and ensuring that individuals are properly trained and
@@ -823,17 +822,17 @@ 5.1.1 Class: Security Audit (FAU)<
The ST author can include other auditable events directly in Table t-audit-mandatory; they are not
limited to the list presented. The ST author should update the table in
FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a
- user id or an identifier specifying a VM, for example.
+ user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and
Table t-audit-sel-based should be included in the ST if the
associated SFRs and selections are included.
The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach
VMs to virtualized network components. Changes to these configurations can be made
- during VM execution or when VMs are not running. Audit records
+ during VM execution or when VMs are not running. Audit records
must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
- to a physical device (when the device becomes part of the VM's hardware view), not
- to log every time that the device is accessed. Generally, this is only once at VM
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
+ to a physical device (when the device becomes part of the VM's hardware view), not
+ to log every time that the device is accessed. Generally, this is only once at VM
startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB
devices such as CD-ROMs). All such connection/disconnection events must be logged.
@@ -924,8 +923,9 @@ 5.1.1 Class: Security Audit (FAU)<
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel as specified in FTP_ITC_EXT.1.
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
- rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full.Application
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
+ rule for overwriting previous audit records ], [assignment:
+ other action ]]when the local storage space for audit data is full.Application
Note:
An external log server, if available, might be used as alternative storage space
in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the
@@ -984,7 +984,7 @@ 5.1.2 Class: Cryptographic Support
FCS_CKM.1 Cryptographic Key Generation
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[selection: -
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
-
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
+
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
- FFC Schemes using Diffie-Hellman group 14 that meet the following: [RFC 3526]
- FFC Schemes using safe primes that meet the following: [‘NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes"]
]and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
@@ -1342,7 +1342,7 @@ 5.1.2 Class: Cryptographic Support
FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
The TSF shall perform [ cryptographic signature services (generation and verification) ] in accordance with a specified cryptographic algorithm[selection: - RSA schemes using cryptographic key sizes [2048-bit or greater] that meet
- the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
].Application
+ the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5] ].Application
Note:
The ST Author should choose the algorithm implemented to perform digital signatures;
if more than one algorithm is available, this requirement should be iterated to specify the
@@ -1533,36 +1533,36 @@ 5.1.2 Class: Cryptographic Support
The TSF shall provide independent entropy across multiple VMs.Application
Note:
- This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
- need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
- must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
- provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
+ This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
+ need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
+ must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
+ provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
- Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
+ Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
3) pass-through access to a hardware entropy source (including a source of random numbers). In all
- cases, it is possible that the guest is made VM-aware through installation of software or drivers.
- For the second and third cases, it is possible that the guest could be VM-unaware. There is no
- requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
+ cases, it is possible that the guest is made VM-aware through installation of software or drivers.
+ For the second and third cases, it is possible that the guest could be VM-unaware. There is no
+ requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a
- mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
- VM-unaware guest would use.
+ mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
+ VM-unaware guest would use.
The ST author should select “Hypercall interface” if the TSF provides an API function through which
guest-resident software can obtain entropy or random numbers. The ST author should select
- “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
+ “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
which it can obtain entropy or random numbers. Such an interface could present a virtualized real
- device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
- that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
+ device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
+ that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or
random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
- of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
+ of entropy provided to another VM on the same platform.
- 5.2 Security Assurance Requirements
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The
- Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP
- identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the
- documentation applicable for the evaluation and performs independent testing.
- This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information
- Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual
- evaluation activities to be performed are specified in both Section 5.1 as well as in this section.
- After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain
- the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform
- actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained
- within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply
- to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also
- provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
-
- 5.2.1 Class ASE: Security Target Evaluation
+ 5.2 Security Assurance Requirements
+ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+ 5.2.1 Class ASE: Security Target Evaluation
As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.
- 5.2.2 Class ADV: Development
+
+ 5.2.2 Class ADV: Development
+
The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE
Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2
should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.
- ADV_FSP.1 Basic functional specification
Developer action elements:
The developer shall provide a functional specification.The developer shall provide a tracing from the functional specification to the SFRs.Developer
+
+ ADV_FSP.1 Basic functional specification
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide a functional specification.The developer shall provide a tracing from the functional specification to the SFRs.The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering.Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence.The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs.5.2.3 Class AGD: Guidance Documents
+
+
+ 5.2.3 Class AGD: Guidance Documents
+
The guidance documents will be provided with the developer’s security target. Guidance must include a description of
how the authorized user verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by an authorized user.
@@ -2826,22 +2837,33 @@ 5.2.2 Class ADV: DevelopmentSFRs where applicable.
- AGD_OPE.1 Operational User Guidance
Developer action elements:
The developer shall provide operational user guidance.
- Developer
+
+ AGD_OPE.1 Operational User Guidance
+
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide operational user guidance.
+
Note:
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance.Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
+ will provide the necessary information for the preparation of acceptable guidance.Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
privileges that should be controlled in a secure processing environment, including appropriate
- warnings.The operational user guidance shall describe, for each user role the authorized user, how to use the available
- interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for each user role the authorized user, the available functions and
+ warnings.The operational user guidance shall describe, for each user role the authorized user, how to use the available
+ interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for each user role the authorized user, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
- values as appropriate.The operational user guidance shall, for each user role the authorized user, clearly present each type of
+ values as appropriate.The operational user guidance shall, for each user role the authorized user, clearly present each type of
security-relevant event relative to the user-accessible functions that need to be performed,
including changing the security characteristics of entities under the control of the TSF.The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation.The operational user guidance shall, for each user role the authorized user, describe the security measures to be
+ maintaining secure operation.The operational user guidance shall, for each user role the authorized user, describe the security measures to be
followed in order to fulfill the security objectives for the operational environment as described in
the ST.The operational user guidance shall be clear and reasonable.Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.AGD_PRE.1 Preparative procedures
Developer action elements:
The developer shall provide the TOE including its preparative procedures.
- Developer
+ was successful or unsuccessful. This includes generation of the hash/digital signature.
+ AGD_PRE.1 Preparative procedures
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE including its preparative procedures.
+
Note:
As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
@@ -2880,16 +2909,24 @@ 5.2.2 Class ADV: DevelopmentTOE adequately addresses all platforms (that is, combination of hardware and
operating system) claimed for the TOE in the ST.
The operational guidance shall contain step-by-step instructions suitable for use by an end-user of
- the VS to configure a new, out-of-the-box system into the configuration evaluated
+ the VS to configure a new, out-of-the-box system into the configuration evaluated
under this Protection Profile.
- 5.2.4 Class ALC: Life-Cycle Support
+
+
+ 5.2.4 Class ALC: Life-Cycle Support
+
At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of
the TOE vendor’s development and configuration management process in order to provide a baseline level of
assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process
in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a
developer’s practices play in contributing to the overall trustworthiness of a product.
- ALC_CMC.1 Labeling of the TOE
Developer action elements:
The developer shall provide the TOE and a reference for the TOE.
+
+ ALC_CMC.1 Labeling of the TOE
+
+
+
+ Developer action elements:
Content and presentation elements:
The TOE shall be labeled with its unique reference.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
@@ -2899,7 +2936,13 @@ 5.2.2 Class ADV: DevelopmentTOE samples received for testing to ensure
that the version number is consistent with that in the ST.
If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that
- the information in the ST is sufficient to distinguish the product.ALC_CMS.1 TOE CM coverage
Developer action elements:
+ ALC_CMS.1 TOE CM coverage
+
+
+
+
+ Developer action elements:
The developer shall provide a configuration list for the TOE.
Content and presentation elements:
The configuration list shall uniquely identify the configuration items.
@@ -2915,37 +2958,50 @@ 5.2.2 Class ADV: DevelopmentTSF is uniquely identified (with respect to other products from
the TSF vendor), and that documentation provided by the developer in association with the requirements
in the ST is associated with the TSF using this unique identification.
-
ALC_TSU_EXT.1 Timely Security Updates
+
+ ALC_TSU_EXT.1 Timely Security Updates
+
This component requires the TOE developer, in conjunction with any other necessary parties, to provide information
- as to how the VS is updated to address security issues in a timely manner. The
+ as to how the VS is updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a security flaw is
reported/discovered, to the time an update is released. This description includes the parties involved
(e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including
worst case time periods, before an update is made available to the public.
- Developer action elements:
The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
The description shall include the process for creating and deploying security updates for the TOE
software/firmware.The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE.Application
+ of a vulnerability and the public availability of security updates to the TOE.
Note:
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
availability per deployment mechanism may differ; each is described.The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE.Application
+ pertaining to the TOE.
Note:
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
proof-of-concept exploit).Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence.5.2.5 Class ATE: Tests
+ presentation of evidence.
+
+ 5.2.5 Class ATE: Tests
+
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or
implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces
with dependency on the availability of design information. One of the primary outputs of the evaluation process is
the test report as specified in the following requirements.
- ATE_IND.1 Independent Testing - Conformance
+
+ ATE_IND.1 Independent Testing - Conformance
+
Testing is performed to confirm the functionality described in the TSS as well as the administrative (including
configuration and operation) documentation provided. The focus of the testing is to confirm that the
requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs
@@ -2953,7 +3009,12 @@ Developer action elements:
TOE combinations that are claiming conformance to this PP.
- Developer action elements:
The developer shall provide the TOE for testing.
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE for testing.
Content and presentation elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
@@ -2985,7 +3046,10 @@ Developer action elements:
5.2.6 Class AVA: Vulnerability Assessment
+
+
+ 5.2.6 Class AVA: Vulnerability Assessment
+
For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn
what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will
require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly
@@ -2994,7 +3058,14 @@ Developer action elements:
PPs.
- AVA_VAN.1 Vulnerability survey
Developer action elements:
The developer shall provide the TOE for testing.
+
+ AVA_VAN.1 Vulnerability survey
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE for testing.
Content and presentation elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
@@ -3014,6 +3085,8 @@ Developer action elements:
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
@@ -3038,7 +3111,7 @@ A.1 Strictly Optional R
list of actions]upon detection of a potential security violation.Application
Note:
In certain cases, it may be useful for Virtualization Systems to perform automated
- responses to certain security events. An example may include halting a VM which has taken some action
+ responses to certain security events. An example may include halting a VM which has taken some action
to violate a key system security policy. This may be especially useful with headless endpoints when
there is no human user in the loop.
The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
@@ -3073,26 +3146,26 @@ A.1 Strictly Optional R
The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment:
- list of Guest VM integrity mechanisms].Application
+ list of Guest VM integrity mechanisms].Application
Note:
The primary purpose of this requirement is to identify and describe
the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion,
though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used.
- Importation for this requirement could include VM migration (live or otherwise), the importation of
+ Importation for this requirement could include VM migration (live or otherwise), the importation of
virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a
- trusted VM could have been modified during the migration or import/export process, or VMs could have
+ trusted VM could have been modified during the migration or import/export process, or VMs could have
been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a
- prudent measure to take. These integrity checks could be as thorough as making sure the entire VM
- exactly matches a previously known VM (by hash for example), or by simply checking certain
- configuration settings to ensure that the VM's configuration will not violate the security model
- of the VS.
+ prudent measure to take. These integrity checks could be as thorough as making sure the entire VM
+ exactly matches a previously known VM (by hash for example), or by simply checking certain
+ configuration settings to ensure that the VM's configuration will not violate the security model
+ of the VS.
A.2 Objective Requirements
A.2.1 Class: Protection of the TSF (FPT)
FPT_DDI_EXT.1 Device Driver Isolation
@@ -3101,14 +3174,14 @@ A.1 Strictly Optional R
- The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.Application
+ The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.Application
Note:
- In order to function on physical hardware, the VMM must have access to the device
+ In order to function on physical hardware, the VMM must have access to the device
drivers for the physical platform on which it runs. These drivers are often written by third parties,
- and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality
+ and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality
of third party code that the virtualization vendor has no control over. By encapsulating these drivers
- within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or
- vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains
+ within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or
+ vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains
have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's
Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used
to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
@@ -3158,21 +3231,21 @@ A.1 Strictly Optional R
- The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.Application
+ The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.Application
Note:
Introspection can be used to support malware and anomaly detection from outside of
- the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing
- an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt
- to break out of the VM and compromise the VMM or other VMs.
- The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure
+ the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing
+ an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt
+ to break out of the VM and compromise the VMM or other VMs.
+ The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure
the integrity of the malware detection/antivirus software. This capability can be implemented in
- the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained
- and does not introduce bugs into the VMM.
+ the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained
+ and does not introduce bugs into the VMM.
The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it.
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-GCM-128, AES-GCM-256 (as specified in RFC 4106),[selection: AES-CBC-128 (specified in RFC 3602), AES-CBC-256 (specified in RFC 3602), no other algorithms]] together with a Secure Hash Algorithm (SHA)-based HMAC.
- The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]Application
+ The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]
The TSF shall ensure the encrypted payload in the[selection: IKEv1, IKEv2]protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and[selection: AES-GCM-128 as specified in RFC 5282, AES-GCM-256 as specified in RFC 5282, no other algorithm].
- The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
+ The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
Note:
The ST author is afforded a selection based on the version of IKE in their
@@ -3365,7 +3440,8 @@ A.1 Strictly Optional R
If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1
must be claimed.
- The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, other supported reference identifier types ]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.Application
+ The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, [assignment:
+ other supported reference identifier types ]]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.Application
Note:
The TOE must support at least one of the following identifier types: IP address,
@@ -3428,7 +3504,7 @@ A.1 Strictly Optional R
can be properly applied.
Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE
boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec
- functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
+ functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which
is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is
allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD
@@ -3856,7 +3932,8 @@ A.1 Strictly Optional R
If "" is selected then
"Ability to configure action taken if unable to determine the validity of a certificate" in the Client or Server module
management function table must also be selected.
- The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, other uses ]Application
+ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, [assignment:
+ other uses ]]Application
Note:
This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital
signature mechanism,” if "certificate-based authentication of the remote peer" is
@@ -4080,9 +4157,9 @@ E.3 Specific Guidance for
PP-specified functionality. If the Product Versions are fully tested separately, then there is
no need to document the differences.
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided
- into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
- installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
- into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
+ into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
+ installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
+ into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
metal or on an operating system, both hardware and software equivalence are relevant.
E.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily
@@ -4093,15 +4170,15 @@ E.3 Specific Guidance for
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
Factor Same/Different/None Guidance Platform Architectures Different Hardware platforms that implement different processor architectures and instruction sets are not
equivalent. PP-Specified Functionality Same For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -4127,15 +4204,15 @@ E.3 Specific Guidance for
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
-
Bare-Metal VS
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
+
Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must
describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor
must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates
differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the
claimed equivalent configuration.
-
VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
+
VS with OS Support
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified
security functionality and how the TOE functions differently to leverage platform differences in the tested configuration
versus the claimed equivalent configuration.
@@ -4147,22 +4224,16 @@ Appendix F - Acronyms
EP Extended Package
FP Functional Package OE Operational Environment OS Guest Operating System OS Host Operating System PP Protection Profile PP-Configuration Protection Profile Configuration PP-Module Protection Profile Module SAR Security Assurance Requirement SFR Security Functional Requirement SSP System Security Policy ST Security Target TOE Target of Evaluation TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification VM Virtual Machine VMM Virtual Machine Manager VS Virtualization System
Appendix G - Bibliography
Table 10: Bibliography Identifier Title [CC] Common Criteria for Information Technology Security Evaluation -
- Part
1: Introduction and General Model, CCMB-2017-04-001, Version 3.1 Revision 5,
diff --git a/xml-builder-test/SanityChecksOutput.md b/xml-builder-test/SanityChecksOutput.md
index 17cbc34..5235f4d 100644
--- a/xml-builder-test/SanityChecksOutput.md
+++ b/xml-builder-test/SanityChecksOutput.md
@@ -289,17 +289,15 @@
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[8]""/f-component[3]""/f-element[1]""/note[1]"This requ"/h:p[1]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[8]""/f-component[4]""/f-element[1]""/note[1]"In enviro"/h:p[1]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[8]""/f-component[4]""/f-element[1]""/aactivity[1]""/Tests[1]"The evalu"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[2]""/a-element[5]""/aactivity[1]"As indica"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[4]"At the as"/a-component[1]""/a-element[3]""/aactivity[1]"The evalu"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[4]"At the as"/a-component[1]""/a-element[3]""/aactivity[1]"The evalu"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[4]"At the as"/a-component[1]""/a-element[3]""/aactivity[1]"The evalu"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[3]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[3]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[2]""/a-element[5]""/aactivity[1]"As indica"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[4]"At the as"/a-component[1]""/a-element[3]""/aactivity[1]"The evalu"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[4]"At the as"/a-component[1]""/a-element[3]""/aactivity[1]"The evalu"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[4]"At the as"/a-component[1]""/a-element[3]""/aactivity[1]"The evalu"/h:p[3]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[3]""
* Warning: Detected an empty _p_ element./PP[1]""/appendix[2]""/section[1]"Documenta"/h:p[1]""
diff --git a/xml-builder-test/SpellCheckReport.txt b/xml-builder-test/SpellCheckReport.txt
index ccefd40..6f5776d 100644
--- a/xml-builder-test/SpellCheckReport.txt
+++ b/xml-builder-test/SpellCheckReport.txt
@@ -3,6 +3,7 @@ output/virtualization-release-linkable.html: KDF
output/virtualization-release-linkable.html: NISTSP
output/virtualization-release-linkable.html: Part1
output/virtualization-release-linkable.html: SPD
+output/virtualization-release-linkable.html: SSP
output/virtualization-release-linkable.html: andpotentially
output/virtualization-release-linkable.html: assuch
output/virtualization-release-linkable.html: bemade
@@ -22,11 +23,13 @@ output/virtualization-release-linkable.html: policythat
output/virtualization-release-linkable.html: potentiallysupport
output/virtualization-release-linkable.html: reducesthe
output/virtualization-release-linkable.html: removeable
+output/virtualization-release-linkable.html: rized
output/virtualization-release-linkable.html: rulesdescribing
output/virtualization-release-linkable.html: rulesets
output/virtualization-release-linkable.html: sel
output/virtualization-release-linkable.html: selectted
output/virtualization-release-linkable.html: serviceattacks
+output/virtualization-release-linkable.html: unautho
output/virtualization-release-linkable.html: untrustedsubjects
output/virtualization-release-linkable.html: valueassociated
output/virtualization-release.html: FFC
@@ -34,6 +37,9 @@ output/virtualization-release.html: KDF
output/virtualization-release.html: NISTSP
output/virtualization-release.html: Part1
output/virtualization-release.html: SPD
+output/virtualization-release.html: SSP
+output/virtualization-release.html: VMM’s
+output/virtualization-release.html: VM’s
output/virtualization-release.html: action’
output/virtualization-release.html: andpotentially
output/virtualization-release.html: assuch
@@ -62,6 +68,7 @@ output/virtualization-release.html: reducesthe
output/virtualization-release.html: removeable
output/virtualization-release.html: rulesdescribing
output/virtualization-release.html: rulesets
+output/virtualization-release.html: securit
output/virtualization-release.html: sel
output/virtualization-release.html: selectted
output/virtualization-release.html: serviceattacks
@@ -72,6 +79,9 @@ output/virtualization.html: KDF
output/virtualization.html: NISTSP
output/virtualization.html: Part1
output/virtualization.html: SPD
+output/virtualization.html: SSP
+output/virtualization.html: VMM’s
+output/virtualization.html: VM’s
output/virtualization.html: action’
output/virtualization.html: andpotentially
output/virtualization.html: assuch
@@ -99,6 +109,7 @@ output/virtualization.html: reducesthe
output/virtualization.html: removeable
output/virtualization.html: rulesdescribing
output/virtualization.html: rulesets
+output/virtualization.html: securit
output/virtualization.html: sel
output/virtualization.html: selectted
output/virtualization.html: serviceattacks
diff --git a/xml-builder-test/effective.xml b/xml-builder-test/effective.xml
index 681ed8e..ae992d8 100644
--- a/xml-builder-test/effective.xml
+++ b/xml-builder-test/effective.xml
@@ -56,7 +56,7 @@
or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected
by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem.
See Operational Network.
- An operating system that runs within a Guest VM.
+ An operating system that runs within a Guest VM.
A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications.
@@ -65,7 +65,7 @@
to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be
considered a Helper VM. For the purposes of this document, Helper VMs are considered a type of Guest VM, and are
therefore subject to all the same requirements, unless specifically stated otherwise.
- An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs.
The Hypervisor is part of the VMM. It is the software executive of the physical platform of a VS.
@@ -98,18 +98,18 @@
designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices,
VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that
help establish communication paths between VMs.
- The overall policy enforced by the VS defining constraints on the behavior
+ The overall policy enforced by the VS defining constraints on the behavior
of VMs and users.
Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM.
- A Virtual Machine is a virtualized hardware environment in which an operating system
+ A Virtual Machine is a virtualized hardware environment in which an operating system
may execute.
- A VMM is a collection of software components responsible for enabling VMs to
+ A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed.
- A software product that enables multiple independent computing systems to
+ A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
@@ -124,17 +124,16 @@
This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
-
+
-
+
-
@@ -689,7 +688,7 @@
- The TSF shall<selectables><selectable id="fau_stg_ext.1.2_1">drop new audit data</selectable><selectable>overwrite previous audit records according to the following rule: <assignable id="fau_stg_ext.1.2_3">rule for overwriting previous audit records </assignable></selectable><selectable id="fau_stg_ext.1.2_5">other action </selectable></selectables>when the local storage space for audit data is full.
+ The TSF shall<selectables><selectable id="fau_stg_ext.1.2_1">drop new audit data</selectable><selectable id="fau_stg_ext.1.2_2">overwrite previous audit records according to the following rule: <assignable>rule for overwriting previous audit records </assignable></selectable><selectable id="fau_stg_ext.1.2_5"><assignable>other action </assignable></selectable></selectables>when the local storage space for audit data is full.
An external log server, if available, might be used as alternative storage space
in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the
new audit data to an external IT entity’.
@@ -727,7 +726,7 @@
The TSF shall generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm<selectables><selectable id="fcs_ckm.1.1_1">
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
- </selectable><selectable> ECC schemes using [“NIST curves” P-256, P-384, and <selectables><selectable id="fcs_ckm.1.1_3">P-521</selectable><selectable id="fcs_ckm.1.1_4">no other curves</selectable></selectables> that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4] </selectable><selectable id="fcs_ckm.1.1_5">
+ </selectable><selectable id="fcs_ckm.1.1_2"> ECC schemes using [“NIST curves” P-256, P-384, and <selectables><selectable id="fcs_ckm.1.1_3">P-521</selectable><selectable id="fcs_ckm.1.1_4">no other curves</selectable></selectables> that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4] </selectable><selectable id="fcs_ckm.1.1_5">
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
</selectable><selectable id="fcs_ckm.1.1_6">FFC Schemes using Diffie-Hellman group 14 that meet the following: [RFC 3526]</selectable><selectable id="fcs_ckm.1.1_7"> FFC Schemes using safe primes that meet the following: [‘NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes"]</selectable></selectables><h:s>and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
@@ -1100,7 +1099,7 @@
<f-component cc-id="fcs_cop.1" id="fcs-cop-1-sig" name="Cryptographic Operation (Signature Algorithms)" iteration="Sig">
<f-element id="fcs-cop-1e1-sig">
<title>The TSF shall perform [ <h:i>cryptographic signature services (generation and verification)</h:i> ] in accordance with a specified cryptographic algorithm<selectables><selectable id="sel-sig-rsa">RSA schemes using cryptographic key sizes [2048-bit or greater] that meet
- the following: [<h:i>FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4</h:i>]</selectable><selectable>ECDSA schemes using [“NIST curves” P-256, P-384 and <selectables><selectable id="fcs_cop.1.1_Sig_1">P-521</selectable><selectable id="fcs_cop.1.1_Sig_2">no other curves</selectable></selectables>] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5] </selectable></selectables>.
+ the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4 ]ECDSA schemes using [“NIST curves” P-256, P-384 and P-521 no other curves .
The ST Author should choose the algorithm implemented to perform digital signatures;
if more than one algorithm is available, this requirement should be iterated to specify the
functionality. For the algorithm chosen, the ST author should make the appropriate
@@ -1536,7 +1535,7 @@
- The TSF shall implement the protocol: <h:p/><selectables><selectable>IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, <selectables><selectable id="fcs_ipsec_ext.1.5_2">no other RFCs for extended sequence numbers</selectable><selectable id="fcs_ipsec_ext.1.5_3">RFC 4304 for extended sequence numbers</selectable></selectables>, <selectables><selectable id="fcs_ipsec_ext.1.5_4">no other RFCs for hash functions</selectable><selectable id="fcs_ipsec_ext.1.5_5">RFC 4868 for hash functions</selectable></selectables>, and <selectables><selectable id="fcs_ipsec_ext.1.5_6">support for XAUTH</selectable><selectable id="fcs_ipsec_ext.1.5_7">no support for XAUTH</selectable></selectables></selectable><selectable>IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and <selectables><selectable id="fcs_ipsec_ext.1.5_9">no other RFCs for hash functions</selectable><selectable id="fcs_ipsec_ext.1.5_10">RFC 4868 for hash functions</selectable></selectables>.</selectable></selectables>
+ The TSF shall implement the protocol: <h:p/><selectables><selectable id="fcs_ipsec_ext.1.5_1">IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, <selectables><selectable id="fcs_ipsec_ext.1.5_2">no other RFCs for extended sequence numbers</selectable><selectable id="fcs_ipsec_ext.1.5_3">RFC 4304 for extended sequence numbers</selectable></selectables>, <selectables><selectable id="fcs_ipsec_ext.1.5_4">no other RFCs for hash functions</selectable><selectable id="fcs_ipsec_ext.1.5_5">RFC 4868 for hash functions</selectable></selectables>, and <selectables><selectable id="fcs_ipsec_ext.1.5_6">support for XAUTH</selectable><selectable id="fcs_ipsec_ext.1.5_7">no support for XAUTH</selectable></selectables></selectable><selectable id="fcs_ipsec_ext.1.5_8">IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and <selectables><selectable id="fcs_ipsec_ext.1.5_9">no other RFCs for hash functions</selectable><selectable id="fcs_ipsec_ext.1.5_10">RFC 4868 for hash functions</selectable></selectables>.</selectable></selectables>
If the TOE implements SHA-2 hash algorithms for IKEv1 or IKEv2, the ST author shall
select RFC 4868.
@@ -1593,7 +1592,7 @@
- The TSF shall ensure that<selectables><selectable>IKEv2 SA lifetimes can be configured by <selectables><selectable id="fcs_ipsec_ext.1.7_2">an Administrator</selectable><selectable id="fcs_ipsec_ext.1.7_3">a VPN Gateway</selectable></selectables> based on <selectables><selectable id="fcs_ipsec_ext.1.7_4">number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_5">length of time</selectable></selectables></selectable><selectable>IKEv1 SA lifetimes can be configured by <selectables><selectable id="fcs_ipsec_ext.1.7_7">an Administrator</selectable><selectable id="fcs_ipsec_ext.1.7_8">a VPN Gateway</selectable></selectables> based on <selectables><selectable id="fcs_ipsec_ext.1.7_9">number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_10">length of time</selectable></selectables></selectable><selectable>IKEv1 SA lifetimes are fixed based on <selectables><selectable id="fcs_ipsec_ext.1.7_12">number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_13">length of time</selectable></selectables>. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs. </selectable></selectables>
+ The TSF shall ensure that<selectables><selectable id="fcs_ipsec_ext.1.7_1">IKEv2 SA lifetimes can be configured by <selectables><selectable id="fcs_ipsec_ext.1.7_2">an Administrator</selectable><selectable id="fcs_ipsec_ext.1.7_3">a VPN Gateway</selectable></selectables> based on <selectables><selectable id="fcs_ipsec_ext.1.7_4">number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_5">length of time</selectable></selectables></selectable><selectable id="fcs_ipsec_ext.1.7_6">IKEv1 SA lifetimes can be configured by <selectables><selectable id="fcs_ipsec_ext.1.7_7">an Administrator</selectable><selectable id="fcs_ipsec_ext.1.7_8">a VPN Gateway</selectable></selectables> based on <selectables><selectable id="fcs_ipsec_ext.1.7_9">number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_10">length of time</selectable></selectables></selectable><selectable id="fcs_ipsec_ext.1.7_11">IKEv1 SA lifetimes are fixed based on <selectables><selectable id="fcs_ipsec_ext.1.7_12">number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_13">length of time</selectable></selectables>. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs. </selectable></selectables>
The ST author is afforded a selection based on the version of IKE in their
implementation. There is a further selection within this selection that allows the
@@ -1793,7 +1792,7 @@
- The TSF shall not establish an SA if the [<selectables><selectable id="fcs_ipsec_ext.1.12_1">IP address</selectable><selectable id="fcs_ipsec_ext.1.12_2">Fully Qualified Domain Name (FQDN)</selectable><selectable id="fcs_ipsec_ext.1.12_3">user FQDN</selectable><selectable id="fcs_ipsec_ext.1.12_4">Distinguished Name (DN)</selectable></selectables>and<selectables><selectable id="fcs_ipsec_ext.1.12_5">no other reference identifier type</selectable><selectable id="fcs_ipsec_ext.1.12_7">other supported reference identifier types </selectable></selectables>] contained in a certificate does not match the expected values for the entity attempting to establish a connection.
+ The TSF shall not establish an SA if the [<selectables><selectable id="fcs_ipsec_ext.1.12_1">IP address</selectable><selectable id="fcs_ipsec_ext.1.12_2">Fully Qualified Domain Name (FQDN)</selectable><selectable id="fcs_ipsec_ext.1.12_3">user FQDN</selectable><selectable id="fcs_ipsec_ext.1.12_4">Distinguished Name (DN)</selectable></selectables>and<selectables><selectable id="fcs_ipsec_ext.1.12_5">no other reference identifier type</selectable><selectable id="fcs_ipsec_ext.1.12_7"><assignable>other supported reference identifier types </assignable></selectable></selectables>] contained in a certificate does not match the expected values for the entity attempting to establish a connection.
The TOE must support at least one of the following identifier types: IP address,
Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN).
@@ -1958,7 +1957,7 @@
There are no auditable events foreseen.
FDP_VMS_EXT.1 VM Separation
- The TSF shall use<selectables><selectable id="fdp_hbi_ext.1.1_1">no mechanism</selectable><selectable id="fdp_hbi_ext.1.1_3">list of platform-provided, hardware-based mechanisms </selectable></selectables>to constrain a Guest VM's direct access to the following physical devices:<selectables><selectable id="fdp_hbi_ext.1.1_4">no devices</selectable><selectable id="fdp_hbi_ext.1.1_6"> physical devices to which the VMM allows Guest VMs physical access </selectable></selectables>.
+ The TSF shall use<selectables><selectable id="fdp_hbi_ext.1.1_1">no mechanism</selectable><selectable id="fdp_hbi_ext.1.1_3"><assignable>list of platform-provided, hardware-based mechanisms </assignable></selectable></selectables>to constrain a Guest VM's direct access to the following physical devices:<selectables><selectable id="fdp_hbi_ext.1.1_4">no devices</selectable><selectable id="fdp_hbi_ext.1.1_6"><assignable> physical devices to which the VMM allows Guest VMs physical access </assignable></selectable></selectables>.
The TSF must use available hardware-based isolation mechanisms to constrain VMs
when VMs have direct access to physical devices. “Direct access” in this context means that the
VM can read or write device memory or access device I/O ports without the VMM being able to intercept
@@ -1993,10 +1992,10 @@
The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:<assignable>list of physical platform resources the VMM isable to control access to</assignable>.
- The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:<selectables><selectable id="fdp_ppr_ext.1.2_1">no physical platform resources</selectable><selectable id="fdp_ppr_ext.1.2_3">list of physical platform resources to which access is explicitly denied </selectable></selectables>.
+ The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:<selectables><selectable id="fdp_ppr_ext.1.2_1">no physical platform resources</selectable><selectable id="fdp_ppr_ext.1.2_3"><assignable>list of physical platform resources to which access is explicitly denied </assignable></selectable></selectables>.
- The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:<selectables><selectable id="fdp_ppr_ext.1.3_1">no physical platform resources</selectable><selectable id="fdp_ppr_ext.1.3_3">list of physical platform resources to which access is always allowed </selectable></selectables>.
+ The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:<selectables><selectable id="fdp_ppr_ext.1.3_1">no physical platform resources</selectable><selectable id="fdp_ppr_ext.1.3_3"><assignable>list of physical platform resources to which access is always allowed </assignable></selectable></selectables>.
For purposes of this requirement, physical platform resources are divided into three categories:
those to which Guest OS access is configurable and moderated by the VMM those to which the Guest OS is never allowed to have direct access, and those to which the Guest OS is always allowed to have direct access. There are no auditable events foreseen.
No dependencies.
- The VS shall provide the following mechanisms for transferring data between Guest VMs:<selectables><selectable id="fdp_vms_ext.1.1_1">no mechanism</selectable><selectable id="fdp_vms_ext.1.1_2">virtual networking</selectable><selectable id="fdp_vms_ext.1.1_4">other inter-VM data sharing mechanisms </selectable></selectables>.
+ The VS shall provide the following mechanisms for transferring data between Guest VMs:<selectables><selectable id="fdp_vms_ext.1.1_1">no mechanism</selectable><selectable id="fdp_vms_ext.1.1_2">virtual networking</selectable><selectable id="fdp_vms_ext.1.1_4"><assignable>other inter-VM data sharing mechanisms </assignable></selectable></selectables>.
The TSF shall by default enforce a policy prohibiting sharing of data between Guest VMs.
@@ -2276,10 +2275,10 @@
FIA_UIA_EXT.1 Administrator Identification and Authentication
FMT_SMR.1 Security Roles
- The TSF shall detect when<selectables><selectable id="fia_afl_ext.1.1_2">a positive integer number </selectable><selectable>an administrator configurable positive integer within a <assignable id="fia_afl_ext.1.1_4">range of acceptable values </assignable></selectable></selectables>unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using<selectables><selectable id="fia_afl_ext.1.1_5">username and password</selectable><selectable id="fia_afl_ext.1.1_6">username and PIN</selectable></selectables>.
+ The TSF shall detect when<selectables><selectable id="fia_afl_ext.1.1_2"><assignable>a positive integer number </assignable></selectable><selectable id="fia_afl_ext.1.1_3">an administrator configurable positive integer within a <assignable>range of acceptable values </assignable></selectable></selectables>unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using<selectables><selectable id="fia_afl_ext.1.1_5">username and password</selectable><selectable id="fia_afl_ext.1.1_6">username and PIN</selectable></selectables>.
- When the defined number of unsuccessful authentication attempts has been met, the TSF shall:<selectables><selectable>prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until <assignable id="fia_afl_ext.1.2_2">action to unlock </assignable> is taken by an Administrator</selectable><selectable id="fia_afl_ext.1.2_3">prevent the offending Administrator from successfully establishing a remote session using
+ <title>When the defined number of unsuccessful authentication attempts has been met, the TSF shall:<selectables><selectable id="fia_afl_ext.1.2_1">prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until <assignable>action to unlock </assignable> is taken by an Administrator</selectable><selectable id="fia_afl_ext.1.2_3">prevent the offending Administrator from successfully establishing a remote session using
any authentication method that involves a password or PIN until an Administrator-defined time
period has elapsed</selectable></selectables>
The action to be taken shall be populated in the selection of the ST
@@ -2341,7 +2340,7 @@
The TSF shall provide the following password management capabilities for administrative passwords: <h:ol><h:li>Passwords shall be able to be composed of any combination of upper and lower case characters,
digits, and the following special characters:
- <selectables><selectable id="fia_pmg_ext.1.1_1">“!”</selectable><selectable id="fia_pmg_ext.1.1_2">“@”</selectable><selectable id="fia_pmg_ext.1.1_3">“#”</selectable><selectable id="fia_pmg_ext.1.1_4">“$”</selectable><selectable id="fia_pmg_ext.1.1_5">“%”</selectable><selectable id="fia_pmg_ext.1.1_6">“^”</selectable><selectable id="fia_pmg_ext.1.1_7">“& ”</selectable><selectable id="fia_pmg_ext.1.1_8">“*”</selectable><selectable id="fia_pmg_ext.1.1_9">“(“</selectable><selectable id="fia_pmg_ext.1.1_10">“)”</selectable><selectable id="fia_pmg_ext.1.1_12">other characters </selectable></selectables></h:li><h:li>Minimum password length shall be configurable</h:li><h:li>Passwords of at least 15 characters in length shall be supported</h:li></h:ol>
+ “!” “@” “#” “$” “%” “^” “& ” “*” “(“ “)” other characters Minimum password length shall be configurable Passwords of at least 15 characters in length shall be supported
This SFR is included in the ST if the ST Author selects ‘authentication based on username and password’
in FIA_UAU.5.1.
- The TSF shall provide the following authentication mechanisms:<selectables><selectable><selectables><selectable id="fia_uau.5.1_1">local</selectable><selectable id="sel-uau-pwd-dirbased">directory-based</selectable></selectables> authentication based on username and password </selectable><selectable id="fia_uau.5.1_2">authentication based on username and a PIN that releases an asymmetric key stored in
- OE-protected storage</selectable><selectable><selectables><selectable id="fia_uau.5.1_3">local</selectable><selectable id="sel-uau-x509-dirbased">directory-based</selectable></selectables> authentication based on X.509 certificates </selectable><selectable><selectables><selectable id="fia_uau.5.1_4">local</selectable><selectable id="sel-uau-ssh-dirbased">directory-based</selectable></selectables> authentication based on an SSH public key credential </selectable></selectables>to support Administrator authentication.
+ The TSF shall provide the following authentication mechanisms:<selectables><selectable id="sel-uau-pwd"><selectables><selectable id="fia_uau.5.1_1">local</selectable><selectable id="sel-uau-pwd-dirbased">directory-based</selectable></selectables> authentication based on username and password </selectable><selectable id="fia_uau.5.1_2">authentication based on username and a PIN that releases an asymmetric key stored in
+ OE-protected storage</selectable><selectable id="sel-uau-x509"><selectables><selectable id="fia_uau.5.1_3">local</selectable><selectable id="sel-uau-x509-dirbased">directory-based</selectable></selectables> authentication based on X.509 certificates </selectable><selectable id="sel-uau-ssh"><selectables><selectable id="fia_uau.5.1_4">local</selectable><selectable id="sel-uau-ssh-dirbased">directory-based</selectable></selectables> authentication based on an SSH public key credential </selectable></selectables>to support Administrator authentication.
Selection of ‘authentication based on username and password’ requires that
FIA_PMG_EXT.1 be included in the ST. This also requires that the ST include a management function for
password management. If the ST author selects ‘authentication based on an SSH public-key credential’,
@@ -2612,7 +2611,7 @@
"Ability to configure action taken if unable to determine the validity of a certificate" in the Client or Server module
management function table must also be selected.
- The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for<selectables><selectable id="sel-x509-2-ipsec">IPsec</selectable><selectable id="sel-x509-2-tls">TLS</selectable><selectable id="sel-x509-2-https">HTTPS</selectable><selectable id="sel-x509-2-ssh">SSH</selectable><selectable id="sel-x5092-signed-updates">code signing for system software updates</selectable><selectable id="fia_x509_ext.2.1_2">other uses </selectable></selectables>
+ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for<selectables><selectable id="sel-x509-2-ipsec">IPsec</selectable><selectable id="sel-x509-2-tls">TLS</selectable><selectable id="sel-x509-2-https">HTTPS</selectable><selectable id="sel-x509-2-ssh">SSH</selectable><selectable id="sel-x5092-signed-updates">code signing for system software updates</selectable><selectable id="fia_x509_ext.2.1_2"><assignable>other uses </assignable></selectable></selectables>
This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital
signature mechanism,” if "certificate-based authentication of the remote peer" is
selected in FTP_ITC_EXT.1, or if "authentication based on X.509 certificates"
@@ -2787,7 +2786,7 @@
There are no auditable events foreseen.
No dependencies.
- The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:<selectables><selectable id="fpt_eem_ext.1.1_1">Address space randomization</selectable><selectable id="fpt_eem_ext.1.1_2">Memory execution protection (e.g., DEP)</selectable><selectable id="fpt_eem_ext.1.1_3">Stack buffer overflow protection</selectable><selectable id="fpt_eem_ext.1.1_4">Heap corruption detection</selectable><selectable id="fpt_eem_ext.1.1_6">other mechanisms </selectable><selectable id="fpt_eem_ext.1.1_7">No mechanisms</selectable></selectables>
+ The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:<selectables><selectable id="fpt_eem_ext.1.1_1">Address space randomization</selectable><selectable id="fpt_eem_ext.1.1_2">Memory execution protection (e.g., DEP)</selectable><selectable id="fpt_eem_ext.1.1_3">Stack buffer overflow protection</selectable><selectable id="fpt_eem_ext.1.1_4">Heap corruption detection</selectable><selectable id="fpt_eem_ext.1.1_6"><assignable>other mechanisms </assignable></selectable><selectable id="fpt_eem_ext.1.1_7">No mechanisms</selectable></selectables>
Processor manufacturers, compiler developers, and operating system vendors have
developed execution environment-based mitigations that increase the cost to attackers by adding
complexity to the task of compromising systems. Software can often take advantage of these mechanisms
@@ -3006,7 +3005,7 @@
Integrity measurements collected.
No dependencies.
- The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:<selectables><selectable id="fpt_ml_ext.1.1_1">Static executable images of the Management Subsystem</selectable><selectable id="fpt_ml_ext.1.1_3">list of (static images of) Service VMs </selectable><selectable id="fpt_ml_ext.1.1_5">list of configuration files </selectable><selectable id="fpt_ml_ext.1.1_6">no other components</selectable></selectables>
+ The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:<selectables><selectable id="fpt_ml_ext.1.1_1">Static executable images of the Management Subsystem</selectable><selectable id="fpt_ml_ext.1.1_3"><assignable>list of (static images of) Service VMs </assignable></selectable><selectable id="fpt_ml_ext.1.1_5"><assignable>list of configuration files </assignable></selectable><selectable id="fpt_ml_ext.1.1_6">no other components</selectable></selectables>
The TSF shall make the measurements selected in FPT_ML_EXT.1.1 available to the Management Subsystem.
@@ -3366,7 +3365,7 @@
The TSF shall use<selectables><selectable id="sel-itc-tls">TLS as conforming to the <h:a href="https://www.niap-ccevs.org/MMO/PP/-439-/">Functional Package for Transport Layer Security</h:a></selectable><selectable id="sel-itc-https">TLS/HTTPS as conforming to FCS_HTTPS_EXT.1</selectable><selectable id="sel-itc-ipsec">IPsec as conforming to FCS_IPSEC_EXT.1</selectable><selectable id="sel-itc-ssh">SSH as conforming to the
<h:a href="https://www.niap-ccevs.org/MMO/PP/-459-/">Functional Package
- for Secure Shell</h:a></selectable></selectables>and<selectables><selectable id="sel-itc-certauth">certificate-based authentication of the remote peer</selectable><selectable id="ftp_itc_ext.1.1_1">non-certificate-based authentication of the remote peer</selectable><selectable id="ftp_itc_ext.1.1_2">no authentication of the remote peer</selectable></selectables>to provide a trusted communication channel between itself, and <h:p/> <h:li>audit servers (as required by FAU_STG_EXT.1), and</h:li><selectables><selectable id="ftp_itc_ext.1.1_3">remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module)</selectable><selectable id="ftp_itc_ext.1.1_4">separation of management and operational networks (if selected in FMT_SMO_EXT.1)</selectable><selectable id="ftp_itc_ext.1.1_6">other capabilities </selectable><selectable id="ftp_itc_ext.1.1_7">no other capabilities</selectable></selectables>that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data.
+ for Secure Shellandcertificate-based authentication of the remote peer non-certificate-based authentication of the remote peer no authentication of the remote peer audit servers (as required by FAU_STG_EXT.1), and remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module) separation of management and operational networks (if selected in FMT_SMO_EXT.1) other capabilities no other capabilities If the ST author selects either TLS or HTTPS, the TSF shall be validated against the
Functional Package for TLS. This PP does not mandate that a product implement TLS with mutual authentication,
but if the product includes the capability to perform TLS with mutual authentication, then
@@ -3537,47 +3536,75 @@
-
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The
- Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP
- identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the
- documentation applicable for the evaluation and performs independent testing.
+
+ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+
As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.
-
+
+
+
The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE
Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2
should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.
- The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs.
+
+
+
+ The developer shall provide a functional specification.
+
+
+ The developer shall provide a tracing from the functional specification to the SFRs.
+
As indicated in the introduction to this section, the functional specification is composed of the information
contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the
ST. The evaluation activities in the functional requirements point to evidence that should exist in the
documentation and TSS section; since these are directly associated with the SFRs, the tracing in element
- ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. The functional specification shall describe the purpose and method of use for each SFR-enforcing and
- SFR-supporting TSFI. The functional specification shall identify all parameters associated with each SFR-enforcing and
- SFR-supporting TSFI. The functional specification shall provide rationale for the implicit categorization of interfaces as
- SFR-non-interfering. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation
- of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs.
+ ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
+
+ The functional specification shall describe the purpose and method of use for each SFR-enforcing and
+ SFR-supporting TSFI.
+
+
+ The functional specification shall identify all parameters associated with each SFR-enforcing and
+ SFR-supporting TSFI.
+
+
+ The functional specification shall provide rationale for the implicit categorization of interfaces as
+ SFR-non-interfering.
+
+
+ The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.
+
+
+ The evaluator shall confirm that the information provided meets all requirements for content and presentation
+ of evidence.
+
+
+ The evaluator shall determine that the functional specification is an accurate and complete instantiation of
+ the SFRs.
+
There are no specific evaluation activities associated with these SARs. The functional specification documentation
is provided to support the evaluation activities described in Section 5.2, and other activities described for
AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is
implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable
to perform an activity because there is insufficient interface information, then an adequate functional
specification has not been provided.
-
+
+
+
The guidance documents will be provided with the developer’s security target. Guidance must include a description of
how the authorized user verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by an authorized user.The developer shall provide operational user guidance.
-
+
+
+
+ The developer shall provide operational user guidance.
+
+
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance. The operational user guidance shall describe what <h:s>for each user role </h:s><refinement>the authorized user-</refinement>accessible functions and
+ will provide the necessary information for the preparation of acceptable guidance.</note>
+ <aactivity/>
+ </a-element>
+ <a-element type="C">
+ <title>The operational user guidance shall describe what <h:s>for each user role </h:s><h:b>the authorized user-</h:b>accessible functions and
privileges that should be controlled in a secure processing environment, including appropriate
- warnings. The operational user guidance shall describe, for <h:s>each user role </h:s><refinement>the authorized user</refinement>, how to use the available
- interfaces provided by the TOE in a secure manner. The operational user guidance shall describe, for <h:s>each user role </h:s><refinement>the authorized user</refinement>, the available functions and
+ warnings.
+
+ The operational user guidance shall describe, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, how to use the available
+ interfaces provided by the TOE in a secure manner.
+
+
+ The operational user guidance shall describe, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
- values as appropriate. The operational user guidance shall, for <h:s>each user role </h:s><refinement>the authorized user</refinement>, clearly present each type of
+ values as appropriate.
+
+ The operational user guidance shall, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, clearly present each type of
security-relevant event relative to the user-accessible functions that need to be performed,
- including changing the security characteristics of entities under the control of the TSF. The operational user guidance shall identify all possible modes of operation of the TOE
+ including changing the security characteristics of entities under the control of the TSF.
+
+ The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation. The operational user guidance shall, for <h:s>each user role </h:s><refinement>the authorized user</refinement>, describe the security measures to be
+ maintaining secure operation.
+
+ The operational user guidance shall, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, describe the security measures to be
followed in order to fulfill the security objectives for the operational environment as described in
- the ST. The operational user guidance shall be clear and reasonable. The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence.
+ the ST.
+
+ The operational user guidance shall be clear and reasonable.
+
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
+ presentation of evidence.
+
Some of the contents of the operational guidance will be verified by the evaluation activities in
Section 5.2 and evaluation of the TOE according to the CEM. The
following additional information is also required.Instructions for obtaining the update itself. This should include instructions for making
the update accessible to the TOE (e.g., placement in a specific directory). Instructions for initiating the update process, as well as discerning whether the process
- was successful or unsuccessful. This includes generation of the hash/digital signature. The developer shall provide the TOE including its preparative procedures.
- As with the operational guidance, the developer should look to the evaluation activities
+ was successful or unsuccessful. This includes generation of the hash/digital signature.
+
+
+ The developer shall provide the TOE including its preparative procedures.
+
+ As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
- The preparative procedures shall describe all the steps necessary for secure acceptance of the
- delivered TOE in accordance with the developer’s delivery procedures. The preparative procedures shall describe all the steps necessary for secure installation of the TOE
+ </note>
+ <aactivity/>
+ </a-element>
+ <a-element type="C">
+ <title>The preparative procedures shall describe all the steps necessary for secure acceptance of the
+ delivered TOE in accordance with the developer’s delivery procedures.
+
+ The preparative procedures shall describe all the steps necessary for secure installation of the TOE
and for the secure preparation of the operational environment in accordance with the security
- objectives for the operational environment as described in the ST. The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely
- for operation.
+ objectives for the operational environment as described in the ST.
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
+ presentation of evidence.
+
+
+ The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely
+ for operation.
+
As indicated in the introduction above, there are significant expectations with respect to the
documentation—especially when configuring the operational environment to support TOE
functional requirements. The evaluator shall check to ensure that the guidance provided for the
@@ -3640,29 +3727,64 @@
The operational guidance shall contain step-by-step instructions suitable for use by an end-user of
the VS to configure a new, out-of-the-box system into the configuration evaluated
under this Protection Profile.
-
+
+
+
+
+
+
At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of
the TOE vendor’s development and configuration management process in order to provide a baseline level of
assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process
in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a
developer’s practices play in contributing to the overall trustworthiness of a product.
- The developer shall provide the TOE and a reference for the TOE.
- The TOE shall be labeled with its unique reference.
- The evaluator shall confirm that the information provided meets all requirements for content and
+
+ <a-component cc-id="alc_cmc.1" name="Labeling of the TOE">
+ <a-element type="D">
+ <title>The developer shall provide the TOE and a reference for the TOE.
+
+
+ The TOE shall be labeled with its unique reference.
+
+
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
-
+
+
The evaluator shall check the ST to ensure that it contains an identifier (such as a product
name/version number) that specifically identifies the version that meets the requirements of the ST. The developer shall provide a configuration list for the TOE.
- The configuration list shall include the following: the TOE itself; and the
+ the information in the ST is sufficient to distinguish the product.<h:p/></aactivity>
+ </a-element>
+ </a-component>
+ <a-component cc-id="alc_cms.1" name="TOE CM coverage">
+ <a-element type="D">
+ <title>The developer shall provide a configuration list for the TOE.
+
+
+ The configuration list shall include the following: the TOE itself; and the
evaluation evidence required by the SARs.
- The configuration list shall uniquely identify the configuration items.
- The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence.
+
+
+ The configuration list shall uniquely identify the configuration items.
+
+
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
+ presentation of evidence.
+
The evaluator shall ensure that the developer has identified (in public-facing development
guidance for their platform) one or more development environments appropriate for use in developing
applications for the developer’s platform. For each of these development environments, the developer
@@ -3673,7 +3795,11 @@
The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from
the TSF vendor), and that documentation provided by the developer in association with the requirements
in the ST is associated with the TSF using this unique identification.
-
+
+
+
+
+
This component requires the TOE developer, in conjunction with any other necessary parties, to provide information
as to how the VS is updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a security flaw is
@@ -3681,25 +3807,53 @@
(e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including
worst case time periods, before an update is made available to the public.
- The developer shall provide a description in the TSS of how timely security updates are made to the
- TOE. The description shall include the process for creating and deploying security updates for the TOE
- software/firmware. The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE.
+
+
+ The developer shall provide a description in the TSS of how timely security updates are made to the
+ TOE.
+
+
+ The description shall include the process for creating and deploying security updates for the TOE
+ software/firmware.
+
+
+ The description shall express the time window as the length of time, in days, between public disclosure
+ of a vulnerability and the public availability of security updates to the TOE.
+
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
- availability per deployment mechanism may differ; each is described. The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE.
+ availability per deployment mechanism may differ; each is described.
+
+ The description shall include the mechanisms publicly available for reporting security issues
+ pertaining to the TOE.
+
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
- proof-of-concept exploit). The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence.
+ proof-of-concept exploit).
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
+ presentation of evidence.
+
+
+
+
+
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or
implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces
with dependency on the availability of design information. One of the primary outputs of the evaluation process is
the test report as specified in the following requirements.
-
+
+
+
Testing is performed to confirm the functionality described in the TSS as well as the administrative (including
configuration and operation) documentation provided. The focus of the testing is to confirm that the
requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs
@@ -3707,11 +3861,26 @@
components. The evaluator produces a test report documenting the plan for and results of testing, as well
as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this PP.
- The developer shall provide the TOE for testing.
- The TOE shall be suitable for testing.
- The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
-
+
+
+ The developer shall provide the TOE for testing.
+
+
+
+ The TOE shall be suitable for testing.
+
+
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
+ presentation of evidence.
+
+
+ The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
+
+
The evaluator shall prepare a test plan and report documenting the testing aspects of the system.
While it is not necessary to have one test case per test listed in an evaluation activity, the
evaluators must document in the test plan that each applicable testing requirement in the
@@ -3739,7 +3908,12 @@
cumulative account, so if there was a test run that resulted in a failure; a fix installed; and
then a successful re-run of the test, the report would show a “fail” and “pass” result (and the
supporting details), and not just the “pass” result.
-
+
+
+
+
+
+
For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn
what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will
require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly
@@ -3748,13 +3922,33 @@
provided by the vendor. This information will be used in the development of penetration testing tools and for the
development of future PPs.
- The developer shall provide the TOE for testing.
- The TOE shall be suitable for testing.
- The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
- in the TOE. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities,
+
+ <a-component cc-id="ava_van.1" name="Vulnerability survey">
+ <a-element type="D">
+ <title>The developer shall provide the TOE for testing.
+
+
+ The TOE shall be suitable for testing.
+
+
+
+ The evaluator shall confirm that the information provided meets all requirements for content and
+ presentation of evidence.
+
+
+ The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
+ in the TOE.
+
+
+ The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities,
to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack
- potential. As with ATE_IND the evaluator shall generate a report to document their findings with respect
+ potential.
+ As with ATE_IND the evaluator shall generate a report to document their findings with respect
to this requirement. This report could physically be part of the overall test report mentioned in
ATE_IND, or a separate document. The evaluator performs a search of public information to determine
the vulnerabilities that have been found in virtualization in general, as well as those that pertain
@@ -3767,7 +3961,11 @@
the assurance level of this PP. If exploiting the vulnerability requires expert skills and an electron
microscope, for instance, then a test would not be suitable and an appropriate justification would be
formulated.
-
+
+
+
+
+
: Implicitly Satisfied Requirements Requirement Rationale for Satisfaction FCS_CKM.4 – Cryptographic Key Destruction
FCS_CKM.1 has a dependency on FCS_CKM.4. The extended SFR FCS_CKM_EXT.4 addresses this dependency
diff --git a/xml-builder-test/meta-info.txt b/xml-builder-test/meta-info.txt
index b672180..9209a76 100644
--- a/xml-builder-test/meta-info.txt
+++ b/xml-builder-test/meta-info.txt
@@ -1,2 +1,2 @@
T_VER=master-2024-04-30_10:59:56_-0400
-BUILD_TIME=2024-07-16 20:43
+BUILD_TIME=2024-08-12 02:34
diff --git a/xml-builder-test/spell-badge.svg b/xml-builder-test/spell-badge.svg
index c44de45..b646719 100644
--- a/xml-builder-test/spell-badge.svg
+++ b/xml-builder-test/spell-badge.svg
@@ -1,5 +1,5 @@
-
TDs Applied
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
A.1.1Class: Security Audit (FAU)A.1.2Class: Protection of the TSF (FPT)A.2Objective Requirements
A.2.1Class: Protection of the TSF (FPT)A.3Implementation-dependent Requirements
Appendix B - Selection-based Requirements
@@ -674,7 +674,7 @@ 1.1 Compliant Targets o
or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected
by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem.
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.1 Compliant Targets o
to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be
considered a Helper VM. For the purposes of this document, Helper VMs are considered a type of Guest VM, and are
therefore subject to all the same requirements, unless specifically stated otherwise.
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.1 Compliant Targets o
designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices,
VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that
help establish communication paths between VMs.
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators. Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules. 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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
+ - 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.
- 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
- Package Claims
3 Security Problem Definition
-
3.1 Threats
- - 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
- - 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -751,16 +750,16 @@ 3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
- security policies map to the security objectives.
Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+ security policies map to the security objectives. Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
will be configured in a correct and secure manner. OE.NON_MALICIOUS_USER If the organization properly vets and trains users, it is expected that they will be non-malicious. A.PHYSICAL OE.PHYSICAL If the TOE is deployed in a location that has appropriate physical safeguards, it can be assumed
to be physically secure. A.PLATFORM_INTEGRITY OE.PHYSICAL If the underlying platform has not been compromised prior to installation of the TOE, its integrity
can be assumed to be intact. A.TRUSTED_ADMIN OE.TRUSTED_ADMIN Providing guidance to administrators and ensuring that individuals are properly trained and
@@ -811,17 +810,17 @@ 5.1.1 Class: Security Audit (FAU)<
The ST author can include other auditable events directly in Table t-audit-mandatory; they are not
limited to the list presented. The ST author should update the table in
FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a
- user id or an identifier specifying a VM, for example.
+ user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and
Table t-audit-sel-based should be included in the ST if the
associated SFRs and selections are included.
The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach
VMs to virtualized network components. Changes to these configurations can be made
- during VM execution or when VMs are not running. Audit records
+ during VM execution or when VMs are not running. Audit records
must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
- to a physical device (when the device becomes part of the VM's hardware view), not
- to log every time that the device is accessed. Generally, this is only once at VM
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
+ to a physical device (when the device becomes part of the VM's hardware view), not
+ to log every time that the device is accessed. Generally, this is only once at VM
startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB
devices such as CD-ROMs). All such connection/disconnection events must be logged.
@@ -907,8 +906,9 @@ 5.1.1 Class: Security Audit (FAU)<
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel as specified in FTP_ITC_EXT.1.
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
- rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full. Application
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
+ rule for overwriting previous audit records ], [assignment:
+ other action ]]when the local storage space for audit data is full. Application
Note:
An external log server, if available, might be used as alternative storage space
in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the
@@ -961,7 +961,7 @@ 5.1.2 Class: Cryptographic Support
FCS_CKM.1 Cryptographic Key Generation
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[selection: -
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
-
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
+
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
- FFC Schemes using Diffie-Hellman group 14 that meet the following: [RFC 3526]
- FFC Schemes using safe primes that meet the following: [‘NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes"]
]and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
following: [assignment: list of standards] . Application
@@ -1297,7 +1297,7 @@ 5.1.2 Class: Cryptographic Support
FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
The TSF shall perform [ cryptographic signature services (generation and verification) ] in accordance with a specified cryptographic algorithm[selection: - RSA schemes using cryptographic key sizes [2048-bit or greater] that meet
- the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
]. Application
+ the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5] ]. Application
Note:
The ST Author should choose the algorithm implemented to perform digital signatures;
if more than one algorithm is available, this requirement should be iterated to specify the
@@ -1466,34 +1466,34 @@ 5.1.2 Class: Cryptographic Support
The TSF shall provide independent entropy across multiple VMs. Application
Note:
- This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
- need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
- must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
- provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
+ This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
+ need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
+ must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
+ provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
- Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
+ Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
3) pass-through access to a hardware entropy source (including a source of random numbers). In all
- cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no
- requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
+ cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no
+ requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a
- mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
- VM-unaware guest would use.
+ mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
+ VM-unaware guest would use.
The ST author should select “Hypercall interface” if the TSF provides an API function through which
guest-resident software can obtain entropy or random numbers. The ST author should select
- “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
+ “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
which it can obtain entropy or random numbers. Such an interface could present a virtualized real
- device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
- that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
+ device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
+ that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or
random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
- of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
+ of entropy provided to another VM on the same platform.
@@ -1580,11 +1580,13 @@ 5.1.3 Class: User Data Protection
- The TSF shall use[selection: no mechanism, list of platform-provided, hardware-based mechanisms ]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, physical devices to which the VMM allows Guest VMs physical access ]. Application
+ The TSF shall use[selection: no mechanism, [assignment:
+ list of platform-provided, hardware-based mechanisms ]]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, [assignment:
+ physical devices to which the VMM allows Guest VMs physical access ]]. Application
Note:
The TSF must use available hardware-based isolation mechanisms to constrain VMs
when VMs have direct access to physical devices. “Direct access” in this context means that the
- VM can read or write device memory or access device I/O ports without the VMM being able to intercept
+ VM can read or write device memory or access device I/O ports without the VMM being able to intercept
and validate every transaction.
- 5.2 Security Assurance Requirements
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The
- Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP
- identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the
- documentation applicable for the evaluation and performs independent testing.
- This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information
- Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual
- evaluation activities to be performed are specified in both Section 5.1 as well as in this section.
- After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain
- the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform
- actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained
- within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply
- to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also
- provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
- 5.2.1 Class ASE: Security Target Evaluation
- As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. 5.2.2 Class ADV: Development
+ 5.2 Security Assurance Requirements
+ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+ 5.2.1 Class ASE: Security Target Evaluation
+ As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.
+ 5.2.2 Class ADV: Development
+
The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE
Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2
should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.
- ADV_FSP.1 Basic functional specification
Developer action elements:
The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. Developer
+
+ ADV_FSP.1 Basic functional specification
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide a functional specification. Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs. Application
+ the SFRs.
Note:
There are no specific evaluation activities associated with these SARs. The functional specification documentation
@@ -2701,7 +2710,10 @@ 5.2.1 Class ASE: Security Targe
AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is
implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable
to perform an activity because there is insufficient interface information, then an adequate functional
- specification has not been provided.
5.2.3 Class AGD: Guidance Documents
+ specification has not been provided.
+
+ 5.2.3 Class AGD: Guidance Documents
+
The guidance documents will be provided with the developer’s security target. Guidance must include a description of
how the authorized user verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by an authorized user.
@@ -2711,21 +2723,32 @@ 5.2.1 Class ASE: Security Targe
environment.
Guidance pertaining to particular security functionality is also provided; specific requirements on such guidance are
contained in the evaluation activities specified with individual SFRs where applicable.
- AGD_OPE.1 Operational User Guidance
Developer action elements:
The developer shall provide operational user guidance. Developer
+
+ AGD_OPE.1 Operational User Guidance
+
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide operational user guidance. Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
+ will provide the necessary information for the preparation of acceptable guidance. Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
privileges that should be controlled in a secure processing environment, including appropriate
- warnings. The operational user guidance shall describe, for each user role the authorized user, the available functions and
+ warnings. The operational user guidance shall describe, for each user role the authorized user, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
- values as appropriate. The operational user guidance shall, for each user role the authorized user, clearly present each type of
+ values as appropriate. The operational user guidance shall, for each user role the authorized user, describe the security measures to be
+ maintaining secure operation. The operational user guidance shall be clear and reasonable. Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. AGD_PRE.1 Preparative procedures
Developer action elements:
+ AGD_PRE.1 Preparative procedures
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
The preparative procedures shall describe all the steps necessary for secure acceptance of the
@@ -2762,21 +2792,35 @@ 5.2.1 Class ASE: Security Targe
TOE adequately addresses all platforms (that is, combination of hardware and
operating system) claimed for the TOE in the ST.
The operational guidance shall contain step-by-step instructions suitable for use by an end-user of
- the VS to configure a new, out-of-the-box system into the configuration evaluated
- under this Protection Profile. 5.2.4 Class ALC: Life-Cycle Support
+ the VS to configure a new, out-of-the-box system into the configuration evaluated
+ under this Protection Profile.
+
+ 5.2.4 Class ALC: Life-Cycle Support
+
At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of
the TOE vendor’s development and configuration management process in order to provide a baseline level of
assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process
in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a
developer’s practices play in contributing to the overall trustworthiness of a product.
- ALC_CMC.1 Labeling of the TOE
Developer action elements:
Content and presentation elements:
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
+
+ ALC_CMC.1 Labeling of the TOE
+
+
+
+ Developer action elements:
Content and presentation elements:
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. ALC_CMS.1 TOE CM coverage
Developer action elements:
Content and presentation elements:
+ ALC_CMS.1 TOE CM coverage
+
+
+
+
+ Developer action elements:
Content and presentation elements:
The configuration list shall uniquely identify the configuration items. Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
+ ALC_TSU_EXT.1 Timely Security Updates
+
This component requires the TOE developer, in conjunction with any other necessary parties, to provide information
- as to how the VS is updated to address security issues in a timely manner. The
+ as to how the VS is updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a security flaw is
reported/discovered, to the time an update is released. This description includes the parties involved
(e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including
worst case time periods, before an update is made available to the public.
- Developer action elements:
The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE. The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE. Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. 5.2.5 Class ATE: Tests
+ presentation of evidence.
+
+ 5.2.5 Class ATE: Tests
+
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or
implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces
with dependency on the availability of design information. One of the primary outputs of the evaluation process is
the test report as specified in the following requirements.
- ATE_IND.1 Independent Testing - Conformance
+
+ ATE_IND.1 Independent Testing - Conformance
+
Testing is performed to confirm the functionality described in the TSS as well as the administrative (including
configuration and operation) documentation provided. The focus of the testing is to confirm that the
requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs
in Section 5.2. The evaluation activities identify the additional testing activities associated with these
components. The evaluator produces a test report documenting the plan for and results of testing, as well
as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this PP.
- Developer action elements:
Content and presentation elements:
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
+
+ 5.2.6 Class AVA: Vulnerability Assessment
+
For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn
what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will
require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly
@@ -2856,7 +2921,14 @@ Developer action elements:
TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation
provided by the vendor. This information will be used in the development of penetration testing tools and for the
development of future PPs.
- AVA_VAN.1 Vulnerability survey
Developer action elements:
Content and presentation elements:
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
+
+ AVA_VAN.1 Vulnerability survey
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities,
to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack
@@ -2874,6 +2946,8 @@ Developer action elements:
.
+
+
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements:
@@ -2895,7 +2969,7 @@ A.1 Strictly Optional R
list of actions]upon detection of a potential security violation. Application
Note:
In certain cases, it may be useful for Virtualization Systems to perform automated
- responses to certain security events. An example may include halting a VM which has taken some action
+ responses to certain security events. An example may include halting a VM which has taken some action
to violate a key system security policy. This may be especially useful with headless endpoints when
there is no human user in the loop.
The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
@@ -2928,25 +3002,25 @@ A.1 Strictly Optional R
The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment:
- list of Guest VM integrity mechanisms]. Application
+ list of Guest VM integrity mechanisms]. Application
Note:
The primary purpose of this requirement is to identify and describe
the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion,
- though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. Importation for this requirement could include VM migration (live or otherwise), the importation of
+ though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. Importation for this requirement could include VM migration (live or otherwise), the importation of
virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a
- trusted VM could have been modified during the migration or import/export process, or VMs could have
+ trusted VM could have been modified during the migration or import/export process, or VMs could have
been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a
- prudent measure to take. These integrity checks could be as thorough as making sure the entire VM
- exactly matches a previously known VM (by hash for example), or by simply checking certain
- configuration settings to ensure that the VM's configuration will not violate the security model
- of the VS.
+ prudent measure to take. These integrity checks could be as thorough as making sure the entire VM
+ exactly matches a previously known VM (by hash for example), or by simply checking certain
+ configuration settings to ensure that the VM's configuration will not violate the security model
+ of the VS.
A.2 Objective Requirements
A.2.1 Class: Protection of the TSF (FPT)
FPT_DDI_EXT.1 Device Driver Isolation
@@ -2955,14 +3029,14 @@ A.1 Strictly Optional R
- The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains. Application
+ The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains. Application
Note:
- In order to function on physical hardware, the VMM must have access to the device
+ In order to function on physical hardware, the VMM must have access to the device
drivers for the physical platform on which it runs. These drivers are often written by third parties,
- and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality
+ and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality
of third party code that the virtualization vendor has no control over. By encapsulating these drivers
- within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or
- vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains
+ within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or
+ vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains
have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's
Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used
to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
@@ -3012,21 +3086,21 @@ A.1 Strictly Optional R
- The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection. Application
+ The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection. Application
Note:
Introspection can be used to support malware and anomaly detection from outside of
- the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing
- an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt
- to break out of the VM and compromise the VMM or other VMs.
- The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure
+ the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing
+ an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt
+ to break out of the VM and compromise the VMM or other VMs.
+ The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure
the integrity of the malware detection/antivirus software. This capability can be implemented in
- the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained
- and does not introduce bugs into the VMM.
+ the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained
+ and does not introduce bugs into the VMM.
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-GCM-128, AES-GCM-256 (as specified in RFC 4106),[selection: AES-CBC-128 (specified in RFC 3602), AES-CBC-256 (specified in RFC 3602), no other algorithms]] together with a Secure Hash Algorithm (SHA)-based HMAC.
- The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]Application
+ The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]
- The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
+ The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]
- The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, other supported reference identifier types ]] contained in a certificate does not match the expected values for the entity attempting to establish a connection. Application
+ The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, [assignment:
+ other supported reference identifier types ]]] contained in a certificate does not match the expected values for the entity attempting to establish a connection. Application
Note:
The TOE must support at least one of the following identifier types: IP address,
@@ -3268,7 +3345,7 @@ A.1 Strictly Optional R
can be properly applied.
Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE
boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec
- functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
+ functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which
is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is
allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD
@@ -3683,7 +3760,8 @@ A.1 Strictly Optional R
If "" is selected then
"Ability to configure action taken if unable to determine the validity of a certificate" in the Client or Server module
management function table must also be selected.
- The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, other uses ]Application
+ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, [assignment:
+ other uses ]]Application
Note:
This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital
signature mechanism,” if "certificate-based authentication of the remote peer" is
@@ -3878,9 +3956,9 @@ A.1 Strictly Optional R
PP-specified functionality. If the Product Versions are fully tested separately, then there is
no need to document the differences.
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided
- into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
- installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
- into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
+ into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
+ installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
+ into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
metal or on an operating system, both hardware and software equivalence are relevant.
E.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily
on processor architecture and instruction sets.
@@ -3888,13 +3966,13 @@ A.1 Strictly Optional R
not an issue because there is likely to be a different product model for different hardware environments.
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
Factor Same/Different/None Guidance Platform Architectures Different Hardware platforms that implement different processor architectures and instruction sets are not
equivalent. PP-Specified Functionality Same For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -3916,13 +3994,13 @@ A.1 Strictly Optional R
then provide the scheme with sufficient information about the TOE instances and platforms that were evaluated, and the
TOE instances and platforms that are claimed to be equivalent.
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
Bare-Metal VS
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must
describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor
must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates
differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the
- claimed equivalent configuration.
VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
+ claimed equivalent configuration.
VS with OS Support
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified
security functionality and how the TOE functions differently to leverage platform differences in the tested configuration
versus the claimed equivalent configuration. Appendix F - Acronyms
Table 9: Acronyms
@@ -3933,22 +4011,16 @@ A.1 Strictly Optional R
EP Extended Package FP Functional Package OE Operational Environment OS Guest Operating System OS Host Operating System PP Protection Profile PP-Configuration Protection Profile Configuration PP-Module Protection Profile Module SAR Security Assurance Requirement SFR Security Functional Requirement SSP System Security Policy ST Security Target TOE Target of Evaluation TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification VM Virtual Machine VMM Virtual Machine Manager VS Virtualization System
Appendix G - Bibliography
Table 10: Bibliography Identifier Title [CC] Common Criteria for Information Technology Security Evaluation -
- Part
1: Introduction and General Model, CCMB-2017-04-001, Version 3.1 Revision 5,
diff --git a/xml-builder-test/virtualization-release.html b/xml-builder-test/virtualization-release.html
index 5238fca..a702ddf 100644
--- a/xml-builder-test/virtualization-release.html
+++ b/xml-builder-test/virtualization-release.html
@@ -632,7 +632,7 @@
Protection Profile for Virtualization
Version: 1.1
2021-06-14
NIAP
Revision History
Version Date Comment 1.0 2016-11-17 Initial Publication 1.1 2021-06-14 Incorporate TDs, Reference TLS Package, Add Equivalency Guidelines, etc.
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
+
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
A.1.1Class: Security Audit (FAU)A.1.2Class: Protection of the TSF (FPT)A.2Objective Requirements
A.2.1Class: Protection of the TSF (FPT)A.3Implementation-dependent Requirements
Appendix B - Selection-based Requirements
@@ -678,7 +678,7 @@ 1.2.1 Common Criteria Terms
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.2.1 Common Criteria Terms
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.
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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
+ - 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.
- 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
- Package Claims
3 Security Problem Definition
-
3.1 Threats
- - 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
- - 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -759,17 +758,17 @@ 3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
-
Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+ Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
will be configured in a correct and secure manner. OE.NON_MALICIOUS_USER If the organization properly vets and trains users, it is expected that they will be non-malicious. A.PHYSICAL OE.PHYSICAL If the TOE is deployed in a location that has appropriate physical safeguards, it can be assumed
to be physically secure. A.PLATFORM_INTEGRITY OE.PHYSICAL If the underlying platform has not been compromised prior to installation of the TOE, its integrity
can be assumed to be intact. A.TRUSTED_ADMIN OE.TRUSTED_ADMIN Providing guidance to administrators and ensuring that individuals are properly trained and
@@ -823,17 +822,17 @@ 5.1.1 Class: Security Audit (FAU)<
The ST author can include other auditable events directly in Table t-audit-mandatory; they are not
limited to the list presented. The ST author should update the table in
FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a
- user id or an identifier specifying a VM, for example.
+ user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and
Table t-audit-sel-based should be included in the ST if the
associated SFRs and selections are included.
The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach
VMs to virtualized network components. Changes to these configurations can be made
- during VM execution or when VMs are not running. Audit records
+ during VM execution or when VMs are not running. Audit records
must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
- to a physical device (when the device becomes part of the VM's hardware view), not
- to log every time that the device is accessed. Generally, this is only once at VM
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
+ to a physical device (when the device becomes part of the VM's hardware view), not
+ to log every time that the device is accessed. Generally, this is only once at VM
startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB
devices such as CD-ROMs). All such connection/disconnection events must be logged.
@@ -924,8 +923,9 @@ 5.1.1 Class: Security Audit (FAU)<
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel as specified in FTP_ITC_EXT.1.
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
- rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full.Application
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
+ rule for overwriting previous audit records ], [assignment:
+ other action ]]when the local storage space for audit data is full.Application
Note:
An external log server, if available, might be used as alternative storage space
in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the
@@ -984,7 +984,7 @@ 5.1.2 Class: Cryptographic Support
FCS_CKM.1 Cryptographic Key Generation
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[selection: -
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
-
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
+
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
- FFC Schemes using Diffie-Hellman group 14 that meet the following: [RFC 3526]
- FFC Schemes using safe primes that meet the following: [‘NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes"]
]and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
@@ -1342,7 +1342,7 @@ 5.1.2 Class: Cryptographic Support
FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
The TSF shall perform [ cryptographic signature services (generation and verification) ] in accordance with a specified cryptographic algorithm[selection: - RSA schemes using cryptographic key sizes [2048-bit or greater] that meet
- the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
].Application
+ the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5] ].Application
Note:
The ST Author should choose the algorithm implemented to perform digital signatures;
if more than one algorithm is available, this requirement should be iterated to specify the
@@ -1533,36 +1533,36 @@ 5.1.2 Class: Cryptographic Support
The TSF shall provide independent entropy across multiple VMs.Application
Note:
- This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
- need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
- must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
- provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
+ This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
+ need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
+ must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
+ provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
- Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
+ Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
3) pass-through access to a hardware entropy source (including a source of random numbers). In all
- cases, it is possible that the guest is made VM-aware through installation of software or drivers.
- For the second and third cases, it is possible that the guest could be VM-unaware. There is no
- requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
+ cases, it is possible that the guest is made VM-aware through installation of software or drivers.
+ For the second and third cases, it is possible that the guest could be VM-unaware. There is no
+ requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a
- mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
- VM-unaware guest would use.
+ mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
+ VM-unaware guest would use.
The ST author should select “Hypercall interface” if the TSF provides an API function through which
guest-resident software can obtain entropy or random numbers. The ST author should select
- “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
+ “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
which it can obtain entropy or random numbers. Such an interface could present a virtualized real
- device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
- that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
+ device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
+ that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or
random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
- of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
+ of entropy provided to another VM on the same platform.
- 5.2 Security Assurance Requirements
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The
- Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP
- identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the
- documentation applicable for the evaluation and performs independent testing.
- This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information
- Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual
- evaluation activities to be performed are specified in both Section 5.1 as well as in this section.
- After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain
- the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform
- actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained
- within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply
- to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also
- provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
-
- 5.2.1 Class ASE: Security Target Evaluation
+ 5.2 Security Assurance Requirements
+ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+ 5.2.1 Class ASE: Security Target Evaluation
As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.
- 5.2.2 Class ADV: Development
+
+ 5.2.2 Class ADV: Development
+
The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE
Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2
should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.
- ADV_FSP.1 Basic functional specification
Developer action elements:
The developer shall provide a functional specification.The developer shall provide a tracing from the functional specification to the SFRs.Developer
+
+ ADV_FSP.1 Basic functional specification
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide a functional specification.The developer shall provide a tracing from the functional specification to the SFRs.The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering.Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence.The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs.5.2.3 Class AGD: Guidance Documents
+
+
+ 5.2.3 Class AGD: Guidance Documents
+
The guidance documents will be provided with the developer’s security target. Guidance must include a description of
how the authorized user verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by an authorized user.
@@ -2826,22 +2837,33 @@ 5.2.2 Class ADV: DevelopmentSFRs where applicable.
- AGD_OPE.1 Operational User Guidance
Developer action elements:
The developer shall provide operational user guidance.
- Developer
+
+ AGD_OPE.1 Operational User Guidance
+
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide operational user guidance.
+
Note:
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance.Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
+ will provide the necessary information for the preparation of acceptable guidance.Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
privileges that should be controlled in a secure processing environment, including appropriate
- warnings.The operational user guidance shall describe, for each user role the authorized user, how to use the available
- interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for each user role the authorized user, the available functions and
+ warnings.The operational user guidance shall describe, for each user role the authorized user, how to use the available
+ interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for each user role the authorized user, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
- values as appropriate.The operational user guidance shall, for each user role the authorized user, clearly present each type of
+ values as appropriate.The operational user guidance shall, for each user role the authorized user, clearly present each type of
security-relevant event relative to the user-accessible functions that need to be performed,
including changing the security characteristics of entities under the control of the TSF.The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation.The operational user guidance shall, for each user role the authorized user, describe the security measures to be
+ maintaining secure operation.The operational user guidance shall, for each user role the authorized user, describe the security measures to be
followed in order to fulfill the security objectives for the operational environment as described in
the ST.The operational user guidance shall be clear and reasonable.Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.AGD_PRE.1 Preparative procedures
Developer action elements:
The developer shall provide the TOE including its preparative procedures.
- Developer
+ was successful or unsuccessful. This includes generation of the hash/digital signature.
+ AGD_PRE.1 Preparative procedures
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE including its preparative procedures.
+
Note:
As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
@@ -2880,16 +2909,24 @@ 5.2.2 Class ADV: DevelopmentTOE adequately addresses all platforms (that is, combination of hardware and
operating system) claimed for the TOE in the ST.
The operational guidance shall contain step-by-step instructions suitable for use by an end-user of
- the VS to configure a new, out-of-the-box system into the configuration evaluated
+ the VS to configure a new, out-of-the-box system into the configuration evaluated
under this Protection Profile.
- 5.2.4 Class ALC: Life-Cycle Support
+
+
+ 5.2.4 Class ALC: Life-Cycle Support
+
At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of
the TOE vendor’s development and configuration management process in order to provide a baseline level of
assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process
in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a
developer’s practices play in contributing to the overall trustworthiness of a product.
- ALC_CMC.1 Labeling of the TOE
Developer action elements:
The developer shall provide the TOE and a reference for the TOE.
+
+ ALC_CMC.1 Labeling of the TOE
+
+
+
+ Developer action elements:
Content and presentation elements:
The TOE shall be labeled with its unique reference.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
@@ -2899,7 +2936,13 @@ 5.2.2 Class ADV: DevelopmentTOE samples received for testing to ensure
that the version number is consistent with that in the ST.
If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that
- the information in the ST is sufficient to distinguish the product.ALC_CMS.1 TOE CM coverage
Developer action elements:
+ ALC_CMS.1 TOE CM coverage
+
+
+
+
+ Developer action elements:
The developer shall provide a configuration list for the TOE.
Content and presentation elements:
The configuration list shall uniquely identify the configuration items.
@@ -2915,37 +2958,50 @@ 5.2.2 Class ADV: DevelopmentTSF is uniquely identified (with respect to other products from
the TSF vendor), and that documentation provided by the developer in association with the requirements
in the ST is associated with the TSF using this unique identification.
-
ALC_TSU_EXT.1 Timely Security Updates
+
+ ALC_TSU_EXT.1 Timely Security Updates
+
This component requires the TOE developer, in conjunction with any other necessary parties, to provide information
- as to how the VS is updated to address security issues in a timely manner. The
+ as to how the VS is updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a security flaw is
reported/discovered, to the time an update is released. This description includes the parties involved
(e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including
worst case time periods, before an update is made available to the public.
- Developer action elements:
The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
The description shall include the process for creating and deploying security updates for the TOE
software/firmware.The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE.Application
+ of a vulnerability and the public availability of security updates to the TOE.
Note:
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
availability per deployment mechanism may differ; each is described.The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE.Application
+ pertaining to the TOE.
Note:
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
proof-of-concept exploit).Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence.5.2.5 Class ATE: Tests
+ presentation of evidence.
+
+ 5.2.5 Class ATE: Tests
+
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or
implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces
with dependency on the availability of design information. One of the primary outputs of the evaluation process is
the test report as specified in the following requirements.
- ATE_IND.1 Independent Testing - Conformance
+
+ ATE_IND.1 Independent Testing - Conformance
+
Testing is performed to confirm the functionality described in the TSS as well as the administrative (including
configuration and operation) documentation provided. The focus of the testing is to confirm that the
requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs
@@ -2953,7 +3009,12 @@ Developer action elements:
TOE combinations that are claiming conformance to this PP.
- Developer action elements:
The developer shall provide the TOE for testing.
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE for testing.
Content and presentation elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
@@ -2985,7 +3046,10 @@ Developer action elements:
5.2.6 Class AVA: Vulnerability Assessment
+
+
+ 5.2.6 Class AVA: Vulnerability Assessment
+
For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn
what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will
require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly
@@ -2994,7 +3058,14 @@ Developer action elements:
PPs.
- AVA_VAN.1 Vulnerability survey
Developer action elements:
The developer shall provide the TOE for testing.
+
+ AVA_VAN.1 Vulnerability survey
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE for testing.
Content and presentation elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
@@ -3014,6 +3085,8 @@ Developer action elements:
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
@@ -3038,7 +3111,7 @@ A.1 Strictly Optional R
list of actions]upon detection of a potential security violation.Application
Note:
In certain cases, it may be useful for Virtualization Systems to perform automated
- responses to certain security events. An example may include halting a VM which has taken some action
+ responses to certain security events. An example may include halting a VM which has taken some action
to violate a key system security policy. This may be especially useful with headless endpoints when
there is no human user in the loop.
The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
@@ -3073,26 +3146,26 @@ A.1 Strictly Optional R
The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment:
- list of Guest VM integrity mechanisms].Application
+ list of Guest VM integrity mechanisms].Application
Note:
The primary purpose of this requirement is to identify and describe
the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion,
though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used.
- Importation for this requirement could include VM migration (live or otherwise), the importation of
+ Importation for this requirement could include VM migration (live or otherwise), the importation of
virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a
- trusted VM could have been modified during the migration or import/export process, or VMs could have
+ trusted VM could have been modified during the migration or import/export process, or VMs could have
been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a
- prudent measure to take. These integrity checks could be as thorough as making sure the entire VM
- exactly matches a previously known VM (by hash for example), or by simply checking certain
- configuration settings to ensure that the VM's configuration will not violate the security model
- of the VS.
+ prudent measure to take. These integrity checks could be as thorough as making sure the entire VM
+ exactly matches a previously known VM (by hash for example), or by simply checking certain
+ configuration settings to ensure that the VM's configuration will not violate the security model
+ of the VS.
A.2 Objective Requirements
A.2.1 Class: Protection of the TSF (FPT)
FPT_DDI_EXT.1 Device Driver Isolation
@@ -3101,14 +3174,14 @@ A.1 Strictly Optional R
- The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.Application
+ The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.Application
Note:
- In order to function on physical hardware, the VMM must have access to the device
+ In order to function on physical hardware, the VMM must have access to the device
drivers for the physical platform on which it runs. These drivers are often written by third parties,
- and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality
+ and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality
of third party code that the virtualization vendor has no control over. By encapsulating these drivers
- within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or
- vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains
+ within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or
+ vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains
have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's
Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used
to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
@@ -3158,21 +3231,21 @@ A.1 Strictly Optional R
- The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.Application
+ The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.Application
Note:
Introspection can be used to support malware and anomaly detection from outside of
- the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing
- an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt
- to break out of the VM and compromise the VMM or other VMs.
- The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure
+ the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing
+ an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt
+ to break out of the VM and compromise the VMM or other VMs.
+ The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure
the integrity of the malware detection/antivirus software. This capability can be implemented in
- the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained
- and does not introduce bugs into the VMM.
+ the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained
+ and does not introduce bugs into the VMM.
The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it.
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-GCM-128, AES-GCM-256 (as specified in RFC 4106),[selection: AES-CBC-128 (specified in RFC 3602), AES-CBC-256 (specified in RFC 3602), no other algorithms]] together with a Secure Hash Algorithm (SHA)-based HMAC.
- The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]Application
+ The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]
The TSF shall ensure the encrypted payload in the[selection: IKEv1, IKEv2]protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and[selection: AES-GCM-128 as specified in RFC 5282, AES-GCM-256 as specified in RFC 5282, no other algorithm].
- The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
+ The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
Note:
The ST author is afforded a selection based on the version of IKE in their
@@ -3365,7 +3440,8 @@ A.1 Strictly Optional R
If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1
must be claimed.
- The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, other supported reference identifier types ]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.Application
+ The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, [assignment:
+ other supported reference identifier types ]]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.Application
Note:
The TOE must support at least one of the following identifier types: IP address,
@@ -3428,7 +3504,7 @@ A.1 Strictly Optional R
can be properly applied.
Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE
boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec
- functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
+ functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which
is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is
allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD
@@ -3856,7 +3932,8 @@ A.1 Strictly Optional R
If "" is selected then
"Ability to configure action taken if unable to determine the validity of a certificate" in the Client or Server module
management function table must also be selected.
- The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, other uses ]Application
+ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, [assignment:
+ other uses ]]Application
Note:
This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital
signature mechanism,” if "certificate-based authentication of the remote peer" is
@@ -4080,9 +4157,9 @@ E.3 Specific Guidance for
PP-specified functionality. If the Product Versions are fully tested separately, then there is
no need to document the differences.
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided
- into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
- installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
- into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
+ into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
+ installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
+ into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
metal or on an operating system, both hardware and software equivalence are relevant.
E.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily
@@ -4093,15 +4170,15 @@ E.3 Specific Guidance for
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
Factor Same/Different/None Guidance Platform Architectures Different Hardware platforms that implement different processor architectures and instruction sets are not
equivalent. PP-Specified Functionality Same For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -4127,15 +4204,15 @@ E.3 Specific Guidance for
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
-
Bare-Metal VS
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
+
Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must
describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor
must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates
differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the
claimed equivalent configuration.
-
VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
+
VS with OS Support
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified
security functionality and how the TOE functions differently to leverage platform differences in the tested configuration
versus the claimed equivalent configuration.
@@ -4147,22 +4224,16 @@ Appendix F - Acronyms
EP Extended Package
FP Functional Package OE Operational Environment OS Guest Operating System OS Host Operating System PP Protection Profile PP-Configuration Protection Profile Configuration PP-Module Protection Profile Module SAR Security Assurance Requirement SFR Security Functional Requirement SSP System Security Policy ST Security Target TOE Target of Evaluation TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification VM Virtual Machine VMM Virtual Machine Manager VS Virtualization System
Appendix G - Bibliography
Table 10: Bibliography Identifier Title [CC] Common Criteria for Information Technology Security Evaluation -
- Part
1: Introduction and General Model, CCMB-2017-04-001, Version 3.1 Revision 5,
diff --git a/xml-builder-test/virtualization.html b/xml-builder-test/virtualization.html
index 60e5980..da3be0d 100644
--- a/xml-builder-test/virtualization.html
+++ b/xml-builder-test/virtualization.html
@@ -632,7 +632,7 @@
Protection Profile for Virtualization
Version: 1.1
2021-06-14
NIAP
Revision History
Version Date Comment 1.0 2016-11-17 Initial Publication 1.1 2021-06-14 Incorporate TDs, Reference TLS Package, Add Equivalency Guidelines, etc.
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Implementation-dependent RequirementsAppendix B - Implicitly Satisfied RequirementsAppendix C - Entropy Documentation and AssessmentC.1Design DescriptionC.2Entropy JustificationC.3Operating ConditionsC.4Health TestingAppendix D - Equivalency GuidelinesD.1IntroductionD.2Approach to Equivalency AnalysisD.3Specific Guidance for Determining Product Model EquivalenceD.4Specific Guidance for Determining Product Version EquivalenceD.5Specific Guidance for Determining Platform EquivalenceD.5.1Hardware Platform EquivalenceD.5.2Software Platform EquivalenceD.6Level of Specificity for Tested and Claimed Equivalent ConfigurationsAppendix E - AcronymsAppendix F - Bibliography1 Introduction
+
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Implementation-dependent RequirementsAppendix B - Implicitly Satisfied RequirementsAppendix C - Entropy Documentation and AssessmentC.1Design DescriptionC.2Entropy JustificationC.3Operating ConditionsC.4Health TestingAppendix D - Equivalency GuidelinesD.1IntroductionD.2Approach to Equivalency AnalysisD.3Specific Guidance for Determining Product Model EquivalenceD.4Specific Guidance for Determining Product Version EquivalenceD.5Specific Guidance for Determining Platform EquivalenceD.5.1Hardware Platform EquivalenceD.5.2Software Platform EquivalenceD.6Level of Specificity for Tested and Claimed Equivalent ConfigurationsAppendix E - AcronymsAppendix F - Bibliography1 Introduction
1.1 Compliant Targets of Evaluation
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
@@ -674,7 +674,7 @@ 1.2.1 Common Criteria Terms
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.2.1 Common Criteria Terms
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.
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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
+ - 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.
- 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
- Package Claims
3 Security Problem Definition
-
3.1 Threats
- - 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
- - 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -755,17 +754,17 @@ 3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
-
Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+ Table 1: Security Objectives Rationale Threat, Assumption, or OSP Security Objectives Rationale T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. A.NON_MALICIOUS_USER OE.CONFIG If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
will be configured in a correct and secure manner. OE.NON_MALICIOUS_USER If the organization properly vets and trains users, it is expected that they will be non-malicious. A.PHYSICAL OE.PHYSICAL If the TOE is deployed in a location that has appropriate physical safeguards, it can be assumed
to be physically secure. A.PLATFORM_INTEGRITY OE.PHYSICAL If the underlying platform has not been compromised prior to installation of the TOE, its integrity
can be assumed to be intact. A.TRUSTED_ADMIN OE.TRUSTED_ADMIN Providing guidance to administrators and ensuring that individuals are properly trained and
@@ -805,7 +804,7 @@ 5.1.1 Class: Security Audit (FAU)<
list of actions]upon detection of a potential security violation.Application
Note:
In certain cases, it may be useful for Virtualization Systems to perform automated
- responses to certain security events. An example may include halting a VM which has taken some action
+ responses to certain security events. An example may include halting a VM which has taken some action
to violate a key system security policy. This may be especially useful with headless endpoints when
there is no human user in the loop.
The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
@@ -836,17 +835,17 @@ 5.1.1 Class: Security Audit (FAU)<
The ST author can include other auditable events directly in Table t-audit-mandatory; they are not
limited to the list presented. The ST author should update the table in
FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a
- user id or an identifier specifying a VM, for example.
+ user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and
Table t-audit-sel-based should be included in the ST if the
associated SFRs and selections are included.
The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach
VMs to virtualized network components. Changes to these configurations can be made
- during VM execution or when VMs are not running. Audit records
+ during VM execution or when VMs are not running. Audit records
must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
- to a physical device (when the device becomes part of the VM's hardware view), not
- to log every time that the device is accessed. Generally, this is only once at VM
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected
+ to a physical device (when the device becomes part of the VM's hardware view), not
+ to log every time that the device is accessed. Generally, this is only once at VM
startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB
devices such as CD-ROMs). All such connection/disconnection events must be logged.
@@ -953,8 +952,9 @@ 5.1.1 Class: Security Audit (FAU)<
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel as specified in FTP_ITC_EXT.1.
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
- rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full.Application
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment:
+ rule for overwriting previous audit records ], [assignment:
+ other action ]]when the local storage space for audit data is full.Application
Note:
An external log server, if available, might be used as alternative storage space
in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the
@@ -1013,7 +1013,7 @@ 5.1.2 Class: Cryptographic Support
FCS_CKM.1 Cryptographic Key Generation
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[selection: -
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
-
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
+
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
-
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
- FFC Schemes using Diffie-Hellman group 14 that meet the following: [RFC 3526]
- FFC Schemes using safe primes that meet the following: [‘NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes"]
]and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
@@ -1371,7 +1371,7 @@ 5.1.2 Class: Cryptographic Support
FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
The TSF shall perform [ cryptographic signature services (generation and verification) ] in accordance with a specified cryptographic algorithm[selection: - RSA schemes using cryptographic key sizes [2048-bit or greater] that meet
- the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
].Application
+ the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5] ].Application
Note:
The ST Author should choose the algorithm implemented to perform digital signatures;
if more than one algorithm is available, this requirement should be iterated to specify the
@@ -1562,36 +1562,36 @@ 5.1.2 Class: Cryptographic Support
The TSF shall provide independent entropy across multiple VMs.Application
Note:
- This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
- need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
- must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
- provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
+ This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy
+ need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM
+ must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can
+ provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide
pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
- Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a
+ Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or
3) pass-through access to a hardware entropy source (including a source of random numbers). In all
- cases, it is possible that the guest is made VM-aware through installation of software or drivers.
- For the second and third cases, it is possible that the guest could be VM-unaware. There is no
- requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
+ cases, it is possible that the guest is made VM-aware through installation of software or drivers.
+ For the second and third cases, it is possible that the guest could be VM-unaware. There is no
+ requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE
does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a
- mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
- VM-unaware guest would use.
+ mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a
+ VM-unaware guest would use.
The ST author should select “Hypercall interface” if the TSF provides an API function through which
guest-resident software can obtain entropy or random numbers. The ST author should select
- “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
+ “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through
which it can obtain entropy or random numbers. Such an interface could present a virtualized real
- device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
- that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
+ device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device
+ that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to
hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or
random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
- of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality
+ of entropy provided to another VM on the same platform.
The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it.
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-GCM-128, AES-GCM-256 (as specified in RFC 4106),[selection: AES-CBC-128 (specified in RFC 3602), AES-CBC-256 (specified in RFC 3602), no other algorithms]] together with a Secure Hash Algorithm (SHA)-based HMAC.
- The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]Application
+ The TSF shall implement the protocol: [selection: - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
]
The TSF shall ensure the encrypted payload in the[selection: IKEv1, IKEv2]protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and[selection: AES-GCM-128 as specified in RFC 5282, AES-GCM-256 as specified in RFC 5282, no other algorithm].
- The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
+ The TSF shall ensure that[selection: - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
]Application
Note:
The ST author is afforded a selection based on the version of IKE in their
@@ -1747,7 +1747,8 @@ 5.1.2 Class: Cryptographic Support
If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1
must be claimed.
- The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, other supported reference identifier types ]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.Application
+ The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, [assignment:
+ other supported reference identifier types ]]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.Application
Note:
The TOE must support at least one of the following identifier types: IP address,
@@ -1810,7 +1811,7 @@ 5.1.2 Class: Cryptographic Support
can be properly applied.
Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE
boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec
- functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
+ functionality implemented totally or in part by the underlying OS platform. The behavior referenced here
is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which
is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is
allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD
@@ -2195,11 +2196,13 @@ 5.1.3 Class: User Data Protection
- The TSF shall use[selection: no mechanism, list of platform-provided, hardware-based mechanisms ]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, physical devices to which the VMM allows Guest VMs physical access ].Application
+ The TSF shall use[selection: no mechanism, [assignment:
+ list of platform-provided, hardware-based mechanisms ]]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, [assignment:
+ physical devices to which the VMM allows Guest VMs physical access ]].Application
Note:
The TSF must use available hardware-based isolation mechanisms to constrain VMs
when VMs have direct access to physical devices. “Direct access” in this context means that the
- VM can read or write device memory or access device I/O ports without the VMM being able to intercept
+ VM can read or write device memory or access device I/O ports without the VMM being able to intercept
and validate every transaction.
- 5.2 Security Assurance Requirements
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The
- Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP
- identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the
- documentation applicable for the evaluation and performs independent testing.
- This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information
- Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual
- evaluation activities to be performed are specified in both Section 5.1 as well as in this section.
- After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain
- the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform
- actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained
- within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply
- to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also
- provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
-
- 5.2.1 Class ASE: Security Target Evaluation
+ 5.2 Security Assurance Requirements
+ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+ 5.2.1 Class ASE: Security Target Evaluation
As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.
- 5.2.2 Class ADV: Development
+
+ 5.2.2 Class ADV: Development
+
The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE
Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2
should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.
- ADV_FSP.1 Basic functional specification
Developer action elements:
The developer shall provide a functional specification.The developer shall provide a tracing from the functional specification to the SFRs.Developer
+
+ ADV_FSP.1 Basic functional specification
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide a functional specification.The developer shall provide a tracing from the functional specification to the SFRs.The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering.Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence.The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs.5.2.3 Class AGD: Guidance Documents
+
+
+ 5.2.3 Class AGD: Guidance Documents
+
The guidance documents will be provided with the developer’s security target. Guidance must include a description of
how the authorized user verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by an authorized user.
@@ -3709,22 +3724,33 @@ 5.2.2 Class ADV: DevelopmentSFRs where applicable.
- AGD_OPE.1 Operational User Guidance
Developer action elements:
The developer shall provide operational user guidance.
- Developer
+
+ AGD_OPE.1 Operational User Guidance
+
+
+
+
+
+
+
+
+
+ Developer action elements:
The developer shall provide operational user guidance.
+
Note:
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance.Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
+ will provide the necessary information for the preparation of acceptable guidance.Content and presentation elements:
The operational user guidance shall describe what for each user role the authorized user-accessible functions and
privileges that should be controlled in a secure processing environment, including appropriate
- warnings.The operational user guidance shall describe, for each user role the authorized user, how to use the available
- interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for each user role the authorized user, the available functions and
+ warnings.The operational user guidance shall describe, for each user role the authorized user, how to use the available
+ interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for each user role the authorized user, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
- values as appropriate.The operational user guidance shall, for each user role the authorized user, clearly present each type of
+ values as appropriate.The operational user guidance shall, for each user role the authorized user, clearly present each type of
security-relevant event relative to the user-accessible functions that need to be performed,
including changing the security characteristics of entities under the control of the TSF.The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation.The operational user guidance shall, for each user role the authorized user, describe the security measures to be
+ maintaining secure operation.The operational user guidance shall, for each user role the authorized user, describe the security measures to be
followed in order to fulfill the security objectives for the operational environment as described in
the ST.The operational user guidance shall be clear and reasonable.Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.AGD_PRE.1 Preparative procedures
Developer action elements:
The developer shall provide the TOE including its preparative procedures.
- Developer
+ was successful or unsuccessful. This includes generation of the hash/digital signature.
+ AGD_PRE.1 Preparative procedures
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE including its preparative procedures.
+
Note:
As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
@@ -3763,16 +3796,24 @@ 5.2.2 Class ADV: DevelopmentTOE adequately addresses all platforms (that is, combination of hardware and
operating system) claimed for the TOE in the ST.
The operational guidance shall contain step-by-step instructions suitable for use by an end-user of
- the VS to configure a new, out-of-the-box system into the configuration evaluated
+ the VS to configure a new, out-of-the-box system into the configuration evaluated
under this Protection Profile.
- 5.2.4 Class ALC: Life-Cycle Support
+
+
+ 5.2.4 Class ALC: Life-Cycle Support
+
At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of
the TOE vendor’s development and configuration management process in order to provide a baseline level of
assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process
in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a
developer’s practices play in contributing to the overall trustworthiness of a product.
- ALC_CMC.1 Labeling of the TOE
Developer action elements:
The developer shall provide the TOE and a reference for the TOE.
+
+ ALC_CMC.1 Labeling of the TOE
+
+
+
+ Developer action elements:
Content and presentation elements:
The TOE shall be labeled with its unique reference.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
@@ -3782,7 +3823,13 @@ 5.2.2 Class ADV: DevelopmentTOE samples received for testing to ensure
that the version number is consistent with that in the ST.
If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that
- the information in the ST is sufficient to distinguish the product.ALC_CMS.1 TOE CM coverage
Developer action elements:
+ ALC_CMS.1 TOE CM coverage
+
+
+
+
+ Developer action elements:
The developer shall provide a configuration list for the TOE.
Content and presentation elements:
The configuration list shall uniquely identify the configuration items.
@@ -3798,37 +3845,50 @@ 5.2.2 Class ADV: DevelopmentTSF is uniquely identified (with respect to other products from
the TSF vendor), and that documentation provided by the developer in association with the requirements
in the ST is associated with the TSF using this unique identification.
-
ALC_TSU_EXT.1 Timely Security Updates
+
+ ALC_TSU_EXT.1 Timely Security Updates
+
This component requires the TOE developer, in conjunction with any other necessary parties, to provide information
- as to how the VS is updated to address security issues in a timely manner. The
+ as to how the VS is updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a security flaw is
reported/discovered, to the time an update is released. This description includes the parties involved
(e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including
worst case time periods, before an update is made available to the public.
- Developer action elements:
The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:
Content and presentation elements:
The description shall include the process for creating and deploying security updates for the TOE
software/firmware.The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE.Application
+ of a vulnerability and the public availability of security updates to the TOE.
Note:
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
availability per deployment mechanism may differ; each is described.The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE.Application
+ pertaining to the TOE.
Note:
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
proof-of-concept exploit).Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence.5.2.5 Class ATE: Tests
+ presentation of evidence.
+
+ 5.2.5 Class ATE: Tests
+
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or
implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces
with dependency on the availability of design information. One of the primary outputs of the evaluation process is
the test report as specified in the following requirements.
- ATE_IND.1 Independent Testing - Conformance
+
+ ATE_IND.1 Independent Testing - Conformance
+
Testing is performed to confirm the functionality described in the TSS as well as the administrative (including
configuration and operation) documentation provided. The focus of the testing is to confirm that the
requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs
@@ -3836,7 +3896,12 @@ Developer action elements:
TOE combinations that are claiming conformance to this PP.
- Developer action elements:
The developer shall provide the TOE for testing.
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE for testing.
Content and presentation elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
@@ -3868,7 +3933,10 @@ Developer action elements:
5.2.6 Class AVA: Vulnerability Assessment
+
+
+ 5.2.6 Class AVA: Vulnerability Assessment
+
For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn
what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will
require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly
@@ -3877,7 +3945,14 @@ Developer action elements:
PPs.
- AVA_VAN.1 Vulnerability survey
Developer action elements:
The developer shall provide the TOE for testing.
+
+ AVA_VAN.1 Vulnerability survey
+
+
+
+
+
+ Developer action elements:
The developer shall provide the TOE for testing.
Content and presentation elements:
The TOE shall be suitable for testing.
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
@@ -3897,6 +3972,8 @@ Developer action elements:
Appendix A - Implementation-dependent Requirements
Implementation-dependent Requirements
Appendix defines requirements that must be claimed in the ST
@@ -4053,9 +4130,9 @@ D.3 Specific Guidance for
PP-specified functionality. If the Product Versions are fully tested separately, then there is
no need to document the differences.
D.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided
- into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
- installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
- into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
+ into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is
+ installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated
+ into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare
metal or on an operating system, both hardware and software equivalence are relevant.
D.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily
@@ -4066,15 +4143,15 @@ D.3 Specific Guidance for
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
Factor Same/Different/None Guidance Platform Architectures Different Hardware platforms that implement different processor architectures and instruction sets are not
equivalent. PP-Specified Functionality Same For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -4100,15 +4177,15 @@ D.3 Specific Guidance for
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
-
Bare-Metal VS
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
+
Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must
describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor
must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates
differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the
claimed equivalent configuration.
-
VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
+
VS with OS Support
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to
its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified
security functionality and how the TOE functions differently to leverage platform differences in the tested configuration
versus the claimed equivalent configuration.
@@ -4120,22 +4197,16 @@ Appendix E - Acronyms
EP Extended Package
FP Functional Package OE Operational Environment OS Guest Operating System OS Host Operating System PP Protection Profile PP-Configuration Protection Profile Configuration PP-Module Protection Profile Module SAR Security Assurance Requirement SFR Security Functional Requirement SSP System Security Policy ST Security Target TOE Target of Evaluation TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification VM Virtual Machine VMM Virtual Machine Manager VS Virtualization System
Appendix F - Bibliography
Table 10: Bibliography Identifier Title [CC] Common Criteria for Information Technology Security Evaluation -
- Part
1: Introduction and General Model, CCMB-2017-04-001, Version 3.1 Revision 5,
3.2 Assumptions
4.1 Se
4.1 Se
4.1 Se
4.3 Security Objectives Rationale<
Threat, Assumption, or OSP Security Objectives Rationale
- T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE.
+ T.3P_SOFTWARE O.VMM_INTEGRITY The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE.
- T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
+ T.DATA_LEAKAGE O.DOMAIN_INTEGRITY Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
- O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
+ O.VM_ISOLATION Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another.
T.DENIAL_OF_SERVICE O.RESOURCE_ALLOCATION The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult.
@@ -480,16 +479,16 @@ 4.3 Security Objectives Rationale<
T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations.
- T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running.
+ T.PLATFORM_COMPROMISE O.PLATFORM_INTEGRITY Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running.
T.UNAUTHORIZED_ACCESS O.MANAGEMENT_ACCESS Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner.
- T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
+ T.UNAUTHORIZED_MODIFICATION O.AUDIT Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
- O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
+ O.VMM_INTEGRITY Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected.
T.UNAUTHORIZED_UPDATE O.VMM_INTEGRITY System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code.
@@ -498,13 +497,13 @@ 4.3 Security Objectives Rationale<
T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available.
- T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another.
+ T.USER_ERROR O.VM_ISOLATION Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another.
- T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
+ T.VMM_COMPROMISE O.VMM_INTEGRITY Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
- O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
+ O.VM_ISOLATION Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed.
T.WEAK_CRYPTO O.VM_ENTROPY Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms.
@@ -584,13 +583,13 @@ FAU_GEN.1 Audit Data Generation
- Application Note: The ST author can include other auditable events directly in Table t-audit-mandatory; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.
+ Application Note: The ST author can include other auditable events directly in Table t-audit-mandatory; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and Table t-audit-sel-based should be included in the ST if the associated SFRs and selections are included.
- The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.
+ The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM's hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM's hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
The following table contains the events enumerated in the auditable events table for the TLS Functional Package. Inclusion of these events in the ST is subject to selection above, inclusion of the corresponding SFRs in the ST, and support in the FP as represented by a selection in the table below.
@@ -753,7 +752,7 @@ FAU_STG_EXT.1 Off-Loading of Audit Data
FAU_STG_EXT.1.2
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full.
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records ], [assignment: other action ]]when the local storage space for audit data is full.
Application Note: An external log server, if available, might be used as alternative storage space in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the new audit data to an external IT entity’.
@@ -820,7 +819,7 @@ FCS_CKM.1 Cryptographic Key Generation
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
+ ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
@@ -1264,7 +1263,7 @@ FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
+ ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
].
@@ -1428,13 +1427,13 @@ FCS_ENT_EXT.1 Entropy for Virtual Machines
The TSF shall provide independent entropy across multiple VMs.
- Application Note: This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide pass-through access to entropy sources provided by the host platform.
+ Application Note: This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or 3) pass-through access to a hardware entropy source (including a source of random numbers). In all cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a VM-unaware guest would use.
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or 3) pass-through access to a hardware entropy source (including a source of random numbers). In all cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a VM-unaware guest would use.
- The ST author should select “Hypercall interface” if the TSF provides an API function through which guest-resident software can obtain entropy or random numbers. The ST author should select “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through which it can obtain entropy or random numbers. Such an interface could present a virtualized real device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or random number source on the platform. The ST author should select all items that are appropriate.
+ The ST author should select “Hypercall interface” if the TSF provides an API function through which guest-resident software can obtain entropy or random numbers. The ST author should select “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through which it can obtain entropy or random numbers. Such an interface could present a virtualized real device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality of entropy provided to another VM on the same platform.
@@ -1450,7 +1449,7 @@ FCS_ENT_EXT.1 Entropy for Virtual Machines
TSS
- The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and how to access the interface to acquire entropy or random numbers. The evaluator shall verify that the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by another.
+ The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and how to access the interface to acquire entropy or random numbers. The evaluator shall verify that the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by another.
Tests
@@ -1458,10 +1457,10 @@ FCS_ENT_EXT.1 Entropy for Virtual Machines
The evaluator shall perform the following tests:
-
- Test FCS_ENT_EXT.1.2:1: The evaluator shall invoke entropy from each Guest VM. The evaluator shall verify that each VM acquires values from the interface.
+ Test FCS_ENT_EXT.1.2:1: The evaluator shall invoke entropy from each Guest VM. The evaluator shall verify that each VM acquires values from the interface.
-
- Test FCS_ENT_EXT.1.2:2: The evaluator shall invoke entropy from multiple VMs as nearly simultaneously as practicable. The evaluator shall verify that the entropy used in one VM is not identical to that invoked from the other VMs.
+ Test FCS_ENT_EXT.1.2:2: The evaluator shall invoke entropy from multiple VMs as nearly simultaneously as practicable. The evaluator shall verify that the entropy used in one VM is not identical to that invoked from the other VMs.
@@ -1530,9 +1529,9 @@ FDP_HBI_EXT.1 Hardware-Based Isolation Mechanisms
FDP_HBI_EXT.1.1
- The TSF shall use[selection: no mechanism, list of platform-provided, hardware-based mechanisms ]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, physical devices to which the VMM allows Guest VMs physical access ].
+ The TSF shall use[selection: no mechanism, [assignment: list of platform-provided, hardware-based mechanisms ]]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, [assignment: physical devices to which the VMM allows Guest VMs physical access ]].
- Application Note: The TSF must use available hardware-based isolation mechanisms to constrain VMs when VMs have direct access to physical devices. “Direct access” in this context means that the VM can read or write device memory or access device I/O ports without the VMM being able to intercept and validate every transaction.
+ Application Note: The TSF must use available hardware-based isolation mechanisms to constrain VMs when VMs have direct access to physical devices. “Direct access” in this context means that the VM can read or write device memory or access device I/O ports without the VMM being able to intercept and validate every transaction.
@@ -1562,7 +1561,7 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.1
- The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:[assignment: list of physical platform resources the VMM isable to control access to].
+ The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:[assignment: list of physical platform resources the VMM isable to control access to].
@@ -1570,7 +1569,7 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.2
- The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, list of physical platform resources to which access is explicitly denied ].
+ The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, [assignment: list of physical platform resources to which access is explicitly denied ]].
@@ -1578,21 +1577,15 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.3
- The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, list of physical platform resources to which access is always allowed ].
+ The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, [assignment: list of physical platform resources to which access is always allowed ]].
Application Note: For purposes of this requirement, physical platform resources are divided into three categories:
- -
- those to which Guest OS access is configurable and moderated by the VMM
-
- -
- those to which the Guest OS is never allowed to have direct access, and
-
- -
- those to which the Guest OS is always allowed to have direct access.
-
+ - those to which Guest OS access is configurable and moderated by the VMM
+ - those to which the Guest OS is never allowed to have direct access, and
+ - those to which the Guest OS is always allowed to have direct access.
- For element 1, the ST author lists the physical platform resources that can be configured for Guest VM access by an administrator. For element 2, the ST author lists the physical platform resources to which Guest VMs may never be allowed direct access. If there are no such resources, the ST author selects "no physical platform resources." Likewise, any resources to which all Guest VMs automatically have access to are to be listed in the third element. If there are no such resources, then "no physical platform resources" is selected.
+ For element 1, the ST author lists the physical platform resources that can be configured for Guest VM access by an administrator. For element 2, the ST author lists the physical platform resources to which Guest VMs may never be allowed direct access. If there are no such resources, the ST author selects "no physical platform resources." Likewise, any resources to which all Guest VMs automatically have access to are to be listed in the third element. If there are no such resources, then "no physical platform resources" is selected.
@@ -1608,11 +1601,11 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
TSS
- The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to physical platform resources. This description shall cover all of the physical platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and how each physical platform resource that is controllable (that is, listed in the assignment statement in the first element) is identified to an Administrator.
+ The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to physical platform resources. This description shall cover all of the physical platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and how each physical platform resource that is controllable (that is, listed in the assignment statement in the first element) is identified to an Administrator.
- The evaluator shall ensure that the TSS describes how the Guest VM is associated with each physical resource, and how other Guest VMs cannot access a physical resource without being granted explicit access. For TOEs that implement a robust interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the TSS describes the possible operations or modes of access between a Guest VM's and physical platform resources.
+ The evaluator shall ensure that the TSS describes how the Guest VM is associated with each physical resource, and how other Guest VMs cannot access a physical resource without being granted explicit access. For TOEs that implement a robust interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the TSS describes the possible operations or modes of access between a Guest VM's and physical platform resources.
- If physical resources are listed in the second element, the evaluator shall examine the TSS and operational guidance to determine that there appears to be no way to configure those resources for access by a Guest VM. The evaluator shall document in the evaluation report their analysis of why the controls offered to configure access to physical resources can't be used to specify access to the resources identified in the second element (for example, if the interface offers a drop-down list of resources to assign, and the denied resources are not included on that list, that would be sufficient justification in the evaluation report).
+ If physical resources are listed in the second element, the evaluator shall examine the TSS and operational guidance to determine that there appears to be no way to configure those resources for access by a Guest VM. The evaluator shall document in the evaluation report their analysis of why the controls offered to configure access to physical resources can't be used to specify access to the resources identified in the second element (for example, if the interface offers a drop-down list of resources to assign, and the denied resources are not included on that list, that would be sufficient justification in the evaluation report).
Guidance
@@ -1623,19 +1616,19 @@ FDP_PPR_EXT.1 Physical Platform Resource Controls
-
- Test FDP_PPR_EXT.1.3:1: For each physical platform resource identified in the first element, the evaluator shall configure a Guest VM to have access to that resource and show that the Guest VM is able to successfully access that resource.
+ Test FDP_PPR_EXT.1.3:1: For each physical platform resource identified in the first element, the evaluator shall configure a Guest VM to have access to that resource and show that the Guest VM is able to successfully access that resource.
-
- Test FDP_PPR_EXT.1.3:2: For each physical platform resource identified in the first element, the evaluator shall configure the system such that a Guest VM does not have access to that resource and show that the Guest VM is unable to successfully access that resource.
+ Test FDP_PPR_EXT.1.3:2: For each physical platform resource identified in the first element, the evaluator shall configure the system such that a Guest VM does not have access to that resource and show that the Guest VM is unable to successfully access that resource.
-
Test FDP_PPR_EXT.1.3:3: [conditional]: For TOEs that have a robust control interface, the evaluator shall exercise each element of the interface as described in the TSS and the operational guidance to ensure that the behavior described in the operational guidance is exhibited.
-
- Test FDP_PPR_EXT.1.3:4: [conditional]: If the TOE explicitly denies access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource from a Guest VM and observe that access is denied.
+ Test FDP_PPR_EXT.1.3:4: [conditional]: If the TOE explicitly denies access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource from a Guest VM and observe that access is denied.
-
- Test FDP_PPR_EXT.1.3:5: [conditional]: If the TOE explicitly allows access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource from a Guest VM and observe that the access is allowed. If the operational guidance specifies that access is allowed simultaneously by more than one Guest VM, the evaluator shall attempt to access each resource listed from more than one Guest VM and show that access is allowed.
+ Test FDP_PPR_EXT.1.3:5: [conditional]: If the TOE explicitly allows access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource from a Guest VM and observe that the access is allowed. If the operational guidance specifies that access is allowed simultaneously by more than one Guest VM, the evaluator shall attempt to access each resource listed from more than one Guest VM and show that access is allowed.
@@ -1650,15 +1643,15 @@ FDP_RIP_EXT.1 Residual Information in Memory
FDP_RIP_EXT.1.1
- The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM.
+ The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM.
- Application Note: Physical memory must be zeroed before it is made accessible to a VM for general use by a Guest OS.
+ Application Note: Physical memory must be zeroed before it is made accessible to a VM for general use by a Guest OS.
- The purpose of this requirement is to ensure that a VM does not receive memory containing data previously used by another VM or the host.
+ The purpose of this requirement is to ensure that a VM does not receive memory containing data previously used by another VM or the host.
- “For general use” means for use by the Guest OS in its page tables for running applications or system software.
+ “For general use” means for use by the Guest OS in its page tables for running applications or system software.
- This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such as read-only OS pages or pages used for virtual device buffers.
+ This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such as read-only OS pages or pages used for virtual device buffers.
@@ -1674,7 +1667,7 @@ FDP_RIP_EXT.1 Residual Information in Memory
TSS
- The evaluator shall ensure that the TSS documents the process used for clearing physical memory prior to allocation to a Guest VM, providing details on when and how this is performed. Additionally, the evaluator shall ensure that the TSS documents the conditions under which physical memory is not cleared prior to allocation to a Guest VM, and describes when and how the memory is cleared.
+ The evaluator shall ensure that the TSS documents the process used for clearing physical memory prior to allocation to a Guest VM, providing details on when and how this is performed. Additionally, the evaluator shall ensure that the TSS documents the conditions under which physical memory is not cleared prior to allocation to a Guest VM, and describes when and how the memory is cleared.
@@ -1686,9 +1679,9 @@ FDP_RIP_EXT.2 Residual Information on Disk
FDP_RIP_EXT.2.1
- The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM.
+ The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM.
- Application Note: The purpose of this requirement is to ensure that a VM does not receive disk storage containing data previously used by another VM or by the host.
+ Application Note: The purpose of this requirement is to ensure that a VM does not receive disk storage containing data previously used by another VM or by the host.
Clearing of disk storage only upon deallocation does not meet this requirement.
@@ -1708,14 +1701,14 @@ FDP_RIP_EXT.2 Residual Information on Disk
TSS
- The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. Any file system format and metadata information needed by the evaluator to perform the below test shall be made available to the evaluator, but need not be published in the TSS.
+ The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. Any file system format and metadata information needed by the evaluator to perform the below test shall be made available to the evaluator, but need not be published in the TSS.
Tests
-
- Test FDP_RIP_EXT.2.1:1: On the host, the evaluator creates a file that is more than half the size of a connected physical storage device (or multiple files whose individual sizes add up to more than half the size of the storage media). This file (or files) shall be filled entirely with a non-zero value. Then, the file (or files) shall be released (freed for use but not cleared). Next, the evaluator (as a VS Administrator) creates a virtual disk at least that large on the same physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, scan through and check that all the non-metadata (as documented in the TSS) in the file corresponding to that virtual disk is set to zero.
+ Test FDP_RIP_EXT.2.1:1: On the host, the evaluator creates a file that is more than half the size of a connected physical storage device (or multiple files whose individual sizes add up to more than half the size of the storage media). This file (or files) shall be filled entirely with a non-zero value. Then, the file (or files) shall be released (freed for use but not cleared). Next, the evaluator (as a VS Administrator) creates a virtual disk at least that large on the same physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, scan through and check that all the non-metadata (as documented in the TSS) in the file corresponding to that virtual disk is set to zero.
@@ -1730,7 +1723,7 @@ FDP_VMS_EXT.1 VM Separation
FDP_VMS_EXT.1.1
- The VS shall provide the following mechanisms for transferring data between Guest VMs:[selection: no mechanism, virtual networking, other inter-VM data sharing mechanisms ].
+ The VS shall provide the following mechanisms for transferring data between Guest VMs:[selection: no mechanism, virtual networking, [assignment: other inter-VM data sharing mechanisms ]].
@@ -1754,11 +1747,11 @@ FDP_VMS_EXT.1 VM Separation
FDP_VMS_EXT.1.4
- The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1.
+ The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1.
- Application Note: The fundamental requirement of a Virtualization System is the ability to enforce separation between information domains implemented as Virtual Machines and Virtual Networks. The intent of this requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with this fundamental requirement in mind.
+ Application Note: The fundamental requirement of a Virtualization System is the ability to enforce separation between information domains implemented as Virtual Machines and Virtual Networks. The intent of this requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with this fundamental requirement in mind.
- The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” and identify all other mechanisms through which data can be transferred between Guest VMs.
+ The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” and identify all other mechanisms through which data can be transferred between Guest VMs.
Examples of non-network inter-VM sharing mechanisms are:
@@ -1769,9 +1762,9 @@ FDP_VMS_EXT.1 VM Separation
For data transfer mechanisms implemented in terms of Hypercall functions, FDP_VMS_EXT.1.3 is met if FPT_HCL_EXT.1.1 is met for those Hypercall functions (Hypercall function parameters are checked).
- For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable).
+ For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable).
- For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 is met (VM access to virtual networks is configurable).
+ For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 is met (VM access to virtual networks is configurable).
@@ -1811,9 +1804,7 @@ FDP_VMS_EXT.1 VM Separation
Test that communications can be passed between the VMs through the channel.
Create two new VMs, the first with the inter-VM communications channel currently being tested enabled, and the second with the inter-VM communications channel currently being tested disabled.
Test that communications cannot be passed between the VMs through the channel.
-
- As an Administrator, enable inter-VM communications between the VMs on the second VM.
-
+ As an Administrator, enable inter-VM communications between the VMs on the second VM.
Test that communications can be passed through the inter-VM channel.
As an Administrator again, disable inter-VM communications between the two VMs.
Test that communications can no longer be passed through the channel.
@@ -1842,9 +1833,9 @@ FDP_VNC_EXT.1 Virtual Networking Components
FDP_VNC_EXT.1.2
- The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment.
+ The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment.
- Application Note: Virtual networks must be separated from one another to provide isolation commensurate with that provided by physically separate networks. It must not be possible for data to cross between properly configured virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host.
+ Application Note: Virtual networks must be separated from one another to provide isolation commensurate with that provided by physically separate networks. It must not be possible for data to cross between properly configured virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host.
Unprivileged users must not be able to connect VMs to each other or to external networks.
@@ -1873,10 +1864,10 @@ FDP_VNC_EXT.1 Virtual Networking Components
-
- Test FDP_VNC_EXT.1.2:1: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a network component. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and attempt the same connection. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
+ Test FDP_VNC_EXT.1.2:1: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a network component. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and attempt the same connection. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
-
- Test FDP_VNC_EXT.1.2:2: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a physical network. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and make the same attempt. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
+ Test FDP_VNC_EXT.1.2:2: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a physical network. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and make the same attempt. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
@@ -1892,7 +1883,7 @@ FIA_AFL_EXT.1 Authentication Failure Handling
FIA_AFL_EXT.1.1
- The TSF shall detect when[selection: a positive integer number , an administrator configurable positive integer within a [assignment: range of acceptable values ]]unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using[selection: username and password, username and PIN].
+ The TSF shall detect when[selection: [assignment: a positive integer number ], an administrator configurable positive integer within a [assignment: range of acceptable values ]]unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using[selection: username and password, username and PIN].
@@ -1900,7 +1891,7 @@ FIA_AFL_EXT.1 Authentication Failure Handling
FIA_AFL_EXT.1.2
- When the defined number of unsuccessful authentication attempts has been met, the TSF shall:[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until [assignment: action to unlock ] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed]
+ When the defined number of unsuccessful authentication attempts has been met, the TSF shall:[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until [assignment: action to unlock ] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed]
Application Note: The action to be taken shall be populated in the selection of the ST and defined in the Administrator guidance.
@@ -1953,7 +1944,7 @@ FIA_PMG_EXT.1 Password Management
The TSF shall provide the following password management capabilities for administrative passwords:
-
- Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “& ”, “*”, “(“, “)”, other characters ]
+ Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “& ”, “*”, “(“, “)”, [assignment: other characters ]]
- Minimum password length shall be configurable
- Passwords of at least 15 characters in length shall be supported
@@ -2001,16 +1992,16 @@ FIA_UAU.5 Multiple Authentication Mechanisms
The TSF shall provide the following authentication mechanisms:[selection:
-
- [selection: local, directory-based] authentication based on username and password
+ [selection: local, directory-based] authentication based on username and password
-
authentication based on username and a PIN that releases an asymmetric key stored in OE-protected storage
-
- [selection: local, directory-based] authentication based on X.509 certificates
+ [selection: local, directory-based] authentication based on X.509 certificates
-
- [selection: local, directory-based] authentication based on an SSH public key credential
+ [selection: local, directory-based] authentication based on an SSH public key credential
]to support Administrator authentication.
@@ -2044,42 +2035,42 @@ FIA_UAU.5 Multiple Authentication Mechanisms
- If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a known username and password and conduct the following tests:
+ If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a known username and password and conduct the following tests:
-
- Test FIA_UAU.5.2:1: The evaluator will attempt to authenticate to the VS using the known username and password. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:1: The evaluator will attempt to authenticate to the VS using the known username and password. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:2: The evaluator will attempt to authenticate to the VS using the known username but an incorrect password. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:2: The evaluator will attempt to authenticate to the VS using the known username but an incorrect password. The evaluator will ensure that the authentication attempt is unsuccessful.
- If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for guidance on supported protected storage and will then configure the TOE or OE to establish a PIN which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware token, or isolated execution environment) with which the VS can interface. The evaluator will then conduct the following tests:
+ If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for guidance on supported protected storage and will then configure the TOE or OE to establish a PIN which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware token, or isolated execution environment) with which the VS can interface. The evaluator will then conduct the following tests:
-
- Test FIA_UAU.5.2:3: The evaluator will attempt to authenticate to the VS using the known user name and PIN. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:3: The evaluator will attempt to authenticate to the VS using the known user name and PIN. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:4: The evaluator will attempt to authenticate to the VS using the known user name but an incorrect PIN. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:4: The evaluator will attempt to authenticate to the VS using the known user name but an incorrect PIN. The evaluator will ensure that the authentication attempt is unsuccessful.
- If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the following tests:
+ If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the following tests:
-
- Test FIA_UAU.5.2:5: The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:5: The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:6: The evaluator will generate a second certificate identical to the first except for the public key and any values derived from the public key. The evaluator will attempt to authenticate to the VS with this certificate. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:6: The evaluator will generate a second certificate identical to the first except for the public key and any values derived from the public key. The evaluator will attempt to authenticate to the VS with this certificate. The evaluator will ensure that the authentication attempt is unsuccessful.
- If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote client. The evaluator shall provision the VS with the client public key for authentication over SSH, and conduct the following tests:
+ If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote client. The evaluator shall provision the VS with the client public key for authentication over SSH, and conduct the following tests:
-
- Test FIA_UAU.5.2:7: The evaluator will attempt to authenticate to the VS using a message signed by the client private key that corresponds to provisioned client public key. The evaluator will ensure that the authentication attempt is successful.
+ Test FIA_UAU.5.2:7: The evaluator will attempt to authenticate to the VS using a message signed by the client private key that corresponds to provisioned client public key. The evaluator will ensure that the authentication attempt is successful.
-
- Test FIA_UAU.5.2:8: The evaluator will generate a second client key pair and will attempt to authenticate to the VS with the private key over SSH without first provisioning the VS to support the new key pair. The evaluator will ensure that the authentication attempt is unsuccessful.
+ Test FIA_UAU.5.2:8: The evaluator will generate a second client key pair and will attempt to authenticate to the VS with the private key over SSH without first provisioning the VS to support the new key pair. The evaluator will ensure that the authentication attempt is unsuccessful.
@@ -2128,7 +2119,7 @@ FMT_SMO_EXT.1 Separation of Management and Operational Networks
The TSF shall support the separation of management and operational network traffic through[selection: separate physical networks, separate logical networks, trusted channels as defined in FTP_ITC_EXT.1, data encryption using an algorithm specified in FCS_COP.1/UDE].
- Application Note: Management communications must be separate from user workload communications. Administrative network traffic—including communications between physical hosts concerning load balancing, audit data, VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, management traffic also includes VMs transmitted over management networks whether for backup, live migration, or deployment.
+ Application Note: Management communications must be separate from user workload communications. Administrative network traffic—including communications between physical hosts concerning load balancing, audit data, VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, management traffic also includes VMs transmitted over management networks whether for backup, live migration, or deployment.
“Separate physical networks” refers to using separate physical interfaces and cables to isolate management and operational networks from each other.
@@ -2157,16 +2148,14 @@ FMT_SMO_EXT.1 Separation of Management and Operational Networks
The evaluator shall examine the TSS to verify that it describes how management and operational traffic is separated.
Guidance
-
- The evaluator shall examine the operational guidance to verify that it details how to configure the VS to keep Management and Operational traffic separate.
-
+ The evaluator shall examine the operational guidance to verify that it details how to configure the VS to keep Management and Operational traffic separate.
Tests
The evaluator shall configure the TOE as documented in the guidance. If separation is logical, then the evaluator shall capture packets on the management network. If plaintext Guest network traffic is detected, the requirement is not met.
If separation uses trusted channels, then the evaluator shall capture packets on the network over which traffic is tunneled. If plaintext Guest network traffic is detected, the requirement is not met.
- If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the requirement is not met.
+ If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the requirement is not met.
@@ -2180,13 +2169,13 @@ FPT_DVD_EXT.1 Non-Existence of Disconnected Virtual Devices
FPT_DVD_EXT.1.1
- The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration.
+ The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration.
- Application Note: The virtualized hardware abstraction implemented by a particular VS might include the virtualized interfaces for many different devices. Sometimes these devices are not present in a particular instantiation of a VM. The interface for devices not present must not be accessible by the VM.
+ Application Note: The virtualized hardware abstraction implemented by a particular VS might include the virtualized interfaces for many different devices. Sometimes these devices are not present in a particular instantiation of a VM. The interface for devices not present must not be accessible by the VM.
Such interfaces include memory buffers, PCI Bus interfaces, and processor I/O ports.
- The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces.
+ The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces.
@@ -2200,7 +2189,7 @@ FPT_DVD_EXT.1 Non-Existence of Disconnected Virtual Devices
Tests
- The evaluator shall connect a device to a VM, then from within the guest scan the VM's devices to ensure that the connected device is present--using a device driver or other available means to scan the VM's I/O ports or PCI Bus interfaces. (The device's interface should be documented in the TSS under FPT_VDP_EXT.1.) The evaluator shall remove the device from the VM and run the scan again. This requirement is met if the device's interfaces are no longer present.
+ The evaluator shall connect a device to a VM, then from within the guest scan the VM's devices to ensure that the connected device is present--using a device driver or other available means to scan the VM's I/O ports or PCI Bus interfaces. (The device's interface should be documented in the TSS under FPT_VDP_EXT.1.) The evaluator shall remove the device from the VM and run the scan again. This requirement is met if the device's interfaces are no longer present.
@@ -2212,7 +2201,7 @@ FPT_EEM_EXT.1 Execution Environment Mitigations
FPT_EEM_EXT.1.1
- The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:[selection: Address space randomization, Memory execution protection (e.g., DEP), Stack buffer overflow protection, Heap corruption detection, other mechanisms , No mechanisms]
+ The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:[selection: Address space randomization, Memory execution protection (e.g., DEP), Stack buffer overflow protection, Heap corruption detection, [assignment: other mechanisms ], No mechanisms]
Application Note: Processor manufacturers, compiler developers, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Software can often take advantage of these mechanisms by using APIs provided by the operating system or by enabling the mechanism through compiler or linker options.
@@ -2246,7 +2235,7 @@ FPT_HAS_EXT.1 Hardware Assists
FPT_HAS_EXT.1.1
- The VMM shall use[assignment: list of hardware-based virtualization assists]to reduce or eliminate the need for binary translation.
+ The VMM shall use[assignment: list of hardware-based virtualization assists]to reduce or eliminate the need for binary translation.
@@ -2254,13 +2243,13 @@ FPT_HAS_EXT.1 Hardware Assists
FPT_HAS_EXT.1.2
- The VMM shall use[assignment: list of hardware-based virtualization memory-handling assists]to reduce or eliminate the need for shadow page tables.
+ The VMM shall use[assignment: list of hardware-based virtualization memory-handling assists]to reduce or eliminate the need for shadow page tables.
- Application Note: These hardware-assists help reduce the size and complexity of the VMM, and thus, of the trusted computing base, by eliminating or reducing the need for paravirtualization or binary translation. Paravirtualization involves modifying guest software so that instructions that cannot be properly virtualized are never executed on the physical processor.
+ Application Note: These hardware-assists help reduce the size and complexity of the VMM, and thus, of the trusted computing base, by eliminating or reducing the need for paravirtualization or binary translation. Paravirtualization involves modifying guest software so that instructions that cannot be properly virtualized are never executed on the physical processor.
- For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all platforms included in the ST that are used by the VMM to reduce or eliminate the need for software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is an acceptable assignment for platforms that do not require virtualization assists in order to eliminate the need for binary translation. This must be documented in the TSS.
+ For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all platforms included in the ST that are used by the VMM to reduce or eliminate the need for software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is an acceptable assignment for platforms that do not require virtualization assists in order to eliminate the need for binary translation. This must be documented in the TSS.
- For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. “None” is an acceptable assignment for platforms that do not require memory-handling assists in order to eliminate the need for shadow page tables. This must be documented in the TSS.
+ For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. “None” is an acceptable assignment for platforms that do not require memory-handling assists in order to eliminate the need for shadow page tables. This must be documented in the TSS.
@@ -2288,11 +2277,11 @@ FPT_HCL_EXT.1 Hypercall Controls
FPT_HCL_EXT.1.1
- The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface.
+ The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface.
- Application Note: The purpose of this requirement is to help ensure the integrity of the VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls.
+ Application Note: The purpose of this requirement is to help ensure the integrity of the VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls.
- A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. For example, a hypercall interface could be used to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest software, these interfaces constitute attack surface.
+ A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. For example, a hypercall interface could be used to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest software, these interfaces constitute attack surface.
There is no expectation that the evaluator will need to review source code in order to accomplish the evaluation activity.
@@ -2318,7 +2307,7 @@ FPT_HCL_EXT.1 Hypercall Controls
The evaluator shall perform the following test:
- For each hypercall interface documented in the TSS or proprietary TSS Annex, the evaluator shall attempt to invoke the function from within the VM using an invalid parameter (if any). If the VMM or VS crashes or generates an exception, or if no error is returned to the guest, then the test fails. If an error is returned to the guest, then the test succeeds.
+ For each hypercall interface documented in the TSS or proprietary TSS Annex, the evaluator shall attempt to invoke the function from within the VM using an invalid parameter (if any). If the VMM or VS crashes or generates an exception, or if no error is returned to the guest, then the test fails. If an error is returned to the guest, then the test succeeds.
@@ -2348,13 +2337,9 @@ FPT_RDM_EXT.1 Removable Devices and Media
For purposes of this requirement, an Information Domain is:
- -
- A VM or collection of VMs
-
+ - A VM or collection of VMs
- The Virtualization System
- -
- Host OS
-
+ - Host OS
- Management Subsystem
These requirements also apply to virtualized removable media—such as virtual CD drives that connect to ISO images—as well as physical media—such as CDROMs and USB flash drives. In the case of virtual CDROMs, virtual ejection of the virtual media is sufficient.
@@ -2387,7 +2372,7 @@ FPT_RDM_EXT.1 Removable Devices and Media
The evaluator shall perform the following test for each listed media or device:
-
- Test FPT_RDM_EXT.1.2:1: The evaluator shall configure two VMs that are members of different information domains, with the media or device connected to one of the VMs. The evaluator shall disconnect the media or device from the VM and connect it to the other VM. The evaluator shall verify that the action performed is consistent with the action assigned in the TSS.
+ Test FPT_RDM_EXT.1.2:1: The evaluator shall configure two VMs that are members of different information domains, with the media or device connected to one of the VMs. The evaluator shall disconnect the media or device from the VM and connect it to the other VM. The evaluator shall verify that the action performed is consistent with the action assigned in the TSS.
@@ -2482,7 +2467,7 @@ FPT_VDP_EXT.1 Virtual Device Parameters
FPT_VDP_EXT.1.1
- The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction.
+ The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction.
@@ -2490,9 +2475,9 @@ FPT_VDP_EXT.1 Virtual Device Parameters
FPT_VDP_EXT.1.2
- The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces.
+ The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces.
- Application Note: The purpose of this requirement is to ensure that the VMM is not vulnerable to compromise through the processing of malformed data passed to the virtual device interface from a Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual device interface is unique to the VS and the data comes from a virtual device driver supplied by the Virtualization Vendor.
+ Application Note: The purpose of this requirement is to ensure that the VMM is not vulnerable to compromise through the processing of malformed data passed to the virtual device interface from a Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual device interface is unique to the VS and the data comes from a virtual device driver supplied by the Virtualization Vendor.
@@ -2510,7 +2495,7 @@ FPT_VDP_EXT.1 Virtual Device Parameters
TSS
- The evaluator shall examine the TSS to ensure it lists all virtual devices accessible by the guest OS. The TSS, or a separate proprietary document, must also document all virtual device interfaces at the level of I/O ports or PCI Bus interfaces - including port numbers (absolute or relative to a base), port name, address range, and a description of legal input values.
+ The evaluator shall examine the TSS to ensure it lists all virtual devices accessible by the guest OS. The TSS, or a separate proprietary document, must also document all virtual device interfaces at the level of I/O ports or PCI Bus interfaces - including port numbers (absolute or relative to a base), port name, address range, and a description of legal input values.
The TSS must also describe the expected behavior of the interface when presented with illegal input values. This behavior must be deterministic and indicative of parameter checking by the TSF.
@@ -2532,7 +2517,7 @@ FPT_VIV_EXT.1 VMM Isolation from VMs
FPT_VIV_EXT.1.1
- The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform.
+ The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform.
@@ -2540,24 +2525,22 @@ FPT_VIV_EXT.1 VMM Isolation from VMs
FPT_VIV_EXT.1.2
- The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM.
+ The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM.
- Application Note: This requirement is intended to ensure that software running within a Guest VM cannot compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM software—whatever its privilege level—can crash the VS or the Platform, or breakout of its virtual hardware abstraction to gain execution on the platform, within or outside of the context of the VMM.
+ Application Note: This requirement is intended to ensure that software running within a Guest VM cannot compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM software—whatever its privilege level—can crash the VS or the Platform, or breakout of its virtual hardware abstraction to gain execution on the platform, within or outside of the context of the VMM.
- This requirement is not violated if software running within a VM can crash the Guest OS and there is no way for an attacker to gain execution in the VMM or outside of the virtualized domain.
+ This requirement is not violated if software running within a VM can crash the Guest OS and there is no way for an attacker to gain execution in the VMM or outside of the virtualized domain.
- FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and invoke privileged code on the Platform.
+ FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and invoke privileged code on the Platform.
At a minimum, the TSF should enforce the following:
- On the x86 platform, a virtual System Management Interrupt (SMI) cannot invoke platform System Management Mode (SMM).
- An attempt to update virtual firmware or virtual BIOS cannot cause physical platform firmware or physical platform BIOS to be modified.
- -
- An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified.
-
+ - An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified.
- Of the above, the first bullet does not apply to platforms that do not support SMM. The rationale behind the third bullet is that a firmware update of a single VM must not affect other VMs. So if multiple VMs share the same firmware image as part of a common hardware abstraction, then the update of a single machine’s BIOS must not be allowed to change the common abstraction. The virtual hardware abstraction is part of the VMM.
+ Of the above, the first bullet does not apply to platforms that do not support SMM. The rationale behind the third bullet is that a firmware update of a single VM must not affect other VMs. So if multiple VMs share the same firmware image as part of a common hardware abstraction, then the update of a single machine’s BIOS must not be allowed to change the common abstraction. The virtual hardware abstraction is part of the VMM.
@@ -2575,7 +2558,7 @@ FPT_VIV_EXT.1 VMM Isolation from VMs
TSS
- The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note.
+ The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note.
@@ -2625,7 +2608,7 @@ FTP_ITC_EXT.1 Trusted Channel Communications
audit servers (as required by FAU_STG_EXT.1), and
- [selection: remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module), separation of management and operational networks (if selected in FMT_SMO_EXT.1), other capabilities , no other capabilities]that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data.
+ [selection: remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module), separation of management and operational networks (if selected in FMT_SMO_EXT.1), [assignment: other capabilities ], no other capabilities]that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data.
Application Note: If the ST author selects either TLS or HTTPS, the TSF shall be validated against the Functional Package for TLS. This PP does not mandate that a product implement TLS with mutual authentication, but if the product includes the capability to perform TLS with mutual authentication, then mutual authentication must be included within the TOE boundary. The TLS Package requires that the X509 requirements be included by the PP, so selection of TLS or HTTPS causes FIA_X509_EXT.* to be selected.
@@ -2656,7 +2639,7 @@ FTP_ITC_EXT.1 Trusted Channel Communications
Tests
- The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.
+ The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.
@@ -2741,11 +2724,11 @@ FTP_UIF_EXT.1 User Interface: I/O Focus
FTP_UIF_EXT.1.1
- The TSF shall indicate to users which VM, if any, has the current input focus.
+ The TSF shall indicate to users which VM, if any, has the current input focus.
- Application Note: This requirement applies to all users—whether User or Administrator. In environments where multiple VMs run at the same time, the user must have a way of knowing which VM user input is directed to at any given moment. This is especially important in multiple-domain environments.
+ Application Note: This requirement applies to all users—whether User or Administrator. In environments where multiple VMs run at the same time, the user must have a way of knowing which VM user input is directed to at any given moment. This is especially important in multiple-domain environments.
- In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is considered to be a program, but this program still needs to know which VM it is sending input to; this would typically be accomplished through programmatic means.
+ In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is considered to be a program, but this program still needs to know which VM it is sending input to; this would typically be accomplished through programmatic means.
@@ -2767,7 +2750,7 @@ FTP_UIF_EXT.1 User Interface: I/O Focus
The evaluator shall ensure that the operational guidance specifies how the current input focus is indicated to the user.
Tests
- For each supported input device, the evaluator shall demonstrate that the input from each device listed in the TSS is directed to the VM that is indicated to have the input focus.
+ For each supported input device, the evaluator shall demonstrate that the input from each device listed in the TSS is directed to the VM that is indicated to have the input focus.
@@ -2779,11 +2762,11 @@ FTP_UIF_EXT.2 User Interface: Identification of VM
FTP_UIF_EXT.2.1
- The TSF shall support the unique identification of a VM’s output display to users.
+ The TSF shall support the unique identification of a VM’s output display to users.
- Application Note: In environments where a user has access to more than one VM at the same time, the user must be able to determine the identity of each VM displayed in order to avoid inadvertent cross-domain data entry.
+ Application Note: In environments where a user has access to more than one VM at the same time, the user must be able to determine the identity of each VM displayed in order to avoid inadvertent cross-domain data entry.
- There must be a mechanism for associating an identifier with a VM so that an application or program displaying the VM can identify the VM to users. This is generally indicated visually for human users (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API function). The identification must be unique to the VS, but does not need to be universally unique.
+ There must be a mechanism for associating an identifier with a VM so that an application or program displaying the VM can identify the VM to users. This is generally indicated visually for human users (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API function). The identification must be unique to the VS, but does not need to be universally unique.
@@ -2805,7 +2788,7 @@ FTP_UIF_EXT.2 User Interface: Identification of VM
The evaluator shall perform the following test:
- The evaluator shall attempt to create and start at least three Guest VMs on a single display device where the evaluator attempts to assign two of the VMs the same identifier. If the user interface displays different identifiers for each VM, then the requirement is met. Likewise, the requirement is met if the system refuses to create or start a VM when there is already a VM with the same identifier.
+ The evaluator shall attempt to create and start at least three Guest VMs on a single display device where the evaluator attempts to assign two of the VMs the same identifier. If the user interface displays different identifiers for each VM, then the requirement is met. Likewise, the requirement is met if the system refuses to create or start a VM when there is already a VM with the same identifier.
@@ -2873,7 +2856,7 @@ 5.1.9 TOE Security Functio
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_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.
@@ -2966,7 +2949,7 @@ 5.1.9 TOE Security Functio
FPT_HCL_EXT.1 Requires that Hypercall parameters be validated.
- FPT_ML_EXT.1 Requires measured launch of the platform and VMM (objective).
+ 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.
@@ -3018,7 +3001,7 @@ 5.1.9 TOE Security Functio
FPT_HCL_EXT.1 Requires that Hypercall parameters be validated.
- FPT_ML_EXT.1 Requires measured launch of the platform and VMM (objective).
+ 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.
@@ -3074,12 +3057,10 @@ 5.1.9 TOE Security Functio
- 5.2 Security Assurance Requirements
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
-
- This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section.
-
- After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.
+ 4.3 Security Objectives Rationale<
T.MISCONFIGURATION O.CORRECTLY_APPLIED_CONFIGURATION Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations.
4.3 Security Objectives Rationale<
T.UNPATCHED_SOFTWARE O.PATCHED_SOFTWARE The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available.
FAU_GEN.1 Audit Data Generation
- Application Note: The ST author can include other auditable events directly in Table t-audit-mandatory; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.
+ Application Note: The ST author can include other auditable events directly in Table t-audit-mandatory; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and Table t-audit-sel-based should be included in the ST if the associated SFRs and selections are included.
- The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.
+ The Table t-audit-mandatory entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.
- The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM's hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
+ The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM's hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
The following table contains the events enumerated in the auditable events table for the TLS Functional Package. Inclusion of these events in the ST is subject to selection above, inclusion of the corresponding SFRs in the ST, and support in the FP as represented by a selection in the table below.
@@ -753,7 +752,7 @@
FAU_STG_EXT.1 Off-Loading of Audit Data
FAU_STG_EXT.1.2
- The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records ], other action ]when the local storage space for audit data is full.
+ The TSF shall[selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records ], [assignment: other action ]]when the local storage space for audit data is full.
- ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
+ ECC schemes using [“NIST curves” P-256, P-384, and [selection: P-521, no other curves] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].
@@ -1264,7 +1263,7 @@
- ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
+ ECDSA schemes using [“NIST curves” P-256, P-384 and [selection: P-521, no other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]
].
@@ -1428,13 +1427,13 @@
@@ -1450,7 +1449,7 @@
Application Note: An external log server, if available, might be used as alternative storage space in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the new audit data to an external IT entity’.
@@ -820,7 +819,7 @@ FCS_CKM.1 Cryptographic Key Generation
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]FCS_COP.1/Sig Cryptographic Operation (Signature Algorithms)
RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]FCS_ENT_EXT.1 Entropy for Virtual Machines
The TSF shall provide independent entropy across multiple VMs.
- Application Note: This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide pass-through access to entropy sources provided by the host platform.
+ Application Note: This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide pass-through access to entropy sources provided by the host platform.
- This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or 3) pass-through access to a hardware entropy source (including a source of random numbers). In all cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a VM-unaware guest would use.
+ This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or 3) pass-through access to a hardware entropy source (including a source of random numbers). In all cases, it is possible that the guest is made VM-aware through installation of software or drivers. For the second and third cases, it is possible that the guest could be VM-unaware. There is no requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a VM-unaware guest would use.
- The ST author should select “Hypercall interface” if the TSF provides an API function through which guest-resident software can obtain entropy or random numbers. The ST author should select “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through which it can obtain entropy or random numbers. Such an interface could present a virtualized real device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or random number source on the platform. The ST author should select all items that are appropriate.
+ The ST author should select “Hypercall interface” if the TSF provides an API function through which guest-resident software can obtain entropy or random numbers. The ST author should select “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through which it can obtain entropy or random numbers. Such an interface could present a virtualized real device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or random number source on the platform. The ST author should select all items that are appropriate.
- For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality of entropy provided to another VM on the same platform.
+ For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality of entropy provided to another VM on the same platform.
FCS_ENT_EXT.1 Entropy for Virtual Machines
TSS
- The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and how to access the interface to acquire entropy or random numbers. The evaluator shall verify that the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by another.
+ The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and how to access the interface to acquire entropy or random numbers. The evaluator shall verify that the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by another.
Tests
@@ -1458,10 +1457,10 @@
FCS_ENT_EXT.1 Entropy for Virtual Machines
-
The evaluator shall perform the following tests:
- - Test FCS_ENT_EXT.1.2:1: The evaluator shall invoke entropy from each Guest VM. The evaluator shall verify that each VM acquires values from the interface. + Test FCS_ENT_EXT.1.2:1: The evaluator shall invoke entropy from each Guest VM. The evaluator shall verify that each VM acquires values from the interface.
- - Test FCS_ENT_EXT.1.2:2: The evaluator shall invoke entropy from multiple VMs as nearly simultaneously as practicable. The evaluator shall verify that the entropy used in one VM is not identical to that invoked from the other VMs. + Test FCS_ENT_EXT.1.2:2: The evaluator shall invoke entropy from multiple VMs as nearly simultaneously as practicable. The evaluator shall verify that the entropy used in one VM is not identical to that invoked from the other VMs.
FDP_HBI_EXT.1 Hardware-Based Isolation Mechanisms
FDP_HBI_EXT.1.1
- The TSF shall use[selection: no mechanism, list of platform-provided, hardware-based mechanisms ]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, physical devices to which the VMM allows Guest VMs physical access ].
+ The TSF shall use[selection: no mechanism, [assignment: list of platform-provided, hardware-based mechanisms ]]to constrain a Guest VM's direct access to the following physical devices:[selection: no devices, [assignment: physical devices to which the VMM allows Guest VMs physical access ]].
@@ -1562,7 +1561,7 @@
- Application Note: The TSF must use available hardware-based isolation mechanisms to constrain VMs when VMs have direct access to physical devices. “Direct access” in this context means that the VM can read or write device memory or access device I/O ports without the VMM being able to intercept and validate every transaction.
+ Application Note: The TSF must use available hardware-based isolation mechanisms to constrain VMs when VMs have direct access to physical devices. “Direct access” in this context means that the VM can read or write device memory or access device I/O ports without the VMM being able to intercept and validate every transaction.
FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.1
- The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:[assignment: list of physical platform resources the VMM isable to control access to].
+ The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:[assignment: list of physical platform resources the VMM isable to control access to].
@@ -1570,7 +1569,7 @@
FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.2
- The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, list of physical platform resources to which access is explicitly denied ].
+ The TSF shall explicitly deny all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, [assignment: list of physical platform resources to which access is explicitly denied ]].
@@ -1578,21 +1577,15 @@
FDP_PPR_EXT.1 Physical Platform Resource Controls
FDP_PPR_EXT.1.3
- The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, list of physical platform resources to which access is always allowed ].
+ The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:[selection: no physical platform resources, [assignment: list of physical platform resources to which access is always allowed ]].
@@ -1608,11 +1601,11 @@
Application Note: For purposes of this requirement, physical platform resources are divided into three categories:
-
-
- - those to which Guest OS access is configurable and moderated by the VMM - -
- - those to which the Guest OS is never allowed to have direct access, and - -
- - those to which the Guest OS is always allowed to have direct access. - +
- those to which Guest OS access is configurable and moderated by the VMM +
- those to which the Guest OS is never allowed to have direct access, and +
- those to which the Guest OS is always allowed to have direct access.
FDP_PPR_EXT.1 Physical Platform Resource Controls
TSS
- The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to physical platform resources. This description shall cover all of the physical platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and how each physical platform resource that is controllable (that is, listed in the assignment statement in the first element) is identified to an Administrator.
+ The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to physical platform resources. This description shall cover all of the physical platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and how each physical platform resource that is controllable (that is, listed in the assignment statement in the first element) is identified to an Administrator.
- The evaluator shall ensure that the TSS describes how the Guest VM is associated with each physical resource, and how other Guest VMs cannot access a physical resource without being granted explicit access. For TOEs that implement a robust interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the TSS describes the possible operations or modes of access between a Guest VM's and physical platform resources.
+ The evaluator shall ensure that the TSS describes how the Guest VM is associated with each physical resource, and how other Guest VMs cannot access a physical resource without being granted explicit access. For TOEs that implement a robust interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the TSS describes the possible operations or modes of access between a Guest VM's and physical platform resources.
- If physical resources are listed in the second element, the evaluator shall examine the TSS and operational guidance to determine that there appears to be no way to configure those resources for access by a Guest VM. The evaluator shall document in the evaluation report their analysis of why the controls offered to configure access to physical resources can't be used to specify access to the resources identified in the second element (for example, if the interface offers a drop-down list of resources to assign, and the denied resources are not included on that list, that would be sufficient justification in the evaluation report).
+ If physical resources are listed in the second element, the evaluator shall examine the TSS and operational guidance to determine that there appears to be no way to configure those resources for access by a Guest VM. The evaluator shall document in the evaluation report their analysis of why the controls offered to configure access to physical resources can't be used to specify access to the resources identified in the second element (for example, if the interface offers a drop-down list of resources to assign, and the denied resources are not included on that list, that would be sufficient justification in the evaluation report).
Guidance
@@ -1623,19 +1616,19 @@
FDP_PPR_EXT.1 Physical Platform Resource Controls
- - Test FDP_PPR_EXT.1.3:1: For each physical platform resource identified in the first element, the evaluator shall configure a Guest VM to have access to that resource and show that the Guest VM is able to successfully access that resource. + Test FDP_PPR_EXT.1.3:1: For each physical platform resource identified in the first element, the evaluator shall configure a Guest VM to have access to that resource and show that the Guest VM is able to successfully access that resource.
- - Test FDP_PPR_EXT.1.3:2: For each physical platform resource identified in the first element, the evaluator shall configure the system such that a Guest VM does not have access to that resource and show that the Guest VM is unable to successfully access that resource. + Test FDP_PPR_EXT.1.3:2: For each physical platform resource identified in the first element, the evaluator shall configure the system such that a Guest VM does not have access to that resource and show that the Guest VM is unable to successfully access that resource.
- Test FDP_PPR_EXT.1.3:3: [conditional]: For TOEs that have a robust control interface, the evaluator shall exercise each element of the interface as described in the TSS and the operational guidance to ensure that the behavior described in the operational guidance is exhibited.
- - Test FDP_PPR_EXT.1.3:4: [conditional]: If the TOE explicitly denies access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource from a Guest VM and observe that access is denied. + Test FDP_PPR_EXT.1.3:4: [conditional]: If the TOE explicitly denies access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource from a Guest VM and observe that access is denied.
- - Test FDP_PPR_EXT.1.3:5: [conditional]: If the TOE explicitly allows access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource from a Guest VM and observe that the access is allowed. If the operational guidance specifies that access is allowed simultaneously by more than one Guest VM, the evaluator shall attempt to access each resource listed from more than one Guest VM and show that access is allowed. + Test FDP_PPR_EXT.1.3:5: [conditional]: If the TOE explicitly allows access to certain physical resources, the evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource from a Guest VM and observe that the access is allowed. If the operational guidance specifies that access is allowed simultaneously by more than one Guest VM, the evaluator shall attempt to access each resource listed from more than one Guest VM and show that access is allowed.
FDP_RIP_EXT.1 Residual Information in Memory
FDP_RIP_EXT.1.1
- The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM.
+ The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM.
@@ -1674,7 +1667,7 @@
- Application Note: Physical memory must be zeroed before it is made accessible to a VM for general use by a Guest OS.
+ Application Note: Physical memory must be zeroed before it is made accessible to a VM for general use by a Guest OS.
- The purpose of this requirement is to ensure that a VM does not receive memory containing data previously used by another VM or the host.
+ The purpose of this requirement is to ensure that a VM does not receive memory containing data previously used by another VM or the host.
- “For general use” means for use by the Guest OS in its page tables for running applications or system software.
+ “For general use” means for use by the Guest OS in its page tables for running applications or system software.
- This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such as read-only OS pages or pages used for virtual device buffers.
+ This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such as read-only OS pages or pages used for virtual device buffers.
FDP_RIP_EXT.1 Residual Information in Memory
TSS
- The evaluator shall ensure that the TSS documents the process used for clearing physical memory prior to allocation to a Guest VM, providing details on when and how this is performed. Additionally, the evaluator shall ensure that the TSS documents the conditions under which physical memory is not cleared prior to allocation to a Guest VM, and describes when and how the memory is cleared.
+ The evaluator shall ensure that the TSS documents the process used for clearing physical memory prior to allocation to a Guest VM, providing details on when and how this is performed. Additionally, the evaluator shall ensure that the TSS documents the conditions under which physical memory is not cleared prior to allocation to a Guest VM, and describes when and how the memory is cleared.
@@ -1686,9 +1679,9 @@ FDP_RIP_EXT.2 Residual Information on Disk
FDP_RIP_EXT.2.1
- The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM.
+ The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM.
- Application Note: The purpose of this requirement is to ensure that a VM does not receive disk storage containing data previously used by another VM or by the host.
+ Application Note: The purpose of this requirement is to ensure that a VM does not receive disk storage containing data previously used by another VM or by the host.
Clearing of disk storage only upon deallocation does not meet this requirement.
@@ -1708,14 +1701,14 @@
FDP_RIP_EXT.2 Residual Information on Disk
TSS
- The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. Any file system format and metadata information needed by the evaluator to perform the below test shall be made available to the evaluator, but need not be published in the TSS.
+ The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. Any file system format and metadata information needed by the evaluator to perform the below test shall be made available to the evaluator, but need not be published in the TSS.
Tests
- - Test FDP_RIP_EXT.2.1:1: On the host, the evaluator creates a file that is more than half the size of a connected physical storage device (or multiple files whose individual sizes add up to more than half the size of the storage media). This file (or files) shall be filled entirely with a non-zero value. Then, the file (or files) shall be released (freed for use but not cleared). Next, the evaluator (as a VS Administrator) creates a virtual disk at least that large on the same physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, scan through and check that all the non-metadata (as documented in the TSS) in the file corresponding to that virtual disk is set to zero. + Test FDP_RIP_EXT.2.1:1: On the host, the evaluator creates a file that is more than half the size of a connected physical storage device (or multiple files whose individual sizes add up to more than half the size of the storage media). This file (or files) shall be filled entirely with a non-zero value. Then, the file (or files) shall be released (freed for use but not cleared). Next, the evaluator (as a VS Administrator) creates a virtual disk at least that large on the same physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, scan through and check that all the non-metadata (as documented in the TSS) in the file corresponding to that virtual disk is set to zero.
FDP_VMS_EXT.1 VM Separation
FDP_VMS_EXT.1.1
- The VS shall provide the following mechanisms for transferring data between Guest VMs:[selection: no mechanism, virtual networking, other inter-VM data sharing mechanisms ].
+ The VS shall provide the following mechanisms for transferring data between Guest VMs:[selection: no mechanism, virtual networking, [assignment: other inter-VM data sharing mechanisms ]].
@@ -1754,11 +1747,11 @@
FDP_VMS_EXT.1 VM Separation
FDP_VMS_EXT.1.4
- The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1.
+ The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1.
Test that communications can be passed between the VMs through the channel.
Create two new VMs, the first with the inter-VM communications channel currently being tested enabled, and the second with the inter-VM communications channel currently being tested disabled.
Test that communications cannot be passed between the VMs through the channel.
-
- As an Administrator, enable inter-VM communications between the VMs on the second VM.
-
+ As an Administrator, enable inter-VM communications between the VMs on the second VM.
Test that communications can be passed through the inter-VM channel.
As an Administrator again, disable inter-VM communications between the two VMs.
Test that communications can no longer be passed through the channel.
@@ -1842,9 +1833,9 @@
- Application Note: The fundamental requirement of a Virtualization System is the ability to enforce separation between information domains implemented as Virtual Machines and Virtual Networks. The intent of this requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with this fundamental requirement in mind.
+ Application Note: The fundamental requirement of a Virtualization System is the ability to enforce separation between information domains implemented as Virtual Machines and Virtual Networks. The intent of this requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with this fundamental requirement in mind.
- The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” and identify all other mechanisms through which data can be transferred between Guest VMs.
+ The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” and identify all other mechanisms through which data can be transferred between Guest VMs.
Examples of non-network inter-VM sharing mechanisms are:
@@ -1769,9 +1762,9 @@
@@ -1811,9 +1804,7 @@ FDP_VMS_EXT.1 VM Separation
For data transfer mechanisms implemented in terms of Hypercall functions, FDP_VMS_EXT.1.3 is met if FPT_HCL_EXT.1.1 is met for those Hypercall functions (Hypercall function parameters are checked). - For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable). + For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable). - For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 is met (VM access to virtual networks is configurable). + For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 is met (VM access to virtual networks is configurable).FDP_VMS_EXT.1 VM Separation
FDP_VNC_EXT.1 Virtual Networking Components
FDP_VNC_EXT.1.2
- The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment.
+ The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment.
- Application Note: Virtual networks must be separated from one another to provide isolation commensurate with that provided by physically separate networks. It must not be possible for data to cross between properly configured virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host.
+ Application Note: Virtual networks must be separated from one another to provide isolation commensurate with that provided by physically separate networks. It must not be possible for data to cross between properly configured virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host.
Unprivileged users must not be able to connect VMs to each other or to external networks.
@@ -1873,10 +1864,10 @@
FDP_VNC_EXT.1 Virtual Networking Components
- - Test FDP_VNC_EXT.1.2:1: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a network component. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and attempt the same connection. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met. + Test FDP_VNC_EXT.1.2:1: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a network component. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and attempt the same connection. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
- - Test FDP_VNC_EXT.1.2:2: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a physical network. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and make the same attempt. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met. + Test FDP_VNC_EXT.1.2:2: The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect to a physical network. The evaluator shall verify that the attempt is successful. The evaluator shall then assume the role of an unprivileged user and make the same attempt. If the attempt fails, or there is no way for an unprivileged user to configure VM network connections, the requirement is met.
FIA_AFL_EXT.1 Authentication Failure Handling
FIA_AFL_EXT.1.1
- The TSF shall detect when[selection: a positive integer number , an administrator configurable positive integer within a [assignment: range of acceptable values ]]unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using[selection: username and password, username and PIN].
+ The TSF shall detect when[selection: [assignment: a positive integer number ], an administrator configurable positive integer within a [assignment: range of acceptable values ]]unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using[selection: username and password, username and PIN].
@@ -1900,7 +1891,7 @@
FIA_AFL_EXT.1 Authentication Failure Handling
FIA_AFL_EXT.1.2
- When the defined number of unsuccessful authentication attempts has been met, the TSF shall:[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until [assignment: action to unlock ] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed]
+ When the defined number of unsuccessful authentication attempts has been met, the TSF shall:[selection: prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until [assignment: action to unlock ] is taken by an Administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed]
Application Note: The action to be taken shall be populated in the selection of the ST and defined in the Administrator guidance.
@@ -1953,7 +1944,7 @@
@@ -2200,7 +2189,7 @@ FIA_PMG_EXT.1 Password Management
The TSF shall provide the following password management capabilities for administrative passwords:- - Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “& ”, “*”, “(“, “)”, other characters ] + Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “& ”, “*”, “(“, “)”, [assignment: other characters ]]
- Minimum password length shall be configurable
- Passwords of at least 15 characters in length shall be supported @@ -2001,16 +1992,16 @@
- - [selection: local, directory-based] authentication based on username and password + [selection: local, directory-based] authentication based on username and password
- authentication based on username and a PIN that releases an asymmetric key stored in OE-protected storage
- - [selection: local, directory-based] authentication based on X.509 certificates + [selection: local, directory-based] authentication based on X.509 certificates
- - [selection: local, directory-based] authentication based on an SSH public key credential + [selection: local, directory-based] authentication based on an SSH public key credential
- - Test FIA_UAU.5.2:1: The evaluator will attempt to authenticate to the VS using the known username and password. The evaluator will ensure that the authentication attempt is successful. + Test FIA_UAU.5.2:1: The evaluator will attempt to authenticate to the VS using the known username and password. The evaluator will ensure that the authentication attempt is successful.
- - Test FIA_UAU.5.2:2: The evaluator will attempt to authenticate to the VS using the known username but an incorrect password. The evaluator will ensure that the authentication attempt is unsuccessful. + Test FIA_UAU.5.2:2: The evaluator will attempt to authenticate to the VS using the known username but an incorrect password. The evaluator will ensure that the authentication attempt is unsuccessful.
- - Test FIA_UAU.5.2:3: The evaluator will attempt to authenticate to the VS using the known user name and PIN. The evaluator will ensure that the authentication attempt is successful. + Test FIA_UAU.5.2:3: The evaluator will attempt to authenticate to the VS using the known user name and PIN. The evaluator will ensure that the authentication attempt is successful.
- - Test FIA_UAU.5.2:4: The evaluator will attempt to authenticate to the VS using the known user name but an incorrect PIN. The evaluator will ensure that the authentication attempt is unsuccessful. + Test FIA_UAU.5.2:4: The evaluator will attempt to authenticate to the VS using the known user name but an incorrect PIN. The evaluator will ensure that the authentication attempt is unsuccessful.
- - Test FIA_UAU.5.2:5: The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The evaluator will ensure that the authentication attempt is successful. + Test FIA_UAU.5.2:5: The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The evaluator will ensure that the authentication attempt is successful.
- - Test FIA_UAU.5.2:6: The evaluator will generate a second certificate identical to the first except for the public key and any values derived from the public key. The evaluator will attempt to authenticate to the VS with this certificate. The evaluator will ensure that the authentication attempt is unsuccessful. + Test FIA_UAU.5.2:6: The evaluator will generate a second certificate identical to the first except for the public key and any values derived from the public key. The evaluator will attempt to authenticate to the VS with this certificate. The evaluator will ensure that the authentication attempt is unsuccessful.
- - Test FIA_UAU.5.2:7: The evaluator will attempt to authenticate to the VS using a message signed by the client private key that corresponds to provisioned client public key. The evaluator will ensure that the authentication attempt is successful. + Test FIA_UAU.5.2:7: The evaluator will attempt to authenticate to the VS using a message signed by the client private key that corresponds to provisioned client public key. The evaluator will ensure that the authentication attempt is successful.
- - Test FIA_UAU.5.2:8: The evaluator will generate a second client key pair and will attempt to authenticate to the VS with the private key over SSH without first provisioning the VS to support the new key pair. The evaluator will ensure that the authentication attempt is unsuccessful. + Test FIA_UAU.5.2:8: The evaluator will generate a second client key pair and will attempt to authenticate to the VS with the private key over SSH without first provisioning the VS to support the new key pair. The evaluator will ensure that the authentication attempt is unsuccessful.
FIA_UAU.5 Multiple Authentication Mechanisms
The TSF shall provide the following authentication mechanisms:[selection:FIA_UAU.5 Multiple Authentication Mechanisms
-
- If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a known username and password and conduct the following tests:
+ If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a known username and password and conduct the following tests:
-
- If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for guidance on supported protected storage and will then configure the TOE or OE to establish a PIN which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware token, or isolated execution environment) with which the VS can interface. The evaluator will then conduct the following tests:
+ If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for guidance on supported protected storage and will then configure the TOE or OE to establish a PIN which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware token, or isolated execution environment) with which the VS can interface. The evaluator will then conduct the following tests:
-
- If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the following tests:
+ If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the following tests:
-
- If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote client. The evaluator shall provision the VS with the client public key for authentication over SSH, and conduct the following tests:
+ If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote client. The evaluator shall provision the VS with the client public key for authentication over SSH, and conduct the following tests:
FMT_SMO_EXT.1 Separation of Management and Operational Networks
The TSF shall support the separation of management and operational network traffic through[selection: separate physical networks, separate logical networks, trusted channels as defined in FTP_ITC_EXT.1, data encryption using an algorithm specified in FCS_COP.1/UDE].
@@ -2180,13 +2169,13 @@
- Application Note: Management communications must be separate from user workload communications. Administrative network traffic—including communications between physical hosts concerning load balancing, audit data, VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, management traffic also includes VMs transmitted over management networks whether for backup, live migration, or deployment.
+ Application Note: Management communications must be separate from user workload communications. Administrative network traffic—including communications between physical hosts concerning load balancing, audit data, VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, management traffic also includes VMs transmitted over management networks whether for backup, live migration, or deployment.
“Separate physical networks” refers to using separate physical interfaces and cables to isolate management and operational networks from each other.
@@ -2157,16 +2148,14 @@
FMT_SMO_EXT.1 Separation of Management and Operational Networks
The evaluator shall examine the TSS to verify that it describes how management and operational traffic is separated.Guidance
-
- The evaluator shall examine the operational guidance to verify that it details how to configure the VS to keep Management and Operational traffic separate.
-
+ The evaluator shall examine the operational guidance to verify that it details how to configure the VS to keep Management and Operational traffic separate.
Tests
The evaluator shall configure the TOE as documented in the guidance. If separation is logical, then the evaluator shall capture packets on the management network. If plaintext Guest network traffic is detected, the requirement is not met.
If separation uses trusted channels, then the evaluator shall capture packets on the network over which traffic is tunneled. If plaintext Guest network traffic is detected, the requirement is not met.
- If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the requirement is not met.
+ If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the requirement is not met.
FPT_DVD_EXT.1 Non-Existence of Disconnected Virtual Devices
FPT_DVD_EXT.1.1
- The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration.
+ The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration.
- Application Note: The virtualized hardware abstraction implemented by a particular VS might include the virtualized interfaces for many different devices. Sometimes these devices are not present in a particular instantiation of a VM. The interface for devices not present must not be accessible by the VM.
+ Application Note: The virtualized hardware abstraction implemented by a particular VS might include the virtualized interfaces for many different devices. Sometimes these devices are not present in a particular instantiation of a VM. The interface for devices not present must not be accessible by the VM.
Such interfaces include memory buffers, PCI Bus interfaces, and processor I/O ports.
- The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces.
+ The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces.
FPT_DVD_EXT.1 Non-Existence of Disconnected Virtual Devices
Tests
- The evaluator shall connect a device to a VM, then from within the guest scan the VM's devices to ensure that the connected device is present--using a device driver or other available means to scan the VM's I/O ports or PCI Bus interfaces. (The device's interface should be documented in the TSS under FPT_VDP_EXT.1.) The evaluator shall remove the device from the VM and run the scan again. This requirement is met if the device's interfaces are no longer present.
+ The evaluator shall connect a device to a VM, then from within the guest scan the VM's devices to ensure that the connected device is present--using a device driver or other available means to scan the VM's I/O ports or PCI Bus interfaces. (The device's interface should be documented in the TSS under FPT_VDP_EXT.1.) The evaluator shall remove the device from the VM and run the scan again. This requirement is met if the device's interfaces are no longer present.
@@ -2212,7 +2201,7 @@ FPT_EEM_EXT.1 Execution Environment Mitigations
FPT_EEM_EXT.1.1
- The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:[selection: Address space randomization, Memory execution protection (e.g., DEP), Stack buffer overflow protection, Heap corruption detection, other mechanisms , No mechanisms]
+ The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:[selection: Address space randomization, Memory execution protection (e.g., DEP), Stack buffer overflow protection, Heap corruption detection, [assignment: other mechanisms ], No mechanisms]
Application Note: Processor manufacturers, compiler developers, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Software can often take advantage of these mechanisms by using APIs provided by the operating system or by enabling the mechanism through compiler or linker options.
@@ -2246,7 +2235,7 @@
FPT_HAS_EXT.1 Hardware Assists
FPT_HAS_EXT.1.1
- The VMM shall use[assignment: list of hardware-based virtualization assists]to reduce or eliminate the need for binary translation.
+ The VMM shall use[assignment: list of hardware-based virtualization assists]to reduce or eliminate the need for binary translation.
@@ -2254,13 +2243,13 @@
FPT_HAS_EXT.1 Hardware Assists
FPT_HAS_EXT.1.2
- The VMM shall use[assignment: list of hardware-based virtualization memory-handling assists]to reduce or eliminate the need for shadow page tables.
+ The VMM shall use[assignment: list of hardware-based virtualization memory-handling assists]to reduce or eliminate the need for shadow page tables.
@@ -2288,11 +2277,11 @@
- Application Note: These hardware-assists help reduce the size and complexity of the VMM, and thus, of the trusted computing base, by eliminating or reducing the need for paravirtualization or binary translation. Paravirtualization involves modifying guest software so that instructions that cannot be properly virtualized are never executed on the physical processor.
+ Application Note: These hardware-assists help reduce the size and complexity of the VMM, and thus, of the trusted computing base, by eliminating or reducing the need for paravirtualization or binary translation. Paravirtualization involves modifying guest software so that instructions that cannot be properly virtualized are never executed on the physical processor.
- For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all platforms included in the ST that are used by the VMM to reduce or eliminate the need for software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is an acceptable assignment for platforms that do not require virtualization assists in order to eliminate the need for binary translation. This must be documented in the TSS.
+ For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all platforms included in the ST that are used by the VMM to reduce or eliminate the need for software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is an acceptable assignment for platforms that do not require virtualization assists in order to eliminate the need for binary translation. This must be documented in the TSS.
- For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. “None” is an acceptable assignment for platforms that do not require memory-handling assists in order to eliminate the need for shadow page tables. This must be documented in the TSS.
+ For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. “None” is an acceptable assignment for platforms that do not require memory-handling assists in order to eliminate the need for shadow page tables. This must be documented in the TSS.
FPT_HCL_EXT.1 Hypercall Controls
FPT_HCL_EXT.1.1
- The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface.
+ The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface.
@@ -2348,13 +2337,9 @@
- Application Note: The purpose of this requirement is to help ensure the integrity of the VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls.
+ Application Note: The purpose of this requirement is to help ensure the integrity of the VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls.
- A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. For example, a hypercall interface could be used to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest software, these interfaces constitute attack surface.
+ A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. For example, a hypercall interface could be used to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest software, these interfaces constitute attack surface.
There is no expectation that the evaluator will need to review source code in order to accomplish the evaluation activity.
@@ -2318,7 +2307,7 @@ FPT_HCL_EXT.1 Hypercall Controls
The evaluator shall perform the following test:
- For each hypercall interface documented in the TSS or proprietary TSS Annex, the evaluator shall attempt to invoke the function from within the VM using an invalid parameter (if any). If the VMM or VS crashes or generates an exception, or if no error is returned to the guest, then the test fails. If an error is returned to the guest, then the test succeeds.
+ For each hypercall interface documented in the TSS or proprietary TSS Annex, the evaluator shall attempt to invoke the function from within the VM using an invalid parameter (if any). If the VMM or VS crashes or generates an exception, or if no error is returned to the guest, then the test fails. If an error is returned to the guest, then the test succeeds.
FPT_RDM_EXT.1 Removable Devices and Media
For purposes of this requirement, an Information Domain is:-
-
- - A VM or collection of VMs - +
- A VM or collection of VMs
- The Virtualization System -
- - Host OS - +
- Host OS
- Management Subsystem
FPT_RDM_EXT.1 Removable Devices and Media
-
The evaluator shall perform the following test for each listed media or device:
- - Test FPT_RDM_EXT.1.2:1: The evaluator shall configure two VMs that are members of different information domains, with the media or device connected to one of the VMs. The evaluator shall disconnect the media or device from the VM and connect it to the other VM. The evaluator shall verify that the action performed is consistent with the action assigned in the TSS. + Test FPT_RDM_EXT.1.2:1: The evaluator shall configure two VMs that are members of different information domains, with the media or device connected to one of the VMs. The evaluator shall disconnect the media or device from the VM and connect it to the other VM. The evaluator shall verify that the action performed is consistent with the action assigned in the TSS.
FPT_VDP_EXT.1 Virtual Device Parameters
FPT_VDP_EXT.1.1
- The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction.
+ The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction.
@@ -2490,9 +2475,9 @@
FPT_VDP_EXT.1 Virtual Device Parameters
FPT_VDP_EXT.1.2
- The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces.
+ The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces.
- Application Note: The purpose of this requirement is to ensure that the VMM is not vulnerable to compromise through the processing of malformed data passed to the virtual device interface from a Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual device interface is unique to the VS and the data comes from a virtual device driver supplied by the Virtualization Vendor.
+ Application Note: The purpose of this requirement is to ensure that the VMM is not vulnerable to compromise through the processing of malformed data passed to the virtual device interface from a Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual device interface is unique to the VS and the data comes from a virtual device driver supplied by the Virtualization Vendor.
@@ -2510,7 +2495,7 @@ FPT_VDP_EXT.1 Virtual Device Parameters
TSS
- The evaluator shall examine the TSS to ensure it lists all virtual devices accessible by the guest OS. The TSS, or a separate proprietary document, must also document all virtual device interfaces at the level of I/O ports or PCI Bus interfaces - including port numbers (absolute or relative to a base), port name, address range, and a description of legal input values.
+ The evaluator shall examine the TSS to ensure it lists all virtual devices accessible by the guest OS. The TSS, or a separate proprietary document, must also document all virtual device interfaces at the level of I/O ports or PCI Bus interfaces - including port numbers (absolute or relative to a base), port name, address range, and a description of legal input values.
The TSS must also describe the expected behavior of the interface when presented with illegal input values. This behavior must be deterministic and indicative of parameter checking by the TSF.
@@ -2532,7 +2517,7 @@
FPT_VIV_EXT.1 VMM Isolation from VMs
FPT_VIV_EXT.1.1
- The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform.
+ The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform.
@@ -2540,24 +2525,22 @@
FPT_VIV_EXT.1 VMM Isolation from VMs
FPT_VIV_EXT.1.2
- The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM.
+ The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM.
- Application Note: This requirement is intended to ensure that software running within a Guest VM cannot compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM software—whatever its privilege level—can crash the VS or the Platform, or breakout of its virtual hardware abstraction to gain execution on the platform, within or outside of the context of the VMM.
+ Application Note: This requirement is intended to ensure that software running within a Guest VM cannot compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM software—whatever its privilege level—can crash the VS or the Platform, or breakout of its virtual hardware abstraction to gain execution on the platform, within or outside of the context of the VMM.
- This requirement is not violated if software running within a VM can crash the Guest OS and there is no way for an attacker to gain execution in the VMM or outside of the virtualized domain.
+ This requirement is not violated if software running within a VM can crash the Guest OS and there is no way for an attacker to gain execution in the VMM or outside of the virtualized domain.
- FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and invoke privileged code on the Platform.
+ FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and invoke privileged code on the Platform.
At a minimum, the TSF should enforce the following:
@@ -2575,7 +2558,7 @@ - On the x86 platform, a virtual System Management Interrupt (SMI) cannot invoke platform System Management Mode (SMM).
- An attempt to update virtual firmware or virtual BIOS cannot cause physical platform firmware or physical platform BIOS to be modified. -
- - An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified. - +
- An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified.
FPT_VIV_EXT.1 VMM Isolation from VMs
TSS
- The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note.
+ The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note.
@@ -2625,7 +2608,7 @@ FTP_ITC_EXT.1 Trusted Channel Communications
Application Note: If the ST author selects either TLS or HTTPS, the TSF shall be validated against the Functional Package for TLS. This PP does not mandate that a product implement TLS with mutual authentication, but if the product includes the capability to perform TLS with mutual authentication, then mutual authentication must be included within the TOE boundary. The TLS Package requires that the X509 requirements be included by the PP, so selection of TLS or HTTPS causes FIA_X509_EXT.* to be selected.
@@ -2656,7 +2639,7 @@
FTP_ITC_EXT.1 Trusted Channel Communications
Tests
- The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.
+ The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.
@@ -2741,11 +2724,11 @@ FTP_UIF_EXT.1 User Interface: I/O Focus
FTP_UIF_EXT.1.1
- The TSF shall indicate to users which VM, if any, has the current input focus.
+ The TSF shall indicate to users which VM, if any, has the current input focus.
@@ -2767,7 +2750,7 @@
- Application Note: This requirement applies to all users—whether User or Administrator. In environments where multiple VMs run at the same time, the user must have a way of knowing which VM user input is directed to at any given moment. This is especially important in multiple-domain environments.
+ Application Note: This requirement applies to all users—whether User or Administrator. In environments where multiple VMs run at the same time, the user must have a way of knowing which VM user input is directed to at any given moment. This is especially important in multiple-domain environments.
- In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is considered to be a program, but this program still needs to know which VM it is sending input to; this would typically be accomplished through programmatic means.
+ In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is considered to be a program, but this program still needs to know which VM it is sending input to; this would typically be accomplished through programmatic means.
FTP_UIF_EXT.1 User Interface: I/O Focus
The evaluator shall ensure that the operational guidance specifies how the current input focus is indicated to the user.
Tests
- For each supported input device, the evaluator shall demonstrate that the input from each device listed in the TSS is directed to the VM that is indicated to have the input focus.
+ For each supported input device, the evaluator shall demonstrate that the input from each device listed in the TSS is directed to the VM that is indicated to have the input focus.
@@ -2779,11 +2762,11 @@ FTP_UIF_EXT.2 User Interface: Identification of VM
FTP_UIF_EXT.2.1
- The TSF shall support the unique identification of a VM’s output display to users.
+ The TSF shall support the unique identification of a VM’s output display to users.
@@ -2805,7 +2788,7 @@
- Application Note: In environments where a user has access to more than one VM at the same time, the user must be able to determine the identity of each VM displayed in order to avoid inadvertent cross-domain data entry.
+ Application Note: In environments where a user has access to more than one VM at the same time, the user must be able to determine the identity of each VM displayed in order to avoid inadvertent cross-domain data entry.
- There must be a mechanism for associating an identifier with a VM so that an application or program displaying the VM can identify the VM to users. This is generally indicated visually for human users (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API function). The identification must be unique to the VS, but does not need to be universally unique.
+ There must be a mechanism for associating an identifier with a VM so that an application or program displaying the VM can identify the VM to users. This is generally indicated visually for human users (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API function). The identification must be unique to the VS, but does not need to be universally unique.
FTP_UIF_EXT.2 User Interface: Identification of VM
The evaluator shall perform the following test:
- The evaluator shall attempt to create and start at least three Guest VMs on a single display device where the evaluator attempts to assign two of the VMs the same identifier. If the user interface displays different identifiers for each VM, then the requirement is met. Likewise, the requirement is met if the system refuses to create or start a VM when there is already a VM with the same identifier.
+ The evaluator shall attempt to create and start at least three Guest VMs on a single display device where the evaluator attempts to assign two of the VMs the same identifier. If the user interface displays different identifiers for each VM, then the requirement is met. Likewise, the requirement is met if the system refuses to create or start a VM when there is already a VM with the same identifier.
@@ -2873,7 +2856,7 @@ 5.1.9 TOE Security Functio
FPT_EEM_EXT.1 Requires that the TOE use security mechanisms supported by the physical platform.
5.1.9 TOE Security Functio
FPT_HCL_EXT.1 Requires that Hypercall parameters be validated.
5.1.9 TOE Security Functio
FPT_HCL_EXT.1 Requires that Hypercall parameters be validated.
5.1.9 TOE Security Functio
5.2 Security Assurance Requirements
++ The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. +
5.2.1 Class ASE: Security Target Evaluation
As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.5.2.2 Class ADV: Development
@@ -3100,7 +3081,7 @@Developer action elements:
The developer shall provide a tracing from the functional specification to the SFRs.
@@ -3151,7 +3132,17 @@
- Developer Note: As indicated in the introduction to this section, the functional specification is composed of the information contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
+ Note: As indicated in the introduction to this section, the functional specification is composed of the information contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
Evaluator action elements:
The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.
+
+
@@ -3179,7 +3170,7 @@
- Application Note: There are no specific evaluation activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 5.2, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.
+ Note: There are no specific evaluation activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 5.2, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.
+
+ Developer action elements:
The developer shall provide operational user guidance.
@@ -3189,7 +3180,7 @@
- Developer Note: Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluators will be checking for. This will provide the necessary information for the preparation of acceptable guidance.
+ Note: Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluators will be checking for. This will provide the necessary information for the preparation of acceptable guidance.
Content and presentation elements:
AGD_OPE.1.1C
- The operational user guidance shall describe what for each user role the authorized user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
+ The operational user guidance shall describe what for each user role the authorized user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
@@ -3197,7 +3188,7 @@
Content and presentation elements:
AGD_OPE.1.2C
- The operational user guidance shall describe, for each user role the authorized user, how to use the available interfaces provided by the TOE in a secure manner.
+ The operational user guidance shall describe, for each user role the authorized user, how to use the available interfaces provided by the TOE in a secure manner.
@@ -3205,7 +3196,7 @@
Content and presentation elements:
AGD_OPE.1.3C
- The operational user guidance shall describe, for each user role the authorized user, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
+ The operational user guidance shall describe, for each user role the authorized user, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
@@ -3213,7 +3204,7 @@
Content and presentation elements:
AGD_OPE.1.4C
- The operational user guidance shall, for each user role the authorized user, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
+ The operational user guidance shall, for each user role the authorized user, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
@@ -3229,7 +3220,7 @@
Content and presentation elements:
AGD_OPE.1.6C
- The operational user guidance shall, for each user role the authorized user, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.
+ The operational user guidance shall, for each user role the authorized user, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.
@@ -3257,7 +3248,7 @@
@@ -3329,7 +3320,7 @@ Evaluator action elements:
The operational guidance shall contain instructions for configuring the password characteristics, number of allowed authentication attempt failures, the lockout period times for inactivity, and the notice and consent warning that is to be provided when authenticating. - The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. + The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. The documentation shall describe the process for verifying updates to the TOE, either by checking the hash or by verifying a digital signature. The evaluator shall verify that this process includes the following steps:-
@@ -3283,7 +3274,7 @@
Developer action elements:
The developer shall provide the TOE including its preparative procedures.
- Developer Note: As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.
+ Note: As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.
Evaluator action elements:
As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST. - The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. + The operational guidance shall contain step-by-step instructions suitable for use by an end-user of the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. @@ -3426,7 +3417,7 @@Evaluator action elements:
ALC_TSU_EXT.1 Timely Security Updates
- This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public. + This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public.Developer action elements:
@@ -3452,7 +3443,7 @@
@@ -3463,7 +3454,7 @@ Content and presentation elements:
The description shall express the time window as the length of time, in days, between public disclosure of a vulnerability and the public availability of security updates to the TOE.
- Application Note: The total length of time may be presented as a summation of the periods of time that each party (e.g., TOE developer, hardware vendor) on the critical path consumes. The time period until public availability per deployment mechanism may differ; each is described.
+ Note: The total length of time may be presented as a summation of the periods of time that each party (e.g., TOE developer, hardware vendor) on the critical path consumes. The time period until public availability per deployment mechanism may differ; each is described.
Content and presentation elements:
The description shall include the mechanisms publicly available for reporting security issues pertaining to the TOE.
- Application Note: The reporting mechanism could include websites, email addresses, and a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).
+ Note: The reporting mechanism could include websites, email addresses, and a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).
Evaluator action elements:
The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
+
5.2.5 Class ATE: Tests
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. @@ -3610,7 +3611,7 @@FAU_ARP.1 Security Audit Automatic Response
The TSF shall take[assignment: list of actions]upon detection of a potential security violation.
- Application Note: In certain cases, it may be useful for Virtualization Systems to perform automated responses to certain security events. An example may include halting a VM which has taken some action to violate a key system security policy. This may be especially useful with headless endpoints when there is no human user in the loop.
+ Application Note: In certain cases, it may be useful for Virtualization Systems to perform automated responses to certain security events. An example may include halting a VM which has taken some action to violate a key system security policy. This may be especially useful with headless endpoints when there is no human user in the loop.
The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
@@ -3683,9 +3684,9 @@ FPT_GVI_EXT.1 Guest VM Integrity
FPT_GVI_EXT.1.1
- The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment: list of Guest VM integrity mechanisms].
+ The TSF shall verify the integrity of Guest VMs through the following mechanisms:[assignment: list of Guest VM integrity mechanisms].
@@ -3701,7 +3702,7 @@
- Application Note: The primary purpose of this requirement is to identify and describe the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion, though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. Importation for this requirement could include VM migration (live or otherwise), the importation of virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a trusted VM could have been modified during the migration or import/export process, or VMs could have been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a prudent measure to take. These integrity checks could be as thorough as making sure the entire VM exactly matches a previously known VM (by hash for example), or by simply checking certain configuration settings to ensure that the VM's configuration will not violate the security model of the VS.
+ Application Note: The primary purpose of this requirement is to identify and describe the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion, though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. Importation for this requirement could include VM migration (live or otherwise), the importation of virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a trusted VM could have been modified during the migration or import/export process, or VMs could have been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a prudent measure to take. These integrity checks could be as thorough as making sure the entire VM exactly matches a previously known VM (by hash for example), or by simply checking certain configuration settings to ensure that the VM's configuration will not violate the security model of the VS.
FPT_GVI_EXT.1 Guest VM Integrity
TSS
- For each mechanism listed in the assignment, the evaluator shall ensure that the TSS documents the mechanism, including how it verifies VM integrity, which set of Guest VMs it will check (all Guest VMs, only migrated VM s, etc.), when such checks occur (before VM startup, immediately following importation/migration, on demand, etc.), and which actions are taken if a VM fails the integrity check (or which range of actions are possible if the action is configurable).
+ For each mechanism listed in the assignment, the evaluator shall ensure that the TSS documents the mechanism, including how it verifies VM integrity, which set of Guest VMs it will check (all Guest VMs, only migrated VM s, etc.), when such checks occur (before VM startup, immediately following importation/migration, on demand, etc.), and which actions are taken if a VM fails the integrity check (or which range of actions are possible if the action is configurable).
@@ -3715,9 +3716,9 @@ FPT_DDI_EXT.1 Device Driver Isolation
FPT_DDI_EXT.1.1
- The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.
+ The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains.
@@ -3794,11 +3795,11 @@
- Application Note: In order to function on physical hardware, the VMM must have access to the device drivers for the physical platform on which it runs. These drivers are often written by third parties, and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality of third party code that the virtualization vendor has no control over. By encapsulating these drivers within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
+ Application Note: In order to function on physical hardware, the VMM must have access to the device drivers for the physical platform on which it runs. These drivers are often written by third parties, and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality of third party code that the virtualization vendor has no control over. By encapsulating these drivers within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained.
FPT_INT_EXT.1 Support for Introspection
FPT_INT_EXT.1.1
- The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.
+ The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection.
@@ -3814,7 +3815,7 @@
- Application Note: Introspection can be used to support malware and anomaly detection from outside of the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt to break out of the VM and compromise the VMM or other VMs.
+ Application Note: Introspection can be used to support malware and anomaly detection from outside of the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt to break out of the VM and compromise the VMM or other VMs.
- The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure the integrity of the malware detection/antivirus software. This capability can be implemented in the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained and does not introduce bugs into the VMM.
+ The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure the integrity of the malware detection/antivirus software. This capability can be implemented in the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained and does not introduce bugs into the VMM.
FPT_INT_EXT.1 Support for Introspection
TSS
- The evaluator shall examine the TSS documentation to verify that it describes the interface for VM introspection and whether the introspection is performed by the VMM or another VM.
+ The evaluator shall examine the TSS documentation to verify that it describes the interface for VM introspection and whether the introspection is performed by the VMM or another VM.
Guidance
The evaluator shall examine the operational guidance to ensure that it contains instructions for configuration of the introspection mechanism.
@@ -3828,7 +3829,7 @@ FPT_ML_EXT.1 Measured Launch of Platform and VMM
FPT_ML_EXT.1.1
- The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:[selection: Static executable images of the Management Subsystem, list of (static images of) Service VMs , list of configuration files , no other components]
+ The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:[selection: Static executable images of the Management Subsystem, [assignment: list of (static images of) Service VMs ], [assignment: list of configuration files ], no other components]
@@ -3838,9 +3839,9 @@
FPT_ML_EXT.1 Measured Launch of Platform and VMM
The TSF shall make the measurements selected in FPT_ML_EXT.1.1 available to the Management Subsystem.
- Application Note: A measured launch of the platform and VS demonstrates that the proper TOE software was loaded. A measured launch process employs verifiable integrity measurement mechanisms. For example, a VS may hash components such as the hypervisor, service VMs, or the Management Subsystem. A measured launch process only allows components to be executed after the measurement has been recorded. An example process may add each component’s hash before it is executed so that the final hash reflects the evidence of a component’s state prior to execution. The measurement may be verified as the system boots, but this is not required.
+ Application Note: A measured launch of the platform and VS demonstrates that the proper TOE software was loaded. A measured launch process employs verifiable integrity measurement mechanisms. For example, a VS may hash components such as the hypervisor, service VMs, or the Management Subsystem. A measured launch process only allows components to be executed after the measurement has been recorded. An example process may add each component’s hash before it is executed so that the final hash reflects the evidence of a component’s state prior to execution. The measurement may be verified as the system boots, but this is not required.
- The Platform is outside of the TOE. However, this requirement specifies that the VS must be capable of receiving Platform measurements if the Platform provides them. This requirement is requiring TOE support for Platform measurements if provided; it is not placing a requirement on the Platform to take such measurements.
+ The Platform is outside of the TOE. However, this requirement specifies that the VS must be capable of receiving Platform measurements if the Platform provides them. This requirement is requiring TOE support for Platform measurements if provided; it is not placing a requirement on the Platform to take such measurements.
If available, hardware should be used to store measurements in such a manner that they cannot be modified in any manner except to be extended. These measurements should be produced in a repeatable manner so that a third party can verify the measurements if given the inputs. Hardware devices, like Trusted Platform Modules (TPM), TrustZone, and MMU are some examples that may serve as foundations for storing and reporting measurements.
@@ -3867,7 +3868,7 @@
FPT_ML_EXT.1 Measured Launch of Platform and VMM
- - Test FPT_ML_EXT.1.2:1: The evaluator shall start the VS, login as an Administrator, and verify that the measurements for the specified components are viewable in the Management Subsystem. + Test FPT_ML_EXT.1.2:1: The evaluator shall start the VS, login as an Administrator, and verify that the measurements for the specified components are viewable in the Management Subsystem.
FCS_IPSEC_EXT.1 IPsec Protocol
[selection:- - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH] + IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], [selection: no other RFCs for hash functions, RFC 4868 for hash functions], and [selection: support for XAUTH, no support for XAUTH]
- - IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions]. + IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].
FCS_IPSEC_EXT.1 IPsec Protocol
The TSF shall ensure that[selection:- - IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time] + IKEv2 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- - IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time] + IKEv1 SA lifetimes can be configured by [selection: an Administrator, a VPN Gateway] based on [selection: number of packets/number of bytes, length of time]
- - IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs. + IKEv1 SA lifetimes are fixed based on [selection: number of packets/number of bytes, length of time]. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
FCS_IPSEC_EXT.1 IPsec Protocol
FCS_IPSEC_EXT.1.12
- The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, other supported reference identifier types ]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.
+ The TSF shall not establish an SA if the [[selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]and[selection: no other reference identifier type, [assignment: other supported reference identifier types ]]] contained in a certificate does not match the expected values for the entity attempting to establish a connection.
Application Note: The TOE must support at least one of the following identifier types: IP address, Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN). In the future, the TOE will be required to support all of these identifier types. The TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP versions supported by the TOE in general. The ST author may assign additional supported identifier types in the second selection.
@@ -4149,7 +4150,7 @@ FCS_IPSEC_EXT.1 IPsec Protocol
If the configuration of the IPsec behavior is from an environmental source, most notably a VPN gateway (e.g through receipt of required connection parameters from a VPN gateway), the evaluator shall ensure that the operational guidance contains any appropriate information for ensuring that this configuration can be properly applied. - Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec functionality implemented totally or in part by the underlying OS platform. The behavior referenced here is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD from the client (e.g., enforcement of packet routing decisions). + Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec functionality implemented totally or in part by the underlying OS platform. The behavior referenced here is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD from the client (e.g., enforcement of packet routing decisions).Tests
@@ -4604,7 +4605,7 @@ FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1
- The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, other uses ]
+ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[selection: IPsec, TLS, HTTPS, SSH, code signing for system software updates, [assignment: other uses ]]
3.3 O
E.3 Specific Guidance for
1.2.1 Common Criteria Terms
3.3 O
D.3 Specific Guidance for
Application Note: This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital signature mechanism,” if "certificate-based authentication of the remote peer" is selected in FTP_ITC_EXT.1, or if "authentication based on X.509 certificates" is selected in FIA_UAU.5.1.
@@ -4837,7 +4838,7 @@ E.4 Specific Guidance f
3.3 O
E.3 Specific Guidance for
3.3 O
@@ -3888,13 +3966,13 @@A.1 Strictly Optional R
not an issue because there is likely to be a different product model for different hardware environments.
E.4 Specific Guidance f
E.5 Specific Guidance for Determining Platform Equivalence
- Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.
+ Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.
E.5.1 Hardware Platform Equivalence
@@ -4847,13 +4848,13 @@ E.5.1 Hardware Platf
Platforms with different processor architectures and instruction sets are not equivalent. This is probably not an issue because there is likely to be a different product model for different hardware environments.
- Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application.
+ Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified security functionality.
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
@@ -4909,19 +4910,19 @@ E.6 Level of Specificity
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
- Bare-Metal VS
+ Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the claimed equivalent configuration.
- VS with OS Support
+ VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
Appendix F - Acronyms
- Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application. + Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality. + For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified security functionality. + The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence @@ -4909,19 +4910,19 @@
E.6 Level of Specificity
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
- The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
+ The information regarding claimed equivalent configurations depends on the platform that the VS was developed for and runs on.
- Bare-Metal VS
+ Bare-Metal VS
For VSes that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE operates differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the claimed equivalent configuration.
- VS with OS Support
+ VS with OS Support
- For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
+ For VSes that run on an OS host or with the assistance of an OS, then the claimed configuration must describe the OS down to its specific model and version number. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
Appendix F - Acronyms
| OE | Operational Environment |
| OS | Guest Operating System | -
| OS | Host Operating System | -
| PP | Protection Profile |
| SFR | Security Functional Requirement |
| SSP | System Security Policy | -
| ST | Security Target |
| TSS | TOE Summary Specification |
| VM | Virtual Machine | -
| VMM | Virtual Machine Manager | -
| VS | Virtualization System | -
Appendix G - Bibliography
TDs Applied
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
A.1.1Class: Security Audit (FAU)A.1.2Class: Protection of the TSF (FPT)A.2Objective Requirements
A.2.1Class: Protection of the TSF (FPT)A.3Implementation-dependent Requirements
Appendix B - Selection-based Requirements
@@ -678,7 +678,7 @@ 1.2.1 Common Criteria Terms
1.2.1 Common Criteria Terms
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.2.1 Common Criteria Terms
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
Guest Network
Guest Operating System (OS)
Guest Operating System
Guest VM
Host Operating System (OS)
Host Operating System
Hypercall
1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
System Security Policy (SSP)
System Security Policy
User
Virtual Machine (VM)
Virtual Machine
Virtual Machine Manager (VMM)
Virtual Machine Manager
Virtualization System (VS)
Virtualization System
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
- 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.
- 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
- Package Claims
3 Security Problem Definition
-3.1 Threats
-- 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
-- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -759,17 +758,17 @@3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
-
| Threat, Assumption, or OSP | Security Objectives | Rationale | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.3P_SOFTWARE | O.VMM_INTEGRITY | The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DATA_LEAKAGE | O.DOMAIN_INTEGRITY | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DENIAL_OF_SERVICE | O.RESOURCE_ALLOCATION | The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.MISCONFIGURATION | O.CORRECTLY_APPLIED_CONFIGURATION | Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.PLATFORM_COMPROMISE | O.PLATFORM_INTEGRITY | Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_ACCESS | O.MANAGEMENT_ACCESS | Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_MODIFICATION | O.AUDIT | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VMM_INTEGRITY | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_UPDATE | O.VMM_INTEGRITY | System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNPATCHED_SOFTWARE | O.PATCHED_SOFTWARE | The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.USER_ERROR | O.VM_ISOLATION | Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.VMM_COMPROMISE | O.VMM_INTEGRITY | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.WEAK_CRYPTO | O.VM_ENTROPY | Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| A.NON_MALICIOUS_USER | OE.CONFIG | If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+
5.2 Security Assurance Requirements- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The - Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP - identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the - documentation applicable for the evaluation and performs independent testing. - This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information - Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual - evaluation activities to be performed are specified in both Section 5.1 as well as in this section. - After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain - the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform - actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained - within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply - to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also - provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. - -5.2.1 Class ASE: Security Target Evaluation+5.2 Security Assurance Requirements+The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. +5.2.1 Class ASE: Security Target EvaluationAs per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. -5.2.2 Class ADV: Development+ +5.2.2 Class ADV: Development+ The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2 should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. -ADV_FSP.1 Basic functional specificationDeveloper action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs.
+
+ Developer
+
+ ADV_FSP.1 Basic functional specification+ + + + + + + + +Developer action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs. 5.2.3 Class AGD: Guidance Documents+5.2.3 Class AGD: Guidance Documents+ The guidance documents will be provided with the developer’s security target. Guidance must include a description of how the authorized user verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by an authorized user. @@ -2826,22 +2837,33 @@5.2.2 Class ADV: DevelopmentSFRs where applicable.
- AGD_OPE.1 Operational User GuidanceDeveloper action elements:The developer shall provide operational user guidance.
-
+
+ Developer
+
+ AGD_OPE.1 Operational User Guidance+ + + + + + + + + +Developer action elements:The developer shall provide operational user guidance.
+
Note:
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance. Content and presentation elements:The operational user guidance shall describe what Content and presentation elements:The operational user guidance shall describe what The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation. The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall be clear and reasonable. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. AGD_PRE.1 Preparative proceduresDeveloper action elements:The developer shall provide the TOE including its preparative procedures.
- Developer
+ was successful or unsuccessful. This includes generation of the hash/digital signature. AGD_PRE.1 Preparative procedures+ + + + + +Developer action elements:The developer shall provide the TOE including its preparative procedures.
+
Note:
As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
@@ -2880,16 +2909,24 @@ 5.2.2 Class ADV: DevelopmentTOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST.The operational guidance shall contain step-by-step instructions suitable for use by an end-user of - the VS to configure a new, out-of-the-box system into the configuration evaluated + the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. -5.2.4 Class ALC: Life-Cycle Support+5.2.4 Class ALC: Life-Cycle Support+ At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of the TOE vendor’s development and configuration management process in order to provide a baseline level of assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product. -ALC_CMC.1 Labeling of the TOEDeveloper action elements:The developer shall provide the TOE and a reference for the TOE.
+
+ ALC_CMC.1 Labeling of the TOE+ + + +Developer action elements:Content and presentation elements:The TOE shall be labeled with its unique reference.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
@@ -2899,7 +2936,13 @@ 5.2.2 Class ADV: DevelopmentTOE samples received for testing to ensure that the version number is consistent with that in the ST.If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that - the information in the ST is sufficient to distinguish the product.ALC_CMS.1 TOE CM coverageDeveloper action elements:ALC_CMS.1 TOE CM coverage+ + + + +Developer action elements:The developer shall provide a configuration list for the TOE.
Content and presentation elements:The configuration list shall uniquely identify the configuration items.
@@ -2915,37 +2958,50 @@ 5.2.2 Class ADV: DevelopmentTSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification. -ALC_TSU_EXT.1 Timely Security Updates+ALC_TSU_EXT.1 Timely Security Updates+ This component requires the TOE developer, in conjunction with any other necessary parties, to provide information - as to how the VS is updated to address security issues in a timely manner. The + as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public. -Developer action elements:The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:Content and presentation elements:The description shall include the process for creating and deploying security updates for the TOE
software/firmware. The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE. Application
+ of a vulnerability and the public availability of security updates to the TOE.
Note:
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
availability per deployment mechanism may differ; each is described. The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE. Application
+ pertaining to the TOE.
Note:
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
proof-of-concept exploit). Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. 5.2.5 Class ATE: Tests+ presentation of evidence.5.2.5 Class ATE: Tests+ Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. -ATE_IND.1 Independent Testing - Conformance+ +ATE_IND.1 Independent Testing - Conformance+ Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operation) documentation provided. The focus of the testing is to confirm that the requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs @@ -2953,7 +3009,12 @@Developer action elements:TOE combinations that are claiming conformance to this PP.
- Developer action elements:The developer shall provide the TOE for testing.
+
+
+
+
+
+ Developer action elements:The developer shall provide the TOE for testing.
Content and presentation elements:The TOE shall be suitable for testing.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
@@ -2985,7 +3046,10 @@
+
+ Developer action elements:5.2.6 Class AVA: Vulnerability Assessment
+ 5.2.6 Class AVA: Vulnerability Assessment+ For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly @@ -2994,7 +3058,14 @@Developer action elements:PPs.
- AVA_VAN.1 Vulnerability surveyDeveloper action elements:The developer shall provide the TOE for testing.
+
+ AVA_VAN.1 Vulnerability survey+ + + + + +Developer action elements:The developer shall provide the TOE for testing.
Content and presentation elements:The TOE shall be suitable for testing.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
@@ -3014,6 +3085,8 @@ Developer action elements:Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
@@ -3038,7 +3111,7 @@ A.1 Strictly Optional R
list of actions]upon detection of a potential security violation. |
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided - into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is - installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated - into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare + into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is + installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated + into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.E.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily @@ -4093,15 +4170,15 @@E.3 Specific Guidance for
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
| Factor | Same/Different/None | Guidance | ||
| Platform Architectures | Different | Hardware platforms that implement different processor architectures and instruction sets are not equivalent. | ||
| PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -4127,15 +4204,15 @@ E.3 Specific Guidance for
EP | Extended Package | |
| FP | Functional Package | |||
| OE | Operational Environment | |||
| OS | Guest Operating System | |||
| OS | Host Operating System | |||
| PP | Protection Profile | |||
| PP-Configuration | Protection Profile Configuration | |||
| PP-Module | Protection Profile Module | |||
| SAR | Security Assurance Requirement | |||
| SFR | Security Functional Requirement | |||
| SSP | System Security Policy | |||
| ST | Security Target | |||
| TOE | Target of Evaluation | |||
| TSF | TOE Security Functionality | |||
| TSFI | TSF Interface | |||
| TSS | TOE Summary Specification | |||
| VM | Virtual Machine | |||
| VMM | Virtual Machine Manager | |||
| VS | Virtualization System |
Appendix G - Bibliography
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|
TDs Applied
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
A.1.1Class: Security Audit (FAU)A.1.2Class: Protection of the TSF (FPT)A.2Objective Requirements
A.2.1Class: Protection of the TSF (FPT)A.3Implementation-dependent Requirements
Appendix B - Selection-based Requirements
@@ -674,7 +674,7 @@ 1.1 Compliant Targets o
or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected
by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem.
1.1 Compliant Targets o
or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected
by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem.
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.1 Compliant Targets o
to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be
considered a Helper VM. For the purposes of this document, Helper VMs are considered a type of Guest VM, and are
therefore subject to all the same requirements, unless specifically stated otherwise.
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.1 Compliant Targets o
designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices,
VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that
help establish communication paths between VMs.
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators. Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
Guest Network
Guest Operating System (OS)
Guest Operating System
Guest VM
Host Operating System (OS)
Host Operating System
Hypercall
1.1 Compliant Targets o
designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices,
VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that
help establish communication paths between VMs.
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators. Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
System Security Policy (SSP)
System Security Policy
User
Virtual Machine (VM)
Virtual Machine
Virtual Machine Manager (VMM)
Virtual Machine Manager
Virtualization System (VS)
Virtualization System
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
- 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.
- 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
- Package Claims
3 Security Problem Definition
-3.1 Threats
-- 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
-- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -751,16 +750,16 @@3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
- security policies map to the security objectives.
| Threat, Assumption, or OSP | Security Objectives | Rationale | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.3P_SOFTWARE | O.VMM_INTEGRITY | The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DATA_LEAKAGE | O.DOMAIN_INTEGRITY | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DENIAL_OF_SERVICE | O.RESOURCE_ALLOCATION | The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.MISCONFIGURATION | O.CORRECTLY_APPLIED_CONFIGURATION | Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.PLATFORM_COMPROMISE | O.PLATFORM_INTEGRITY | Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_ACCESS | O.MANAGEMENT_ACCESS | Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_MODIFICATION | O.AUDIT | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VMM_INTEGRITY | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_UPDATE | O.VMM_INTEGRITY | System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNPATCHED_SOFTWARE | O.PATCHED_SOFTWARE | The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.USER_ERROR | O.VM_ISOLATION | Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.VMM_COMPROMISE | O.VMM_INTEGRITY | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.WEAK_CRYPTO | O.VM_ENTROPY | Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| A.NON_MALICIOUS_USER | OE.CONFIG | If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+ security policies map to the security objectives.
5.2 Security Assurance Requirements- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The - Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP - identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the - documentation applicable for the evaluation and performs independent testing. - This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information - Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual - evaluation activities to be performed are specified in both Section 5.1 as well as in this section. - After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain - the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform - actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained - within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply - to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also - provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. -5.2.1 Class ASE: Security Target Evaluation- As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE.5.2.2 Class ADV: Development+5.2 Security Assurance Requirements+The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. +5.2.1 Class ASE: Security Target Evaluation+ As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. +5.2.2 Class ADV: Development+ The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2 should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. -ADV_FSP.1 Basic functional specificationDeveloper action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs.
+
+ Developer
+
+ ADV_FSP.1 Basic functional specification+ + + + + + + + +Developer action elements:The developer shall provide a functional specification. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs. Application
+ the SFRs.
Note:
There are no specific evaluation activities associated with these SARs. The functional specification documentation
@@ -2701,7 +2710,10 @@ 5.2.1 Class ASE: Security Targe AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional - specification has not been provided.5.2.3 Class AGD: Guidance Documents+ specification has not been provided.5.2.3 Class AGD: Guidance Documents+ The guidance documents will be provided with the developer’s security target. Guidance must include a description of how the authorized user verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by an authorized user. @@ -2711,21 +2723,32 @@5.2.1 Class ASE: Security Targe
environment.
Guidance pertaining to particular security functionality is also provided; specific requirements on such guidance are
contained in the evaluation activities specified with individual SFRs where applicable.
- AGD_OPE.1 Operational User GuidanceDeveloper action elements:The developer shall provide operational user guidance. Developer
+
+ AGD_OPE.1 Operational User Guidance+ + + + + + + + + +Developer action elements:The developer shall provide operational user guidance. Content and presentation elements:The operational user guidance shall describe what Content and presentation elements:The operational user guidance shall describe what The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall be clear and reasonable. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. AGD_PRE.1 Preparative proceduresDeveloper action elements:
+ AGD_PRE.1 Preparative procedures+ + + + + +Developer action elements:Content and presentation elements:The preparative procedures shall describe all the steps necessary for secure acceptance of the
@@ -2762,21 +2792,35 @@ 5.2.1 Class ASE: Security Targe TOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST.The operational guidance shall contain step-by-step instructions suitable for use by an end-user of - the VS to configure a new, out-of-the-box system into the configuration evaluated - under this Protection Profile.5.2.4 Class ALC: Life-Cycle Support+ the VS to configure a new, out-of-the-box system into the configuration evaluated + under this Protection Profile.5.2.4 Class ALC: Life-Cycle Support+ At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of the TOE vendor’s development and configuration management process in order to provide a baseline level of assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product. -ALC_CMC.1 Labeling of the TOEDeveloper action elements:Content and presentation elements:Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
+
+ ALC_CMC.1 Labeling of the TOE+ + + +Developer action elements:Content and presentation elements:Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. ALC_CMS.1 TOE CM coverageDeveloper action elements:Content and presentation elements:ALC_CMS.1 TOE CM coverage+ + + + +Developer action elements:Content and presentation elements:The configuration list shall uniquely identify the configuration items. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. ALC_TSU_EXT.1 Timely Security Updates+ This component requires the TOE developer, in conjunction with any other necessary parties, to provide information - as to how the VS is updated to address security issues in a timely manner. The + as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public. -Developer action elements:The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:Content and presentation elements:The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE. The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. 5.2.5 Class ATE: Tests+ presentation of evidence.5.2.5 Class ATE: Tests+ Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. -ATE_IND.1 Independent Testing - Conformance+ +ATE_IND.1 Independent Testing - Conformance+ Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operation) documentation provided. The focus of the testing is to confirm that the requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs in Section 5.2. The evaluation activities identify the additional testing activities associated with these components. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this PP. -Developer action elements:Content and presentation elements:Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
+
+
+
+
+
+ Developer action elements:Content and presentation elements:Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. 5.2.6 Class AVA: Vulnerability Assessment+ For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly @@ -2856,7 +2921,14 @@Developer action elements:TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation
provided by the vendor. This information will be used in the development of penetration testing tools and for the
development of future PPs.
- AVA_VAN.1 Vulnerability surveyDeveloper action elements:Content and presentation elements:Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
+
+ AVA_VAN.1 Vulnerability survey+ + + + + +Developer action elements:Content and presentation elements:Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities,
to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack
@@ -2874,6 +2946,8 @@
+
+
Developer action elements:.
Appendix A - Optional RequirementsAs indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements:@@ -2895,7 +2969,7 @@ A.1 Strictly Optional R
list of actions]upon detection of a potential security violation. |
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided - into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is - installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated - into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare + into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is + installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated + into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.E.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily on processor architecture and instruction sets.@@ -3888,13 +3966,13 @@
A.1 Strictly Optional R
not an issue because there is likely to be a different product model for different hardware environments.
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
| Factor | Same/Different/None | Guidance | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Platform Architectures | Different | Hardware platforms that implement different processor architectures and instruction sets are not equivalent. | |||||||||||||||||||||||||||||||||||||||||||||||||||
| PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -3916,13 +3994,13 @@ A.1 Strictly Optional R
then provide the scheme with sufficient information about the TOE instances and platforms that were evaluated, and the
TOE instances and platforms that are claimed to be equivalent.
Appendix G - Bibliography
Contents1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements
A.1.1Class: Security Audit (FAU)A.1.2Class: Protection of the TSF (FPT)A.2Objective Requirements
A.2.1Class: Protection of the TSF (FPT)A.3Implementation-dependent Requirements
Appendix B - Selection-based Requirements
@@ -678,7 +678,7 @@ 1.2.1 Common Criteria Terms | |||||||||||||||||||||||||||||||||||||||||||||||||||
Guest Network | See Operational Network. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Guest Operating System (OS) | An operating system that runs within a Guest VM. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Guest Operating System | An operating system that runs within a Guest VM. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Guest VM | A Guest VM is a VM that contains a virtual environment for the execution of an independent computing system. Virtual environments execute mission workloads and implement customer-specific client or server functionality in Guest VMs, such as a web server or desktop productivity applications. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Host Operating System (OS) | An operating system onto which a VS is installed. Relative to the VS, the Host OS is + | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Host Operating System | An operating system onto which a VS is installed. Relative to the VS, the Host OS is part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Hypercall | An API function that allows VM-aware software running within a VM to invoke VMM functionality. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
System Security Policy (SSP) | The overall policy enforced by the VS defining constraints on the behavior + | ||||||||||||||||||||||||||||||||||||||||||||||||||||
System Security Policy | The overall policy enforced by the VS defining constraints on the behavior of VMs and users. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
User | Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators. Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software entities that operate within the VM. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Virtual Machine (VM) | A Virtual Machine is a virtualized hardware environment in which an operating system + | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Virtual Machine | A Virtual Machine is a virtualized hardware environment in which an operating system may execute. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Virtual Machine Manager (VMM) | A VMM is a collection of software components responsible for enabling VMs to + | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Virtual Machine Manager | A VMM is a collection of software components responsible for enabling VMs to function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Virtualization System (VS) | A software product that enables multiple independent computing systems to + | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Virtualization System | A software product that enables multiple independent computing systems to execute on the same physical hardware platform without interference from one another. For the purposes of this document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem, and other components. |
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
- 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.
- 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
- Package Claims
3 Security Problem Definition
-3.1 Threats
-- 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
-- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -759,17 +758,17 @@3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
-
| Threat, Assumption, or OSP | Security Objectives | Rationale | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.3P_SOFTWARE | O.VMM_INTEGRITY | The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DATA_LEAKAGE | O.DOMAIN_INTEGRITY | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DENIAL_OF_SERVICE | O.RESOURCE_ALLOCATION | The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.MISCONFIGURATION | O.CORRECTLY_APPLIED_CONFIGURATION | Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.PLATFORM_COMPROMISE | O.PLATFORM_INTEGRITY | Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_ACCESS | O.MANAGEMENT_ACCESS | Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_MODIFICATION | O.AUDIT | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VMM_INTEGRITY | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_UPDATE | O.VMM_INTEGRITY | System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNPATCHED_SOFTWARE | O.PATCHED_SOFTWARE | The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.USER_ERROR | O.VM_ISOLATION | Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.VMM_COMPROMISE | O.VMM_INTEGRITY | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.WEAK_CRYPTO | O.VM_ENTROPY | Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| A.NON_MALICIOUS_USER | OE.CONFIG | If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+
5.2 Security Assurance Requirements- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The - Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP - identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the - documentation applicable for the evaluation and performs independent testing. - This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information - Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual - evaluation activities to be performed are specified in both Section 5.1 as well as in this section. - After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain - the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform - actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained - within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply - to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also - provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. - -5.2.1 Class ASE: Security Target Evaluation+5.2 Security Assurance Requirements+The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. +5.2.1 Class ASE: Security Target EvaluationAs per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. -5.2.2 Class ADV: Development+ +5.2.2 Class ADV: Development+ The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2 should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. -ADV_FSP.1 Basic functional specificationDeveloper action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs.
+
+ Developer
+
+ ADV_FSP.1 Basic functional specification+ + + + + + + + +Developer action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs. 5.2.3 Class AGD: Guidance Documents+5.2.3 Class AGD: Guidance Documents+ The guidance documents will be provided with the developer’s security target. Guidance must include a description of how the authorized user verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by an authorized user. @@ -2826,22 +2837,33 @@5.2.2 Class ADV: DevelopmentSFRs where applicable.
- AGD_OPE.1 Operational User GuidanceDeveloper action elements:The developer shall provide operational user guidance.
-
+
+ Developer
+
+ AGD_OPE.1 Operational User Guidance+ + + + + + + + + +Developer action elements:The developer shall provide operational user guidance.
+
Note:
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance. Content and presentation elements:The operational user guidance shall describe what Content and presentation elements:The operational user guidance shall describe what The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation. The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall be clear and reasonable. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. AGD_PRE.1 Preparative proceduresDeveloper action elements:The developer shall provide the TOE including its preparative procedures.
- Developer
+ was successful or unsuccessful. This includes generation of the hash/digital signature. AGD_PRE.1 Preparative procedures+ + + + + +Developer action elements:The developer shall provide the TOE including its preparative procedures.
+
Note:
As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
@@ -2880,16 +2909,24 @@ 5.2.2 Class ADV: DevelopmentTOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST.The operational guidance shall contain step-by-step instructions suitable for use by an end-user of - the VS to configure a new, out-of-the-box system into the configuration evaluated + the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. -5.2.4 Class ALC: Life-Cycle Support+5.2.4 Class ALC: Life-Cycle Support+ At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of the TOE vendor’s development and configuration management process in order to provide a baseline level of assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product. -ALC_CMC.1 Labeling of the TOEDeveloper action elements:The developer shall provide the TOE and a reference for the TOE.
+
+ ALC_CMC.1 Labeling of the TOE+ + + +Developer action elements:Content and presentation elements:The TOE shall be labeled with its unique reference.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
@@ -2899,7 +2936,13 @@ 5.2.2 Class ADV: DevelopmentTOE samples received for testing to ensure that the version number is consistent with that in the ST.If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that - the information in the ST is sufficient to distinguish the product.ALC_CMS.1 TOE CM coverageDeveloper action elements:ALC_CMS.1 TOE CM coverage+ + + + +Developer action elements:The developer shall provide a configuration list for the TOE.
Content and presentation elements:The configuration list shall uniquely identify the configuration items.
@@ -2915,37 +2958,50 @@ 5.2.2 Class ADV: DevelopmentTSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification. -ALC_TSU_EXT.1 Timely Security Updates+ALC_TSU_EXT.1 Timely Security Updates+ This component requires the TOE developer, in conjunction with any other necessary parties, to provide information - as to how the VS is updated to address security issues in a timely manner. The + as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public. -Developer action elements:The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:Content and presentation elements:The description shall include the process for creating and deploying security updates for the TOE
software/firmware. The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE. Application
+ of a vulnerability and the public availability of security updates to the TOE.
Note:
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
availability per deployment mechanism may differ; each is described. The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE. Application
+ pertaining to the TOE.
Note:
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
proof-of-concept exploit). Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. 5.2.5 Class ATE: Tests+ presentation of evidence.5.2.5 Class ATE: Tests+ Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. -ATE_IND.1 Independent Testing - Conformance+ +ATE_IND.1 Independent Testing - Conformance+ Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operation) documentation provided. The focus of the testing is to confirm that the requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs @@ -2953,7 +3009,12 @@Developer action elements:TOE combinations that are claiming conformance to this PP.
- Developer action elements:The developer shall provide the TOE for testing.
+
+
+
+
+
+ Developer action elements:The developer shall provide the TOE for testing.
Content and presentation elements:The TOE shall be suitable for testing.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
@@ -2985,7 +3046,10 @@
+
+ Developer action elements:5.2.6 Class AVA: Vulnerability Assessment
+ 5.2.6 Class AVA: Vulnerability Assessment+ For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly @@ -2994,7 +3058,14 @@Developer action elements:PPs.
- AVA_VAN.1 Vulnerability surveyDeveloper action elements:The developer shall provide the TOE for testing.
+
+ AVA_VAN.1 Vulnerability survey+ + + + + +Developer action elements:The developer shall provide the TOE for testing.
Content and presentation elements:The TOE shall be suitable for testing.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
@@ -3014,6 +3085,8 @@ Developer action elements:Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
@@ -3038,7 +3111,7 @@ A.1 Strictly Optional R
list of actions]upon detection of a potential security violation. |
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided - into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is - installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated - into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare + into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is + installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated + into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.E.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily @@ -4093,15 +4170,15 @@E.3 Specific Guidance for
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
| Factor | Same/Different/None | Guidance | ||
| Platform Architectures | Different | Hardware platforms that implement different processor architectures and instruction sets are not equivalent. | ||
| PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -4127,15 +4204,15 @@ E.3 Specific Guidance for
EP | Extended Package | |
| FP | Functional Package | |||
| OE | Operational Environment | |||
| OS | Guest Operating System | |||
| OS | Host Operating System | |||
| PP | Protection Profile | |||
| PP-Configuration | Protection Profile Configuration | |||
| PP-Module | Protection Profile Module | |||
| SAR | Security Assurance Requirement | |||
| SFR | Security Functional Requirement | |||
| SSP | System Security Policy | |||
| ST | Security Target | |||
| TOE | Target of Evaluation | |||
| TSF | TOE Security Functionality | |||
| TSFI | TSF Interface | |||
| TSS | TOE Summary Specification | |||
| VM | Virtual Machine | |||
| VMM | Virtual Machine Manager | |||
| VS | Virtualization System |
Appendix G - Bibliography
| Identifier | Title | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|
Contents
1Introduction1.1Compliant Targets of Evaluation1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.3Class: User Data Protection (FDP)5.1.4Class: Identification and Authentication (FIA)5.1.5Class: Security Management (FMT)5.1.6Class: Protection of the TSF (FPT)5.1.7Class: TOE Access Banner (FTA)5.1.8Class: Trusted Path/Channel (FTP)5.1.9TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target Evaluation5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documents5.2.4Class ALC: Life-Cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Implementation-dependent RequirementsAppendix B - Implicitly Satisfied RequirementsAppendix C - Entropy Documentation and AssessmentC.1Design DescriptionC.2Entropy JustificationC.3Operating ConditionsC.4Health TestingAppendix D - Equivalency GuidelinesD.1IntroductionD.2Approach to Equivalency AnalysisD.3Specific Guidance for Determining Product Model EquivalenceD.4Specific Guidance for Determining Product Version EquivalenceD.5Specific Guidance for Determining Platform EquivalenceD.5.1Hardware Platform EquivalenceD.5.2Software Platform EquivalenceD.6Level of Specificity for Tested and Claimed Equivalent ConfigurationsAppendix E - AcronymsAppendix F - Bibliography
1 Introduction
1.1 Compliant Targets of Evaluation
1.2 Terms
The following sections list Common Criteria and technology terms used in this document. @@ -674,7 +674,7 @@1.2.1 Common Criteria Terms
Guest Network See Operational Network. Guest Operating System (OS) An operating system that runs within a Guest VM. Guest Operating System An operating system that runs within a Guest VM. Guest VM A Guest VM is a VM that contains a virtual environment for the execution of an independent computing
system. Virtual environments execute mission workloads and implement customer-specific client or server functionality
in Guest VMs, such as a web server or desktop productivity applications. 1.2.1 Common Criteria Terms
-Host Operating System (OS) An operating system onto which a VS is installed. Relative to the VS, the Host OS is
+ Host Operating System An operating system onto which a VS is installed. Relative to the VS, the Host OS is
part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support
guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. Hypercall An API function that allows VM-aware software running within a VM to invoke VMM functionality. 1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
Guest Network
Guest Operating System (OS)
Guest Operating System
Guest VM
Host Operating System (OS)
Host Operating System
Hypercall
1.2.1 Common Criteria Terms
-System Security Policy (SSP) The overall policy enforced by the VS defining constraints on the behavior
+ System Security Policy The overall policy enforced by the VS defining constraints on the behavior
of VMs and users. User Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators.
Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software
entities that operate within the VM. Virtual Machine (VM) A Virtual Machine is a virtualized hardware environment in which an operating system
+ Virtual Machine A Virtual Machine is a virtualized hardware environment in which an operating system
may execute. Virtual Machine Manager (VMM) A VMM is a collection of software components responsible for enabling VMs to
+ Virtual Machine Manager A VMM is a collection of software components responsible for enabling VMs to
function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service
VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device
drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. Virtualization System (VS) A software product that enables multiple independent computing systems to
+ Virtualization System A software product that enables multiple independent computing systems to
execute on the same physical hardware platform without interference from one another. For the purposes of this
document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem,
and other components.
System Security Policy (SSP)
System Security Policy
User
Virtual Machine (VM)
Virtual Machine
Virtual Machine Manager (VMM)
Virtual Machine Manager
Virtualization System (VS)
Virtualization System
1.3 Use Cases
This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules.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.
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC].
- PP Claim
- Package Claim
- 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.
- 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
- Package Claims
3 Security Problem Definition
-3.1 Threats
-- 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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.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.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 policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother 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, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities.
- 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.
- 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.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.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.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.UNPATCHED_SOFTWARE
- Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform.
- 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.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.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.
3.2 Assumptions
-- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- 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.
- 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.PLATFORM_INTEGRITY
- The platform has not been compromised prior to installation of the VS.
- A.TRUSTED_ADMIN
- TOE Administrators are trusted to follow and apply all administrator guidance.
3.3 Organizational Security Policies
@@ -755,17 +754,17 @@3.3 O
4 Security Objectives
4.1 Security Objectives for the TOE
- - 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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.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.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.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.RESOURCE_ALLOCATION
- The TOE will provide mechanisms that enforce constraints on the allocation of system resources in accordance with existing security policy.
- 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.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.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.
4.2 Security Objectives for the Operational Environment
- - OE.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.CONFIG
- TOE administrators will configure the VS correctly to create the intended security policy.
- 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.
- 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.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
-
| Threat, Assumption, or OSP | Security Objectives | Rationale | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.3P_SOFTWARE | O.VMM_INTEGRITY | The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DATA_LEAKAGE | O.DOMAIN_INTEGRITY | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.DENIAL_OF_SERVICE | O.RESOURCE_ALLOCATION | The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.MISCONFIGURATION | O.CORRECTLY_APPLIED_CONFIGURATION | Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.PLATFORM_COMPROMISE | O.PLATFORM_INTEGRITY | Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_ACCESS | O.MANAGEMENT_ACCESS | Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_MODIFICATION | O.AUDIT | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VMM_INTEGRITY | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNAUTHORIZED_UPDATE | O.VMM_INTEGRITY | System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.UNPATCHED_SOFTWARE | O.PATCHED_SOFTWARE | The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.USER_ERROR | O.VM_ISOLATION | Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.VMM_COMPROMISE | O.VMM_INTEGRITY | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| O.VM_ISOLATION | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| T.WEAK_CRYPTO | O.VM_ENTROPY | Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| A.NON_MALICIOUS_USER | OE.CONFIG | If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE
+
5.2 Security Assurance Requirements- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The - Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP - identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the - documentation applicable for the evaluation and performs independent testing. - This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information - Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual - evaluation activities to be performed are specified in both Section 5.1 as well as in this section. - After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain - the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform - actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained - within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply - to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also - provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. - -5.2.1 Class ASE: Security Target Evaluation+5.2 Security Assurance Requirements+The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section. After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. +5.2.1 Class ASE: Security Target EvaluationAs per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. -5.2.2 Class ADV: Development+ +5.2.2 Class ADV: Development+ The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE Summary Specification (TSS) portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.2 should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. -ADV_FSP.1 Basic functional specificationDeveloper action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs.
+
+ Developer
+
+ ADV_FSP.1 Basic functional specification+ + + + + + + + +Developer action elements:The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and presentation
of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of
- the SFRs. 5.2.3 Class AGD: Guidance Documents+5.2.3 Class AGD: Guidance Documents+ The guidance documents will be provided with the developer’s security target. Guidance must include a description of how the authorized user verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by an authorized user. @@ -3709,22 +3724,33 @@5.2.2 Class ADV: DevelopmentSFRs where applicable.
- AGD_OPE.1 Operational User GuidanceDeveloper action elements:The developer shall provide operational user guidance.
-
+
+ Developer
+
+ AGD_OPE.1 Operational User Guidance+ + + + + + + + + +Developer action elements:The developer shall provide operational user guidance.
+
Note:
Rather than repeat information here, the developer should review the evaluation activities for this
component to ascertain the specifics of the guidance that the evaluators will be checking for. This
- will provide the necessary information for the preparation of acceptable guidance. Content and presentation elements:The operational user guidance shall describe what Content and presentation elements:The operational user guidance shall describe what The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall describe, for The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and implications for
- maintaining secure operation. The operational user guidance shall, for The operational user guidance shall, for The operational user guidance shall be clear and reasonable. Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. AGD_PRE.1 Preparative proceduresDeveloper action elements:The developer shall provide the TOE including its preparative procedures.
- Developer
+ was successful or unsuccessful. This includes generation of the hash/digital signature. AGD_PRE.1 Preparative procedures+ + + + + +Developer action elements:The developer shall provide the TOE including its preparative procedures.
+
Note:
As with the operational guidance, the developer should look to the evaluation activities
to determine the required content with respect to preparative procedures.
@@ -3763,16 +3796,24 @@ 5.2.2 Class ADV: DevelopmentTOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST.The operational guidance shall contain step-by-step instructions suitable for use by an end-user of - the VS to configure a new, out-of-the-box system into the configuration evaluated + the VS to configure a new, out-of-the-box system into the configuration evaluated under this Protection Profile. -5.2.4 Class ALC: Life-Cycle Support+5.2.4 Class ALC: Life-Cycle Support+ At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of the TOE vendor’s development and configuration management process in order to provide a baseline level of assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product. -ALC_CMC.1 Labeling of the TOEDeveloper action elements:The developer shall provide the TOE and a reference for the TOE.
+
+ ALC_CMC.1 Labeling of the TOE+ + + +Developer action elements:Content and presentation elements:The TOE shall be labeled with its unique reference.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
@@ -3782,7 +3823,13 @@ 5.2.2 Class ADV: DevelopmentTOE samples received for testing to ensure that the version number is consistent with that in the ST.If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that - the information in the ST is sufficient to distinguish the product.ALC_CMS.1 TOE CM coverageDeveloper action elements:ALC_CMS.1 TOE CM coverage+ + + + +Developer action elements:The developer shall provide a configuration list for the TOE.
Content and presentation elements:The configuration list shall uniquely identify the configuration items.
@@ -3798,37 +3845,50 @@ 5.2.2 Class ADV: DevelopmentTSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification. -ALC_TSU_EXT.1 Timely Security Updates+ALC_TSU_EXT.1 Timely Security Updates+ This component requires the TOE developer, in conjunction with any other necessary parties, to provide information - as to how the VS is updated to address security issues in a timely manner. The + as to how the VS is updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, hardware vendors) and the steps that are performed (e.g., developer testing), including worst case time periods, before an update is made available to the public. -Developer action elements:The developer shall provide a description in the TSS of how timely security updates are made to the
+
+
+
+
+
+
+ Developer action elements:Content and presentation elements:The description shall include the process for creating and deploying security updates for the TOE
software/firmware. The description shall express the time window as the length of time, in days, between public disclosure
- of a vulnerability and the public availability of security updates to the TOE. Application
+ of a vulnerability and the public availability of security updates to the TOE.
Note:
The total length of time may be presented as a summation of the periods of time that each party (e.g.,
TOE developer, hardware vendor) on the critical path consumes. The time period until public
availability per deployment mechanism may differ; each is described. The description shall include the mechanisms publicly available for reporting security issues
- pertaining to the TOE. Application
+ pertaining to the TOE.
Note:
The reporting mechanism could include websites, email addresses, and a means to protect the sensitive
nature of the report (e.g., public keys that could be used to encrypt the details of a
proof-of-concept exploit). Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
- presentation of evidence. 5.2.5 Class ATE: Tests+ presentation of evidence.5.2.5 Class ATE: Tests+ Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. -ATE_IND.1 Independent Testing - Conformance+ +ATE_IND.1 Independent Testing - Conformance+ Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operation) documentation provided. The focus of the testing is to confirm that the requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs @@ -3836,7 +3896,12 @@Developer action elements:TOE combinations that are claiming conformance to this PP.
- Developer action elements:The developer shall provide the TOE for testing.
+
+
+
+
+
+ Developer action elements:The developer shall provide the TOE for testing.
Content and presentation elements:The TOE shall be suitable for testing.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
@@ -3868,7 +3933,10 @@
+
+ Developer action elements:5.2.6 Class AVA: Vulnerability Assessment
+ 5.2.6 Class AVA: Vulnerability Assessment+ For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly @@ -3877,7 +3945,14 @@Developer action elements:PPs.
- AVA_VAN.1 Vulnerability surveyDeveloper action elements:The developer shall provide the TOE for testing.
+
+ AVA_VAN.1 Vulnerability survey+ + + + + +Developer action elements:The developer shall provide the TOE for testing.
Content and presentation elements:The TOE shall be suitable for testing.
Evaluator action elements:The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence. The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
@@ -3897,6 +3972,8 @@ Developer action elements:Appendix A - Implementation-dependent Requirements
Implementation-dependent Requirements
Appendix defines requirements that must be claimed in the ST
@@ -4053,9 +4130,9 @@ D.3 Specific Guidance for PP-specified functionality. If the Product Versions are fully tested separately, then there is no need to document the differences. |
D.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that a product must be tested on. These guidelines are divided - into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is - installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated - into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare + into sections for determining hardware equivalence and software (host OS/control domain) equivalence. If the Product is + installed onto bare metal, then only hardware equivalence is relevant. If the Product is installed onto an OS—or is integrated + into an OS—then both hardware and software equivalence are required. Likewise, if the Product can be installed either on bare metal or on an operating system, both hardware and software equivalence are relevant.D.5.1 Hardware Platform Equivalence
If a Virtualization Solution runs directly on hardware without an operating system, then platform equivalence is based primarily @@ -4066,15 +4143,15 @@D.3 Specific Guidance for
Equivalency analysis becomes important when comparing platforms with the same processor architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified
- from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
+ from being equivalent for purposes of a VPP evaluation. If the VS takes the same code paths when executing PP-specified
security functionality on different processors of the same family, then the processors can be considered equivalent with
respect to that application.
- For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
- not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
+ For example, if a VS follows one code path on platforms that support the AES-NI instruction and another on platforms that do
+ not, then those two platforms are not equivalent with respect to that VS functionality. But if the VS follows the same code
path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
- The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
+ The platforms are equivalent with respect to the VS if the platforms are equivalent with respect to all PP-specified
security functionality.
Table 7: Factors for Determining Hardware Platform Equivalence
| Factor | Same/Different/None | Guidance | ||
| Platform Architectures | Different | Hardware platforms that implement different processor architectures and instruction sets are not equivalent. | ||
| PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on
@@ -4100,15 +4177,15 @@ D.3 Specific Guidance for
EP | Extended Package | |
| FP | Functional Package | |||
| OE | Operational Environment | |||
| OS | Guest Operating System | |||
| OS | Host Operating System | |||
| PP | Protection Profile | |||
| PP-Configuration | Protection Profile Configuration | |||
| PP-Module | Protection Profile Module | |||
| SAR | Security Assurance Requirement | |||
| SFR | Security Functional Requirement | |||
| SSP | System Security Policy | |||
| ST | Security Target | |||
| TOE | Target of Evaluation | |||
| TSF | TOE Security Functionality | |||
| TSFI | TSF Interface | |||
| TSS | TOE Summary Specification | |||
| VM | Virtual Machine | |||
| VMM | Virtual Machine Manager | |||
| VS | Virtualization System |
Appendix F - Bibliography
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|