topic SAQs for Authorize.net APIs in Integration and Testing

SAQs for Authorize.net APIs

ynermk — Mon, 30 Sep 2013 21:05:47 GMT

I know that some of the Authorize.net APIs allow for reduced PCI compliance scope, however is there any guidance anywhere indicating to what level? The PCI DSS E-commerce Guidelines released by the PCI SSC would seem to indicate that the only merchants that are allowed to use an SAQ A would be ones that employ a “wholly-outsourced E-commerce Implementation” (page 17).

Link to PCI DSS E-commerce Guidelines:

https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_eCommerce_Guidelines.pdf

Since the various APIs offered by Authorize.net require some level of integration with the merchant, whether it is serving up the payment page/client side code or redirecting the customer to a hosted payment page, does that mean a SAQ D is required (wholly or sections). Would any of the APIs allow us to fill out a SAQ C?

Re: SAQs for Authorize.net APIs

TJPride — Tue, 01 Oct 2013 00:35:30 GMT

Hmm, good question. DPM is definitely SAQ-C. AIM, ARB, and non-hosted CIM are -probably- SAQ-C, unless you store credit card data on your end, in which case SAQ-D. SIM and hosted CIM are probably SAQ-A. But an official word from Authorize.net would be nice. Compliance requirements also vary by volume of transactions, btw.

Re: SAQs for Authorize.net APIs

ynermk — Tue, 01 Oct 2013 18:04:51 GMT

Based on the guidance provided I don't see how SIM and CIM could be SAQ A. On page 17 of the e-commerce guidelines it clearly states that in a wholly outsourced e-commerce implementation "the merchant may be able to complete a SAQ A.”

A wholly outsourced implementation "consists of e-commerce application, hosted servers, and hosted infrastructure, which are all provided and managed by the third party". The note on that page is particularly clear: "Note that if the merchant has to install an application or code on a server, configure a server file, etc. for their e-commerce implementation, they should refer to Section 3.4.3, “Shared-management E-commerce Implementations,” above.”

Based on that statement I don’t see how any Authorize.net API or from any other vendor for that matter can qualify for an SAQ A. I’d love to be wrong on this, but after reading and rereading this document several times I just don’t see any other way to interpret this.

Without a doubt the API solutions provided by Authorize.net and others greatly reduces the scope of PCI, but I don’t think to the level that many people assume.

Can you get away with a SAQ C? I can’t say I’ve seen any definitive documentation to prove or disprove that assertion. If someone has something more substantive than a blog post I’d love to see it.

Also, transaction volume determines if you can fill out a SAQ or if you have to have a ROC completed by a QSA. It has nothing to do with the type of SAQ you are required to fill out. If you are dealing with less than 6 million transactions in a year then you can fill out a SAQ, otherwise it is a ROC.

Re: SAQs for Authorize.net APIs

TJPride — Wed, 02 Oct 2013 08:10:20 GMT

SIM forwards to Authorize.net. None of the e-commerce part has anything to do with you. Similarly, hosted CIM loads a page from Authorize.net, and uses cross-domain Javascript to trigger the callback. You have zero interaction with the credit card part. I'm still betting SAQ-A for those. And SAQ-D is for instances where you store, rather than just transmit, credit card data.

You can pay with a credit card through Paypal, and you can submit your shopping cart to Paypal externally, yet somehow nobody is required to fill out a SAQ for that. A shopping cart does not equate to an ecommerce solution.

Re: SAQs for Authorize.net APIs

ynermk — Wed, 02 Oct 2013 17:34:22 GMT

Agreed with both solutions the merchant has zero visibility of the cardholder data. However, the merchant plays a role in ensuring that data is securely transmitted to Authorize.net. For example:

a merchant is utilizing SIM ,
their systems are compromised
the code used to perform the redirect to Authorize.net is modified
instead the customer and/or their data is sent to a nefarious site

In my mind that equates to a breach caused by some weakness in the merchant’s e-commerce infrastructure.

Based on how I’m reading the e-commerce guidelines, if you manage code or systems involved in the transmission of credit card data it is under scope for PCI, and you cannot get by with a SAQ A. I agree with the statement above that a shopping cart does not equate to an e-commerce solution, but I think it is clear that is a component of that solution and therefore whoever is managing it is responsible for addressing PCI requirements.

Re: SAQs for Authorize.net APIs

TJPride — Thu, 03 Oct 2013 01:45:14 GMT

Any site can be compromised to redirect to a hacker's site. In the Paypal example I gave, it would be quite simple to change the post location to a simulation of Paypal instead of to the real Paypal. Not sure what would qualify as SAQ-A if you are correct - would you have to offload your entire catalog to a third-party service? If you do that, why bother with SAQ at all? What is the purpose of SAQ-A?

Need someone who's an expert on SAQ to post on this, I guess.

Re: SAQs for Authorize.net APIs

ynermk — Thu, 03 Oct 2013 17:56:03 GMT

Not sure what would qualify as SAQ-A if you are correct - would you have to offload your entire catalog to a third-party service?

Yes, that is exactly what the e-commerce guideline is saying. From page 17 of the PCI DSS e-commerce guidlines:

“Many merchants are interested in managing their PCI DSS responsibility by outsourcing all cardholder data storage, processing, and transmission to a third party hosting provider or e-commerce payment processor. In this case, merchants may elect to use a solution provided and hosted by a third party, which is wholly under the control and responsibility of the third party. This type of solution could consist of an e-commerce application, hosted servers, and hosted infrastructure, which are all provided and managed by the third party. A web interface is provided for the merchant to access the third-party site, and to manage the e-commerce store and customers.”

“PCI DSS Scoping Guidance: In this scenario, the merchant may be eligible for the PCI DSS Self-Assessment Questionnaire (SAQ) A. SAQ A reduces the number of applicable PCI DSS requirements for merchants that outsource all storing, processing, and transmitting of cardholder data to an e-commerce payment processor. More information about SAQ A can be found below under “Outsourced e-commerce Implementations and SAQ A.”

If you do that, why bother with SAQ at all? What is the purpose of SAQ-A?

Actually if you look at the requirements the merchant is being asked to attest to in a SAQ A (for reference at the bottom of this post), it totally lines up with a “wholly outsourced implementation”. Basically the merchant is validating 3 areas:

1. They are eligible to complete a SAQ A because wholly outsource the handling, storage,

processing, and/or transmission of cardholder data.

2. There are physical controls to protect credit card data that is on paper media received by

the merchant from the vendor.

3. The merchant has the appropriate contractual and policy pieces in place to spell out the

vendor’s responsibility in protecting cardholder data and ensure the vendor’s adherence to

PCI DSS.

Nothing in SAQ A references technical controls on the merchant’s part. It does not make sense that if you are using one of the APIs that you would not have to attest to some technical or process controls, because at a minimum it is your responsibility to ensure that the code that specifies where the cardholder data is posted is protected from unauthorized changes.

So we get back to my original question which SAQ or subsections of an SAQ make sense for a particular API?

SAQ A Validation Questions :

Requirement 9: Restrict physical access to cardholder data

	Question Response:	Yes	No	Special*
9.6	Are all paper and electronic media that contain cardholder data physically secure?
9.7	(a) Is strict control maintained over the internal or external distribution of any kind of media that contains cardholder data?
(b) Do controls include the following:
	9.7.1	Is the media classified so it can be identified as confidential?
	9.7.2	Is the media sent by secured courier or other delivery method that can be accurately tracked?
9.8	Are processes and procedures in place to ensure management approval is obtained prior to moving any and all media containing cardholder data from a secured area (especially when media is distributed to individuals)?
9.9	Is strict control maintained over the storage and accessibility of media that contains cardholder data?
9.10	Is media containing cardholder data destroyed when it is no longer needed for business or legal reasons? Destruction should be as follows:
	9.10.1	Are hardcopy materials cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed?

Requirement 12: Maintain a policy that addresses information security for employees and contractors

	Question Response:	Yes	No	Special*
12.8	If cardholder data is shared with service providers, are policies and procedures maintained and implemented to manage service providers, and do the policies and procedures include the following?
	12.8.1	A list of service providers is maintained.
	12.8.2	A written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
	12.8.3	There is an established process for engaging service providers, including proper due diligence prior to engagement.
	12.8.4	A program is maintained to monitor service providers’ PCI DSS compliance status.

Re: SAQs for Authorize.net APIs

TJPride — Thu, 03 Oct 2013 23:58:32 GMT

Well, which API are you going to use? Assuming you are correct, in which case all of the API's fall under SAQ-C, unless you are storing credit card data locally for later use. SAQ-C covers all pass-through solutions.

Re: SAQs for Authorize.net APIs

ynermk — Tue, 08 Oct 2013 07:42:29 GMT

I think it will be SIM where possible and DPM in cases where product owners are concerned about the user experience. I am hoping that PCI 3.0 provides a bit more clarity regarding API solutions and possibly some more relevant SAQs.