One of our readers recently emailed me with a major dilemma. They need to keep their website PCI compliant in order to keep using their payment gateway to process credit card transactions. Their PCI scanner is telling them they have vulnerabilities, while their hosting provider tells them they are fine. Meanwhile our reader is caught in the middle, paying fines.
I don’t dare to use my business e-mail address, because it would disclose my business name. I have been battling with my website host and security vendor concerning the Non-PCI Compliance of my website. It is actually my host’s IP address that is being scanned and for several months it has had ONE Critical and at least SIX High Risk scan results. This has caused my Payment Gateway provider to start penalizing me $XXXX per month for Non-PCI compliance. I wonder how long they will even keep me. When I contact my host, they say their system is in compliance. My security vendor is saying they are not. They are each saying I have to resolve the problem, although I am in the middle. Is there not a review board that can resolve this issue? I can’t do anything with my host’s system, and don’t know enough gibberish to even interpret the scan results. I have just been sending them to my host for the last several months.
There is no way that this could be the first or last time this has happened, or will happen, to someone in this situation. This sort of thing is bound to come up in compliance situations where the customer doesn’t own the underlying infrastructure, whether it’s a traditional hosted offering, and ASP, or the cloud. How do you recommend the reader – or anyone else stuck in this situation – should proceed? How would you manage being stuck between two rocks and a hard place?
Reader interactions
12 Replies to “Help a Reader: PCI Edition”
@Maritz:
If your client is completely passing off the entire credit card transaction to a third party such that no sensitive cardholder data is touching their environment, I believe they can make the case that the e-commerce site is out of scope for PCI, including scanning. It may be different in the UK from the US. To qualify as segregated in this way, the customer has to enter their cardholder data into page hosted at the third party site. Your client will be on the hook to document that the third party provider is PCI compliant.
If your client can prove that they’re running a apache and PHP at patch levels that are not vulnerable to the threats posed by the reported apache version, the ASV should document this as a false positive. If by “the bank,” you mean your client’s acquirer, then your client’s quarrel isn’t with the ASV but with the acquirer. They’re on the hook if your client is noncompliant, they’re the people with the final say on whether to accept your client’s practices as compliant.
Your client should also be pushing back on their vendor to support compliant versions of Apache, and shopping for alternate vendors if the current vendor won’t do it.
We have issues here in the UK with ASVs and banks being particularly unreasonable when it comes to PCI compliance.
A Tier-3 client of mine uses a very popular open-source e-commerce platform which is PCI compliant. An ASV scan of the client’s e-commerce site detected that the PHP and Apache versions are out of date (based on the banners returned to the scanning software by the server), and therefore their site is not PCI compliant.
In this case there are some mitigating factors though, which the bank or the ASV are choosing to ignore, resulting in a fine of