20
Jun
09

In Scope – Example I

I thought I would write about a recent meeting I had with a client regarding whether or not their proposed point-of-sale (POS) solution was going to be in or out of scope.  Obviously, the hope was that it would be out of scope.

I would like to commend this organization for taking the high road to PCI compliance.  I wish there were more organizations like them.  After slugging through a very ugly PCI compliance process last year with a multitude of compensating controls to get them compliant, senior management set a goal of removing all cardholder data (CHD) from their point-of-sale (POS) systems over the next year and a half.  To accomplish this, they are going to implement a tokenization solution on their centralized transaction switch that they are developing in-house.  As part of this effort, the company is purchasing a new POS solution that is PABP compliant with the vendor stating that the next version will be PA-DSS compliant.  The discussion at my meeting was to determine if the POS solution would be in or out of scope.

Prior to the meeting, the client had provided me with some documentation describing their plans for the POS implementation.  I have taken some editorial license to protect the identity of the client, but here is the verbiage that I was provided regarding the configuration of the POS solution.

“The POS PC is connected to a separate credit card terminal by a USB connection.  There is a software client running that communicates with their centralized transaction hub that then submits transactions for authentication as well as handling settlement.  The only interaction between the PC and the terminal is to pass the amount of the transaction from the PC to the terminal and for the terminal to tell the PC whether or not the transaction was approved or declined.”

On the face of things, the solution appears to keep the POS solution out of scope.  However, this is a prime example of why documentation must be complete, clear and accurate.  Interpreting the documentation and lacking a detailed network diagram, I assumed that the credit card terminal and the PC had separate network connections.

As Paul Harvey was so famous for saying, “And now for the rest of the story.”  It turned out that the documentation had a slight flaw.  The person who wrote the majority of the documents had inconsistently used the terms ‘terminal’ and ‘POS’ through out.  A common mistake since most people that develop documentation are usually very close to the implementation process and make the assumption that everyone that reads the document has the same background with the topic in question.  As a result, it was not clear whether the terminal was the PC or the terminal was the credit card terminal.  What the meeting uncovered was that the client software that communicated with the centralized transaction server was in fact running on the PC, not the credit card terminal.  This meant that all communications to and from the credit card terminal were routed through the PC to the centralized transaction server.  That means that the POS solution is in scope.

The moral of the story is that a good QSA never assumes they know everything about a solution and why they seem to ask many questions about something you would think they would know.  The reason is that a good QSA knows that it is your organization’s implementation of the product, not another organization’s implementation and there will be differences.  And those differences could mean the difference between in scope and out of scope.

Advertisements

0 Responses to “In Scope – Example I”



  1. Leave a Comment

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

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 is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

June 2009
M T W T F S S
« May   Jul »
1234567
891011121314
15161718192021
22232425262728
2930  

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

Join 1,868 other followers


%d bloggers like this: