Addressing PCI DSS in Cloud and Virtual Environments

Protecting cardholder data in virtual workloads

wHiTEpApER

Introduction
While many organizations find the Payment Card Industry Data Security Standard (PCI DSS) requirements challenging, most organizations recognize that security and compliance are part of a successful risk management strategy that requires continual enhancements as their IT operations evolve. For example, organizations are taking advantage of the operational and cost benefits provided by virtualized and public cloud infrastructures, but face challenges when trying to protect cardholder data and maintain compliance in these environments. The Payment Card Industry Security Standards Council (PCI SSC) has updated their guidance on the standard to support these data center consolidation and cloud migration trends by publishing specific requirements for virtualization and cloud in advance of the next major release of PCI DSS. The guidelines are a critical part of any PCI DSS assessment performed by Internal Security Assessors (ISA) and Qualified Security Assessors (QSA) when creating an annual Report on Compliance (ROC) for an organizations cardholder data environment.

Use of a PCI DSS compliant CSP does not result in PCI DSS compliance for the clients. The client must still ensure they are using the service in a compliant manner, and is also ultimately responsible for the security of their cardholder data (CHD) outsourcing daily management of a subset of PCI DSS requirements does not remove the clients responsibility to ensure CHD is properly secured and that PCI DSS controls are met. -Information Supplement: PCI DSS v2.0 Cloud Computing Guidelines, March 2013

Protecting Cardholder Data in Virtual Workloads

A critical requirement of PCI DSS is protection of stored cardholder data with strong encryption and key management best practices. However, it can be difficult to address these requirements and achieve comprehensive protection in virtualized environments, where virtual image snapshots are created and automated operations routinely backup or move virtual workloads to other host systems. Maintaining control of cardholder data, regardless of where virtual workloads are moved, and being able to respond quickly and effectively in the event of a data breach are critical to achieving security and compliance of cardholder data residing in virtual machines (VM). This is especially important when organizations work with cloud service providers (CSP): The PCI SSC has emphasized that simply working with a compliant CSP does not result PCI DSS compliance for the client.

Addressing PCI DSS in Cloud and Virtual Environments Whitepaper

The following are key criteria for protecting virtual workloads and addressing PCI DSS cloud compliance requirements: Ensure the entire VM can be encrypted, including OS, swap, and data partitions Prevent unauthorized users from starting VMs containing sensitive data, even those that have been moved, cloned, terminated or archived Separate administration and access of cryptographic keys from encrypted data Maintain ownership of cryptographic keys and retain the ability to delete them in case of a breach (or CSP agreement termination) to render data in VMs unreadable Log and report on administrative activities and events associated with VMs containing cardholder data

The PCI DSS virtual and cloud guidelines focus on several characteristics of cloud environments that can make cardholder data stored in these environments vulnerable. The guidelines highlight cloud security concerns when sensitive data is contained in VM images, clones and backups. Sensitive data inadvertently replicated in VMs as a result of these cloud maintenance functions or remnant data left in terminated VMs needs to be protected in accordance with the guidelines. Specific considerations detailed in the guidance include preventing unauthorized access to sensitive data captured as VMs are moved or copied, protecting data remnants that may exist in terminated VMs (sensitive data may still remain in swap and OS partitions), separating the management of cryptographic keys from the encrypted data and purging data from VMs in the event of a data breach or termination of the CSP agreement. SafeNet ProtectV and SafeNet KeySecure can address these requirements and many others the PCI SSC has specified for achieving PCI DSS compliance in cloud and virtual environments.

Maintaining Compliance with SafeNet ProtectV and SafeNet KeySecure

SafeNet enables organizations to leverage the business benefits of virtualization and cloud services, while addressing their governance, compliance, and data protection requirements. With SafeNet ProtectV, organizations can encrypt and secure entire virtualized machines, consistently enforce security policies, and protect cardholder data from theft or exposure. ProtectV enables organizations to address the specific security and compliance requirements in cloud environments. With ProtectV, these organizations can isolate, track and report on VMs containing cardholder data. As a result, they can eliminate costly compensating controls that may be in place for VM protection that complicate PCI DSS assessments. ProtectV is deployed with SafeNet KeySecure, a robust key management solution. KeySecure features an optional FIPS 140-2 level 3 validated hardware security module. In addition, SafeNet offers Virtual KeySecure, a hardened virtual appliance that offers additional flexibility in cloud environments. ProtectV and KeySecure deliver robust high-availability capabilities that enable organizations to scale deployments in highly dynamic virtual and cloud environments. Following are more details on these solutions key capabilities. Partition Encryption Policies and regulations often require enterprises to guarantee that, even if a storage node is compromised, sensitive data retained on that node will remain unreadable. To address this requirement, ProtectV provides partition encryption, a key mechanism for protectioneven when other defenses are breached. This feature offers multiple permissions for controlling disk access to the virtual partition. By using the solutions combination of volume access controls and decryption key rights, security administrators can ensure that only authorized users gain access to encrypted data. ProtectV encrypts the entire data partition in a non-intrusive manner, so there is no need to backup data, reformat the partition prior to encryption, and restore the data after encryption. In addition, ProtectV offers a partition recovery feature that allows the resumption of encryption mid-cycle, even after interruption by power outages and other unexpected events. Boot Management Many VM security and compliance requirements cover the copying and cloning of images within the virtual or cloud environment. ProtectV StartGuard provides organizations with critical control over the boot process. As a result, ProtectV protects VMs from unauthorized boot, even when they are moved, dormant, offline, or archived. ProtectV enforces boot management controls through a mechanism that coordinates activities between the ProtectV manager and its associated ProtectV client nodes.

Addressing PCI DSS in Cloud and Virtual Environments Whitepaper

When the ProtectV client is installed on a node, a dual-phase boot loader is also installed. This splits the boot process into two separate phases: bootstrapping and networking is separated from loading the operating system (OS). Once this dual-phase loader is installed, the client asks the ProtectV manager for permission to proceed with an OS load. The manager performs this check based on a unique identifier for each node. If that particular node is registered to allow automatic booting, the OS loads normally. If not, the OS remains unloaded until explicit boot permission is granted by a user ProtectV management console. An immediate benefit of dual-phase boot is that it offers protection against data being exposed through intentional or unintentional VM copying and cloning. If a VM is cloned, the resulting unique identifier will not be registered with the ProtectV manager, so the second boot phase will be denied. For cases where boot authorization is required, the cloned VM can be registered, either programmatically or with a few mouse clicks. Group, Role, and User Policy Management ProtectV offers group, role, and user editors that enable auditing and compliance by procedurally enforcing separation of duties and security policies. Following are more details on these editors: Group editor. ProtectV allows administrators to place VMs in one or more groups. Each group has an assigned policy. For example, a policy may require that all volumes contained in a group are encrypted. Also, a group-based policy may grant or deny automatic reboot. Role editor. ProtectV offers an editor for creating, modifying, and deleting roles with detailed controls. Each role consists of a unique set of permissions for dozens of operations, enabling organizations to enforce highly granular administrator roles and separation of duties. ProtectV ships with several useful roles predefined, including three distinct administration roles. User editor. With ProtectV, administrators can manage user policies, including assigning names, passwords, and default roles.
Fig. A

Fig. A - Through the ProtectV console, administrators can assign VMs, create new groups, and also assign a VM to several different groups simultaneously. Fig. B

Fig. B - ProtectV features a sophisticated role editor that enables organizations to enforce separation of duties as required by PCI DSS

Addressing PCI DSS in Cloud and Virtual Environments Whitepaper

ProtectV Addresses PCI DSS Cloud and Virtualization Guidance

PCI DSS v2.0 Cloud Computing Guidelines Addressed by ProtectV
PCI DSS Section
Protect Cardholder Data

Requirement*
How are VM images, snapshots, and backups managed to prevent unnecessary capture of sensitive data? How is data securely deleted [..] and stored images? Will data remnants exist in terminated VMs? Is all client data securely purged from all CSP systems upon termination of the agreement?

ProtectV/KeySecure Capabilities
ProtectV controls who can start VMs and encryption protects sensitive data captured in backups and snapshots. With ProtectV, organizations can delete all the a keys associated with data, OSs, and swap partitions. This renders all the sensitive data in the VM unreadable. With ProtectV, the customer owns the keys, not the CSP. As a result, organizations can delete keys and effectively ensure encrypted assets are purged when a CSP agreement is terminated. ProtectV does encryption in-place so data does not have to be sent outside the protected VM to be encrypted or decrypted. ProtectV and KeySecure provide separation of duties between key administration and virtual infrastructure management. Keys are stored separately in a secure vault. ProtectV StartGuard offers pre-boot authentication that can control who can launch a VM or provide a challenge/response mechanism for physical systems.

Where are encryption/decryption processes being performed? Where are cryptographic keys stored, and who controls the keys? Are data-encryption keys stored and managed separately from the data they protect? Maintain a Vulnerability Management Program Are VMs protected from within the VM or from the hypervisor?

*Information Supplement: PCI DSS Cloud Computing Guidelines, February 2013

PCI DSS v2.0 Virtualization Guidelines Addressed by ProtectV

PCI DSS Section
Protect Cardholder Data

Requirement*
As well as being present in known locations, cardholder data could exist in archived, off-line, or dormant VM images, or be unknowingly moved between virtual systems via dynamic mechanisms such as live migration or storage migration tools. Separating logical access to encrypted file systems from accounts across all virtual layers (including the host system, individual VMs, hypervisor accounts, etc.) adds additional levels of complexity. Privileged accounts or processes running on the host or hypervisor could inadvertently be granted access to cryptographic keys from within a hosted component. Specialized tools and processes may be needed to locate and manage cryptographic keys stored in archived, off-line, or relocated images.

ProtectV/KeySecure Capabilities
ProtectV encrypts entire instances (including OS, swap, and data partitions), securing dormant images from exposure.

ProtectV enforces separation of duties to add an additional level of protection to individual VMs. Pre-boot authentication ensures administrators are properly authorized to start systems. ProtectV enforces separate encryption and VM administration domains. System administrators can not inadvertently be granted access to encryption keys. ProtectV and KeySecure eliminate the need for specialized tools and processes since keys are never stored in archived, offline, or relocated images. All keys are centrally managed in the KeySecure appliance. KeySecure provides a FIPS 140-2 level 3 validated version of the appliance for secure key generation.

Do not virtualize critical resources used in the generation of cryptographic keys (for example, physical FIPS modules). *Information Supplement: PCI DSS Virtualization Guidelines, June 2011

Conclusion
ProtectV and KeySecure address many of the requirements for protecting cardholder data in virtual workloads as detailed in PCI DSS Cloud and Virtualization guidelines. By encrypting entire virtual workloads and enforcing pre-boot authentication, organizations can take advantage of the flexibility and lower cost operational models provided by virtualization and cloud environments, while still maintaining security and compliance of payments data.

Addressing PCI DSS in Cloud and Virtual Environments Whitepaper

Glossary of Key PCI DSS Specific Terms*

Cardholder Data At a minimum, cardholder data consists of the full PAN (primary account number). Cardholder data may also appear in the form of the full PAN, plus any of the following: cardholder name, expiration date and/or service code. The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components. Compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other controls. Compensating controls must: Meet the intent and rigor of the original PCI DSS requirement; Provide a similar level of defense as the original PCI DSS requirement; Be above and beyond other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement. PAN Acronym for primary account number and also referred to as account number. Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account. Acronym for Qualified Security Assessor, company approved by the PCI SSC to conduct PCI DSS on-site assessments. Also referred to as ROC. Report containing details documenting an entitys compliance status with the PCI DSS. Also referred to as ROC. Report containing details documenting an entitys compliance status with the PCI DSS. Process of identifying all system components, people, and processes to be included in a PCI DSS assessment. The first step of a PCI DSS assessment is to accurately determine the scope of the review.

Cardholder Data Environment Compensating Controls

QSA

Report on Compliance Scoping

*PCI DSS v2.0 Glossary of Terms, Abbreviations, and Acronyms, October 2010

Contact Us: For all office locations and contact information, please visit www.safenet-inc.com Follow Us: www.safenet-inc.com/connected
2013 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners. WP (EN)-06.14.13

Addressing PCI DSS in Cloud and Virtual Environments Whitepaper