magnafix,
May I ask a couple of questions? Are you using and running Zen Cart? If you aren't, why are you here?
magnafix,
May I ask a couple of questions? Are you using and running Zen Cart? If you aren't, why are you here?
Please do not PM for support issues: a private solution doesn't benefit the community.
Be careful with unsolicited advice via email or PM - Make sure the person you are talking to is a reliable source.
Which goes directly against your assertion that MySQL and Web must be on seperate servers if you store card details.you need to work hard to restrict your 'cardholder data environment' to as few machines as possible
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
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.)
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)
.
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.
We take a hard stand on this that is not shared by all.Originally Posted by magnafix
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
Zen-Venom Get Bitten
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:
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.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
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".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
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.
Last edited by Kim; 19 May 2009 at 04:19 PM.
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.
Please do not PM for support issues: a private solution doesn't benefit the community.
Be careful with unsolicited advice via email or PM - Make sure the person you are talking to is a reliable source.
Bookmarks