PCI DSS Virtualization Guide. Part 3
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 2
The measures outlined in this section are recommendations and useful experiences that will help meet PCI DSS requirements in virtual environments.
')
Organizations should carefully and comprehensively assess the risks associated with the virtualization of system components before choosing 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 benefits and risks, with a comprehensive system for controlling data, applications and the environment as a whole.
Organizations that use virtualization to consolidate their environment on one or more physical hardware platforms may find themselves in the situation that they now have a complex set of virtual system configurations that make it difficult to define the boundaries or scope of their CDE .
As stated earlier in this document, placing multiple components on a single physical system can significantly increase the likely impact if an attacker gains access to this system.
In a physical environment, a defense-in-depth approach that covers preventive, detective, and response measures is the best practice for protecting data and other values. Logic security tools are commonly used at the network, host, application, and data layers, and physical security is used to protect media, systems, and objects from unauthorized physical access. Monitoring the effectiveness of measures and their potential to respond quickly and effectively to potential violations is also of paramount importance. The layered defense approach also includes the training and education of personnel on the proper use of important resources, the identification of potential security threats and the appropriate measures to be taken in the event of a violation. In addition, the layered environment has well-defined and documented policies, processes and procedures that are understood and implemented by all employees.
The security features provided by the virtual machines must be performed with the same separation process as in the physical world. It is recommended that this requirement be even more strictly observed in virtualized systems, since this significantly complicates the effort required from an attacker who has hacked several CDE components of the system. For example, proactive monitoring, such as a network firewall, should never be combined on the same logical host with the payment card data that it must protect. Similarly, one should not confuse the processes that control network segmentation and the function of aggregation of logs, which should detect falsification of network segmentation. If such security features need to be placed on the same hypervisor or host, the isolation level of security features must be such that they can be viewed as installed on separate machines.
The 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 of securing administrative access, such as the introduction of two-factor authentication or the creation of dual or split-management of administrative passwords between multiple administrators. Access control devices should be evaluated for both local and remote access to the hypervisor and management system. Special 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 the security of the hypervisor is thoroughly tested prior to deployment and that there are proper patch management and other controls to respond to threats and vulnerabilities. It is critical to have detection and deployment technologies that facilitate robust 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-accepted security guidelines and guidelines. Careful management of virtual system configurations, installation of patches, and control of changes are essential, as confirmation that all changes to the hypervisor are monitored, performed only after authorization, are fully checked and carefully monitored. Because of the potential seriousness of the hypervisor hacking, patches and other risk mitigation actions need to be deployed as soon as possible whenever new security vulnerabilities have been discovered and include immediate vulnerability testing in the process to confirm the danger.
It is also important that all individual virtual machines are installed and configured securely and in accordance with the best industry solutions and protection guidelines. The recommendations presented above for enhancing hypervisor security also apply to VMs and virtual components.
Management tools allow administrators to perform functions such as system backup, recovery, remote connection, migration, and changes in the configuration of virtual systems. The management tools of the covered components will also be considered covered because these tools directly affect the safety and performance of the components. Access to these management tools should be limited to those employees who need such access to perform their duties. Segregation of roles and responsibilities is recommended for the functions of management tools, and any use of management tools should be monitored and logged.
Virtual machines are actually data that can be located in the active state (on the hypervisor) or in the inactive state (in any place). Inactive virtual machines are stored datasets that can contain sensitive information and virtual device configuration information. A person who has access to an inactive VM can copy and turn it on in another location, or it can scan inactive files with payment card data and other confidential information. Access to inactive VMs must therefore be limited, monitored and carefully controlled.
Ideally, any virtual network infrastructure deployment 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 the underlying physical components are properly isolated and protected and do not create a path between the virtual network devices. The isolation between virtual network devices must be such that virtual systems can be effectively treated as separate parts.
Sometimes virtual hosting providers virtualize their offers, allocating individual resources to customers, rather than allocating separate physical systems. Organizations that consider a virtual hosting service should ensure that this offer uses administrative, procedural, and technical segmentation to isolate the environment of each hosted organization from the environment of another hosted organization. This 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 complete understanding of virtualization technologies is very important for effective assessment and security in the environment. , . , , :
( ) ; , .
, . , , , , PCI DSS , , (, ) , , , .
, -, , PCI DSS . , , . , , -, .
, , 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 2
4 Recommendations
The measures outlined in this section are recommendations and useful experiences that will help meet PCI DSS requirements in virtual environments.
')
4.1 General recommendations
4.1.1 Evaluate the risks associated with virtual technology.
Organizations should carefully and comprehensively assess the risks associated with the virtualization of system components before choosing 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 benefits and risks, with a comprehensive system for controlling data, applications and the environment as a whole.
Virtual environments and system components must still be included in the annual risk assessment process. Risk assessment and management decisions must be fully documented and supported by detailed business and technical expertise.
4.1.2 Understand the impact of virtualization in CDE
Organizations that use virtualization to consolidate their environment on one or more physical hardware platforms may find themselves in the situation that they now have a complex set of virtual system configurations that make it difficult to define the boundaries or scope of their CDE .
As in physical systems, the scope of application of the PCI DSS standard in virtual components should be thoroughly checked and documented. The virtual environment should be assessed using the guidance provided in the “Scope of Compliance Assessment with PCI DSS Requirements ” section of the PCI DSS standard. If any components running on the same hypervisor are in scope, it is recommended that all components in this hypervisor are also considered to be in scope, including but not limited to virtual machines, virtual devices, and hypervisor plugins. Designing all the components of virtualization, even those that are out of scope, in accordance with the requirements of PCI DSS , not only provides 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 verify compliance of the components covered by the scope.
4.1.3 Limit physical access
As stated earlier in this document, placing multiple components on a single physical system can significantly increase the likely impact if an attacker gains access to this system.
Access control using physical tools is therefore particularly important in virtualized environments and should be strengthened as necessary measures to mitigate the associated risks. When evaluating access measures using physical means, consideration should be given to the potential damage from cases where an unauthorized user or attacker gains simultaneous access to all VMs, networks, security devices, applications, and hypervisors.
which can provide one physical host. Ensure that all unused physical interfaces are disabled, and that physical access or access at the console level is limited and monitored.
4.1.4 Implement defense in depth
In a physical environment, a defense-in-depth approach that covers preventive, detective, and response measures is the best practice for protecting data and other values. Logic security tools are commonly used at the network, host, application, and data layers, and physical security is used to protect media, systems, and objects from unauthorized physical access. Monitoring the effectiveness of measures and their potential to respond quickly and effectively to potential violations is also of paramount importance. The layered defense approach also includes the training and education of personnel on the proper use of important resources, the identification of potential security threats and the appropriate measures to be taken in the event of a violation. In addition, the layered environment has well-defined and documented policies, processes and procedures that are understood and implemented by all employees.
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 a physical environment. For example, consider how security can be applied to protect each technical layer, including but not limited to physical devices, the hypervisor, the host platform, guest operating systems, VM, perimeter network, network within the host, applications, and the data layer . Physical measures, documented policies and procedures, as well as staff training, should also be part of a multi-layered protection approach for securing virtual environments.
4.1.5 Isolate security features
The security features provided by the virtual machines must be performed with the same separation process as in the physical world. It is recommended that this requirement be even more strictly observed in virtualized systems, since this significantly complicates the effort required from an attacker who has hacked several CDE components of the system. For example, proactive monitoring, such as a network firewall, should never be combined on the same logical host with the payment card data that it must protect. Similarly, one should not confuse the processes that control network segmentation and the function of aggregation of logs, which should detect falsification of network segmentation. If such security features need to be placed on the same hypervisor or host, the isolation level of security features must be such that they can be viewed as installed on separate machines.
4.1.6 Ensure the lowest privileges and segregation of duties
The 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 of securing administrative access, such as the introduction of two-factor authentication or the creation of dual or split-management of administrative passwords between multiple administrators. Access control devices should be evaluated for both local and remote access to the hypervisor and management system. Special 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 divided properly. For example, the same administrator should not be granted privileged access to firewalls and monitoring servers for these firewalls. This level of access can lead to undetected falsification and data loss, which could have been avoided if there was a separation of duties. It is best to limit administrative access to a specific function of the VM, virtual network, hypervisor, hardware, application, and data storage.
4.1.7 Evaluate hypervisor technologies
Ensure that the security of the hypervisor is thoroughly tested prior to deployment and that there are proper patch management and other controls to respond to threats and vulnerabilities. It is critical to have detection and deployment technologies that facilitate robust 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-accepted security guidelines and guidelines. Careful management of virtual system configurations, installation of patches, and control of changes are essential, as confirmation that all changes to the hypervisor are monitored, performed only after authorization, are fully checked and carefully monitored. Because of the potential seriousness of the hypervisor hacking, patches and other risk mitigation actions need to be deployed as soon as possible whenever new security vulnerabilities have been discovered and include immediate vulnerability testing in the process to confirm the danger.
Since the hypervisor is a single point of failure, unauthorized or malicious changes can threaten the reliability of all systems located in the environment. The following additional measures are recommended for the hypervisor and any significant management tools:
- Restrict the use of administrative functions in certain end networks and devices, such as specific laptops or desktops, that have been approved for such access.
- Require multi-factor authentication to perform all administrative functions.
- Make sure all changes are implemented 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 change, delete, or disable the hypervisor audit log.
- Send the hypervisor logs (logs) to physically separate secure storage systems in the mode closest to the real-time mode.
- Track an audit trail to identify activities that might indicate a breakdown in segmentation integrity, security monitoring, or the presence of communication channels between workloads.
- Separate responsibilities for administrative functions, for example, access credentials for the hypervisor do not allow 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 securely and in accordance with the best industry solutions and protection guidelines. The recommendations presented above for enhancing hypervisor security also apply 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 separately, 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 limits on the use of VM resources;
- Make sure that all operating systems and applications running in the virtual machine are also enhanced;
- Send logs to separate secure vaults, in the mode closest to real time;
- Check the integrity of cryptographic key management operations;
- Strengthen the security of individual iron VMs and containers;
- Other security measures depending on the situation.
Security requirements may vary depending on certain 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 changes in the configuration of virtual systems. The management tools of the covered components will also be considered covered because these tools directly affect the safety and performance of the components. Access to these management tools should be limited to those employees who need such access to perform their duties. Segregation of roles and responsibilities is recommended for the functions of management tools, 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 be located in the active state (on the hypervisor) or in the inactive state (in any place). Inactive virtual machines are stored datasets that can contain sensitive information and virtual device configuration information. A person who has access to an inactive VM can copy and turn it on in another location, or it can scan inactive files with payment card data and other confidential information. Access to inactive VMs must therefore be limited, monitored and carefully controlled.
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 stores of plastic card holders. Ways to migrate inactive VMs should be carefully evaluated, as they can bring additional systems into scope. VM, active VM and inactive VM backups should always be protected and safely deleted or erased when data stored on them is no longer required. Careful change management, monitoring, and notification processes are critical to ensuring that only authorized VMs are added and removed from the environment, and that all actions and access are recorded.
4.1.12 Evaluate the security features of a virtualized network.
Ideally, any virtual network infrastructure deployment 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 the underlying physical components are properly isolated and protected and do not create a path between the virtual network devices. The isolation between virtual network devices must be such that virtual systems can be effectively treated 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 must ensure compliance with the minimum rights, individually for each device, and across the platform.
4.1.13 Clearly define all hosted virtual services
Sometimes virtual hosting providers virtualize their offers, allocating individual resources to customers, rather than allocating separate physical systems. Organizations that consider a virtual hosting service should ensure that this offer uses administrative, procedural, and technical segmentation to isolate the environment of each hosted organization from the environment of another hosted organization. This 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 may affect the security and integrity of the data or that may affect its compliance with the PCI DSS , are clearly defined and described in the formal agreement.
4.1.14 Understand Technology
Virtual environments are significantly different from traditional physical environments, and a complete understanding of virtualization technologies is very important for effective assessment and security in the environment. , . , , :
- - ( CIS )
- ( ISO )
- ISACA ( )
- ( NIST )
- SysAdmin Audit Network Security ( SANS ) Institute
4.2
( ) ; , .
, . , , , , PCI DSS , , (, ) , , , .
, -, , PCI DSS . , , . , , -, .
, , PCI DSS .
4.2.1
, ; , . , .
, , , . , , , , , , , , , API . , . , , , . .
, , . , , , , .
. . , , , .
, , .
, SAN , , , , .
Source: https://habr.com/ru/post/248343/
All Articles