PCI Cloud Compliance Technical Considerations Part 2

By Eric Sampson and Doug Barbin

In a previous article, we provided a summary of the key components of the PCI DSS Cloud Computing Guidelines (“cloud supplement”). That article focused on roles, responsibilities, agreements, and audit considerations. This article speaks more to the technical considerations.

Segmentation challenges

Cloud hosted environments often present new layers of responsibility for common shared layers, such as hypervisors and virtual infrastructure layers, which can present a single point of entry (or attack) for all systems above or below those shared layers. The security applied to these layers is therefore critical not only to the security of the individual environments they support, but also to ensure that segmentation is enforced between different tenants’ environments.

Regardless of whether a hosted environment can achieve PCI DSS compliance, risks and threats persist, especially for shared cloud environments. The need for adequate segmentation of client environments in a public or shared cloud is underscored by the principle that the other client environments running on the same infrastructure are to be considered untrusted networks. The client has no way of confirming whether other client environments are securely configured or patched appropriately to protect against attack, or that they are not already compromised or designed with malicious intent. This is particularly relevant where a cloud provider offers IaaS and PaaS services, as the individual tenants have greater control and management of their environments.

Virtualization Considerations

Virtualization requirements apply generally to cloud hosted environments. The SSC had previously published the PCI DSS Virtualization Guidelines to discuss security considerations for virtual technologies. In a complementary manner, the Cloud Guidelines reiterates some virtualization guidance and provides additional security considerations for cloud hosted environments. Of note regarding technical considerations are the following:

• VM-to-VM traffic does not pass through traditional network-based security controls, such as a firewall, router, or network IDS/IPS. Rather, traffic can pass through virtual network routes. The use of additional host-based security controls to monitor and control traffic, such as host-based firewalls and host-based IDS/IPS applications may be necessary.
• Dormant virtual machines must be secured when dormant and not actively used for any period of time. Security vulnerabilities can be introduced when dormant host is activated. In the same vein, if a virtual machine can be removed and replaced, a malicious user can make modifications offline and introduce a malware infected virtual machine.
• In cloud hosted environments, audit logs are available both at the virtual host and at the virtual machine operating system. Cloud providers and tenants should discuss roles and responsibilities to ensure all audit logs are reviewed appropriately and in a timely manner. Creating an environment where virtual host and virtual machine audit logs can be correlated into meaningful events is recommended.
• Where the hypervisor has introspection capabilities, or the ability to control and monitor individual VM activity from outside the VMs, presents security challenges. For instance, the introspection function allows files of VMs to be access within the privileged state of the hypervisor without an audit trail being generated by the VM. This can present a greater concern for tenants of public, community, or hybrid cloud hosted environments than for tenants of private cloud services. Tenants should be aware that any personnel with access to the introspection function on the hypervisor could potentially have access to data on any VM managed by the hypervisor. Therefore, the introspection function should be carefully managed, controlled, and monitored to ensure that role-based access and segregation of duties is maintained. For example, the hypervisor administration and hypervisor monitoring and auditing functions should be separated.

As noted in the previous article, many of the above issues apply equally in the world of SOC 1, SOC 2, ISO 27001 certification, and FedRAMP.

Please feel free to contact Schellman if you have any additional questions. Schellman specializes in PCI validation for cloud providers. We are also the only firm in the world that is a licensed CPA firm, PCI QSA, ISO 27001 certification body, and FedRAMP 3PAO.

Eric Sampson is a QSA at Schellman who leads assessments for some of the largest SaaS providers in the US. Doug Barbin is a Principal at Schellman and the firm-wide practice leader for PCI.