Ubercart

Hmm... I think there is generally lack of awareness and a confusion about PCI compliance. I actually hadn't investigated the shared hosting sites we have affiliate links with for PCI compliance. The lack of mention in the docs is mostly a result of my documenting being behind my coding.

Looking over the docs once more, it reads to me to be referring to protecting your personal internet traffic with a firewall. This would mean your home or your office network. I can't imagine a web host wouldn't be operating behind a firewall, but maybe I'm misunderstanding something.

You might PM Lyle about the GCO module he was working on... it should be usable at this point, we were just waiting for a review from Google which sadly seems to be never-coming.

Actually glad you opened this. It is a topic that needs some feed back. I am Just recently going through the PCI process myself. If I had to do it over again I think I would use a PCI-safe chekout like, PayPal wps, Payflow, or 2Checkout or similar. The standards are almost impossible to make compliance. Only real advantage is for level 4 merchants where proof of compliace will most likely only be required in the event of an issue.

As far as the way your company wants to process the card orders, it may require that the cvv be stored with the PAN, For compliance storage of the cvv is not allowed. I don't know if a manually entered cc on a your clients swipe terminal requires cvv or not.
I know at present UC can store the cvv which is a compliance breaker if used. (however, it is NOT functionality I would want to loose from UC). As without this function automatic recurring billing is not possible unless you use one of the above PCI-safe methods.

I was informed that the firewall requirement applies to any and all internet accessable devices. This inclueds the webserver. As such I am currently waiting for my scan results from mcafeesecure.com against my e-commerce website. Hopefully this will let me know if my host-provider & website passs these requirements.

This is just my view and experience so far, and any information offered should NOT be concidered authoritive.

Matt, the PCI regulations require from a hoster just a contractual confirmation, that he is AWARE of the regulations and KNOWS about the standards. Nothing more, nothing less..
The full responsibility has to be taken by the merchant as he is the only one who has a contract with a member (acquirer) or an IPSP.
The merchant is the one who has to care about compliance to the PCI standards (that includes his technology and his internal structures and operational procedures)
see: https://www.pcisecuritystandards.org/saq/index.shtml

These regulations postulate the use of firewalls to separate "functional" devices from each other. That means a firewall towards the open-network is not enough as you have to keep webserver, appl.server, database etc. apart from each other. It therefore does not make sense to put your client's processes on their "in-store" machine. You are free to use what you want but you better work with DMZ and IP tables or some free firewall apps and tune it well. Otherwise invalid settings will be detected in the vulnerability scan.

What you call "current PCI-safe" payment options is any solution from a PSP (Payment Service Provider) -and I mean only those who are listed as "PCI-compliant Service providers" in the VISA & MasterCard listings- that redirects the cardholder to a PCI compliant data entry form that the PSP provides. Usually those solutions are called Web payment frontends or html redirect forms.
Just check the listings of the associations to find a suitable solution. Just take care that they provide 3D-secure also.

Another Option is the integration of a compliant PA (Payment application). You find Providers of such solutions on the association websites too. Depending on the region the merchant is located in (US, LATAM, EMEA, ASIAPAC etc.) such PA has to pass a PA-DSS certification or not.
(e.g.: for US this is mandatory, but for EMEA and LATAM it is not.)

These two Options are the only way to get around any of the PCI regulations by a merchant.

The standard does not regard DRUPAL or UberCart as a PA but as a storefront.
Storefronts do not require "PA-DSS" nor "service provider DSS" certification. But if you develop a plugin or aplication for the storefront that manages Credit Card Payments, this will be seen as a PA and you might be forced to pass a DSS certification. (see the requirements on https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml)

Most important is awareness. If you do not instruct your client well, he might be in deep trouble. MasterCard does not take prisoners, they execute!!
I know dozens of cases where MasterCard imposed violation fees over 50.000 USD and more to mid-sized merchants who did not even know about PCI but have been compromised through data loss and ID theft. (internal and external)

So PCI really makes it easy:
a) integrate an existing and compliant PA or Service Provider OR
b) create your own PA and have it certified OR
c) make your client FULLY PCI compliant according the specifications OR
d) tell your client not to accept Cards any more

@ Ryan:
regarding your comment: "Looking over the docs once more, it reads to me to be referring to protecting your personal internet traffic with a firewall. This would mean your home or your office network. I can't imagine a web host wouldn't be operating behind a firewall, but maybe I'm misunderstanding something. "

-Yep, you misunderstood it.
The firewall has to protect your private / corporate network on one hand, but your webshop and the payment interface for sure too.
PCI wants a merchant to protect ANY PC of his employees with a (personal) firewall and anti-Virus software AND any of his applications connected to an open network like the internet.

@fourcws:
your are wrong regarding CVV/CVC2. There is NO PERMISSION AT ALL!!!! to store that value. Neither on a POS device nor in any ecommerce application. The same is with full magstripe data and PIN values.
Automated recurrent billing is always possible, if the transaction is flagged correctly. (that is depending on the abilities of your PSP / acxquirer / processor. Good ones can, others can't.. )
You see that in the native terminal protocol languages like ISO8583 and its dialects or APACS. Depending on the naming you find indicators for installemts or recurring billing.

Hope that helped a bit..