PCI compliance on shared server?

magnafix,

May I ask a couple of questions? Are you using and running Zen Cart? If you aren't, why are you here?

you need to work hard to restrict your 'cardholder data environment' to as few machines as possible

Which goes directly against your assertion that MySQL and Web must be on seperate servers if you store card details.

Here in the UK at least you can store encrypted card data on a server which contains both Web and SQL, provided that the data is encrypted, the server firewalled, and the server and site pass PCI scanning.

That said, most sites do not store card data and use off-site 3rd Party payment processors. In the case of 3rd party payment processors like Pay Pal the website does not collect or pass any card data to them (Pay Pal Pro excepted).

Vger

Vger:

Which goes directly against your assertion that MySQL and Web must be on separate servers if you store card details.

There's no contradiction. I'm not inventing this stuff, just reading the requirements, really. :)

You should try and restrict the number of machines in your CDE (cardholder data environment) because otherwise it's just a lot more work to get compliant. Draw a firm boundary around the CDE (with firewalls, auditing, documented policies etc) to reduce the scope of work.

That doesn't absolve you of the requirement #2.2.1, "implement only one primary function per server":

*For a sample of system components, verify that only one primary function is implemented per server. For example, web servers, database servers, and DNS should be implemented on separate servers. *

That applies for all servers that store, process, or transmit cardholder data.

(by the way I am here because we have a customers using Zen Cart and I have been actively researching how hosting companies are handling PCI compliance questions from their customers for a year or so.)

magnafix:

But that doesn't stop the processors/merchant account providers from tacking on a non-compliance fee of whatever they please.

And now there is a large and growing scanning/compliance/consulting industry to which PCI DSS gives a tremendous boost. Vested interests.

Exactly, and I've been saying something like that since the PCI discussion started here.

None of this, when applied to businesses like most Zencarters operate, has anything to do with security. It all has to do with the payment processors' (and their kickback-giving 'trusted partners') profit margins.

Eventually, I'd guess the FTC will want to know why, if PCI is all about cardholders' safety, the processors allow merchants to opt out by paying a fee (to the processors, of course)
.

stevesh:

Eventually, I'd guess the FTC will want to know why, if PCI is all about cardholders' safety, the processors allow merchants to opt out by paying a fee (to the processors, of course)
.

Heh that's an interesting and not entirely untrue way to put it.

Of course the card industry would object to the phrase "opt out" -- PCI compliance is required for everyone who touches cards (digitally or physically).

My understanding is that PCI DSS came about as Congress started rumbling about 'there oughta be a law!', and the card industry said "no, no need, we will regulate it ourselves!"

But Minnesota now has a law substantially based on PCI DSS, and other states are sure to follow.

magnafix:

That applies for all servers that store, process, or transmit cardholder data.
We take a hard stand on this that is not shared by all.
PCI/DSS is written for the storage, processing, and transmission of cardholder data.
If you actually read the requirements, most apply only if your are actually "Storing" the data.
There is only one that covers the transmission of Card holder data and that is it be under SSL.

Fully our interpretation as we do NOT read this as:
storage and/or processing and/or transmission of cardholder data.
but read these as discrete events, each with their own set of rules:
If you store or If you process or If you transmit cardholder data.

So if you only transmit, then you are only bound by that section.

Look at it logically: Why does one require an elaborate system to restrict and track who has access to card holder data when there is no storage of this data to restrict?

This aside from operating a secure server environment

kobra:

We take a hard stand on this that is not shared by all.
PCI/DSS is written for the storage, processing, and transmission of cardholder data.
If you actually read the requirements, most apply only if your are actually "Storing" the data.
There is only one that covers the transmission of Card holder data and that is it be under SSL.

Fully our interpretation as we do NOT read this as:
storage and/or processing and/or transmission of cardholder data.
but read these as discrete events, each with their own set of rules:
If you store or If you process or If you transmit cardholder data.

So if you only transmit, then you are only bound by that section.

Look at it logically: Why does one require an elaborate system to restrict and track who has access to card holder data when there is no storage of this data to restrict?

This aside from operating a secure server environment

I don't think this is right. The entire PCI DSS applies to your CDE (cardholder data environment), which is defined as all those machines that store, process, or transmit.

Here is the quote from the PCI DSS glossary:

Cardholder data environment: Area of computer system network that possesses cardholder data or sensitive authentication data and those systems and segments that directly attach or support cardholder processing, storage, or transmission. 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 and thus the scope of the PCI assessment

So at my hosting company, we are first focused on how we store, process, and transmit cardholder data and working towards compliance. Once we nail that we'll turn to attention to how we can possibly provide pci compliant hosting to customers.

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 and thus the scope of the PCI assessment

This can be made to mean almost anything. But let's look at the word "systems". Does this mean a single web page backed by another page that initiates the data transmission? That's not my definition of "systems".

You are over-thinking this and, in my opinion, making some wrong conclusions about PCI compliancy.

We have customers on shared servers who are required by their Banks to pass PCI scans carried out by companies nominated by those Banks.

We have customers on dedicated servers who are required by their Banks to pass PCI scans carried out by companies nominated by those Banks.

Using your interpretation of PCI none of them would ever pass - but they do.

And provided that they pass the scan imposed by their Bank, and that the customers' card passes 3D Secure checks, the liability for chargebacks passes from the online retailer to the Bank.

Vger

I wish you were right.

Clearly different compliance assessors are using wildly different standards, despite access to one authoritative (though in many places vague) document. (This makes "compliance" mostly meaningless of course.)

Some of my interpretations are from the guys at forum.paymentsecuritypros.com/

If your QSA says an occasional remote scan is all it takes to claim "We are 100% PCI DSS Compliant", that's good luck.

Why don't you continue this discussion on that other forum?

You have hijacked a thread and gone completely off topic for the thread and none of this has to do with Zen Cart as a program.

I am not a Zen Cart user. Just someone that has been pulling his hair out all day trying to understand all this PCI Compliance nonsense.. At this moment I had come to the conclusion that magnafix did after reading the PCI Council's site, then investigating further and finding support for the conclusion I reached here:

http://tylerhannan.com/2009/07/hosted-payment-page-and-pci-compliance/

I would like to know where Kobra read that if you are only transmitting cardholder data (like most of us are) that you need only be using SSL and other PCI DSS Compliance criteria do not apply?

Further, I found this on Glowhost information page:

Why do I need a Dedicated Server?
PCI still remains a gray area. Recent "standards" state that all merchants must comply, regardless of how many dollars they process per month. It is important to know that that PCI standards say that a dedicated server is required to accept payment via credit card due to the nature of access controls and the inability to effectively manage users in a shared hosting environment. PCI states that a machine that holds, transmits, or stores sensitive data must be owned by a single entity, and that entity must only grant access to sensitive cardholder data on a "need to know" basis.

We feel that the above requirements are impossible on a shared hosting platform, and this is why we only offer PCI Compliance on a dedicated machine. If you see a host offering PCI compliance on a shared machine we strongly suggest reviewing the current PCI standards.

It seems to me that it doesn't really matter how much opinion, conjecture and interpretation is bandied about here ... the key test is whether the PCI compliance specialists appointed by the banks are willing to approve as compliant merchants operating on shared servers for the transmission only of card data.

Vger has confirmed that in the UK they are. Merlin has confirmed the same for the US.

dax702:

Further, I found this on Glowhost information page:

Why do I need a Dedicated Server?
PCI still remains a gray area. Recent "standards" state that all merchants must comply, regardless of how many dollars they process per month. It is important to know that that PCI standards say that a dedicated server is required to accept payment via credit card due to the nature of access controls and the inability to effectively manage users in a shared hosting environment. PCI states that a machine that holds, transmits, or stores sensitive data must be owned by a single entity, and that entity must only grant access to sensitive cardholder data on a "need to know" basis.

We feel that the above requirements are impossible on a shared hosting platform, and this is why we only offer PCI Compliance on a dedicated machine. If you see a host offering PCI compliance on a shared machine we strongly suggest reviewing the current PCI standards.

This is the work of a good sales person,
I can in fact tell you that PCI Compliance can be attained on a shared hosting environment ( IF the host is willing to do the work ) any host that says that you MUST have a dedicated server only wants deep in your pockets

Merlinpa1969:

This is the work of a good sales person,
I can in fact tell you that PCI Compliance can be attained on a shared hosting environment ( IF the host is willing to do the work ) any host that says that you MUST have a dedicated server only wants deep in your pockets

I suppose if the definition of PCI Compliance is whatever a QSA tolerates, then yes, anything's possible. I have heard of QSAs only requiring a remote scan; I have also heard that some QSAs provide the self-assessment questionnaire already filled out for you, with YES to everything of course, because that is the only way to pass.

well,
scanalert trustwave security metrics

we have passed them all,

it is VERY POSSIBLE to pass PCI Compliance on a shared server.

remember that you said

Some of my interpretations

Unless you have spent the time withthe folks at these companies and verified that everything is good to go please STOP saying its not possible....

Merlinpa1969:

you dont need a dedicated ssl for PCI Compliance, and anyone that tells you so is full of crap.....

we have alot of folks ( on shared servers ) that are PCI Compliant,

how do I know this,

cause Im the ############## that gets to deal with

Macfee
Comodo
Security Metrics
etc.....

its a little more intense to setup a shared server to be pci compliant... the thing is that the servers themselves need to be compliant before you worry about an account

Merlin,

I am on a dedicated server and I have been dealing with Security Metrics.. WOW, what a group of rude techs they have over there. I am still struggling with a few issues. Finally got rid of all of the SSL Ciphers, but they are talking about vulnerabilities in files that are not on my server. Do you have any suggestions on a good guideline to becoming PCI Compliant?

Thanks,

send me a copy of the report lets see what happens