This tip is a part of the SearchCloudSecurity.com learning guide, PCI and cloud computing: Cloud computing compliance guide.
For those of us chartered with ensuring
It’s not that vendors aren’t trying to reduce the anxiety that end users have. After all, more and more cloud service vendors have started going through the process of becoming PCI compliant and certified. Most notably, Amazon Web Services announced in December that it achieved Level-1 PCI compliance and is now a validated PCI service provider, but customers still have anxiety when the cardholder data environment (CDE) and the off-premises environments intersect. It’s like asking our friend to look after our pet; sure we trust our friend, but we don’t quite trust them as much as we trust ourselves to do it right.
So how can compliance and security professionals reduce their anxiety? What can we do to get a handle on cloud computing -- and the impact to our compliance efforts with PCI DSS requirements -- to make sure we’re prepared for the migration to the cloud?
Understand what data is moving
First of all, it’s important to understand that not every cloud transition is going to have the same impact on every organization. We need to honestly analyze and evaluate the proposed migration so we can evaluate the extent to which it’s even an issue from a PCI perspective. Moving to a cloud storage model? The impact will be much different if what’s being stored includes cardholder data such as PAN’s. Moving an application to a hosted virtual platform? The impact will be different if it’s an application that processes payment data.
So it’s vital that we understand what will be moving -- and where it’ll be moving to -- in order to understand what the new cardholder data environment (CDE) will be post-transition. We also need to understand how that technology is being used currently and how it will be used post-migration. Specifically, we need to know whether it stores, processes or transmits cardholder data currently, and whether it will continue to do so after it’s transitioned. This helps us put our arms around our new CDE -- and, most importantly, the degree to which it will or won’t intersect the hosted environment.
It’s important for us to figure the scope out as early as possible in the migration cycle, since one strategy we’ll want in our back pocket is to selectively minimize the CDE elements outside our direct control. A good way to accomplish this is by mapping out the data flows (particularly flows of cardholder data) as they currently exist and then updating those flows for the proposed post-migration infrastructure. Recall that for PCI DSS requirements compliance generally, we need to map and document the flow of cardholder data (requirement 1.1.2), so doing this exercise for the proposed post-transition environment will not be wasted effort. As we identify areas that do store/process/transit the cardholder data, that can help shape either our vendor selection, our migration strategy or both.
Reduce/eliminate off-premises cardholder data
It goes without saying that it’s easiest for us to manage compliance when the entirety of the CDE is within an environment that we manage and directly control. Note that this does not mean that vendors won’t have the same (or better) technical, physical or administrative controls, just that it’s easier from a governance standpoint when we directly control the environment. Therefore, as we go through the transition effort, it’s helpful for us to try to architect in a direction that keeps cardholder data out of vendor/partner control. There are a few strategies to do this.
The most direct strategy is to limit the flow of data to the service provider by refraining from transitioning applications and devices that directly store, process or transmit cardholder data. If we identify that a transition plan will impact a device that performs one of these functions, we can attempt to strategically re-architect how data flows prior to the transition. For example, if we identify that cardholder data is relayed via a particular server in the environment, potentially we can change the business process so the server is no long involved; once we engineer this change and scrub the server of any lingering data, we can scope that server out of the CDE.
Another strategy is to utilize encryption as a means of scoping out portions of the transition infrastructure. The PCI Security Standards Council has stated in the past that encrypted data can be “out of scope” of assessment efforts when the entity in possession of it has no ability to decrypt it.So if we do need to store the data or allow it to traverse a vendor environment, encrypting that data can help us to consider it out of scope -- provided we don’t share the encryption key with our cloud service provider and we validate that no data leakage occurs.
Of course, it will not always be possible to limit the scope of what’s deployed. Sometimes, situations will occur that leave us in a position of having our CDE extend beyond the infrastructure and environments we manage. This could be because we identify cardholder data on devices scheduled for migration (and we can’t change it) and other times we’ll discover cardholder data on devices we didn’t know had it. For both sets of circumstances, it’s useful to start as early as possible to ensure we’re prepared. That’s accomplished first by selecting vendors who understand our PCI compliance challenges and that have a reasonable, fact-based PCI “story;” ideally that involves some type of certification. Second, we need to ensure we can (as much as possible) align the controls in the vendor-managed environment with what we require internally for devices in the CDE (with the frank understanding from the get-go that we might not be able to get all the way there).
Realistically, there are quite a few challenges that result from the intersection of PCI DSS requirements compliance and cloud computing, but with forethought and a workman-like approach, it’s really doesn’t have to be all that scary after all.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of consultancy Security Curve.
This was first published in February 2011