DPM & PCI Compliance - again!

[jbeales]

So, I've searched the forum and found a bunch of posts stating something along the lines of "With DPM the credit card info never goes to your server so you're off the PCI compliance hook."

However, if I have a site that uses DPM, that has been hacked, wouldn't it be pretty simple for an attacker to add a Javascript to the payment form that my site renders and either log keystrokes or capture the form data on the onsubmit event?  It seems to me that DPM and AIM should have identical PCI compliance requirements. Do they? If so, why not?

I'm asking because I'm a developer with a customer who is currently using AIM and looking to simplify being PCI compliant.

Thanks,

John

[stevelogan]

DPM uses https:// to post the payment information directly to Authorize.net.  The unencrypted data never actually hits your server in that it goes directly from a visitor's web browser to Authorize.net.

[swartzer]

I think the point is that if an attacker gets source code access to your website, they could change the page so that it submits to evilserver.net instead of authorize.net.  If they were more subtle, they could insert javascript code to send the data to evilserver.net via AJAX, while still submitting the transaction itself to authorize.net.

This seems like a weakness in the PCI standard itself.  As long as you aren't actually storing card data or transmitting it through your network, compliance isn't required.  Granted, I'm no lawyer, but the financial people at my organization have the same interpretation and have given their OK to DPM on that basis.

I still think PCI compliance is a good idea, but no standard can ensure absolute security, because absolute security  doesn't exist. All we developers can do is try our best.

[RaynorC1emen7]

http://developer.authorize.net/api/compare/

Data stored on Authorize.Net PCI-compliant servers (reduces risk to merchant).

I think you will still need some PCI compliance.

From https://www.pcisecuritystandards.org/security_standards/documents.php?category=supporting&document=p...

Build and Maintain a Secure Network
1.  Install and maintain a firewall configuration to protect cardholder data
2.  Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3.  Protect stored cardholder data
4.  Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program
5.  Use and regularly update anti-virus software or programs
6.  Develop and maintain secure systems and applications

Implement Strong Access Control Measures
7.  Restrict access to cardholder data by business need to know
8.  Assign a unique ID to each person with computer access
9.  Restrict physical access to cardholder data

Regularly Monitor and Test Networks
10.  Track and monitor all access to network resources and cardholder data
11.  Regularly test security systems and processes

Maintain an Information Security Policy
12.  Maintain a policy that addresses information security for all personne

PCI and You

[jbeales]

Swartzer's understood it exactly. A really smart attacker will even drop some Javascript on the transaction results page so he'll have a list of *known good* card numbers & associated data, as well as at least some idea of a transaction size that would go through easily.

I'm not sure what the actual PCI requirement is, (and I'd love to know - is there anyone I could ask?), but it seems that it should require compliance even when using DPM, which makes me question the point of DPM.

[RaynorC1emen7]

PCI is still required for DPM, it just less that what you need for AIM, for example.

[jbeales]

That's what I figured. Do you know if I use Trustwave, (Auth.net's preferred provider), if they'll do a different scan depending on whether I use DPM or AIM?

[jeffshaikh]

I just got off the phone with a QSA and we had this same discussion in regards to my application that uses DPM.

The response from the QSA was that if the form is generated by the application server, even though it is submitted to directly to Authorize.net, it is still in scope of PCI-DSS. There are ways for a hacked site to add javascript, change the post action and so forth.

The only way he would remove the application, server, website and network from the PCI scope was to use Authorize.net's SIM (or any other payment service) where the payment page completely leaves the applicaiton and is COMPLETELY generated by and submited to the PCI compliant payment gateway.

We dove deeper and I asked about Iframes for the payment form and the response was that they would need to do a code review and pen test to determine the security of that option.

I see a reponse "PCI is still required for DPM, it just less that what you need for AIM, for example." (not picking on you RaynorC1emen7, I thought the same thing before this mornings conversation with the QSA). I also see Authorize.net has on their website (http://developer.authorize.net/api/compare/) "Data stored on Authorize.Net PCI-compliant servers (reduces risk to merchant)".

From my conversation with the QSA, if it's in scope it's in scope (all or nothing) there is no levels of scope or less scope.

From my understanding Authorize.net's statement "reduces risk to merchant" is correct. It does, it is less likely and risky to run DPM,  BUT it does not reduce or remove the application from PCI compliance scope. It will still need SAQ, internal pen test, internal vuln scan, external vuln scan (quarterly) and external pen tests (annual).

Please, correct me if I am wrong.

[hobbes]

They have to draw the line somehwere, but from a true security standpoint, it's a bit silly, because if someone hacks the server, they can just as easily redirect DPM or SIM.  Yes, the merchant will know as the payment page won't be at AN, but most users will be clueless if the payment is on an SSL-protected site that looks legitimate.  You do however get some additional benefits from using SIM over DPM over AIM.

[nonno34]

I disagree with the whole PCI thing..  Of course there are people who have been complete idiots handling sensative data - that has resulted in identity theft... more than credit card theft.  and companies that are included in this are chase, home depot, and huge medical networks etc..   Mean while they are calling upon huge requirements and expense for small mom and pop retailers who cant afford this stuff.. who process less than 3k cards per year..   to do what others do  in a day..  the risk doesnt warrant the expense... at all..

I run a small store . and its hard enough to do what i do.. mind the map pricing and discounting the consumers expect.. they will spend 200 per mo to watch tv service - which is all ads..  yet they wont spend 200$ for the tv..

Basically, I should say why do the banks care?? they never pay fraud charges.. tthey always pass it on to the merchant.. the bank is never left screwed.. so why are they making the merchant bleed more..forexample.  if I take a bunch of bad cards for orders.. and ship them all new printers and tvs and stuff.. the bank will just reverse the charge and i am left holding the empty bag..   and they want to fine me for not complying?  basically it is the merchants responsibilty to verify the identity of the person buying the goods or service.. and if it someone other than they say they are.. I didnt do my job - and i am paying not the bank.. the banks never eat the money on these fraud charges.. it seems like they do to the victim.. but they dont - the merchant eats it..

As for the dpm  - or other payment methods . there is no such method known as cim.. CIM is just a method of saving a profile and can be done in the aim - method and also in the sim(third party method)   the dpm is a hybrid of sim and aim.  But not really - its only appears to be..   It is much more close to sim than aim - just the consumer is hidden from the redirect. it still happens - its just not seen.. doesnt this pose a risk? no. because not all third party processors are known to the consumer -they dont know if they are or arenot anyone... and most people have no way of knowing if they are redirected are where they are supposed to be.. they really want to be where they are buying from .. not a stranger site..   and even if someone.is familiar with paypal- there can be a spoof site to look like this .. though it would be hard to retreive the correct account data - and relay it to the consumer.. with out some nifty scripting..

but to the QSA inspector - who thinks dpm is inthe scope .. then why is offered at all and not just aim?/ there would be zero point in doing it... there is no such thing as just lessor scope.. there are scopes defined by category.. Abcd etc. and its not tht its in the scope - its what scope.. and dpm is not same d just lessor d.. there is no such thing.. your in d or not. - dpm is in sac a just as paypal is ...- this garbage about who generates the form is crap.. its about where the data goes.. and not on server. means not in scope.. not transmitted on server not on scope.. server doesnt see it - not in scope...  As for someone hacking the site and forging the form>  yes possible - but not more possible then someone forging the checkout page and dummie payment method... no difference what so ever.. so if third party payment is out of scope then dpm is out or scope..  however both are in risk.. always there is a risk.. scope and risk are not the same.. you cant prevent every possible risk . can they bring the server in scope for all payments - yes.......... but currently they dont.. do i think they should ? yes - but based on risk for example i fyou do 20 orders per day.. how much risk is that before you note that yu have been hacked>??? not much at all.. if you process 1000 transactions per hour.. and you have been hacked ,how much risk is that?   that is when you decide if it needs to be in scope or not.. period.. there is no sense to  make a little mom pop spend the time and money chase must....  total differences..   in the mean time - dpm is not in scope - according to the guide - which is transmits or stores data.. in this casse the answer is no.. if you try to ask if the payment is off site.. that is harder to answer.. but it definately is offsite.. but it loooks on site. that is all. so its offsite 3rd party processing......just done seamlessly