We have an eCommerce website hosted by LunarPages. Our site collects credit card numbers and transmits them to SkipJack (credit card processing agent) for processing. We do not store the numbers nor do we transmit any more of the stripe data than the acct no, expiration date and CCV number. We have hired a service to analyze our site for PCI compliance. The report comes back with a few violations, all of which have to do with the LunarPages server configuration.
Question is, who is liable for the non-compliance? Are we (the vendor) or is LunarPages (the ISP)? We are a Level 4 merchant by PCI definition. Actually, the question probably comes down to the defintion of who is transmitting the data. We collect the data through our website, but I believe LunarPages would be defined as the transmitter of that data. Hence, they carry the burden of being PCI compliant and responsible for any non-compliance.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
>> I would think...
Not good enough. I need facts and references.
We have done all we can to insure credit card info security, ie SSL connection. The rest is out of our hands within the confines of our hosting agreement. However, that may not be enough to protect us from liability. This is what I'm trying to confirm.
Thanks for your response, though.
I don't have any hard facts (apart from the PCI standard itself) or references so take this with a grain of salt, but judging by your description you are both liable. I'm assuming that neither you nor the hosting company are PCI certified? This is from PCI DSS v1.1:
"PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. These security requirements apply to all system components. System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include but are not limited to the following: web, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications."
The key point here is that when negotiating a deal with your hosting provider, you need to make them aware of the PCI DSS requirements and require compliance from them. Even this, however, will not remove nor limit your liability as the vendor. The appendix A in the DSS, "PCI DSS Applicability for Hosting Providers" specifies the _additional_ requirements that apply to them as a hosting provider.
If I'm wrong, someone please correct me, since I'm currently working on a PCI DSS certification project. ;)
Only you would be liable. An Internet service provider or carrier is just that - they host stuff for you but they aren't responsible for what you host, etc. Almost think of it as an attitude of 'you rent an apt from your landlord' but if you decide to grow weed or have a tiger as a pet, the landlord is never held responsible.
I've seen a lawsuit with a similar law before which the ISP won. I'll try to find a link
Your service provider needs to be informed of your exact requirements and it's up to them if they can suffice those or not.
billwharton:
Do we need be concerned about PCI Compliance if we collect data over an SSL using 128-bit encryption and our ISP transmits that data to our credit card processing agent also over SSL using 128-bit encryption and we, nor our ISP, actually records, saves or stores any of that credit card information? I would think only the credit card processing agent would possibly need to be PCI Compliant - and I'm not sure if even they would be, as long as they are not storing that data and only transmit it to the bank, also across SSL.
You're putting it a little differently now and I'll answer this question as its own
1) The good thing you're doing here is not storing credit card data
2) If you're using SSL 128-bit, you're good for the moment. You are the transmitter though, not the service provider. The service provider simply provides you hosting resources, nothing else. They're not required to be compliant to anything except what they state in their IP SLA agreements with you
What sections did you fail on the audit?
Are we talking about the same PCI DSS here? :) The Payment Card Industry Data Security Standard is widely known as the most expensive security standard on the planet to implement, and it specifies around 270 detailed requirements, ranging from configuration management, regular penetration testing and auditing, 24/7 incident response teams and over 250 similar ones. Just using 128-bit SSL is not actually anything close to resembling compliance.
As stated in the PCI DSS, "if a Primary Account Number (PAN) is stored, processed, or [b]transmitted[/]".
Also regarding hosting providers, from Appendix A:
"As referenced in Requirement 12.8, all service providers with access to cardholder data (including hosting providers) must adhere to the PCI DSS."
I think those statements are quite clear.
>> The good thing you're doing here is not storing credit card data
Right. And the transmission of the data is the only part of the standard to which we are exposed. This is what I'm trying to clarify.
Our ISP (LunarPages) had one major failure (level 7): Their mySql database server is listening on port 3306. It is possible to extract the version number of the remote installation by receiving the server greeting.
Again, we are not storing the CC data, so a vulnerability in their DB server should not concern us.
They also had 4 mid-level (level 4) failures:
1. The following ports were open at the beginning of the scan but are now closed: ....
Not sure what this means. It goes on to state that the open ports were closed prior to completion of the scan. Don't know if this is still a vulnerability or not.
2 & 3. The remote Apache server can be used to guess the presence of a given user
name on the remote host.
Identical failures on two ports: 80 - http and 443 - https.
4. The remote service encrypts traffic using a protocol with known weaknesses (port 993: imaps).
I'll contact LunarPages on this one. They claim all upgrades and patches have been applied to their servers. Obviously, they missed this one.
I don't believe any of these vulnerabilities really affect us as long as we only transmit the data and do not store it. Agree?
If CoccoBill is correct (I assume he is), the burden of proof lies with the ISP. As you can see, all these vulnerabilities listed above lie with the ISP server. We have no control over their server configuration - we can only inform them of the vulnerabilities and leave it up to them to take corrective action. Our only recourse is to leave them and find a compliant ISP. I hate to do that because I am very satisfied (in every other way but this) with LunarPages.
To clarify, whomever the owner of the credit card buys things from (ie the merchant), is responsible for PCI DSS compliance. If they don't store/process/transmit and hand off to a service provider, then the merchant is STILL responsible for PCI DSS compliance, however it's quite simple to address by ensuring you have contracts in place between merchant and service provider indicating whom has liability for PCI DSS compliance.
Business Accounts
Answer for Membership
by: QBRadPosted on 2007-09-04 at 06:36:08ID: 19825000
I would think that both of you would be liable.
If I am a customer of yours and give you my info and you put it in your system, I am going to assume that you are doing what you need to for the sake of security. I'm also going to assume that you have some type of security spelled out on your site stating that your Credit Card info and any other info is secure on your site.
Then, you the company can go after lunarpages for their lack of security ecspecially if it is again spelled out on their site or in their documentation.
My point is that if i get my info stolen such as identity or credit card info, i dont care if your hosting company wasnt secure i'm going after you since you took my info knowing that the data wasn't secure. Then i may go after lunar pages as well.
Just contact lunar pages and see what you can do to fix the issues.