Strategy & Best Practices

PCI in the Public Cloud

By Erik Ginorio / May 08, 2013

Pci  Blog  Header

It seems like we’ve been talking about the cloud forever; ten years ago, I recall being at a convention listening to someone tell me how I was never going to install software on my computer again. The cloud would not only change our idea of the desktop, but change how we work altogether.

Well, here we are in 2013, and those prophecies are starting to come true. I’ve been hard pressed to find any software that I used to install from a CD-ROM that isn’t alive and living in the cloud somewhere, and that I can access from anywhere via any browser. No licensing keys, online registrations, or any of that nonsense. I click on the application I want to use and it appears in a matter of seconds—it’s how I had imagined it all those years ago.

For consumers and companies, the cloud this is an awesome advancement; it can reduce costs, improve productivity, and give IT resources a break. For the business side, it’s a win too, but for security professionals like me, the cloud also proves to be quite an interesting challenge, especially when it comes to protecting customer data, specifically, PCI compliance.

So now we reach the crux of the problem: How do you become PCI compliant while using a public cloud environment? Even more relevant, how do you do it without investing $50,000, $100,000, or even $200,000 on software, applications, management tools, consultants, and everything else to get you past your audit?

Budget restraints mean that you need to make smart, strategic decisions about securing your environment. For the sake of this article, I’m going to stick to the technical side of the issue and address one possible solution to getting your cardholder data environment (CDE) locked down to meet PCI requirements.

First and foremost, ensure your cloud provider is already PCI Level 1 compliant; otherwise you will never get your certification. For example, if you’re running on Amazon’s public cloud, which is PCI Level 1, you simply sign an NDA with them to get a copy of their attestation of compliance to give to your PCI auditor. That’s one hurdle down.

Next, to greatly simplify the scope of the audit and make your life a lot easier, your production CDE network needs to be 100 percent segregated from any other environment or networks you may have. In our case, we have our corporate/desktop network, and then our development, pre-production, load, and production environments. Engineers need access to development, load, and pre-production from our corporate/desktop network, but none of them should need access to your production CDE network. If you’re using a proper SDLC, all the testing and verification should be taking place before your code is pushed to your production environment (hence why developers shouldn’t need access).

It’s also common for the development, load and pre-production networks to crossover and be accessible from the corporate network for developers. That’s okay, but your production CDE network should be 100 percent segregated with zero crossover and zero data mingling.


To achieve this, you can use totally different Amazon accounts to ensure these environments are completely separate. This way, the developers in the office can access the environment they need to do their work, but no one can touch the production network, which is your PCI CDE.

So the next question is, how do you access your production network? You can set up two additional systems, the first being a VPN system sitting in its own account and own security zone. This VPN box can only do one thing: accept two-factored authentications from approved users and then allow traffic to specifically one whitelisted bastion host in the production environment. The bastion host, on the other side, only allows connections from the VPN system, and then only via SSH/SCP and by authorized users. From the bastion host, you can then reach the rest of your production environment.


The end-user system must of course be running anti-virus software, disk encryption, a personal firewall, and have the correct two-factor VPN client installed. This satisfies PCI because the system connecting to the VPN is now an end point, protected from any outside connections.

The VPN system uses two-factor authentication and restricts access by the allowed user list on the VPN system, both of which are PCI requirements. This small list of users should be easy to control and audit without the need for a complex IAM systems or the like.

Lastly, the bastion host allows you to control and audit who accesses the environment via other open source tools, like auditd and normal syslog mechanisms, as well as outside tools like tripwire. You’ll also need to have a logging infrastructure set up to log all of this data, but that’s something we’ll tackle in a later post when I discuss using Splunk.

If you find yourself questioning if PCI compliance can be accomplished, it can, and many companies are doing it. Even more importantly, it doesn’t have to cost you a small fortune, require lots of commercial third-party tools, or require expensive consultants or contractors. Achieving PCI in the public cloud isn’t a mystical black art; it is a lot of work, but for security professionals, that’s just part of the job.

Erik Ginorio is AppDirect’s Information Security Officer.