cancel
Showing results for 
Search instead for 
Did you mean: 

Compliance Standards and AIM

I really wish there was a greater discussion on compliance. Our POS uses AIM, and I can show any person that we do nothing more than hand off credit card number to authorize.net. No storage, no manipulation. Easily testable, easily viewable to anyone trying to security test. How would that code be flagged as non-compliant? Its being executed on the clients own computer, so it is no more subject to scruitiny than the user punching their numbers into a web browser and the browser handling the exchange.

 

This is not a question about weither or not security is an issue - but in rather how compliance specifically impacts our impletementation. Yes there are standards out there, but I have noticed that only a small subset of them are even enforced by state or federal law.

 

Is it just the prospect of being questioned about compliance or having to pay for a compliance test that keeps us worrying about this? Is it only when it becomes a law, that compliance becomes a legally forceable issue? As opposed to it just being an customer expected standard?

 

Just my thoughts - what are yours?

 

___________________________________
<-- Kudos is always welcome....
TSdotNet

TSdotNet
Trusted Contributor
3 REPLIES 3

I am in a low-level quandary over this also - its the ambiguity that has me perplexed, rather than actual fear of non-PCI compliance. There is enough 'fear' out there to drive a developer away from AIM and also CIM - there is also little-to-no law enforcement of the issue just to make things more frustrating. Seems to me we are all running high on paranoia without having a clear reason to be.

 

Im not trying to be flippant or antagonistic - but there is a substantial lack of clear, object and tangible guidelines to comply with. To be fair there are so many variables to content with it is too hard to be concise. And to take things further, in the absence of a clear rule, the process to enforcement then falls down to our own interpretation.

 

For what its worth we have our own servers here, implement AIM and CIM in our software, and have never once had an issue raised by anyone on the subject. 

 

I've had it from both sides -

 

"We never store the card detail or manipulate them - and we have the means to prove it."

 

and them

 

"Just not storing them is enough - you are transmitting the data to another server"

 

But something I realized is - the apparent quandary that we are presented with is no different on the technical level from a user punching their card detail into a web page and the browser on the local computer passing the data off to the payment gateway. I do this at home every day practically, and I know my local machine is not certified as PCI compliant! I also know that through the various plugins you get for browsers today - there could be the question of PCI compliance of the browser also - how do you know your card details are not being manipulated without looking at the code.  

 

I don't know the 'certified' PCI compliance of our servers - but Im still not 100% convinced that I need to be.

 

It seems to me you can also put together a plausible argument for PCI non-compliance even for DPM.  Even with DPM I can still manipulate the card details using JavaScript and Ajax. Its that simple. Unless I have had my code reviewed by an independent PCI compliance agent, how can I claim compliance? Unless I pay the fee to have the code tested, the server tested etc etc how can I claim compliance.

 

Seems to me this is the biggest fear is the compliance $ costs. Awesome. The argument is now no longer technical -  and we are forced to subject ourselves to compaines with their own interpretation and application of the PCI compliance standard. We just have to pay the fee and we are good to go. Man im in the wrong business....

 

___________________________________
<-- Kudos is always welcome....
TSdotNet

TSdotNet
Trusted Contributor

The PCI Compliance standards come from the PCI Security Standards Council (SSC). The SSC was formed by the card brands (Visa, MC, AMEX, Disc, etc.). According to the SSC's website, It's ultimately each card brand that determines whether compliance is mandatory.

 

But what we are experiencing is that our customers/potential customers are coming to us and saying, "is your software PCI Compliant"? In our case, we are subject to the PA-DSS because we "...develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties" (taken from the PA-DSS).

 

We had begun the process of being PA-DSS validated by a SSC-certified QSA. But the requirements are so burdensome that we are looking at changing the way that we do things to get out of scope, such as using the Server Integration Method with the Hosted Payment Form instead of using AIM. That way, we never have to actually touch the Cardholder data, getting us out of scope.

 

silentsky
Contributor

We at Authorize.Net feel your pain. We are also required to comply with the PCI-DSS and PA-DSS as applicable to our business. We sympathize with the concerns you have voiced about complexity, ambiguity and confusion caused by inconsistent interpretation of the standards. We too find compliance with these standards can be costly and sometimes feels like a moving target. That said, we must also acknowledge that these standards, while imperfect and subject to interpretation and regular evolution, also serve a critical need in our industry.

PCI-DSS and PA-DSS serve as a baseline of minimum requirements to increase the security of cardholder data and reduce the likelihood of costly data breaches and brand damage. Even full compliance with these standards is no guarantee of security, but it is a start and one has to start somewhere. We feel that it is ultimately to the benefit of the payment card industry and merchants to self-regulate and take responsible and proactive measures to protect cardholder information and consequently their business and reputation.

While Authorize.Net is not in a position to provide advice on how to comply with PCI-DSS or PA-DSS—we are not a QSA or acquirer—we do take every measure within our scope to enable payments, reduce cost and complexity, and facilitate compliance. We go to significant effort to ‘build it in’ to our services and applications wherever feasible and we have developed relationships with certified partners to help merchants find services that can help them implement compliant solutions.

We have also established a relationship with Trustwave, a Qualified Security Assessor (QSA) for both PCI-DSS and PA-DSS compliance validation and consulting services at reduced cost to Authorize.Net merchants—to learn more see: http://www.authorize.net/trustwave/.

 

If you prefer to find another QSA for these services the PCI Security Standards Council maintains a list of “Qualified Security Assessor Companies” here: https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php and of “Payment Application QSAs” (PA-QSA) here: https://www.pcisecuritystandards.org/approved_companies_providers/payment_application_qsas.php

To learn more about the standards and your obligation to comply, you may also find the following links useful:


PCI SSC resources for merchants
https://www.pcisecuritystandards.org/merchants/index.php

PCI-SSC documents library
https://www.pcisecuritystandards.org/security_standards/documents.php

 

Visa CISP
http://usa.visa.com/merchants/risk_management/cisp_overview.html

Visa CISP Tools and FAQ for Merchants (contains links to additional PCI SSC resources, Visa’s Global Registry of Service Providers - PCI DSS Validated Entities”, “What To Do If Compromised”, etc.)
http://usa.visa.com/merchants/risk_management/cisp_tools_faq.html?it=r|/merchants/risk_management/ci...