PCI DSS Virtualization Guide. Part 2
Standard: PCI Data Security Standard (PCI DSS)
Version: 2.0
Date: June 2011
Posted by: Virtualization Task Force PCI Security Standards Council
More Information: PCI DSS Virtualization Guide
PCI DSS Virtualization Guide. Part 1
PCI DSS Virtualization Guide. Part 3
Although virtualization provides a certain amount of functional and operational benefits, the transition to a virtual environment does not reduce the risks that exist in physical systems, and can also bring new and unique risks. Consequently, there are a number of factors that should be considered when creating virtual technologies, including, but not limited to, those defined below.
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 may inadvertently expose internal systems for Internet attacks in the same way as an incorrectly configured physical firewall.
Physical threats also apply to use in virtual environments; the most correctly configured and well-placed logical partitions still require adequate physical measures to protect equipment. For this reason, the physical host system will always remain in scope, even in cases where there is a logical reduction.
')
A key risk factor unique to virtual environments is the hypervisor. If it is hacked or misconfigured, all VMs residing on this hypervisor are potentially at risk. The hypervisor provides a single point of access to the virtual environment and is also potentially a single point of failure. Incorrectly configured hypervisors become a single point for hacking the security of all hosted components. No matter how securely the individual VMs or components are configured, the hacked hypervisor can overwrite all settings and get direct access to the virtual systems.
Along with providing a potential point of entry 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 enhancements, and patching can be identified and applied for their own purposes, which will allow attackers to gain access to individual VMs.
Additionally, the default configuration of the hypervisor is often not the most secure, and if not configured properly, each hypervisor can potentially be exploited for hacking purposes.
It is very important that access to the hypervisor is limited in accordance with the least privileges and the principle of the necessary knowledge, and that mandatory independent monitoring of all activities is carried out. Hypervisors are not created equal, so it is especially important to choose a solution that supports the required security functions for each environment.
Virtualized configurations can include both systems and networks; for example, VMs can transmit data to each other through the hypervisor, as well as through a virtual network connection or through virtual network security devices, such as virtual firewalls. While such configurations can offer significant operational benefits, these additional levels of technology also introduce significant challenges that need to be carefully managed and which may require additional security measures and complex 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 accidental configuration changes or even completely new threats that were not foreseen when developing the system. Since instances of virtual components are often duplicated across multiple systems, the presence of such vulnerabilities can lead to significant hacking throughout the environment.
A particular concern in virtual environments is the possibility that hacking one of the virtual functions of the system may lead to the disruption of other functions on the same physical system. A compromised VM can use virtualization-level communication mechanisms to launch attacks on other virtual machines on the same host or even on the hypervisor. Virtualization technology can reduce the risk of this division of the 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.
See also - Mixing VMs of different levels of trust (descriptions of related risks are given there).
One of the challenges when planning a virtualization deployment is to determine the proper configurations for the different types of workloads that are located within a particular virtualization technology. It is necessary to clearly assess the risk of placing VMs of different levels of trust on the same host. In a virtual context, a VM with a lower trust will, as a rule, have less security measures than a VM with a higher level of trust. Thus, VMs with lower confidence can be used for hacking, potentially providing a place to attack more sensitive VMs within a single system. Theoretically, placing VMs of different levels of trust on the same hypervisor or host can reduce the overall security level for all components to the level of the least protected component (also known as the principle that security is as strong as the least protected element is strong).
Due to the increased risks and adjustment problems, 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 data storage systems. Remember to evaluate the risk of mixing sensitive data with data that has a lower level of trust.
It can be particularly difficult to determine the exact roles of users (for example, to separate a network administrator from a server administrator) and access policies in a distributed, virtualized environment. The risks of incorrect definition of roles and access policies are very important because access to the hypervisor can potentially provide broad access to key infrastructure components (including switches, firewalls, payment applications, server logs, databases, etc.). Because of the increased availability of multiple virtual devices and functions from a single logical location or user, monitoring and enforcing compliance with the appropriate segregation of duties is crucial in a virtual environment.
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 unprotected 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, through negligence, not subjected to security procedures.
Since inactive VMs are not used, they can easily be overlooked and inadvertently excluded from security procedures. Inactive VMs are most likely not to be updated with the latest security patches, as a result of which the system is exposed to known vulnerabilities that the organization believes were resolved. Dormant VMs are also unlikely to have an updated access policy, and can be excluded from the security and monitoring function, possibly creating an unverified
backdoor in a virtual environment.
In addition, data in the VM's memory (which may include, for example, an unencrypted PAN) often remains when the VM is in an inactive (dormant) state, leading to 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 the VM currently 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.
Virtual machine images and snapshots provide tools for quickly deploying or restoring virtual systems to 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 snapshot, including the contents of the active memory. This can lead to the unintentional capture, storage or even deployment of unprotected 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, resulting in the instant hacking of multiple hosts.
At the same time, as virtualization increases the need for logging and monitoring, it is now recognized that tools for monitoring virtual networks, virtual firewalls, virtual correspondence systems, etc., are not as developed as their physical counterparts.
Compared to traditional monitoring tools for a physical network, tools for virtual systems cannot provide the same level of confidence or control within messages within the host or the traffic flow between VMs in a virtual network. In addition, specialized tools for monitoring and logging virtual environments may be needed to reflect the level of detail required from several components, including embedded hypervisors, management interfaces, virtual machines, host systems, and virtual devices.
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.
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 gather information about other components on the same host and potentially gain enough knowledge for further hacking and adverse effects. For example, an attacker may gain access to the memory of the underlying operating system, leading to the ability to collect confidential information from several components. Incorrect configuration of the hypervisor can also become a channel for information leakage between virtual instruments and networks. Isolating all physical resources (including memory, CPU, network, etc.) is crucial to prevent information leaks between virtual machines and other components or networks on the same host.
Version: 2.0
Date: June 2011
Posted by: Virtualization Task Force PCI Security Standards Council
More 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 amount of functional and operational benefits, the transition to a virtual environment does not reduce the risks that exist in physical systems, and can also bring new and unique risks. Consequently, 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 also apply in a 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 may inadvertently expose internal systems for Internet attacks in the same way as an incorrectly configured physical firewall.
Physical threats also apply to use in virtual environments; the most correctly configured and well-placed logical partitions still require adequate physical measures to protect equipment. For this reason, the physical host system will always remain in scope, even in cases where there is a logical reduction.
')
3.2 The hypervisor creates new spaces for attack
A key risk factor unique to virtual environments is the hypervisor. If it is hacked or misconfigured, all VMs residing on this hypervisor are potentially at risk. The hypervisor provides a single point of access to the virtual environment and is also potentially a single point of failure. Incorrectly configured hypervisors become a single point for hacking the security of all hosted components. No matter how securely the individual VMs or components are configured, the hacked hypervisor can overwrite all settings and get direct access to the virtual systems.
Along with providing a potential point of entry 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 enhancements, and patching can be identified and applied for their own purposes, which will allow attackers to gain access to individual VMs.
Additionally, the default configuration of the hypervisor is often not the most secure, and if not configured properly, each hypervisor can potentially be exploited for hacking purposes.
It is very important that access to the hypervisor is limited in accordance with the least privileges and the principle of the necessary knowledge, and that mandatory independent monitoring of all activities is carried out. Hypervisors are not created equal, so it is especially important to choose a solution that supports the required security functions for each environment.
3.3 Increased complexity of virtualized systems and networks
Virtualized configurations can include both systems and networks; for example, VMs can transmit data to each other through the hypervisor, as well as through a virtual network connection or through virtual network security devices, such as virtual firewalls. While such configurations can offer significant operational benefits, these additional levels of technology also introduce significant challenges that need to be carefully managed and which may require additional security measures and complex 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 accidental configuration changes or even completely new threats that were not foreseen when developing the system. Since instances of virtual components are often duplicated across multiple systems, the presence of such vulnerabilities can lead to significant hacking throughout the environment.
3.4 More than one function per physical system
A particular concern in virtual environments is the possibility that hacking one of the virtual functions of the system may lead to the disruption of other functions on the same physical system. A compromised VM can use virtualization-level communication mechanisms to launch attacks on other virtual machines on the same host or even on the hypervisor. Virtualization technology can reduce the risk of this division of the 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.
See also - Mixing VMs of different levels of trust (descriptions of related risks are given there).
3.5 Mixing VMs of different levels of trust
One of the challenges when planning a virtualization deployment is to determine the proper configurations for the different types of workloads that are located within a particular virtualization technology. It is necessary to clearly assess the risk of placing VMs of different levels of trust on the same host. In a virtual context, a VM with a lower trust will, as a rule, have less security measures than a VM with a higher level of trust. Thus, VMs with lower confidence can be used for hacking, potentially providing a place to attack more sensitive VMs within a single system. Theoretically, placing VMs of different levels of trust on the same hypervisor or host can reduce the overall security level for all components to the level of the least protected component (also known as the principle that security is as strong as the least protected element is strong).
Due to the increased risks and adjustment problems, 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 data storage systems. Remember to evaluate the risk of mixing sensitive data with data that has a lower level of trust.
3.6 Lack of separation of duties
It can be particularly difficult to determine the exact roles of users (for example, to separate a network administrator from a server administrator) and access policies in a distributed, virtualized environment. The risks of incorrect definition of roles and access policies are very important because access to the hypervisor can potentially provide broad access to key infrastructure components (including switches, firewalls, payment applications, server logs, databases, etc.). Because of the increased availability of multiple virtual devices and functions from a single logical location or user, monitoring and enforcing compliance with the appropriate segregation of duties is crucial 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 unprotected 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, through negligence, not subjected to security procedures.
Since inactive VMs are not used, they can easily be overlooked and inadvertently excluded from security procedures. Inactive VMs are most likely not to be updated with the latest security patches, as a result of which the system is exposed to known vulnerabilities that the organization believes were resolved. Dormant VMs are also unlikely to have an updated access policy, and can be excluded from the security and monitoring function, possibly creating an unverified
backdoor in a virtual environment.
In addition, data in the VM's memory (which may include, for example, an unencrypted PAN) often remains when the VM is in an inactive (dormant) state, leading to 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 the VM currently 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 Images of VMs and snapshots
Virtual machine images and snapshots provide tools for quickly deploying or restoring virtual systems to 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 snapshot, including the contents of the active memory. This can lead to the unintentional capture, storage or even deployment of unprotected 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, resulting in the instant hacking of multiple hosts.
3.9 Immaturity of monitoring decisions
At the same time, as virtualization increases the need for logging and monitoring, it is now recognized that tools for monitoring virtual networks, virtual firewalls, virtual correspondence systems, etc., are not as developed as their physical counterparts.
Compared to traditional monitoring tools for a physical network, tools for virtual systems cannot provide the same level of confidence or control within messages within the host or the traffic flow between VMs in a virtual network. In addition, specialized tools for monitoring and logging virtual environments may be needed to reflect the level of detail required from several components, including embedded hypervisors, management interfaces, virtual machines, host systems, and virtual devices.
3.10 Information leakage between virtual network segments
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 gather information about other components on the same host and potentially gain enough knowledge for further hacking and adverse effects. For example, an attacker may gain access to the memory of the underlying operating system, leading to the ability to collect confidential information from several components. Incorrect configuration of the hypervisor can also become a channel for information leakage between virtual instruments and networks. Isolating all physical resources (including memory, CPU, network, etc.) is crucial to prevent information leaks between virtual machines and other components or networks on the same host.
Source: https://habr.com/ru/post/246433/
All Articles