Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

My company has a website/service that stores/processes credit cards and is PCI compliant (Site A). We also have websites with storefronts that need to submit credit card data to that site for processing (Site B). When someone orders something on Site B, and enters their billing information, how do I submit that information to Site A and remain PCI compliant?

Obviously they're on a secure page on Site B, when they are entering their billing details.

Can I just post the form to a secure page on Site A from a secure page on Site B? Do I need to encrypt the credit card during this transaction? Obviously it is stored in some sort of encrypted state, but does it need to be encrypted during the submit transaction?

Do I need to setup some sort of handshake between the websites, like a secret key? If so, what would be a secure way to create that key/handshake?

We've been reading and reading about PCI compliance trying to find concrete answers, but it seems kindof subjective, and obscure what we are supposed to be doing.

This question is also currently posted on StackOverflow.

share|improve this question
    
Perhaps not a repeat of this question -- but my answer here provides valuable PCI Scoping information -- security.stackexchange.com/questions/2922/… –  atdre Apr 14 '11 at 19:53
    
Thank you for your comment atdre –  mikemick Apr 18 '11 at 14:10

2 Answers 2

up vote 6 down vote accepted

The PCI DSS applies to any system which stores, processes or transmits cardholder data. In the scenario you describe above, to the letter of the law, you would need to apply the standard to all systems and networks which make up Site B.

As you are not storing cardholder data in Site B this will at least reduce the amount of work you would need to cover as, for example, as far as I can see, the whole of "Requirement 3 - Protect stored cardholder data" would be N/A.

You will however need to ensure that things like your firewall/DMZ architecture is appropriately put together and managed (Requirement 1), that cardholder data is encrypted in transmission if the connection between Site A and Site B is over an "open, public network" like the Internet.

Picking up your point, and to echo @Rook, SSL will be fine for this purpose (see Requirement 4.1). You do not need to hash or encrypt the card data at this point. It is only when it is at rest.

Moving through the standard, pretty much everything else will apply, Systems should be hardened (Requirement 2), Anti-virus (if it's a system "commonly affected by viruses") and patch management (Requirement 5), good Software Development processes (Requirement 6) - not forgetting the legendary 6.6, code review or WAF.

Strong access controls (Requirements 7 and 8), Physical security (9), Logging and monitoring (10), regular testing (11) and good information security management (12) will all apply as far as I can see.

Without any of these elements if I were the attacker I would simply target Site B and grab the data either straight off the server as it's input by the customer or as it transmits out of Site B into Site A.

This is actually a common scenario in the payment processing world (think PayPal, WorldPay, etc). "Merchants" (someone taking credit card payments) typically have two choices when they wish to integrate with a payment processor to take credit card payments.

1) They receive the card data themselves, typically through a web form and then POST that data to the payment processor's API for authorisation, etc. This is typically done by the larger merchants. They process the response and update their systems and respond to the customer appropriately.

2) They "redirect" the customer to the payment processor who then takes the card data through a form on their own website so the merchant never sees the card data at all. The merchant is typically then updated as the success of the order by some "out of band" HTTP POST to the merchant's website. The customer obviously has an immediate on screen result.

In option 1, the merchant would be required to achieve full PCI DSS compliance. In option 2 the merchant does not have a need to comply as they are not storing, processing or transmitting card data.

If Site B is not currently in scope of your PCI DSS compliance and you wish to keep it that way, I would suggest you develop a means to take the payment data directly on Site A and Site B just points people that way.

I hope this was useful. I've got a lot of experience with the PCI DSS so would be happy to discuss further. Standard disclaimer though, I'm not a QSA so any decisions regarding scope should be verified with a Qualified Security Assessor before beginning work.

share|improve this answer
    
Excellent answer, well done. +1. –  AviD Apr 14 '11 at 20:57
1  
Only (nitpicking) comment: I'm not a QSA - even if you were a QSA it wouldn't matter, as you are not his QSA, and whomever that is gets to make the calls anyway :D –  AviD Apr 14 '11 at 20:58
    
Yeh, spot on and fair point. Thanks for feedback and vote. :-) –  Marc Wickenden Apr 14 '11 at 21:03
    
Thank you for taking the time to break this down for me. Much appreciated. –  mikemick Apr 18 '11 at 14:09

In short the PCI-DSS states that credit card information must never be in plain text. That being said you shouldn't whip up your own protocol for this. HTTPS is a great solution.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.