PCI DSS Virtualization Guide. Part 2

Original author: Virtualization Special Interest Group PCI Security Standards Council
  • Transfer
Standard: PCI Data Security Standard (PCI DSS)
Version: 2.0
Date: June 2011
Posted by: Virtualization Task Force PCI Security Standards Council PCI
Additional Information: PCI DSS

Virtualization Guide PCI DSS Virtualization Guide. Part 1
PCI DSS Virtualization Guide. Part 3

3 Risks of virtualized environments


Although virtualization provides a certain number of functional and operational advantages, the transition to a virtual environment does not reduce the risks that exist in physical systems, and can also introduce new and unique risks. Therefore, there are a number of factors that should be considered when creating virtual technologies, including, but not limited to, those defined below.

3.1 Vulnerabilities in the physical environment are applicable in the virtual environment

Virtual systems and networks are subject to the same attacks and vulnerabilities that exist in the physical infrastructure. An application that has configuration flaws or is vulnerable to malicious exposure will have the same flaws and vulnerabilities when installed in a virtual environment.
Similarly, a poorly configured virtual firewall can inadvertently expose internal systems for Internet attacks in the same way as an improperly configured physical firewall.
Physical threats also apply to virtual environments; the most properly configured and well-placed logical partitions still require adequate physical measures to protect the equipment. For this reason, the physical host system will always remain in scope even when there is a logical reduction.

3.2 Hypervisor creates new spaces for attack

A key risk factor unique to virtual environments is the hypervisor. If it is hacked or configured incorrectly, all VMs located on this hypervisor are potentially at risk. The hypervisor provides a single access point to the virtual environment and is also potentially a single point of failure. Incorrectly configured hypervisors become a single point for breaking the security of all hosted components. No matter how securely configured individual VMs or components are configured, a hacked hypervisor can overwrite all settings and gain direct access to virtual systems.

Along with providing a potential penetration point to the VM, the hypervisor itself creates a new attack surface that does not exist in the physical world and may be vulnerable to direct attacks. Weaknesses in hypervisor isolation technology, access measures, security enhancement, and patching can be identified and used for their own purposes, which will allow attackers to gain access to individual VMs.

Additionally, the default hypervisor configuration is often not the most secure, and if it is not configured properly, each hypervisor can potentially be exploited for hacking purposes.

It is very important that access to the hypervisor be limited in accordance with the least privileges and the principle of necessary knowledge, and that mandatory independent monitoring of all activities is carried out. Hypervisors are not created the same, so it’s especially important to choose a solution that supports the required security features for each environment.


3.3 Increased complexity of virtualized systems and networks

Virtualized configurations can include both systems and networks; for example, VMs can transfer data to each other through a hypervisor, as well as through connecting to a virtual network or through virtual network security devices such as virtual firewalls. While such configurations can offer significant operational benefits, these additional layers of technology also pose significant challenges that need to be carefully managed and that may require additional security measures and sophisticated management policies to ensure proper security at each level. Combined with potential vulnerabilities in virtual operating systems and applications, this increase in complexity can also lead to an accidental configuration change or even to completely new threats that were not foreseen during the development of the system. Since instances of virtual components are often duplicated across multiple systems, the presence of such vulnerabilities can lead to significant hacking in the entire environment.

3.4 More than one function per physical system

A particular concern in virtual environments is the possibility that hacking one of the system’s virtual functions can lead to disruption of other functions on the same physical system. An endangered VM can use communication mechanisms at the virtualization level to launch attacks on other virtual machines on the same host or even on the hypervisor. Virtualization technology can reduce the risk of this separation of process between different functions. Even so, we should consider the risk associated with the location of many functions or components on a single physical system. For example, several functions hosted on the same physical system increase the potential for hacking if an attacker gains physical access to the host system.
Смотрите также — Смешивание ВМ разных уровней доверия (там приведены описания связанных рисков).

3.5 Смешивание ВМ разных уровней доверия

One of the challenges in planning a virtualization deployment is to determine the appropriate configurations for the various types of workloads placed within a particular virtualization technology. It is necessary to clearly assess the risk of hosting VMs of different levels of trust on the same host. In a virtual context, lower-trust VMs will typically have fewer security measures than higher-trust VMs. Thus, VMs with lower trust can be used for hacking, potentially providing a place to attack more sensitive VMs within a single system. In theory,
Due to the increased risks and problems with tuning, the levels of trust and risk associated with each VM function should be considered when planning the design of a virtual network. Similarly, databases and other storage systems that store cardholder data require a higher level of security than non-sensitive storage systems. Remember to properly assess the risk of mixing sensitive data with data that has a lower level of trust.

3.6 Lack of segregation of duties

It can be especially difficult to determine the exact roles of users (for example, to separate the network administrator from the server administrator) and the access policy in a distributed, virtualized environment. The risks of incorrect role definitions and access policies are very important, since access to the hypervisor can potentially provide wide access to key infrastructure components (including switches, firewalls, payment applications, server logging fees, databases, etc.). Because of the increased accessibility to multiple virtual devices and functions from a single logical location or user, monitoring and enforcing an appropriate separation of duties is critical in a virtual environment.

3.7 Inactive virtual machines

On many virtual platforms, virtual machines can exist in both active and inactive states. VMs that are no longer active (inactive or no longer in use) may still contain insecure data, such as authentication data, encryption keys, or critical configuration information. Due to the fact that inactive VMs are not actively used, they can easily be overlooked and inadvertently not subjected to security procedures.

Since inactive VMs are not used, they can easily be overlooked and inadvertently excluded from security procedures. Inactive VMs will most likely not be updated with the latest security patches, as a result of which the system is exposed to known vulnerabilities that the organization believes have been resolved. Sleeping VMs are also unlikely to have an updated access policy, and can be excluded from the security and monitoring functions, possibly creating an unchecked
backdoor in a virtual environment.

In addition, the data in the VM memory (which may include, for example, an unencrypted PAN) often remains when the VM is in an inactive (sleeping) state, leading to the unintentional storage of important data. Since this data was in memory when it was stopped, such data can easily be ignored and remain unprotected, despite the fact that at present the VM remains in an inactive ("sleeping") state. Although they are inactive, such VMs pose real security threats and therefore must be identified and monitored so that appropriate security measures can be taken.

3.8 VM images and snapshots

Virtual machine images and snapshots provide tools for quickly deploying or recovering virtual systems on multiple servers in a short period of time. Particular attention should be paid to the preparation of VM images and screenshots, since they can capture the unprotected data available on the system at the time of the image, including the contents of the active memory. This can lead to unintentional capture, storage, or even deployment of insecure information in the environment.

Additionally, if the images are not protected from changes, the attacker can gain access and add vulnerabilities or malicious code. The malicious image can then spread throughout the environment, leading to instant hacking of multiple hosts.

3.9 Immaturity of monitoring decisions

While virtualization increases the need for logging and monitoring, it is now recognized that tools for monitoring virtual networks, virtual firewalls, virtual compliance systems, etc. are not as advanced as their physical counterparts.

Compared to traditional monitoring tools for a physical network, tools for virtual systems cannot provide the same level of reliability or control within messages within a host or traffic flow between VMs in a virtual network. In addition, specialized tools for monitoring and recording virtual environments may be needed to reflect the level of detail required by several components, including embedded hypervisors, management interfaces, virtual machines, host systems, and virtual devices.

3.10 Information leakage between virtual network segments

You need to understand the potential risk of information leakage between logical network segments when considering network virtualization. Information leakage in the data plane leads to the fact that confidential data now exists outside of known locations, bypassing data protection measures. Information leakage in the control plane or control plane can be used to enable information leakage in the data plane, or to influence the route network and forwarding behavior, bypassing network security measures. Ideally, virtualization capabilities on all three planes of the network infrastructure should provide measures and functions for a secure virtual infrastructure at a level equivalent to individual physical devices.

3.11 Information leakage between virtual components

Information leakage between virtual components can occur when access to shared resources allows one of the components to collect information about another component on the same host. For example, an attacker could use a compromised component to collect information about other components on the same host and potentially gain enough knowledge for further hacking and adverse effects. For example, an attacker could gain access to the memory of the underlying operating system, leading to the possibility of collecting sensitive information from several components. Incorrect hypervisor settings can also become a channel for information leakage between virtual appliances and networks. Isolation of all physical resources (including memory, CPU, network, etc.

Also popular now: