January 20, 2015 at 16:07PCI DSS Virtualization Guide. Part 3
- Transfer
Standard: PCI Data Security Standard ( PCI DSS )
Version: 2.0
Date: June 2011
Author: Ad Hoc Group on Virtualization Security Standards Council PCI
Additional information: Virtualization Guide PCI DSS
on the PCI DSS Virtualization Guidelines. Part 1
PCI DSS Virtualization Guide. Part 2
The measures outlined in this section are recommendations and useful experiences that will help you meet PCI DSS requirements in virtual environments.
Organizations must carefully and comprehensively assess the risks associated with virtualizing system components before selecting or implementing a specific virtualization solution. The flow and storage of cardholder data should be carefully documented as part of this risk assessment process to ensure that all areas of risk are identified and that appropriate measures are taken. Virtualization should be deployed with full consideration of all its advantages and risks, with a comprehensive system for monitoring data, applications and the entire environment at the ready.
Organizations that use virtualization to consolidate their environment on one or more physical hardware platforms may find themselves in a situation where they now have a complex set of virtual system configurations that make it difficult to determine the boundaries or scope of their CDE .
As stated earlier in this document, placing multiple components on the same physical system can significantly increase the likely impact if an attacker gains access to that system.
In the physical environment, a defense in depth approach that encompasses preventive, detection and response measures is the best practice for protecting data and other values. Logical security tools are typically used at the network, host, application, and data level, and physical security is used to protect media, systems, and objects from unauthorized physical access. Monitoring the effectiveness of measures and their potential to quickly and effectively respond to potential violations is also of paramount importance. The defense-in-depth approach also includes the training and education of personnel in the proper use of important resources, the identification of potential security threats and the appropriate measures to be taken in the event of a breach. Moreover,
The security functions provided by virtual machines must be performed with the same separation process as in the physical world. It is recommended that this requirement is even more strictly enforced in virtualized systems, as this greatly complicates the efforts required by an attacker who has decided to crack several CDEssystem components. For example, preventive control, such as a network firewall, should never be combined on the same logical host with the payment card data that it must protect. Similarly, you should not mix processes that control network segmentation and the log aggregation function, which should detect falsification of network segmentation. If such security features need to be hosted on the same hypervisor or host, the isolation level of the security features must be such that they can be viewed as installed on separate machines.
Credentials and data for administrative access to the hypervisor must be carefully controlled, and depending on the level of risk, the use of large restrictions on access to the hypervisor is often justified. Organizations should consider additional methods for securing administrative access, such as implementing two-factor authentication or creating dual or split-management of administrative passwords between multiple administrators. Access controls should be evaluated for both local and remote access to the hypervisor and management system. Particular attention should be paid to the individual functions of the virtual components, to ensure appropriate role-based access ( RBAC), which will avoid unnecessary access to resources and help to maintain separation of duties.
Ensure that hypervisor security has been thoroughly tested prior to deployment and that there is proper patch management and other controls to respond to threats and vulnerabilities. It is critical to have identifying and implementing technologies that facilitate reliable protection, since not all hypervisors or VMMs have the functionality to support appropriate security measures.
The hypervisor platform must be located in a safe place in accordance with industry recommendations and security guidelines. Careful management of virtual system configurations, installation of patches, and control over changes are essential as confirmation that all changes to the hypervisor are monitored, performed only after authorization, are fully verified and carefully monitored. Due to the potential severity of a hypervisor hack, patches and other risk-mitigation actions need to be deployed as soon as possible whenever new security vulnerabilities are discovered, and immediate vulnerability testing is included in the process to confirm the danger.
It is also important that all individual virtual machines are installed and configured reliably and in accordance with industry-leading security solutions and guidelines. The recommendations presented above to enhance hypervisor protection apply also to VMs and virtual components.
Management tools allow administrators to perform functions such as system backup, recovery, remote connection, migration, and making changes to virtual system configurations. Management tools for components that are within the scope of the scope will also be considered as part of the scope, as these tools directly affect the safety and performance of the components. Access to these management tools should be limited only to those employees who need such access to perform job duties. Segregation of roles and responsibilities is recommended for management tool functions, and any use of management tools should be monitored and logged.
Virtual machines are actually data that can reside in an active state (on the hypervisor) or in an inactive state (anywhere). Inactive virtual machines are stored datasets that can contain sensitive information and configuration information for virtual devices. A person who has access to an inactive VM can copy and turn it on elsewhere, or he can scan inactive files with payment card data and other confidential information. Access to inactive VMs should therefore be limited, monitored, and closely monitored.
Ideally, any deployment of a virtual network infrastructure should include effective security measures in the data plane, control plane, and control plane. This will help minimize the likelihood of direct and indirect vulnerabilities moving from one plane to another, and damage to virtual network devices. While they are ideal, effective safety measures are not always possible on all three work planes. In these cases, it is becoming increasingly important to ensure that all major physical components are properly isolated and protected and do not create a path between virtual network devices. The isolation between virtual network devices must be such that virtual systems can be effectively considered as separate parts.
Sometimes, shared hosting providers virtualize their offerings, allocating individual resources to clients, rather than allocating separate physical systems. Organizations considering a virtual hosting service should make sure that this proposal uses administrative, procedural, and technical segmentation to isolate the environment of each hosting organization from the environment of another hosting organization. Such isolation should, at a minimum, include all PCI DSS measures , including but not limited to segmented authentication, network and access restrictions, encryption and logging.
Virtual environments are significantly different from traditional physical environments, and a full understanding of virtualization technologies is very important for effective assessment and security in the environment. In the absence of formal virtualization security standards, organizations should familiarize themselves with industry best practices and guidelines for securing virtual environments. Examples of resources that provide guidance include publications from:
It is highly recommended (and this is a basic security principle) that VMs of different security levels should not be located on the same hypervisor or physical host; the main problem is that VMs with lower security requirements will have less access security and can be used to attack or create access to more sensitive VMs on the same system.
This principle should be applied in cases when incoming and out of scope VMs must be installed on the same host or hypervisor. Typically, any VM or other virtual component that resides on the same hardware or hypervisor as the component in the scope will also be included in the scope for PCI DSS, since both the hypervisor and the host underlying it provide a connection (physical, logical, or both) between the virtual devices, and it may not be possible to achieve the appropriate level of isolation or segmentation between components that are not in the scope of coverage, located on the same volume same server or hypervisor.
As mentioned earlier in this document, any hypervisor or host system that hosts a virtual component within the scope will also be within the scope of PCI DSS. In order for VMs that enter and are not within the scope of coexistence on the same host or hypervisor, virtual machines must be isolated from each other so that they can be effectively considered as separate hardware in different network segments without connecting to each other . Any system components shared by a VM, including the hypervisor and the underlying host system, should not represent an access path between virtual machines.
Even with adequate segmentation between virtual components, the amount of effort and administrative expense required to ensure segmentation is performed and the security levels of each component are maintained can be more onerous than using PCI DSS for the system as a whole.
The segmentation level for systems entering and outside the scope of application on the same host should be equivalent to the isolation level achievable in the physical world; that is, segmentation should ensure that external components cannot be used to access internal ones. Unlike individual physical systems, network segmentation alone cannot isolate components within the sphere from those that are not part of the virtual environment.
Version: 2.0
Date: June 2011
Author: Ad Hoc Group on Virtualization Security Standards Council PCI
Additional information: Virtualization Guide PCI DSS
on the PCI DSS Virtualization Guidelines. Part 1
PCI DSS Virtualization Guide. Part 2
4 Recommendations
The measures outlined in this section are recommendations and useful experiences that will help you meet PCI DSS requirements in virtual environments.
4.1 General recommendations
4.1.1 Assess the risks associated with virtual technology
Organizations must carefully and comprehensively assess the risks associated with virtualizing system components before selecting or implementing a specific virtualization solution. The flow and storage of cardholder data should be carefully documented as part of this risk assessment process to ensure that all areas of risk are identified and that appropriate measures are taken. Virtualization should be deployed with full consideration of all its advantages and risks, with a comprehensive system for monitoring data, applications and the entire environment at the ready.
Virtual environments and system components should continue to be included in the annual risk assessment process. Risk assessment and management decisions should be fully documented and supported by detailed business and technical expertise.
4.1.2 Understand the Impact of CDE Virtualization
Organizations that use virtualization to consolidate their environment on one or more physical hardware platforms may find themselves in a situation where they now have a complex set of virtual system configurations that make it difficult to determine the boundaries or scope of their CDE .
As with physical systems, the application of the PCI DSS standard in virtual components must be thoroughly tested and documented. The virtual environment should be assessed using the guidance provided in the PCI DSS Compliance Assessment section of the PCI DSS standard .. If any components running on the same hypervisor fall within the scope, it is recommended that all components on this hypervisor also be considered to be within the scope, including but not limited to virtual machines, virtual devices, and hypervisor plug-ins. Designing all virtualization components, even those that are out of scope, in accordance with PCI DSS requirements , will not only provide a secure foundation for the virtual environment as a whole, but will also reduce the complexity and risks associated with managing multiple security profiles, as well as reduce the overhead and effort required to maintain and confirm compliance with the scope of components.
4.1.3 Restrict physical access
As stated earlier in this document, placing multiple components on the same physical system can significantly increase the likely impact if an attacker gains access to that system.
Physical access control is therefore especially important in virtualized environments and should be strengthened as necessary to mitigate associated risks. When assessing access measures using physical means, consideration should be given to potential damage from cases where an unauthorized user or attacker gains simultaneous access to all VMs, networks, security devices, applications and hypervisors,
which one physical host can provide. Ensure that all unused physical interfaces are disabled and that physical or console level access is restricted and monitored.
4.1.4 Implement defense in depth
In the physical environment, a defense in depth approach that encompasses preventive, detection and response measures is the best practice for protecting data and other values. Logical security tools are typically used at the network, host, application, and data level, and physical security is used to protect media, systems, and objects from unauthorized physical access. Monitoring the effectiveness of measures and their potential to quickly and effectively respond to potential violations is also of paramount importance. The defense-in-depth approach also includes the training and education of personnel in the proper use of important resources, the identification of potential security threats and the appropriate measures to be taken in the event of a breach. Moreover,
In a virtualized environment, appropriate security measures must be defined and implemented that provide the same level and depth of security that can be achieved in the physical environment. For example, consider how security can be applied to protect each technical level, including but not limited to physical devices, a hypervisor, a host platform, guest operating systems, a VM, a perimeter network, a network inside a host, applications, and a data layer . Physical measures, documented policies and procedures, as well as staff training, should also be part of the defense in depth approach for the security of virtual environments.
4.1.5 Isolate Security Functions
The security functions provided by virtual machines must be performed with the same separation process as in the physical world. It is recommended that this requirement is even more strictly enforced in virtualized systems, as this greatly complicates the efforts required by an attacker who has decided to crack several CDEssystem components. For example, preventive control, such as a network firewall, should never be combined on the same logical host with the payment card data that it must protect. Similarly, you should not mix processes that control network segmentation and the log aggregation function, which should detect falsification of network segmentation. If such security features need to be hosted on the same hypervisor or host, the isolation level of the security features must be such that they can be viewed as installed on separate machines.
4.1.6 Provide Least Privileges and Separation of Duties
Credentials and data for administrative access to the hypervisor must be carefully controlled, and depending on the level of risk, the use of large restrictions on access to the hypervisor is often justified. Organizations should consider additional methods for securing administrative access, such as implementing two-factor authentication or creating dual or split-management of administrative passwords between multiple administrators. Access controls should be evaluated for both local and remote access to the hypervisor and management system. Particular attention should be paid to the individual functions of the virtual components, to ensure appropriate role-based access ( RBAC), which will avoid unnecessary access to resources and help to maintain separation of duties.
Administrative privileges also need to be shared appropriately. For example, the same administrator should not provide privileged access to the firewalls and monitoring servers for these firewalls. This level of access can lead to undetected falsification and loss of data, which could have been avoided if there were a separation of duties. It is best to restrict administrative access to a specific VM function, virtual network, hypervisor, hardware, application, and data warehouse.
4.1.7 Evaluate Hypervisor Technologies
Ensure that hypervisor security has been thoroughly tested prior to deployment and that there is proper patch management and other controls to respond to threats and vulnerabilities. It is critical to have identifying and implementing technologies that facilitate reliable protection, since not all hypervisors or VMMs have the functionality to support appropriate security measures.
4.1.8 Strengthen Hypervisor Security
The hypervisor platform must be located in a safe place in accordance with industry recommendations and security guidelines. Careful management of virtual system configurations, installation of patches, and control over changes are essential as confirmation that all changes to the hypervisor are monitored, performed only after authorization, are fully verified and carefully monitored. Due to the potential severity of a hypervisor hack, patches and other risk-mitigation actions need to be deployed as soon as possible whenever new security vulnerabilities are discovered, and immediate vulnerability testing is included in the process to confirm the danger.
Because the hypervisor is a single point of failure, unauthorized or malicious changes can threaten the integrity of all systems in the environment. The following additional measures are recommended for the hypervisor and any significant management tools:
- Limit the use of administrative functions on specific end networks and devices, such as specific laptops or desktop computers, that have been approved for such access.
- Require multi-factor authentication to perform all administrative functions.
- Make sure that all changes are performed and tested properly. Consider the need for additional management oversight that has wider boundaries than is required by the normal change management process.
- Separate administrative functions. That is, hypervisor administrators should not be able to modify, delete, or disable the hypervisor audit log.
- Send hypervisor logs (logs) to physically separate secure storage systems in the mode closest to real-time.
- Track the audit trail to identify activities that might indicate a violation of segmentation integrity, security controls, or communication channels between workloads.
- Separate responsibilities for administrative functions, for example, hypervisor access credentials prevent access to applications, data, or individual virtual components.
- Before implementing a virtualization solution, verify that security control solutions are supported and how they minimize the risk of penetration into the hypervisor.
Please note that since the hypervisor and management tools can directly affect the security of virtual components, they should always be considered as part of PCI DSS .
4.1.9 Strengthen the security of virtual machines and other components
It is also important that all individual virtual machines are installed and configured reliably and in accordance with industry-leading security solutions and guidelines. The recommendations presented above to enhance hypervisor protection apply also to VMs and virtual components.
Please note that these guidelines may not be applicable for each type of virtual machine or component. Implementations should be evaluated individually to confirm that the following has been considered:
- Disable or remove all unnecessary interfaces, ports, devices and services;
- Securely configure all virtual network interfaces and storage areas;
- Set restrictions on the use of VM resources;
- Make sure that all operating systems and applications running on the virtual machine are also strengthened;
- Send logs to separate secure storages, in the mode closest to real time;
- Check the integrity of cryptographic key management operations;
- Strengthen the security of individual VM hardware and containers;
- Other security measures as appropriate.
Security requirements may vary depending on the specific services or applications running on each virtual component; therefore, you must individually determine the appropriate security settings.
4.1.10 Determine the proper use of management tools
Management tools allow administrators to perform functions such as system backup, recovery, remote connection, migration, and making changes to virtual system configurations. Management tools for components that are within the scope of the scope will also be considered as part of the scope, as these tools directly affect the safety and performance of the components. Access to these management tools should be limited only to those employees who need such access to perform job duties. Segregation of roles and responsibilities is recommended for management tool functions, and any use of management tools should be monitored and logged.
4.1.11 Recognize the dynamic nature of virtual machines
Virtual machines are actually data that can reside in an active state (on the hypervisor) or in an inactive state (anywhere). Inactive virtual machines are stored datasets that can contain sensitive information and configuration information for virtual devices. A person who has access to an inactive VM can copy and turn it on elsewhere, or he can scan inactive files with payment card data and other confidential information. Access to inactive VMs should therefore be limited, monitored, and closely monitored.
Inactive VMs that contain payment card data should be treated with the same level of sensitivity, and they should have the same guarantees as any other data warehouse of plastic card holders. The transition paths for inactive VMs should be carefully evaluated, as they can bring additional systems to the scope. Backups of VMs, active VMs and inactive VMs should always be protected and safely deleted or erased when the data stored on them is no longer required. Careful change management, monitoring, and the notification process are critical to ensure that only authorized VMs are added and removed from the environment, and that all actions and access are recorded.
4.1.12 Assess the security features of a virtualized network
Ideally, any deployment of a virtual network infrastructure should include effective security measures in the data plane, control plane, and control plane. This will help minimize the likelihood of direct and indirect vulnerabilities moving from one plane to another, and damage to virtual network devices. While they are ideal, effective safety measures are not always possible on all three work planes. In these cases, it is becoming increasingly important to ensure that all major physical components are properly isolated and protected and do not create a path between virtual network devices. The isolation between virtual network devices must be such that virtual systems can be effectively considered as separate parts.
Each of the virtualized devices must support separate access configurations. The audit path for virtual infrastructures must be detailed and detailed enough to determine the individual access and activities carried out on each specific virtual component. Access restriction should ensure compliance with the minimum rights, both individually for each device and throughout the platform.
4.1.13 Clearly identify all hosted virtual services
Sometimes, shared hosting providers virtualize their offerings, allocating individual resources to clients, rather than allocating separate physical systems. Organizations considering a virtual hosting service should make sure that this proposal uses administrative, procedural, and technical segmentation to isolate the environment of each hosting organization from the environment of another hosting organization. Such isolation should, at a minimum, include all PCI DSS measures , including but not limited to segmented authentication, network and access restrictions, encryption and logging.
In addition, it is important to ensure that all the details of this service, including the obligation to maintain measures that could adversely affect the security and integrity of the data or that may affect its PCI DSS compliance , are clearly defined and described in a formal agreement.
4.1.14 Understand Technology
Virtual environments are significantly different from traditional physical environments, and a full understanding of virtualization technologies is very important for effective assessment and security in the environment. In the absence of formal virtualization security standards, organizations should familiarize themselves with industry best practices and guidelines for securing virtual environments. Examples of resources that provide guidance include publications from:
- Internet Security Center ( CIS )
- International Organization for Standardization ( ISO )
- ISACA (former Association of Audit and Control of Information Systems)
- National Institute of Technology Standards ( NIST )
- SysAdmin Audit Network Security ( SANS ) Institute
4.2 Recommendations for mixed mode environments
It is highly recommended (and this is a basic security principle) that VMs of different security levels should not be located on the same hypervisor or physical host; the main problem is that VMs with lower security requirements will have less access security and can be used to attack or create access to more sensitive VMs on the same system.
This principle should be applied in cases when incoming and out of scope VMs must be installed on the same host or hypervisor. Typically, any VM or other virtual component that resides on the same hardware or hypervisor as the component in the scope will also be included in the scope for PCI DSS, since both the hypervisor and the host underlying it provide a connection (physical, logical, or both) between the virtual devices, and it may not be possible to achieve the appropriate level of isolation or segmentation between components that are not in the scope of coverage, located on the same volume same server or hypervisor.
As mentioned earlier in this document, any hypervisor or host system that hosts a virtual component within the scope will also be within the scope of PCI DSS. In order for VMs that enter and are not within the scope of coexistence on the same host or hypervisor, virtual machines must be isolated from each other so that they can be effectively considered as separate hardware in different network segments without connecting to each other . Any system components shared by a VM, including the hypervisor and the underlying host system, should not represent an access path between virtual machines.
Even with adequate segmentation between virtual components, the amount of effort and administrative expense required to ensure segmentation is performed and the security levels of each component are maintained can be more onerous than using PCI DSS for the system as a whole.