PA-DSS scope

[Levis]

Hello,

would it be possible to help me little bit with the scope of PA-DSS: Here is the concrete case:

- Merchant has POS terminal (or terminals...) which is owned by an acquirer;
- This terminal is installed by the service provider (also authorisation centre);
- The terminal is connected also to LAN with the other systems - ECR, servers, switches, etc...
- It could be in scope of PA-DSS because of mentined connection to LAN, BUT the payment application is inside the POS terminal and the vendor and developer of this application is mentioned service provider (also authorisation centre).

I read in PA-DSS document, that in case the payment application is provided and developed by service provider, that it is out-of-scope PA-DSS even if the POS terminal is connected to merchant´s network.

Am I right with it or not.

Thank you guys for your help and wish you a merry christmas

Martin

[jbhall56]

Applicability of the PA-DSS to card terminals is a sore subject in my opinion. A lot of terminal vendors think that if they are PCI PED or PCI PTS certified, then they have no other obligation. However, I know of a couple of instances where these terminals are storing PANs in clear text until an end-of-day (EOD) process is performed. Storing the PAN in clear text is against the PA-DSS as well as the PCI DSS, yet these terminal vendors are still allowed to sell these devices even though they are not PCI compliant.

From page v of the PA-DSS states that applications developed by application or service providers are exempt if:

• The application is a service offered to customers (typically merchants) and the customers do not have the ability to manage, install, or control the application or its environment;
• The application is covered by the application or service provider’s own PCI DSS review (this coverage should be confirmed by the customer); and/or
• The application is not sold, distributed, or licensed to third parties.

Examples provided in the PA-DSS to illustrate these exceptions are Software As A Service (SAAS) such as that offered by an Application Service Provider (ASP) or virtual terminal applications.

I am guessing that the acquirer is relying on the first bullet to claim they do not have to be PA-DSS certified.

On page vi, the PA-DSS also does not apply if "a payment application developed for and sold to only one customer since this application will be covered as part of the customer’s normal PCI DSS compliance review. Note that such an application (which may be referred to as a “bespoke” application) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to customer-provided specifications."

It also does not apply if "PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance."

On page vii in the PA-DSS entitled "PA-DSS Applicability to Hardware Terminals". If ALL of the following is true, then the PA-DSS does NOT apply.

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.

Based on your description of the situation, your terminals violate the first bullet. However, how would the acquirer know that this was the case? From what you describe, the service provider did the installation, not the acquirer, so the acquirer is out of the loop.

In the end, I think this is just another example of a flaw in the PA-DSS that needs to get fixed.

[Levis]

Hello Jeff,

great!, thank you for valuable information... right now, I´m about to struggle with our AC. I wish you merry Christmas and NY!

Martin

[Levis]

Hello Jeff,

I´d like to ask you to help me with the following question.

It has been said that POS is out of scope PADSS if :

The terminal has no connections to any of the merchant’s systems or networks;

I suppose if the POS terminal is connected to merchant´s (IP terminal) LAN and the communication goes to auth. centre via SSL is it still in scope PADSS because of the possibility of man-in-the-middle attack am I right ? Is this the main reason?

And second question is - is POS terminal in scope of PADSS if POS is connected only with ECR (cashdesk) by means of serial connection RS-232 and POS receives only the amount from the ECR, nothing else and the merchant is unable to connect or upload anything else to POS.

Thank you very much.

[lyalc]

PA-DSS training by the council was very clear about the 4 criteria by which a POS terminal may be out of scope for PA-DSS purposes.
'Any connection" means "any connection", ignoring the other 3 criteria for a moment (see Page vii, PA-DSS assessment procedures, V 1.2.1).
This includes serial or use of any shared network infrastructure at the site in question.
In the case of a terminal serially connected to a POS workstation/cashdesk that is wholly isolated from the rest of the merchant's infrastructure, them PA-DSS would appear to not apply, although PCI DSS will continue to apply.

The difficulty is that the vendor would need to clearly state in installation and marketing materials that the only way acceptable to install the vendor's product is to isolate the workstation from all other systems - and this may be so restrictive that it will damage sales potential. However, this is a commercial decision, not a PA-DSS/PCI DSS requirement.

lyalc

[Levis]

Thank you Lyalc,

seems if POS is connected via IP and of course must be connected to some router/hub where is not connected any other merchants devices, than also fall to scope of PA-DSS because of mentioned router (open ports, possible man-in-the-middle attack on ssl,etc... ).
Am I right ?

Thank you

[jbhall56]

You are correct.

Once you introduce a network into the equation (VLAN or otherwise), now everything on that network is in-scope including any serial attached terminals and other POS devices that process, store or transmit cardholder data.

[Levis]

Hello Jeff,

FYI - I received the reaction from ssc to our discussion :

The intent of this bullet is that a terminal should not be connected to any system that creates risk for the transaction traffic, like a system with email or an Internet connection, or that has connectivity to such systems. Terminals can still meet this bullet if 1) they only connect to a stand-alone cash register (and the cash register does not have email, Internet, or other connections), or 2) they are connected to a device (again, without email, Internet, or other connections) that manages and routes transaction traffic (for example, a store controller for 3 terminals that share one outbound connection).

It seems the fact is, If the terminal is connected with stand-alone cash register by means of serial cable, there is no other devices and connection except the terminal communication to AC, than PA in terminal is PA-DSS out of scope. Of course if the terminal meets the other 2 bullets :

- The payment application vendor provides secure remote - updates, troubleshooting, access and maintenance;
- The sensitive authentification data are never stored after authorization.

Once again thank you for your help.

[jbhall56]

My problem with all of this is that the terminal manufacturers make each of their terminals with three to four connectivity options but all of these terminals typically run the same internal application software since it would be too expensive to do otherwise. One of those connectivity options meets the requirements you state (usually the dialup option), the other options violate those requirements therefore meaning that the terminal application software should go through the PA-DSS certification process.

What I suspect/fear is happening is that the terminal vendors are using their one communication option that meets the requirements to avoid the expense of PA-DSS certification.

Security is only as good as its weakest link. As a result, we are all less secure because of a small group of vendors that seem to think they do not need to comply.

[lyalc]

Originally Posted by jbhall56

What I suspect/fear is happening is that the terminal vendors are using their one communication option that meets the requirements to avoid the expense of PA-DSS certification.

What would also help is some accuracy in marketing/sales materials from these vendors:
e.g. "This product has not been assessed when used in configuration x as PA DSS does not apply.
Other configurations may require additional PA-DSS or PCI DSS assessment effort to ensure compliance".

I know caveat emptor also applies, but its also unconscionable to mislead prospective customers, imho.

lyalc