In general, the way to check for PCI compliance is to use a PCI QSA to check, so normally this sort of question would be a bit offtopic, however in this instance I think there are some good core points in the answers which are valid in any case.
–
Rory Alsop♦Aug 21 '11 at 8:45

1

@Rory, dont forget that the lower levels do not necessarily require a QSA to be involved (self questionaire). Besides, the question might be during planning, with the intent to bring the QSA on when its ready... Still, a valid point that if there is anything questionable, the QSA should be involved early on, so you're not surprised at the end.
–
AviD♦Sep 5 '11 at 13:27

Second, whoever has a terminal that is processing cards is responsible being complaint. It sounds like in this circumstance, you're not the processor and don't have an agreement with a credit card company. In that sense, you don't need to be compliant (HUGE caveat following)

However, the person with the terminal does need to be compliant, and everything they use in the process of handling cards (including you as a 3rd party) needs to achieve compliance. Compliance requires active review -- the depth of which depending on the volume of transactions handled.

Most critically, I wonder what circumstance you're in that you would be storing credit card numbers and not actually processing them.

PCI compliance has to do with volume of transactions processed. Smaller volume shops don't have to worry about a lot. Large volume companies are only PCI compliant if they meet all the standards specified and they are signed off on by a PCI council approved auditor. VISA, for example, specifies those as anyone handling 6 million transactions a year.

Smaller volume shops still need to be compliant, they just have an easier audit and approval process.
–
AviD♦Sep 5 '11 at 13:31

True... I did mean that they still have a bar when I said "don't have to worry about a lot." They do have to self-review and sign off on it, but they don't have to hire an auditor.
–
Jeff Ferland♦Sep 5 '11 at 13:33

Storing card details is only approved for certain setups, far more advanced than this.

Doing this as described would not only be not PCI complaint it would be illegal in many countries under various privacy and commerce laws (many of which defer to the PCI SSC for policy and regulation.)

Furthermore it's almost certainly a server breach of the MSA to process payments through a terminal which were obtained in this way. Such a breach may be governed by a remedy of fine or legal action.

It'd complicated, but in short, this setup would not be compliant. For a start, based on the limited information provided, you are storing the card data in an internet facing zone, rather than an internal system. There are numerous other things wrong with this setup (management interfaces, key management for encryption etc), but the data storage is a glaring one.

There are also additional requirements for shared hosting providers that would need to be validated. Under PCI, shared hosting is not really appropriatefor anything other than a merchant page that then redirects to a compliant payment gateway. Why is your client not doing this?

All good answers. PCI says if you are storing credit card data in any form you need at the very least an ASV to scan your system for vulnerabilities. If you get to a level 1 or 2 (based on your transaction level) you will need a QSA to do it. The bottom line is if you are storing credit card data in any fashion you are a risk to everyone. You can do it but the costs to validate your systems could be prohibitive, depending on the volume you are doing.

Installing a web-application-firewall in front of public-facing web applications.

This is probably the most demanding section in the whole bill as it requires you to either have a WAF in place or to perform routine checks after (and this is important) EVERY CHANGE made to your web applications.

In other words - pure nightmare...

This section is what drives many SMB website owners away from PCI DDS, and into an arms of a 3rd party billing providers, as the setup and maintenance costs are simply just too high. (WAF will cost thousands of dollars,even before maintenance costs, and routine checks after every change are not an option, and even if it is - it comes with an even greater accumulative cost)

Recently a affordable solution to this issue was made available via Cloud-based PCI compliant WAF.

The idea here is that of "shared-usage" and "economy of scale". In this scenario, WAF protection is distributed via Cloud to a community of users (websites) and each member community gets full WAF features and updates but needs to pays only a fraction of the full price.

This cuts heavily on initial setup/purchase costs and also eliminates all additional maintenance costs (as a centered security team operates and updates the WAF for all Cloud users.)

Also this provides full standardization and promises a very high upkeep quality (very important in an ever-changing security landscape but not achievable without a dedicated security person/team)

Hi, it wasn't spam - at least not an intentional one. Currently the above described solution is available via only one specific provider and so I figured I can mention him (it) by name... I do see your point. So, following your comment I`ve re-edited the post and removed all brand mentions.
–
Igal ZeifmanJul 17 '12 at 11:28

Thanks Igal - it just read a lot like an advert. This is definitely better - I have added a brief disclaimer just to let the reader know.
–
Rory Alsop♦Jul 17 '12 at 11:46

Thanks again, this all thing actually prompted me to go and have a look at infosecfrog so I feel it was a "score 1" for me :)
–
Igal ZeifmanJul 17 '12 at 12:23

Well, I gave you an upvote for the revised version as well :-)
–
Rory Alsop♦Jul 17 '12 at 12:37

@IgalZeifman - I find it hard to believe there is a single solution available and you just happen to work for them.
–
RamhoundJul 17 '12 at 14:26