Question of outsourcing payment processing

[art]

My company has been looking at offloading CC storage and processing and there seems to be 2 options out there. One is a "hosted gateway", which some companies will offer to integrate into our checkout process via an iFrame.

Alternative is purely an external gateway with an API, where our side will post the CC data to the 3rd party.

What I am not clear about is where these solutions are identical from the PCI compliance perspective. Does it make a difference whether we post to a 3rd party API or include the page via iFrame? From a technical perspective, the potential risk is similar. If someone was to compromise the web server, they could either redirect the post somewhere else or redirect the iFrame.

Any advice on this would be appreciated.

Thanks.

[jbhall56]

The iFrame approach totally bypasses your systems and infrastructure altogether, so your organization would be totally off the hook and out of scope as long as you do not get cardholder data (CHD) on the back side due to disputes and chargebacks.

If your applicaiton posts up the data to the third party, then your application is technically transmitting CHD and therefore is in-scope and so would it's infrastructure.

[djnavetta]

The iFrame approach totally bypasses your systems and infrastructure altogether, so your organization would be totally off the hook and out of scope as long as you do not get cardholder data (CHD) on the back side due to disputes and chargebacks.

If your applicaiton posts up the data to the third party, then your application is technically transmitting CHD and therefore is in-scope and so would it's infrastructure.

Not totally off the hook, I believe 12.8 would still apply.

[jbhall56]

Okay. You're right, 12.8 would still apply. But that's far short of the whole thing.

[art]

If you're doing an integrated gateway....and the form does a post to a 3rd party site, wouldn't you technically be out of the "processing" loop?

The interaction goes something like this:

user --> get --> form from my site
user --> post --> data to 3rd party.

So you could technically say that it's the user that is interacting with the 3rd party and transmitting the data. Wouldn't that be considered a valid explanation?

[alphonze]

And if your site gets hacked and the form is changed so that the CHD is sent to a *different* third-party...?

Jeff's quite right. Even if you're using a third-party payment gateway, you need to be suitably compliant. WorldPay, for example, seems to insist on a passing ASV scan for new payment gateway clients now.

[jbhall56]

And if your site gets hacked and the form is changed so that the CHD is sent to a *different* third-party...?

Jeff's quite right. Even if you're using a third-party payment gateway, you need to be suitably compliant. WorldPay, for example, seems to insist on a passing ASV scan for new payment gateway clients now.

Good points and a good catch. You should have your Web site scanned by an ASV to ensure that you are not propagating some flaw that would allow your site to then reference some other site's payment process.

A flaw could also be used as a staging ground to possibly compromise your processor.

Either way, you need to make sure that your Web site is not the source of such attacks.

[jbhall56]

If you're doing an integrated gateway....and the form does a post to a 3rd party site, wouldn't you technically be out of the "processing" loop?

The interaction goes something like this:

user --> get --> form from my site
user --> post --> data to 3rd party.

So you could technically say that it's the user that is interacting with the 3rd party and transmitting the data. Wouldn't that be considered a valid explanation?

The problem with your example is that since it is your form, the data will get cached on your system until it gets flushed. Depending on how you developed your application and what languages are used, that cache could stay around for quite a while.

I cannot tell you how many times we have run pen tests against Web sites and found tons of cached credentials and cardholder data in various temporary directories on servers. I think it's a larger problem than developers want to admit. And it's usually an easy hack to get at the data.

[art]

I agree with the point about the site being hacked and the form redirected. But isn't that essentially the same vulnerability as using an iFrame? The site can also get hacked and that iFrame could come from anywhere....or be setup with some sort of a MiTM or many other methods?

[lyalc]

If you're doing an integrated gateway....and the form does a post to a 3rd party site, wouldn't you technically be out of the "processing" loop?

The interaction goes something like this:

user --> get --> form from my site
user --> post --> data to 3rd party.

So you could technically say that it's the user that is interacting with the 3rd party and transmitting the data. Wouldn't that be considered a valid explanation?

This model is arguably not as secure without the source (merchant) application being reviewed.
However, I don't believe bringing the complete merchant applicaiton into scope is the intent of PCI DSS validation.

Many smaller sites use pre-packaged/COTS products that use databases for most/all web content. Putting the mercantsite in scope means they all must use SAQD, not the intent of the PCI SSC when, with conset of card brands the SAQ A-C were released.

In my view, this is another case of
"compliance != security"

Comments?
lyalc

[art]

[QUOTE=lyalc;3155]
In my view, this is another case of
"compliance != security"
/QUOTE]

I agree with you completely. I think the differentiation between compliance and security is obvious. However, my questions are purely from a compliance/liability perspectives. I am trying to evaluate different options from 3rd party vendors to see if I can reduce my compliance scope, not to improve my security.

From the the two approaches that I've been proposed.....the integrated gateway (form > post) is more convenient from a business perspective. From a technical perspective, I see the security risk as pretty much identical. What I don't know is how this looks from a PCI perspective.....:)