PCI Compliance in a Virtualized World

PCI Compliance in a Virtualized World Security Technology Infrastructure Security Integration 24x7 Support MSS Training Information Assurance Staff Augmentation

Presenters John Clark QSA, PMP, CISA, CISSP Security Consultant, FishNet Security Over 13 years in technology and security Trusted security expert in legal, financial, utilities, and banking Expert in customer centric solutions & remediation strategies Eric Fisher QSA, MCSE, MCP, CEH Security Consultant, FishNet Security More than 20 years in virtualized security planning and design Held membership in PCI Council special interest group Current member of Cloud Security Alliance National speaker on PCI Compliance in virtual environments

Agenda Basic definitions History & Trending PCI Compliance in virtualized environments Impact on Compliance Scoping Guidance Security Control Considerations SSC Recommendations FishNet Security s Take Dealing with The Cloud Key points [Top Advice / Recommended Best Practices] In Summary Links Questions

Definitions Virtualization is the usage of a logical simulation to create independent versions of something, such as an operating system, server hardware, storage, memory, networking, data or other resources from those resources. Host is the actual component on which virtualization occurs Guest is the virtualized entity Hardware Virtualization Full / Partial / Paravirtualization (Hypervisors, vpar, npar, LPAR) Software Virtualization Application / Workspace (XenApp / App-V / ThinApp / Wine) Operating System level (Containers / VEs / VPSs / Jails / Zones) Desktop / Session (VDI / Remote Desktop Services / Citrix / Virtual Linux Desktop / Virtual Terminal )

History Has been around since mainframes decades ago. May not be obvious but most everyone uses the core technology in some way. Advancement, formalization and marketing Virtualization The Cloud

PCI Compliance in Virtualized Environments

Some Statistics Gartner Reports In 2010 it was estimated that 18 million virtual servers will be deployed in 2011 The penetration of server virtualization in midsize companies with between 100 and 1,000 employees will exceed the Global 500 It is not uncommon for organizations to halt their virtualization deployments Cost overruns and process issues Found that these issues were avoidable, with good upfront planning. Gartner report G00201551: Six Misconceptions about Server Virtualization

PCI DSS Virtualization Guidelines What happened SSC Published guidelines in June 6 sections Introduction Virtualization Overview Risks for Virtualized Environments Recommendations Conclusion Virtualization Considerations for PCI DSS No new requirements for the DSS Provided clarity in how to address virtualized components in an assessment

PCI Compliance Any virtual environment can be compliant Virtual Machines of different security levels (Mixed- Mode) can be hosted on the same hypervisor or physical host, but do you want to do that? Security Considerations Complexity Cost Consideration

Impact on Compliance Four principles to keep in mind 1. PCI DSS requirements apply to the virtualization technologies and components used in the storage, processing or transmittal of cardholder data. 2. Virtualization technology introduces new risks that may not be relevant to other technologies, and those risks must be assessed. 3. Implementations of virtual technologies can vary greatly. 4. There is no one-size-fits-all method or solution to configure virtualized environments to meet PCI DSS requirements.

Scope Guidance Virtual devices should be treated no differently than their physical counterparts Segmentation Physical Security Defense in Depth Least Privilege Access Hardening Standards Single Primary Purpose PCI scope must include all devices required to facilitate the virtual environment

Scope Guidance PCI DSS Virtualization Guidelines Section 2.2 includes Scope Guidance for key areas of virtualization If any virtual component connected to (or hosted on) the hypervisor is in scope for PCI DSS, the hypervisor itself will always be in scope (2.2.1) An entire VM will be in scope if it stores, processes or transmits cardholder data, or if it connects to or provides an entry point into the CDE. If a VM is in scope, both the underlying host system and the hypervisor would also be considered in scope, as they are directly connected to and have a fundamental impact on the functionality and security of the VM (2.2.2)

Scope Guidance Virtual Appliances used to connect or provide services to inscope system components or networks would be considered in-scope. Any Virtual Security Appliance that could impact the security of the CDE would also be considered in scope (2.2.3) Networks provisioned on a hypervisor-based virtual switch will be in scope if provisioned with an in-scope component or if they provide services or connect to an in-scope component. Physical devices hosting virtual switches or routers would be considered in scope if any of the hosted components connects to an in-scope network (2.2.4)

Scope Guidance Virtual applications and desktops will be in scope if they are involved in the processing, storage, or transmission of cardholder data, or provide access to the CDE. If a virtual application or desktop is provisioned on the same physical host or hypervisor as an in-scope component, the virtual application/desktop will also be in scope unless adequate segmentation is in place that isolates all in-scope components from the out-of-scope components (2.2.5)

Security Control Considerations

SSC Recommendations Recommendations are very similar to what is already required by the PCI-DSS Risk Assessment Physical Access Least privilege Hardening

SSC Recommendations There are some new considerations If any components running on a single hypervisor are in scope, it is recommended that all components on that hypervisor be considered in-scope Isolate security functions from the virtual devices (including the host) they are protecting Example: Do not run a virtual firewall on the same logical host as the card data it is configured to protect.

Segmentation is Possible 4.2 In order for in-scope and out-of-scope VMs to coexist on the same host or hypervisor, the VMs must be isolated from each other such that they can effectively be regarded as separate hardware on different network segments with no connectivity to each other. Proper segmentation for in-scope and out-of-scope systems on the same host must be equivalent to a level of isolation achievable in the physical world Beware of out of band communication resulting from shared resources (processors, volatile and non-volatile memory, device drivers, etc)

Segmentation is Possible 4.2.1 If it is not feasible for a particular implementation to enforce isolation of in-scope components from out-of-scope components via shared resources or other out-of-band channels, all components accessing the shared resource or out-ofband channel should be considered in scope, as they are effectively connected to the in-scope component. Proper Segmentation is Difficult

Control Considerations Requirement 1: Install and maintain a firewall configuration to protect cardholder data Inbound and outbound traffic to/from the CDE could include VM-to-VM interactions that never traverse the physical network. Boundaries between trusted and untrusted networks may be dynamic and difficult to define Recommendation Do not locate untrusted systems or networks on the same host or hypervisor as systems included in the CDE.

Security Control Considerations Requirement 3: Protect stored cardholder data CHD, sensitive data and cryptographic keys could exist in archived, off-line or dormant VM images and snapshots Privileged accounts or processes running on the host or hypervisor could inadvertently be granted access to cryptographic keys from within a hosted component Recommendation Do not house virtual components that perform keymanagement functions or store keys on the same hypervisor or host as components that store or access data protected by those keys.

Control Considerations Requirement 6: Develop and maintain secure systems and applications Development/test systems and data could be inadvertently moved to production environments, or vice versa, via virtual replication, imaging, or snapshot mechanisms. Testing of changes to virtualized components may need to consider multiple levels of potential impact. Recommendation Do not locate development/test systems or networks on the same host or hypervisor as production systems or networks.

FishNet Security s Take

Scoping The Cloud Defining The Cloud? The Cloud refers to complete services delivered over the Internet typically using self-service end user portals with no visibility to the underlying technologies that enable these services and can incorporate hardware, software and services into a single revenue stream. A cloud can be private, public or a combination. A public cloud sells services to anyone on the Internet. A private cloud is a proprietary network or a data center that supplies hosted services to users behind a firewall.

Scoping The Cloud What type of cloud Cloud services are broadly divided into three categories: Infrastructure-as-a-Service (IaaS) Platform-as-a-Service (PaaS) Software-as-a-Service (SaaS).

Scoping The Cloud

Scoping The Cloud Cloud Considerations Compliance is not focused on SLAs, but control, ownership and acceptance of such. The cloud ultimately means a partial loss of control Cloud providers are still service providers Loss of control to a service provider means requirements in 12.8 must be fulfilled Tracking Due diligence Contractual ownership of cardholder data in possession PCI Compliance tracking at least annually

Key actions Carefully plan the security for a virtualization solution before installing, configuring and deploying it Deliver network security and segmentation Address platform hardening Harden and secure both the host and the virtualization application itself Ensure that only required capabilities are installed or active. Assure that all elements of a virtualization solution; Are secured to a principle of least privilege Provide a separation of duties where applicable Restrict, protect, account and log administrative access Maintain their security

Key actions Extend configuration and change management principles to the virtual components Monitor logs from the virtual infrastructure alongside those of physical assets Implement VM-specific security mechanisms, where available, to monitor and detect information opaque to traditional network security controls Track all instances from cradle to grave and assure proper destruction Validate any VM image or template before implementation Monitor for unplanned or unauthorized virtualization usage across enterprise Perform due diligence on service providers engaged in cloud services.

In Summary

Make Compliance Easier All PCI-DSS requirements apply to a virtualized environment. Do not mix non Card Data Environments with Card Data Environments on the same host Document all connections and data flows into the virtual environment and within the virtual environment If 1 virtual component is deemed in scope, consider all physical and virtual devices on the same host as in scope for a PCI-DSS assessment and treat them in the same manner as the physical counterpart

Links PCI SSC Virtualization Supplement Document https://www.pcisecuritystandards.org/documents/virtualization_infosupp_v2.pdf National Institute of Standards and Technology http://www.nist.gov/itl/csd/virtual-020111.cfm VMware Compliance Center http://www.vmware.com/technical-resources/security/compliance/index.html Microsoft Virtualized Server Security http://whitepapers.hackerjournals.com/wp-content/uploads/2010/04/virtualization- Security.pdf The Cloud Security Alliance Consensus Assessments Initiative https://cloudsecurityalliance.org/research/initiatives/consensus-assessmentsinitiative/ Center for Internet Security Virtual Machine Security Guidelines http://benchmarks.cisecurity.org/tools2/vm/cis_vm_benchmark_v1.0.pdf

Questions