Differences In SAQ C vs D

[gzink]

Greetings,

A general question: do the same requirments apply to all merchants, just the reporting structure is different?

We are a mid size company, we accept payments from customer service reps (who use their workstation to access an external cc application), web-site and IVR.

I think SAQ C is approrpaiate for us, but I'm trying to get my head around the right level, and things like network segmentation, isolation, encryption. I spoke to a colleague who said they had to get seperate routers, switches, etc. to meet compliance, which seems excessive for our volume.

We are also a VM shop, so does that complicate things even further.

Thanks for any assistance you can offer.

Greg

[jbhall56]

A general question: do the same requirements apply to all merchants, just the reporting structure is different?

For others wondering about this, not all requirements are applicable to all merchants. Hence why there are four SAQs.

However, all PCI requirements are the basis of the SAQs. It's just the level of detail of the tests that are different from the Security Assessment Procedures which documents the full PCI DSS testing.

We are a mid size company, we accept payments from customer service reps (who use their workstation to access an external cc application), web-site and IVR.

I think SAQ C is appropriated for us, but I'm trying to get my head around the right level, and things like network segmentation, isolation, encryption. I spoke to a colleague who said they had to get separate routers, switches, etc. to meet compliance, which seems excessive for our volume.

It is up to your acquiring bank to determine what SAQ your company should use. While your analysis may be correct, you need your acquiring bank to make that decision. So, someone from your organization needs to contact them and confirm what SAQ to use based on a detailed description of your CHD processing.

VLANs properly secured are acceptable. However, if you are using unmanaged devices, then you may have to upgrade your network infrastructure. For more information see this blog entry http://pciguru.wordpress.com/2009/02/15/network-segmentation/

Your colleague may not be telling your the whole story or possibly got sold a bill of goods. If they were using unmanaged devices and therefore could not properly secure things and properly segregate their CHD network from their non-CHD network, they likely had to do something. Buying separate devices is one way to segregate a network and may have been the cheapest alternative.

We are also a VM shop, so does that complicate things even further.

Virtualization does add an additional layer of complexity, but it shouldn't be too much of an issue. See this blog entry for additional information http://pciguru.wordpress.com/2009/06/27/server-virtualization-and-pci/

[gzink]

Jeff,

Thank you for pointing me in the right direction about speaking to acuiring bank. The following is my interpretatioin of the information you presented about requirements versus testing.

SAQ D 2.2 (a) Have configuration standards been developed for all system components

SAQ C Does not have a 2.2 requirement, therefore if we were at the SAQ C level, while it may be advisible to have standard configurations, we would not have to and if we met all other requirements we would be considered pci compliant.

Which is why it is critical to be on the same page with the acquiring bank, otherwise we may think we are a SAQ C customer, meet all of the requirements, and potential be non-compliant as the acquiring bank classifies us as SAQ D.

Thanks again for your assistance.

Greg

[jbhall56]

SAQ D 2.2 (a) Have configuration standards been developed for all system components

SAQ C Does not have a 2.2 requirement, therefore if we were at the SAQ C level, while it may be advisible to have standard configurations, we would not have to and if we met all other requirements we would be considered pci compliant.

The assumption in SAQ C is that the merchant is using a packaged POS system or other purchased solution that the merchant cannot modify and can only implement per the vendor's implementation instructions. As a result, a configuration standard would be dictated by the vendor and the vendor is required to be providing a PA-DSS certified solution.

SAQ D is referred to in the QSA community as SAP 'light' since it covers all 12 requirements just like the SAP. The only difference is that SAQ D does not have the level of detail of the SAP. SAQ D is for those situations where the merchant does not fit any of the other SAQs' requirements - it is the 'catch all' SAQ.

[manukabay]

The assumption in SAQ C is that the merchant is using a packaged POS system or other purchased solution that the merchant cannot modify and can only implement per the vendor's implementation instructions. As a result, a configuration standard would be dictated by the vendor and the vendor is required to be providing a PA-DSS certified solution.

Where is it documented that SAQ C only applies if you are using a vendor packaged POS system that the merchant cannot modify? I don't see that anywhere in SAQ C.

[jbhall56]

It is not documented, it is an assumption. That assumption gets more strength when the PA-DSS certification requirement gets implemented next year.

[manukabay]

It is not documented, it is an assumption. That assumption gets more strength when the PA-DSS certification requirement gets implemented next year.
The VISA PA-DSS certification mandate shouldn't change a thing since neither the mandate or PA-DSS apply to in-house developed payment applications which are not prohibited in SAQ C as far as I can tell. I guess I don't understand who is doing the assuming if its not documented.

As for the OP's original question about configuration requirements. PA-DSS doesn't apply to all system components - only the payment application. So configuration standards for many system components (routers, firewall, OS, servers, etc.) do not need to be covered by a vendor. The OP is correct to be concerned about the configuration standards if he is pushed to SAQ D as the vendor configuration standards likely won't cover the requirement.

[jbhall56]

The VISA PA-DSS certification mandate shouldn't change a thing since neither the mandate or PA-DSS apply to in-house developed payment applications which are not prohibited in SAQ C as far as I can tell. I guess I don't understand who is doing the assuming if its not documented.

Just a nit, but Visa has nothing to do with the PA-DSS other than providing the original framework from their PABP program. The PCI SSC is responsible for the PA-DSS certification program and the listing of certified applications.

While you are correct about in-house developed software solutions, the assumption made by the developers of the SAQs was that most of the organizations filling out SAQs would be using purchased, unmodified solutions.

You also need to remember that Visa has mandated (http://usa.visa.com/download/merchants/payment_application_security_mandates.pdf) that all packaged POS solutions used by merchants as of July 2010 need to be PABP or PA-DSS certified.

As for the OP's original question about configuration requirements. PA-DSS doesn't apply to all system components - only the payment application. So configuration standards for many system components (routers, firewall, OS, servers, etc.) do not need to be covered by a vendor. The OP is correct to be concerned about the configuration standards if he is pushed to SAQ D as the vendor configuration standards likely won't cover the requirement.

I apologise, but the discussion got off on a tangent.

However, you are correct, the PABP/PA-DSS has nothing to do with PCI DSS compliance. They are two different things which is why a lot of application vendors are shocked when they get calls from QSAs doing assessments. There are a number of great posts (http://pciguru.wordpress.com/2009/06/10/pabp-or-pa-dss-compliance-does-not-imply-pci-dss-compliance/) on this topic (http://pciguru.wordpress.com/2009/03/10/pa-dss-certified-%E2%80%93-so-what/).

The bottom line is that all applications have to be assessed against the PCI DSS. A PABP/PA-DSS certified application can save a bit on this assessment process as long as it has been implemented according to the vendor's PCI compliance implementation guide. However, that is where we run into the most problems. In a lot of cases, there is no implementation guide, so we have to go through the whole application to ensure it is compliant.

[gzink]

The assumption in SAQ C is that the merchant is using a packaged POS system or other purchased solution that the merchant cannot modify and can only implement per the vendor's implementation instructions.

In our case, we are using a payment processing vendor to process our transactions. We host a web page that does a URL redirect to the payment vendor. In this scenario, would this be considered a POS solution? In all of our cases, externally facing url and ivr, and the internal page our CSR reps use all are transmitted to the process vendor.

The other key thing in our case, is that we do not store any credit card data other than the authorization #.

[jbhall56]

It appears that you have effectively gotten rid of the obvious PCI DSS compliance points. However, do you have any accounting types that come in contact with cardholder data (CHD)?

What a lot of people miss is those back office people that handle chargebacks and disputes. They can come in contact with CHD every day and can retain some CHD on paper or in files on their computers. Also watch out for those people that are great at customer service. Sometimes they hang onto their best customers card numbers so that they do not have to repeatedly ask for it. While it's great from a customer service perspective, it can be highly risky if they ever loose that spiral notebook or their spreadsheet that contains all those card numbers.

So, you still need to look around your organization and make sure that the not so obvious places also get investigated.

[manukabay]

In our case, we are using a payment processing vendor to process our transactions. We host a web page that does a URL redirect to the payment vendor. In this scenario, would this be considered a POS solution? In all of our cases, externally facing url and ivr, and the internal page our CSR reps use all are transmitted to the process vendor.

The other key thing in our case, is that we do not store any credit card data other than the authorization #.
SAQ C doesn't apply just to POS systems, it applies to any payment application per the SAQ instructions:
SAQ C has been developed to address requirements applicable to merchants whose payment application systems (for example, point-of-sale or shopping cart systems) are connected to the Internet (via high-speed connection, DSL, cable modem, etc.)
So you may well qualify for SAQ C but you do need to validate the areas Jeff mentioned and make sure your payment application systems do not connect to any other systems in your environment.