bsbgolf
asked on
PCI Email Compliance
I am currently going through a PCI compliance project and found one business process that has turned into a difficult situation to resolve.
We have private dining events with large clients that may reserve several of our locations and other fine dining establishments. The central client responsible for coordinating everything generates single user credit card numbers for each location and (from what I'm told) emails those CC numbers to our corporate location and/or each individual location for payment processing.
Anyone familiar with PCI will know why this is a major issue in itself, but the business is not willing to change their business processes because the client has informed us they do this same process with every other fine dining establishment without issue. This is hard to understand as all of these other establishments fall under the same if not more strict PCI regulations.
Right now we're comtemplating building a completely seperate AD/Exchange environment for just the people involved with that business process that will have all drive volumes encrypted, seperate internet connection, firewall, etc with their only access being via webmail.
Needless to say, our auditors have been less then helpful with other solutions, and I'm definitely not in favor of maintaining a seperate environment for this purpose. Does anyone that has dealt with PCI requirements have any suggestions or experiences with this type of senario? Ideas? Solutions?
Any assistance would be aprecciated.
Thanks,
Bg
We have private dining events with large clients that may reserve several of our locations and other fine dining establishments. The central client responsible for coordinating everything generates single user credit card numbers for each location and (from what I'm told) emails those CC numbers to our corporate location and/or each individual location for payment processing.
Anyone familiar with PCI will know why this is a major issue in itself, but the business is not willing to change their business processes because the client has informed us they do this same process with every other fine dining establishment without issue. This is hard to understand as all of these other establishments fall under the same if not more strict PCI regulations.
Right now we're comtemplating building a completely seperate AD/Exchange environment for just the people involved with that business process that will have all drive volumes encrypted, seperate internet connection, firewall, etc with their only access being via webmail.
Needless to say, our auditors have been less then helpful with other solutions, and I'm definitely not in favor of maintaining a seperate environment for this purpose. Does anyone that has dealt with PCI requirements have any suggestions or experiences with this type of senario? Ideas? Solutions?
Any assistance would be aprecciated.
Thanks,
Bg
ASKER
Wish it was that simple. The transmit portion would be an easy thing to solve. The database storage (Win2003/Exch2003) would also need to be encrypted and it would also bring our entire Exchange enviroment into scope, something we are trying to eliminate, not to mention all the Outlook clients and mobile devices that would also need to have some type of encryption (BYOD causing a major headache on that front). We just completed a project of injecting a firewall and putting the POS at every location onto an "island" along with tokenizing the CC data at the POS level to remove the rest of the network from being in scope..
Assuming you are in the Hospitality Industry - then PCI compliance is a bit of a hit & miss project for the most part. Not only do you face the prospect of CC and PID coming in by email, you may still have Fax operational, MOTO (telephone) orders/reservations with the CRS operators writing the CC/PID on scraps of paper (we've seen that way to many times to count).
The bottom-line is going to come from who is doing your PCI audit more than anything else. What we have seen commonly used to circumvent the very scenario you are talking about it, is the introduction of "server access control limitation" - meaning you reduce the number of people that have access to the Exchange data store to a total of 2 or 3 individuals in your IT department. In turn those individuals may have to be "security bonded" (read as covered by professional indemnity insurance) depending on who your PCI auditor is.
In your SAQ you need to describe in detail the way in which you secure access to the CC/PID within your Exchange data store, including that only 2 (or 3) people have access to that, and that the passwords are changed every X number of days, and that the passwords can not be reused, etc. etc.
Next in your SAQ you need to describe in detail the "exception" as to why CC/PID must be accepted by email, and who in the organisation apart from your 2 (or 3) team members have access to it (meaning who receives the emails).
Finally, you must create a "standard credit card authorisation and disclaimer" document that each "client" that will be sending CC/PID through email must sign (i.e. sign on real paper) and send to your organisation. This may have to shown to the PCI auditor. It basically is a form of indemnification from the Client saying they will not hold your organisation responsible for misuse of their CC/PID.
The bottom-line is going to come from who is doing your PCI audit more than anything else. What we have seen commonly used to circumvent the very scenario you are talking about it, is the introduction of "server access control limitation" - meaning you reduce the number of people that have access to the Exchange data store to a total of 2 or 3 individuals in your IT department. In turn those individuals may have to be "security bonded" (read as covered by professional indemnity insurance) depending on who your PCI auditor is.
In your SAQ you need to describe in detail the way in which you secure access to the CC/PID within your Exchange data store, including that only 2 (or 3) people have access to that, and that the passwords are changed every X number of days, and that the passwords can not be reused, etc. etc.
Next in your SAQ you need to describe in detail the "exception" as to why CC/PID must be accepted by email, and who in the organisation apart from your 2 (or 3) team members have access to it (meaning who receives the emails).
Finally, you must create a "standard credit card authorisation and disclaimer" document that each "client" that will be sending CC/PID through email must sign (i.e. sign on real paper) and send to your organisation. This may have to shown to the PCI auditor. It basically is a form of indemnification from the Client saying they will not hold your organisation responsible for misuse of their CC/PID.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for all the info. You likely already know that our QSA is not offering up any of your suggested options. I really like the last option, although the manta being delivered from our upper management is not to disrupt anything on the customer side, i.e. all of the work is to be done on our side.
I'm also looking at a possible vendor solution called ProofPoint which could grab those emails and encrypt them, although that process sounds like it could be left to the determination of the QSA if a solution meets those requirements or not.
I'm also looking at a possible vendor solution called ProofPoint which could grab those emails and encrypt them, although that process sounds like it could be left to the determination of the QSA if a solution meets those requirements or not.
This is a basic PCI requirements page:
http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard#Requirements