08
Nov
09

Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

  • The PANs can only be displayed one at a time.
  • You have to be in administration mode to view the PANs.
  • The PANs cannot be printed out.
  • The PANs are stored in memory, not on a hard drive.
  • The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

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

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.

About these ads

5 Responses to “Credit Card Terminals And PCI Compliance”


  1. April 23, 2013 at 2:40 AM

    Thanks for finally talking about >Credit Card Terminals And
    PCI Compliance | PCI Guru <Liked it!

  2. 2 Martin
    January 12, 2011 at 2:24 PM

    My company wants to avoid PCI requirements on our network. We have a POS system at our sites that presently takes Credit Cards. If we move to stand alone terminals with no connection to our networks (dsl or even dial driven connections) I would think as long as the terminals and the “provider” are PCI compliant that all the work from a network and PC compliance standpoint for PCI compliance will not apply to “our stuff” I know there are other PCI compliance issues tied to processing Credit cards on a terminal, but those are operational to that device, correct?

    thanks

  3. 3 Scott Spiker
    November 23, 2009 at 11:19 AM

    I have made the similar comments to MasterCard and Visa even prior to the formation of the PCI SSC. The real problem is that the PCI DSS is a set of best practices for Windows based POS systems, this its genesis. It has been tweaked here and there to try and be more generic, but at the core, it is the vulnerabilities of Windows that has caused the most concerns for the protection of CHD. The PA-DSS is the software subset to the PCI DSS. Again, primary target is for Windows based applications and systems. There are many areas of the PA-DSS that are difficult to meet in a stand alone payment terminal. My comments to the card brands and the PCI SSC is that a specific set of requirements for these type of devices is needed.

    In defense of the payment terminal vendor, these devices have been exclude from the CISP and SDP programs and the PCI DSS until recently. The are primarily used by level 4 merchants and only recently have these merchants been drug into the security of CHD. Data, by the way, that is impossible to protect since it starts our in the clear on the magnetic stripe of the card. But that is a different topic.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response to too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

November 2009
M T W T F S S
« Oct   Dec »
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 923 other followers


Follow

Get every new post delivered to your Inbox.

Join 923 other followers

%d bloggers like this: