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.

Question: Is there a way to store credit card information on a shared hosting server AND be PCI compliant?

Here is the setup:

1) SSL is being implemented for the whole checkout process and for the client's site's admin section.

2) The credit card information is being stored on the server (a shared hosting plan) in a MYSQL database. It is encrypted.

3) The client accesses a password protected admin panel and prints the credit card from her website.

4) The client then manually runs the credit card info through a terminal and deletes this credit card info from the server.

share|improve this question
2  
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

7 Answers 7

up vote 6 down vote accepted

PCI compliance is a bit complicated. Firstly, with shared hosting, you need the provider you're on to meet all their relevant requirements. See Has anyone achieved PCI compliance on AWS?

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.

There's a guide for merchants at https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php

share|improve this answer
2  
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

Unfortunately, as previously stated, the answer is "No"

To achieve full PCI compliance you need to fulfill many, very specific, requirements. Full list can be found here:

https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

Some of these requirements deal with the way you manage your servers, other talk about internal role distribution and so on...

For example section 9.1.1 states:

"Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law." [this obviously talks about serves access]

I`m choose to focus on this section to show that PCI complicancy is not a "purely technical" issue.

Having said that, on a technical site, you probably will want to take notice of section 6.6 that calls for one of the following :

  • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any change.
  • 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)

(disclaimer - I work for the company which provides this solution)

share|improve this answer
    
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 Zeifman Jul 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 Zeifman Jul 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. –  Ramhound Jul 17 '12 at 14:26

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.

share|improve this answer

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?

share|improve this answer

Absolutely Positively Not

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.

share|improve this answer

If you are taking the CC info and then running it through a terminal does that mean you are storing the cvv? You are not allowed to store that for ANY reason under pci.

share|improve this answer

Its not ideal, and to be honest it sounds like you are violating OWASP a9. The checkout process is meaningless, the problem is spilling your authentication token (THE COOKIE) over plain text.

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.