Don't believe anyone who tells you you cant host a PCI compliant enterprise architecture on AWS.
If your QSA, or Technical team are telling you that "The Cloud" cant be made PCI DSS 2.0 compliant, its time to hire new staff.
It's no walk in the park either, but with a competent team who can look at each of the 12 requirements sensibly, and intelligently you can build a fully compliant (and often more secure) platform with no upfront costs.
There are some issues you need to think carefully about.
AWS takes the management of "hardware" firewalls and wraps these up into "security groups". Thats great news on the management front, as you no longer have to worry about hardware maintenance contracts, downtime for updates, and failover, but it also means there are challenges when you NEED to see the firewall logs.
AWS will make logs available for criminal / PFI investigation, but your not going to be able to get these as a matter of course. As a result, many people have failed to overcome this problem,and given up on cloud PCI compliance at this stage. But take a few moment to think about what you need firewall logs for.
What does a firewall log "ACTUALLY" tell you?
Lets say in your DC you have a pair of ASA's in failover mode, and you run a basic e-commerce site.
You serve some html from apache, and push this through a reverse proxy into your DMZ.
You have inbound rules for email, WWW, ssh, vpn
You allow outbound mail, DNS, ssh, http/https
What are your firewall rules going to tell you? - They are going to tell you exactly what you expect them to... that you allow a few things in, a few things out, and that loads of stuff is dropped as it hits your ASA's either because someone has tried to ssh to the wrong host by accident, or that they are trying to brute force your ssh root account (by the way, thats a fail straight away!)
So what. What can you do with information about all the Drops your FW is handling - your already dropping them, you cant do much else.
What about the Permits?... well as long as these are what you expect, its just boring log files..right?
What WOULD be useful, is to know if anything is getting through your ASA's that shouldn't be, or If its blocking something that it shouldn't be.
Its all about "layered defences"
So grab yourself another two ASA's and configure them with exactly the same rule set as the first, but chain them together. Now think about what happens if you ever see a Deny message from your second ASA's. This means that something nasty got through the first set of firewalls, but it got caught by the second. Thats a really powerful set of logs - and something you defiantly want to know about.
You now have 4 firewalls in your estate, the first two protect the second two, and prevent any of the nasty stuff ever hitting your second layer. And the second firewall sees all of the traffic that is permitted.
Now you have a blueprint for your cloud offering
The security group forms your first line of defense. You configure your inbound and outbound rules, in the SG, and let it keep out all the bad guys. But you need to prove that the Bad guys ARE being stopped.
So you install your own firewall which is in your control. At the most basic level this is iptables, or the windows firewall. You log what this firewall produces because now you have proof what is getting in, and more importantly you have proof that nothing gets through the security group that shouldnt be - and IF it ever did, you would have the logs (And AWS would let you have theirs if you can prove that your Security Group failed)
What you need now is a PCI compliant method of managing updating, recording, and auditing your iptables or windows firewall. If you want more info on this, contact me.
