CBAlexander
asked on
PCI DSS: Charging via Web Portal
I am attempting to prepare a solution for a level 3 merchant that needs to have the ability to capture payment card data remotely at workshops. They are working on a web portal that will have a transaction service perform all of their payment processing. Basically, I am thinking about setting up their firewall to use RSA SecurID tokens to provide a second authentication layer to create a secure VPN tunnel into their network, which will allow them to access their internal payment processing portal. I just need to know if this will meet PCI DSS.
Thanks,
Chad
Thanks,
Chad
ASKER
Thanks for the info.
To clarify, the company tends to do a lot of business at trade shows, and they want to capture that data and charge on the spot while they've got the customer there. The site they're entering the data into stores the PAN in an encrypted database, and none of the users has rights to read the full PAN (last 4 digts are displayed to provide additioanl means to confirm identity when the doctors call in to customer service). The payment processing is done through an API on the site that polls the database and charges the customer for products. The company deals with doctors and usually processes several hundred transactions per doctor per month, so as a matter of convenience they store the PAN and customer info to automate the purchase process as much as possible.
The HQ network stores all of the servers behind a firewall, and most of the internal network appears to be compliant, although I haven't had the chance to run a full-on audit yet. The first question I have to answer for them concerns the ability to enter and process payments remotely. My thought was to provide a laptop that they can take with them to trade shows, and also set up the RSA system with their firewall to provide 2 layer authentication (RSA to secure the VPN tunnel, and standard network login once the system has connected to the HQ network via VPN). The payment processing system aslo has another authentication step that is seperate from the network login. So at this point, my questions concern if this VPN tunnel approach would meet PCI compliance and if there are any concerns with authorizing charges to a remote system while traveling out of state.
To clarify, the company tends to do a lot of business at trade shows, and they want to capture that data and charge on the spot while they've got the customer there. The site they're entering the data into stores the PAN in an encrypted database, and none of the users has rights to read the full PAN (last 4 digts are displayed to provide additioanl means to confirm identity when the doctors call in to customer service). The payment processing is done through an API on the site that polls the database and charges the customer for products. The company deals with doctors and usually processes several hundred transactions per doctor per month, so as a matter of convenience they store the PAN and customer info to automate the purchase process as much as possible.
The HQ network stores all of the servers behind a firewall, and most of the internal network appears to be compliant, although I haven't had the chance to run a full-on audit yet. The first question I have to answer for them concerns the ability to enter and process payments remotely. My thought was to provide a laptop that they can take with them to trade shows, and also set up the RSA system with their firewall to provide 2 layer authentication (RSA to secure the VPN tunnel, and standard network login once the system has connected to the HQ network via VPN). The payment processing system aslo has another authentication step that is seperate from the network login. So at this point, my questions concern if this VPN tunnel approach would meet PCI compliance and if there are any concerns with authorizing charges to a remote system while traveling out of state.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
To correct, there are no card swipes conducted at all in this environment. The card number and card holder information are entered into an intranet web portal, which houses an API provided by a third-party payment processor. At the moment, payment information is written down by hand on worksheets at the workshop and transferred back to their HQ in their luggage. This is not an acceptable solution.
Getting these workshop sales guys on a VPN connection to the HQ facility would essentially extend the HQ environment to where they are with their laptop. From there, they would be required to log in to the Windows system, which will check their credentials against what is current in AD. Once they have been authenticated, they would then have to log in to the intranet web portal (which is currently synching with AD to get ID and password info) in order to enter and process any payments. Hopefully this arrangement makes sense.
As long as this VPN/Windows session/Intranet session authentication method satisfies PCI DSS for remote processing of payment card data, then I think that should answer my question, I just wanted to make sure there weren't any hidden interpretations or auditor experience that would say otherwise.
Getting these workshop sales guys on a VPN connection to the HQ facility would essentially extend the HQ environment to where they are with their laptop. From there, they would be required to log in to the Windows system, which will check their credentials against what is current in AD. Once they have been authenticated, they would then have to log in to the intranet web portal (which is currently synching with AD to get ID and password info) in order to enter and process any payments. Hopefully this arrangement makes sense.
As long as this VPN/Windows session/Intranet session authentication method satisfies PCI DSS for remote processing of payment card data, then I think that should answer my question, I just wanted to make sure there weren't any hidden interpretations or auditor experience that would say otherwise.
PCI DSS Documents. It sounds like you might be working on a wireless solution. Besides reading PCI DSS v2.0, check out the Wireless Guideliness and Overview of the PCI DSS Wireless Guideline.
There are a number of things that should be done though. You provided a few things, but left out some things. For example, how are they obtaining this data at the remoate stations? If they are keying in the entry, do you store the Primary Account Number (PAN)? If so, do you do this because the customer might want a refund? What numbers of the PAN do you show - the max you can show is the first 6 and the last 4 - all other numbers should be masked. And you should not store the Card Verification Value - Card Verification Code - Card Identification Number.
Go through each of those requirements on PCI DSS 2 to make sure everything is covered. Take a look at the documents in PCI DSS New Self-Assessment Questionnaire (SAQ) to see if everything on that list can be covered as well (the merchant should complete this as well).