Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am using EC2 instances to power our web service that needs to be PCI SAQ-C compliant. I am trying to figure out what point 1.3 of the self assessment really means:

1.3 Does the firewall configuration prohibit direct public access between the Internet and any system component in the cardholder data environment, as follows:

1.3.3 Are direct connections prohibited for inbound or outbound traffic between the Internet and the cardholder data environment?

1.3.5 Is outbound traffic from the cardholder data environment to the Internet explicitly authorized?

1.3.6 Is stateful inspection, also known as dynamic packet filtering, implemented (that is, only established connections are allowed into the network)?

Since I am on EC2 a DMZ is not really an option because all instances have a public IP. I have been searching for several days on the web trying to figure out what this means and what I need to do to comply, but I cannot find anything. This is probably in large part because I have a programming background not security, or system administration. So I am guessing I am looking in the wrong place. But, I am not sure what the right place is. So, if you can recommend a resource that would explain this in more depth, or software that will fulfill this requirement, I would appreciate it.

share|improve this question
    
Amazon should be taking care of this for you. See aws.amazon.com/security/pci-dss-level-1-compliance-faqs –  bobince Dec 11 '12 at 9:55

2 Answers 2

Section 1.3 is intended to prevent repositories of sensitive information (in PCI DSS world - cardholder datastores and processing engines) from being able to either offer an internet-facing service, or push data directly out of their store to the internet. The concept behind the first part is to minimise the attack surface available to an unfriendly outsider, and the second part is to provide some defence in depth, so that if a breach occurs, there is a barrier to an attacker simply piping data out to their location.

As with a lot of PCI DSS, if you can avoid storing data post-authorisation you will save yourself heartache (and costs). It might be worth considering whether you can get the results you want using a payment service provider like worldpay instead of rolling your own payment system.

A lot of "reference sites" to PCI DSS are simply vendors looking to push their products as the solution to PCI DSS (tip: they are not, usually), however the PCI Council is worth reading through, as is Amazon's AWS Reference (since you are using EC2)

share|improve this answer
    
We use Authorize.net to handle processing and storage. But, because the credit card information is set to our servers, then we send it to Authorize.net, I believe we fall under PCI SAQ-C –  Josh Moore Dec 11 '12 at 3:26

Since I am on EC2 a DMZ is not really an option because all instances have a public IP

A DMZ is defined by firewall rules, not by the presence of NAT. Establish appropriate firewall rules for your security group that only allow your credit card handling servers to talk to the front-end servers and you'll have the effect you're looking for.

Of further note, "DMZ" is a term that usually refers to a system that has exposure to the Internet and limited access to the private network. Your credit card handling systems would be considered an internal network, not a DMZ.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.