In the face of an increasing list of compliance frameworks, IT organizations operating on an already stretched budget are desperate for relief. Regulations around Personally Identifiable Information (PII), cardholder data (CHD) and patient health information all require a separate environment for storing and transmitting sensitive data. Who can afford THAT?
First of all, allow me the gratuitous act of saying, this is why it is in your best interest to call in a professional. Qualified Security Assessors (QSAs) are experts in translating the intent of PCI DSS requirements and can most likely identify ways to leverage your existing environment to achieve PCI compliance. For more information, check out my boss’ page: https://www.halock.com/practices-achieving-pci-compliance/
One solution to the database issue is the use of virtualization for storage of CHD. William Hau, V.P. of professional services at Foundstone wrote an incredibly informative white paper on the impact of virtualization on various PCI DSS requirements. However, this paper being co-authored by members of the VMWare organization, the information is slightly slanted toward VMWare solutions.
I’ve doctored Hau’s guidance with a more holistic commentary. Regardless of how one is storing their CHD in a virtualized storage environment, IT organizations must meet the intent of each PCI DSS requirement. The following will be most affected by the use of virtualization:
1.1.3 Requirements for a firewall at each Internet connection and between any DMZ and the internal network zone
Access to each guest virtual machine must be controlled using by IP address. Limit inbound and outbound traffic by building ACLs to permit necessary services and deny all other traffic. Functions a firewall must provide include:
- Examine all network traffic and block transmissions that do not meet the specified security criteria
- Support configuration of a DMZ
- Restrict outbound traffic
- Perform stateful packet inspection
- Perform NAT or PAT (IP masquerading)
2.1 Always change vendor-supplied defaults before installing a system on the network
Preventative actions such as renaming/disabling default accounts or changing the default bootstrap password prevent malicious users from exploiting known authentication methods to gain access to the cardholder data environment. However, preventative actions performed on the host OS are not reflected on the guest OS. Therefore, standards and guidelines used to address vendor defaults should be altered to take under consideration default settings for:
- Guests
- Hosts
- Virtual management utilities
· One of the greatest benefits of virtualization is the flexibility of having an offline image of your virtual machine (VM) in the case that there is a system malfunction. Conversely, one of the biggest vulnerabilities in the virtual environment is the security and management of offline images, templates, and clones. In order to reduce the risk of exploitation, vendor default accounts, passwords and security settings should be changed before the image is captured.
*For a list of vendor default accounts and/or passwords, browse to: http://www.CIRT.net/passwords or http://www.cyxla.com/passwords/passwords.html
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
The PCI DSS requires each system component to have a specific hardening guideline. These guidelines must follow an industry accepted standard such as SANs, NIST or CIS. Virtual machines, images, clones, virtual management utilities, hyper-visors, and virtual firewalls should be added to the list of system components requiring hardening guidelines.
Additionally, organizations should consider hosting control management systems on their own dedicated server which is properly segmented from systems not part of their PCI scope. This follows best practices for reducing scope of the PCI environment. Administrative access to the cardholder data environment should be limited by IP and protocol, and require two-factor authentication over secured protocols.
2.2.1 Implement only one primary function per server
The intent of this requirement, which is to limit the impact of risk to the cardholder data environment, can be met or exceeded using virtualization solutions. A server should perform a specific function, such as a web server OR a database server but not both, since the services required for a web server would make a database vulnerable to exploits. In a virtual cluster, as long as each guest does not perform more than one fundamental function, and the proper controls are put in place, virtualization does not hinder compliance with requirement 2.2.1.
Traffic to and from the guest must be limited to support the function of that server. All other unnecessary services, protocols, scripts, or access methods to data should be disabled. Specifically this means that virtual machine templates must undergo strenuous customization before they are brought online to ensure only necessary services are explicitly permitted.
Virtualization solutions provide native access controlling technologies, such as hyper-visors, virtual switches and virtual firewalls. These technologies need to be implemented in a manner which prevents inappropriate access between guests, and between the host and guests. Access Control Lists should contain specific documented services required for each VM, and contain a “deny all” rule for any service requests not explicitly allowed. For example: permit SSH access to the guest VM from a specific and limited list of IP addresses, however explicitly deny all other requests, therefore disallowing the use of VNC and other insecure protocols to administer the VM.
2.2.2 Disable all unnecessary and insecure services and protocols
Traditionally, this means allowing secure administration through the use of SSH versus telnet, or securing FTP for file transfers. In a virtual environment, follow the vendor provided guidelines for security administration settings. Also, replace the use of native and insecure protocols like VNC with SSH.
2.2.3 Configure system security parameters to prevent misuse
This requirement ensures security hardening procedures documented in requirement 2.2 are reflected in the configuration of system components. During an on-site assessment, QSAs will run vulnerability assessment tools and examine configuration files of virtual components in the cardholder data environment, not just the host.
2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers
Administrators tend to build scripts, procedures, and open access methods to improve efficiency. In this process, exploit vectors may be introducing into their environment. When administering multiple virtual systems from the same user interface, it is typical to want to drag and drop files from one “screen” to another. However, when one physical host contains virtual machines both in and out of the cardholder data environment, it is imperative to disable sharing between VMs before the systems are brought on-line.
2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web based management and other non-console administrative access
This requirement elaborates on the requirement for only secure protocols and services (PCI requirement 2.2.2). VM administrators have more concentrated power in their hands than traditional network and server administrators. Therefore, it is vital to use secure protocols such as SSL/TLS for connectivity to the hosts and virtual management servers. In the best case scenario, management of the VMs occurs from one highly secure system hosted on a separate segment. Access is controlled by IP and administrators utilize a VLAN to connect to the virtual machine(s) in the cardholder data environment via secure protocols.
3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
The very nature of virtual computing challenges the intent of requirement 3.1. The configuration of each virtual machine or VM is stored as a directory on the host (like a file server). When the virtual machine is copied, or a snapshot is taken, that is another instance of the VM which is stored on the host. Organizations could very quickly lose control of the amount of cardholder data stored on that host. Strong controls should be implemented to limit administrative abilities to create multiple instances of VMs, especially those with stored cardholder data.
3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse.
As with requirement 3.1, if cryptographic keys are stored on a guest VM, organizations need to put strong controls in place to prevent replication of those keys. Also, if business needs justify the archival of keys, (by creating a snapshot for instance), those keys stored offline need to be tracked, revoked, and destroyed when they reach their expiry date, as the key management policy dictates.
5.1 Deploy anti-virus software on all systems commonly affected by malicious software
Systems “commonly affected by malicious software” generally refers to Microsoft systems, or systems with a master boot record. In a virtual environment, regardless of whether it is a host or guest, all Microsoft based systems must have anti-virus (and anti-malware) installed and configured to meet the intent of these requirements. Even Windows XP VMs installed on a UNIX based host must have AV software installed, enabled and configured. Administrators should install anti-virus software on all templates to ensure that no system is inadvertently brought on-line without protections against malicious code.
6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release
Requirement 6.1 is also going to be particularly challenging in a virtual environment. Offline templates, images, and snapshots may quickly become out-of-date, so the use of products that can perform offline patching and antivirus updates is highly recommended. Virtualization vendors will most likely have recommendations specific to their technology regarding offline patching.
If a vendor solution is not used, organizations need to create process and procedure around the maintenance of offline images. Monthly patching schedules and weekly antivirus updates should include offline images as well as the supporting virtualization infrastructure.
6.2 Establish a process to identify newly discovered security vulnerabilities
In addition to monitoring the traditional security message boards, System Administrators of a virtual environment should add monitors for known exploits against virtual environments as well as adding the vendor specific subscriptions.
6.3.2 Separate development/test and production environments
Virtualization has traditionally been used extensively for testing. Organizations should ensure test images are properly segmented from development images. Specifically, a snapshot of a production and/or development system containing cardholder data should never be brought on-line in the test environment, regardless of how convenient it would be. Policies and procedures should specifically designate templates for development or testing, and explicitly prohibit implementing development systems in a test environment and vice versa.
6.3.5 Removal of test data and accounts before production systems become active
Just as it would be easy to bring a production image on-line in a test environment, it is very easy to copy a virtual machine directly from a test environment directly into production. However, in doing so, test data and accounts would be brought into the production environment. Hard-coded source files may be revealed and proper error handling may not be implemented. As with 6.3.4, it is more secure to keep the test and production images segmented from each other in order to meet this PCI requirement.
6.4 Follow change control procedures for all changes to system components
Due to the ease with which changes can be made and undone in the virtual environment, it is very tempting to bypass change control procedures. Unfortunately this is a policy enforcement issue, and is therefore prone to a lack in compliance. Thus, logging of privilege use becomes very important. Virtual management software packages can be used to provide audit controls around the storage and deployment of images.
7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities
Become educated about privilege use accounts specific to the virtualization vendor. Restrict all privileges which allow arbitrary virtual machine network assignment. Since network segmentation is used to limit the scope of the PCI environment, all administrators should be prevented from inadvertently assigning an IP address located in the PCI segment to a guest virtual machine. Consider specific actions required when assigning privileges and avoid handing out overly excessive permissions unless absolutely necessary for business.
7.2 Establish an access control system for systems components with multiple users that restricts access based upon a user’s need to know, and is set to “deny all” unless specifically allowed
Some believe only the bare-metal or native virtualization solutions provide authorization controls strong enough to meet the intent of this requirement. However, any solution which sufficiently supports Role-Based Access Control (RBAC) meets the intent of this requirement. There is a caveat, however, and that is that further guidance for virtualization is anticipated in the next release of the PCI DSS (version 2), and the same consortium which favor bare-metal virtualization did provide some guidance to the PCI SSC.
8.1 Assign all users a unique ID before allowing them to access system components or cardholder data
The only guidance specific to a virtualized environment would be to integrate access controls to the management console with a directory service, such as Active Directory.
8.5 Ensure proper user authentication and password management for non-consumer users and administrators on all system components
By default, many virtualization vendors do not allow special characters within password. Therefore, password parameters on the virtualization management console should be altered to fall in line with PCI requirements for password complexity. Integration with a directory services such as AD enables the use of existing centralized password management policies.
9.6 – 9.10 Media containing cardholder data
The nature of virtualization makes the security of media containing cardholder data particularly challenging. Templates, images and snapshots containing cardholder data could very quickly be propagated into several file directories on the host computer. Organizations need to restrict access to these files and the ability to copy them to other media. They also need to keep track of all potential replicas of these files, and destroy all copies when the VM is no longer required. Requirement 9.10 requires that destruction procedures such as degaussing and PGP shredding be used to destroy remnant files for deleted VMs.
10.2 Implement automated audit trails for all systems components
Ensure audit trails are maintained for the virtual infrastructure components, especially management utilities and the host. Monitor virtual networks in the cardholder data environment for any virtual machine assignment so that any unauthorized virtual machine on a network can be immediately detected and responded to. Each VM should meet logging criteria, and push those logs to a centralized log manager. Due to the significant impact on CPU, memory and disk space, organizations should plan to accommodate logging when allocating computing resources.
Bare-metal virtualization vendors provide centralized management capabilities that allow remote administration of hyper-visors using mature administrative interfaces that in turn depend on production-grade relational databases as the back-end data repository to store the hyper-visor configuration settings and administrative privileges. Auditing and logging on these databases should be enabled as well as any other logging capabilities provided by the hyper-visor vendor.
10.3. X Record at least the following audit trail entries for all components for each event (User ID, Type of Event, Date and Time, Success/Failure indication, Origination of Event, Identity of affected system/data)
This requirement applies to the host, the guests and the virtual infrastructure management components.
10.4 Synchronize all critical systems clocks and times
Each guest VM should synchronize with the host, and the host to the internal NTP server. For virtualized servers in the DMZ, the host should synchronize with the network device or external NTP time source. Note: only one host within the DMZ should synchronize with an external source, and all others should sync with it.
At some point there were some weaknesses identified in the hyper-visor implemented in some virtualization vendors which caused the NTP daemon to “go to sleep”. At this time, there are no NTP issues known in the market. Organizations should verify their virtualization solution does not have any NTP latency issues.
10.5 Secure audit trails so they cannot be altered
Closely restrict access to any database where events are recorded. Log files from individual guests should be sent to a secure remote syslog server, thus reducing the possibility of tampering.
10.6 Review logs for all system components at least daily
Add virtualization to the existing log management tools and process so as to ensure that these are audited on a regular basis just like other logs within your environment.
11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files; and configure the software to perform critical file comparisons at least weekly
File Integrity Monitoring should be configured on the guest VMs to monitor and alert on files containing cardholder data. On the host computer FIM should be configured to monitor the system and configuration files of the VMs.
12.1.1 Establish, publish, maintain and disseminate a security policy that addresses all PCI DSS requirements.
Ensure all security policies include VM specific measures for the virtual firewall, standard build of templates, disposal of VMs storing CHD, and any other additional security measures specific to virtual machines. Only allow virtual machine deployment via virtual machine templates, which embeds the network assignment in its specification.
12.2 Develop daily operational security procedures that are consistent with PCI DSS specifications
Security procedures should be extended to describe virtualization specific issues. For example: monitoring for unauthorized VM images or instances, patch management of guest VMs, and periodic reviews of virtual firewall configurations.
12.3 Develop usage policies for critical employee-facing technologies
Usage policies should be extended to describe virtualization specific issues. Specifically, testing and production templates and VMs should not be copied and/or cloned outside of their functional area. Restrict the ability to create copy, delete or move VMs which are a part of the cardholder data environment. Prohibit system administrators from enabling “shared” technologies between guest VMs, especially those in the cardholder data environment.
The use of virtualization enables IT organizations to meet the requirements of various compliance frameworks on a fixed/limited budget. The key to successfully achieving PCI compliance is to design the virtualization solution on the foundation of these requirements.