PED Stores PAN Unencrypted In Journal

[jbhall56]

Here's a good one.

We have a client that is going from an old PED that stores and prints PANs to a new PED that masks the PAN on reports, but it turns out, stores the PAN unencrypted in its electronic journal file. Apparently the hardware vendor's software is custom developed for this client and we are trying to figure out a compensating control for this situation.

Has anyone else run into this situation? If so, how have you responded to this situation with a compensating control?

We cannot come up with a compensating control that meets the 'above and beyond' aspect, so we're stuck.

While I'm at it. How would this be PED compliant? The vendor claimed that it is. Or is it the PIN standard that it violates?

[andrewj]

It is quite common for PEDs to store all sorts of CHD for all sorts of reasons (some valid, many not). The PED standard does not touch upon the storage of CHD, and therefore it is perfectly possible for a device to be compliant to PCI PED, but to violate PCI DSS or PA DSS (or MasterCard PTS, whilst we're quoting standards). The standards are complimentary and do not overlap in most areas.

If the PAN data is stored in plaintext in the memory of the PED, but (i) logical access requires a suitable password, and (ii) physical access would require destruction of the PED and dumping the contents of memory, then this would meet the physical security requirements for storing such data IMHO. It is certainly harder to dump the memory of a device than it is to pick the vast majority of locks that are used to protect physical copies of card data.

If it is storing track data, or some other sensitive auth data (check what happens with tipping and hospitality transactions), then that is a problem.

[lyalc]

I have a client transitioning away from a similar situation.
In this case, as the client manages their own PINPad fleet, they are going to roll-out updated terminal software to encrypt all PAN in the EJ, and remove Track 2 etc other than when supporting Store and Forward (when storage encryption will be maintained).
The vendor's OS driver software also used to store Track 2 on the POS; this is in the process of becoming PA-DSS compliant.

If the EJ is stored within the tamper-resistant PED, I'd be less/not concerned, however if the EJ is output to a POS workstation, then POS storage encryption seems warranted.
The cost of POS storage encryption may be similar to updating the PED software....

lyalc

[jbhall56]

Further research into this indicates that the administrative user must logon to the PED to gain access to the electronic journal. However, this is a shared account (i.e., admin) and, of course, there is no logging of when people log on/off to the device. Yikes!

It is the PAN with the cardholder name and the expiration date that is stored in the electronic journal. It prints out masked on all reports generated, but can be accessed one entry at a time through the LCD display using the administrative account. This information is apparently cleared when the EOD process is performed.

I would think that the device has to be PCI DSS compliant was well as PED compliant. But according to the vendors involved, they tell us that the device only needs to be PED compliant.

[andrewj]

Yes, the device does need to comply to both PCI PED (in regards to PIN security), and PCI DSS (in regards to the security of the storage and transmission of cardholder data, including the encrypted PIN block). If your vendor is telling you different, they are not correct.

It is common for these types of devices to lack logging and proper password controls for access to journals. Indeed, it is difficult to see how these types of devices can comply to the password and logging requirements (eg, regular password expirey, and checking of password history, protecting logs from modification and deletion).

IMHO, these devices are best viewed as physical storage systems, rather than electronic storage systems, and then applying controls suitable to section 9. Ultimately, if the only way to view the PAN is one at a time through the LCD, I would not see this as a big issue. If you really wanted to build some controls around it, you could dual control the password (ie give half to one member of staff, half to another, with backups in a safe or some such for BCP) and require dual entry writen logs to be created for access.

[jbhall56]

This story just gets better and better.

I was speaking with another of our clients that also uses the terminal in question. They have a letter from their acquiring bank (different from our first client) saying that they understand the situation and that they are okay with the situation as long as the QSA is also okay with the situation.

What the ...??? As I recall from training, the acquirer is the one that makes the compliance decisons, not the QSA. Just unbelievable.

[jbhall56]

To add insult to injury in this whole mess, our client has been informed by the vendor that a fix for this situation is at least a year off.

One, I cannot believe the vendor and the card brands have known about this and have let it go without so much as a peep. Second, I cannot believe it has taken this long for this situation to have been identified. You would have thought that the PED certification would have at least identified the situation. I realize that the PED process has no reason to force the problem to be fixed, but you would have thought it would have been brought to the vendor's attention a long time ago and therefore fixed a long time ago. Finally, it floors me that the vendor still believes that it's no big deal.

[lyalc]

This story just gets better and better.

I was speaking with another of our clients that also uses the terminal in question. They have a letter from their acquiring bank (different from our first client) saying that they understand the situation and that they are okay with the situation as long as the QSA is also okay with the situation.

What the ...??? As I recall from training, the acquirer is the one that makes the compliance decisons, not the QSA. Just unbelievable.

I see this all the time.
In my jurisdiction, the banks are very risk averse, and (from the outside) don't seem to have suitable resources to make these decisions.
So they rely on QSA's - after all, thats what the SSC qualified them to do!

lyalc

[egrenier]

...saying that they understand the situation and that they are okay with the situation as long as the QSA is also okay with the situation....

What the ...??? As I recall from training, the acquirer is the one that makes the compliance decisons, not the QSA. Just unbelievable.

I've been in this situation a couple of time already, this is a huge trap in which I've always refused to fall. I can only recommend you to document the risk and the compensating controls and have them formely accept the risk.

Acquirer often try to push down our throat the risk acceptance process, when that happend, I take care of getting the process completed but it remains their responsability to accept it... not ours (the QSA).

[jbhall56]

One of our other clients with the offending terminal was informed today that their processor is going to work with the terminal's vendor to see if the vendor can create a separate "management" account that will allow store personnel to run reports and invoke end of day, but they will not have access to the unencrypted PANs. If they can implement this, I will feel much better even though the CHD will still be in the device.

[lyalc]

I see this all the time.
In my jurisdiction, the banks are very risk averse, and (from the outside) don't seem to have suitable resources to make these decisions.
So they rely on QSA's - after all, thats what the SSC qualified them to do!

lyalc

To expand on my earlier post - if the bank/Acquirer isn't prepared to make a decision or formal position statement when asked in these situations, then I have treated it as a clear case of 'not compliant', and asked for remediation to a compliant level is reached.

These quickly become what I term 'fun' discussions - up to 15 people repeatedly insisting the risk is acceptable, the QSA is <insert derogtory adjective here> because remediation is too <insert objection here>, but no one with a capacity to do will dare put the risk acceptance in writing!

In my view, that really means the risk wasn't actually acceptable after all.

lyalc

[jbhall56]

These quickly become what I term 'fun' discussions - up to 15 people repeatedly insisting the risk is acceptable, the QSA is <insert derogtory adjective here> because remediation is too <insert objection here>, but no one with a capacity to do will dare put the risk acceptance in writing!

In my view, that really means the risk wasn't actually acceptable after all.

That is my position as well. If you want me to sign my Firm's name, you better be willing to do the same. If not, then don't expect me to hang my @ss out there.

Don't get me wrong, I like my clients. But I'm not willing to go to jail for them or take on unnecessary risk, if no one else is going to assist in also taking on that risk.

Here's a good one for you. We just went through our QA review with the PCI SSC and they have given us this advice. They told us that, if you run into these situations and that they are out of the QSA's and merchant's control, then you are to document the situation in detail in the 'In Place' box so that the acquirer must address and accept it or send it back.

The rationale is that the situation is out of the merchant's control and therefore the merchant cannot be held responsible for it, so it is 'In Place' as far as the merchant's compliance. However, QSAs are to document all of the details of the situation so that all readers of the ROC are aware of the details.

[DuvenJ]

Yea that is a good one.

So we now have an 'In Place' column with detail text telling us why the paticular security requirement is not realy in place.