This is page 2 of:
The PCI Scoping Discussion Is Over. Now It’s On To SAQ Roulette
In the case of SAQ C, in particular, two subtle requirements are frequently overlooked.
The first overlooked requirement is: “Your company store is not connected to other store locations, and any LAN is for a single store only.” That means if a merchant’s retail or hospitality application supports more than one location, or even more than one “store” at a single location, that merchant has to use SAQ D regardless of whether or not it retains electronic cardholder data.
The second, and more frequently overlooked requirement—and this is where the PCI Council’s scoping guidance comes in—is: “The payment application/Internet device is not connected to any other systems (emphasis provided) within your environment.” To paraphrase what the PCI Council told the assembled masses at the Community Meeting, what is it about “not connected to” that you don’t understand?
Let me give just two examples of connected systems. If a merchant’s payment application can receive an inbound connection from outside the CDE, such as from a patch update or antivirus server (even through a properly configured firewall), that merchant has a “connected to” system, and it cannot use SAQ C. Or, if the payment application initiates an outbound connection to a internal domain name server (DNS) or Active Directory controller, that, too, is a “connected to” system. And forget about any shortened SAQ (and that includes SAQ C-VT for all you virtual terminal users).
The fun does not stop there. In addition to needing to use SAQ D, those “connected to” systems and devices must be included in the merchant’s PCI scope. That is because, to the PCI Council, “segmentation” means “isolation.” It does not matter that there is a firewall between the connected systems. All that matters is whether the payment application can receive a connection from or initiate a connection to another system or device within the merchant environment. If that situation exists, the merchant has not sufficiently segmented its systems to minimize PCI scope.
Therefore, the only way to qualify for SAQ C or C-VT is with an isolated, dedicated device.
The reality is that very few merchants qualify for SAQ C or C-VT, and those that do may be in for a lot of work. The PCI Council recognizes this situation in its instructions that accompany each SAQ: “This shortened version of the SAQ includes questions which apply to a specific type of small merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to your environment which are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment.”
What does a “small merchant environment” for SAQ C look like? To this QSA, it would be a standalone merchant with a single, dedicated POS computer. If that description doesn’t match your business, if you have a security infrastructure in place that supports your payment environment or if your application supports multiple locations, all I can say is welcome to SAQ D land.
The PCI Council’s guidance on scoping a PCI DSS assessment has not changed. What the discussion about scoping has done is to make more merchants aware of that guidance and what it means for their own PCI scope.
What do you think? Does your organization qualify to use a shortened SAQ? Did you think you did before reading this column? Either way, I’d like to hear your thoughts. Leave a comment or E-mail me.
-Marc
October 17th, 2012 at 1:17 pm
I think this is a very strict interpretation of “connected” systems. You may be right in that PCI SSC views scoping in this purist view, but this is one of the problems with PCI. SAQ-C for example, creates a catch-22 for merchants. A requirement for SAQ-C is “Use and regularly update anti-virus software.” Well, to do this, the AV application must have connectivity to another “connected” system. Yes, I know, a merchant can manually copy AV definitions to removable media and manually update the CDE, but how many are really going to do this and for the few that do, how up-to-date are they really? So this strictest view of “connected” makes SAQ-C invalid so why does PCI even have the SAQ? This sounds like nothing more than a PCI/card brand liability trap for merchants.
October 17th, 2012 at 8:36 pm
A related problems for retailers can be the payment equipment supplied by the bank, ISO or integrator. For example, consider a dial-up terminal/PINPad without an integrated printer.
This means receipt printing on a printer attached to the POS workstation which is in turn connected to the in-store LAN and thus may/may place the entire ‘typical’store network in scope – because PAN is often printed on merchant receipts during offline/SAF modes as a result of business requirements of Acquirers. The decisions made by the Acquirers can affect the scope and compliance of merchants, even those apparently suitable for SAQ A. And the Acquirer has made the validation process move from SAQ A to SAQ D for many small retailers. I’d prefer that Acquirers and ISOs et al design their solutions with the end user’s PCI DSS compliance in mind. Then PCI DSS will have even greater benefits.
October 18th, 2012 at 12:00 am
Steve, Lyal,
Thank you both for the thoughtful comments.
Steve, I agree my position is a strict interpretation of the PCI SSC’s guidance, but that is exactly what I as a QSA am supposed to do. The same goes for merchants, too. The only position that matters is that of the PCI Council’s or maybe the merchant’s acquiring bank. That is, if the acquirer wants to give the merchant a pass on a particular SAQ, I would have no problem with that. Otherwise, we all have to play by the house’s rules.
I have some sympathy for your point of about how the rules for SAQ C may not make sense in the real world that many merchants live in. You are right about the difficulty of meeting SAQ C if a merchant or retailer has any meaningful security or IT infrastructure. But as I pointed out, that appears to be the Council’s intent. That is, they aimed the shortened SAQs at the small merchant, not one with extensive scope or multiple locations. It isn’t for me to agree or disagree with this (and I, too, have been very critical of SAQ C). Rather we all have to live with the PCI rules the Council has laid out. If merchants want to change things, they need to get involved and have their views heard individually or through their associations.
Lyle, you make a powerful point about how acquirers can make a merchant’s situation easier or harder. I disagree, though, with your point about PAN data printed on batch tapes or other “requirements of Acquirers.” Take a look at the excellent Visa publication on this topic (http://usa.visa.com/download/merchants/PAN_truncation_best_practices.pdf). My advice based on Visa’s position is that if an acquirer makes the merchant keep cardholder data, I’d think about getting a new acquirer.
October 18th, 2012 at 12:06 pm
I agree that you, as a QSA, you must use a strict interpretation. But with this strict interpretation, I argue that in the real world, with this strict interpretation, no merchant can qualify for SAQ-C and still comply with SAQ-C. Either PCI SSC needs to relax their “connected systems” definition, or drop SAQ-C — the latter being a boom for alternative payments.
October 20th, 2012 at 10:18 am
Agreed on excellent thoughts above. I don’t have a single customer that qualifies for the shortened SAQ any more. I think the SAQ is getting to be such a burden that businesses are making decisions to not upgrade to new equipment and technologies. This stifles business growth and inhibits moving to solutions that encourage more secure practices, as well as other benefits.
For example, I regularly encounter business to business companies that say they don’t store credit data because of risk. But when employees are probed, they really do store data. They have all sorts of excuses- we only hold it for 30 days and it’s in a locked file drawer, etc. I’ve heard it all.
What’s really needed is a simpler method for merchants to identify the correct SAQ, including case studies or merchant scenario’s so they can more easily identify the correct SAQ. How about adding a simple logic tree?
November 8th, 2012 at 3:05 pm
I disagree; this is an issue of scoping as it applies to the unencrypted cardholder data. If the data is encrypted, and the retailer does not hold any of the keys or ability to access the keys, then the data is out of scope, and therefore the system that data is on is also out of scope.
November 12th, 2012 at 4:33 am
Walter,
You wrote “The PCI Council made it clear that any device ‘connected to’ the cardholder data environment (CDE) is in scope, and that includes what the Council termed any ‘connected to connected to’ system”.
This seems to be a key clarification, but I’m a little confused as to what a “connected to connected to” might mean. Three possibilities come to mind:
1. “connected to connected to” describes a device which cannot connect with a system component that stores, processes or transmits cardholder data, but which *can* connect with a device directly connected to such (e.g. on the same [V]LAN). That is, what the Open PCI Scripting Tookit refers refers to as Category 2a, 2b and 2c devices.
OR
2. “connected to connected to” describes a device in the sense of Open PCI Scripting Tookit Category 2x, i.e. which is completely isolated from any device that stores, processes or transmits cardholder data and from any device directly connected to such (e.g. on the same [V]LAN), however, it’s still possible to administer one of these devices via a connection to an intermediate device that *can* connect with it.
OR
3. both of the above
Did they use specific language as I have above, or did they just speak generally in language affirming that scope of assessment extends out to two degrees of separation as a rule of thumb?
Was this a formal written clarification (e.g. a FAQ)?
Sounds like the details on this could make a good article 8-)