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]

Originally Posted by gzink

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.

Originally Posted by gzink

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...-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.

Originally Posted by gzink

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...ation-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]

Originally Posted by gzink

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]

Originally Posted by jbhall56

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]

Originally Posted by jbhall56

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]

Originally Posted by manukabay

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 that all packaged POS solutions used by merchants as of July 2010 need to be PABP or PA-DSS certified.

Originally Posted by manukabay

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 on this topic.

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]

Originally Posted by jbhall56

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.