RetailEdge Discussion Forums

I'm in the process of digging into filling out the PCI DSS self-assessment questionnaire. I'm assuming that an installation using a combination of Retailedge/PPI would fall questionnaire C (validation type 4)? Is that correct?
Bob

Bob,

Type C is for Merchants with POS systems connected to the Internet, no electronic cardholder data storage. And although you are connected to the internet, RetailEdge does allow you to store Cardholder data, so you would be required to fill out Self Assessment Questionnaire (SAQ) D (Validation Type 5).

Cardholder data is defined by the PCI Security Standards Council as
At a minimum, cardholder data contains the full PAN (Primary Account Number) . Cardholder data may also appear in the form of the full PAN plus any of the following:
Cardholder name
Expiration date
Service Code

RetailEdge during our PA-DSS Validation process elected to allow storage of this information for a few reasons but a few important ones are:

1. Many RetailEdge users perform recurring billing or just for the convenience of the customer want to be able to charge items to a customers card on file.

2. We store the information about the credit card sale in RetailEdge for a limited period of time to allow RetailEdge users to be able to correct sales once a customer has left the store. This can be useful if a customer has been over/undercharged for a particular item(s). Or if someone has rented something for two days and then drops off the item(s) late and needs to be charged for the extra time.

3. If a person is processing sales off-line (because of an internet connection problem or ringing in sales at a trade show where internet connections are unreliable). They can store the transaction and card information with the customer/sale and then process it properly when they are re-connected to the internet and can process the sales properly. Storing the data in the customer records will be a lot more secure than what we have seen dome by some customers in the past (swiping the cards with a knuckle buster or keying the data into a program where the cardholder data is not secure (notepad, etc.)

Our PA-DSS Validation lets you know that this information is being stored in a secure manner and we felt that these reasons were important enough for us to have these functions be apart of our validation. However it does push you into doing a more extensive SAQ.

Some processors do support what is called "tokenization". This will allow programs that process credit cards like RetailEdge to store Tokens instead of Cardholder Data (CHD). The token allow the program to reference a sale on the processors server and void it by passing it this token. However not all processors support tokenization and tokenization will not allow the other features listed above.

We have a suggestion to include a feature to allow users to turn off storing cardholder data so that they can make the decision for themselves. I don't know when this might get into the program but probably sooner rather than later.

You can verify that RetailEdge is storing Cardholder information by choosing About from the Help menu and seeing whether the CC Data Option is "Yes". If Yes then you should fill out SAQ D.

bobdist wrote:I'm in the process of digging into filling out the PCI DSS self-assessment questionnaire. I'm assuming that an installation using a combination of Retailedge/PPI would fall questionnaire C (validation type 4)? Is that correct?
Bob

Ah, too bad. SAQ D seems considerably more complex to fill out than SAQ C, and requires a lot more back-end processes and supporting documentation. I had hoped it might be possible to avoid SAQ D by having a policy of never explicitly storing customer CC info.
Thanks for the info Bill.
Bob

We do understand that it is more complex and more complexity is not something that we want to add to our customers experience. Also many of the people using RetailEdge don't even understand what is being said in some of the questions let alone how to answer them. This is why we are considering the feature to allow users to select the level of CHD they are storing.

Let us know how it goes and whether you have any more questions.

bobdist wrote:Ah, too bad. SAQ D seems considerably more complex to fill out than SAQ C, and requires a lot more back-end processes and supporting documentation. I had hoped it might be possible to avoid SAQ D by having a policy of never explicitly storing customer CC info.
Thanks for the info Bill.
Bob

Yes, some of the questions are pretty complex. And there's lots of interesting issues to think about... Just as an example, one of the requirements is that each user have their own unique login id. In our environment, where we have several clerks all accessing the same two registers many, many times per day, it seems impractical to have each one do a Windows login each time they want to use a register. So, I recently started assigning clerk ids, and turned on clerk tracking. But, I have no idea if that meets the intent of that requirement. I'd love to hear how other RetailEdge users handled some of these issues.

Bob

My question has to do with the PCI compliance scans. According to DRG Co. I will have to pay them $185 per scan. Must we complete the scan? If so, are there any other resources besides the one mentioned where it won't cost me $? thanks.

Fran

bobdist wrote:Yes, some of the questions are pretty complex. And there's lots of interesting issues to think about... Just as an example, one of the requirements is that each user have their own unique login id. In our environment, where we have several clerks all accessing the same two registers many, many times per day, it seems impractical to have each one do a Windows login each time they want to use a register. So, I recently started assigning clerk ids, and turned on clerk tracking. But, I have no idea if that meets the intent of that requirement. I'd love to hear how other RetailEdge users handled some of these issues.

Bob

I would also like to know how this will affect us? We also have multiple users,with each having a clerk ID's, but will they have to have a separate password and log into the machine every time they make a sale. If this is a requirement, it will be a major pain in the rear, one would probably have to switch back to stand alone terminals.

You might want to take a look at the following link.

Navigating PCI DSS Document

https://www.pcisecuritystandards.org/pd ... ng_dss.pdf

There is a lot of discussion about what is meant by Requirement 8: Assign a unique ID to each person with computer access.

In this document they have the following guidance

8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

Guidance
By ensuring each user is uniquely identified—instead of using one ID for several employees—an organization can maintain individual responsibility for actions and an effective audit trail per employee. This will help speed issue resolution and containment when misuse or malicious intent occurs.


8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:
Password or passphrase
Two-factor authentication (for example, token
devices, smart cards, biometrics, or public keys)

Guidance
These authentication items, when used in addition to unique IDs, help protect users’ unique IDs from being compromised (since the one attempting the compromise needs to know both the unique ID and the password or other authentication item).

RetailEdge does allow you to turn on security and track Clerk IDs and require passwords, so that you can track what a person is doing within the program. In addition, RetailEdge has an Audit log and so almost every action in RetailEdge is tracked and with clerk tracking turned on, we can tell who did what, when.

In addition, you should also be doing other things like only allowing clerks to log into the Windows system as a regular user and not an Administrator. This can also prevent employees and clerks from installing programs that might cause problems when they misuse the system or are doing something with malicious intent.

If you have questions like this you might also want to check with the person helping you with the PCI compliance issues. When using PPI or MPS who RetailEdge has a direct integration with, they have relationships with people who will do the remote port scans and also will help you with the SA Questionnaires. In addition, PPI has insurance program that will help protect you against breaches in the event that your system is compromised. If you are using another processor for your credit card processing, you should check with them to see what kind of service and/or help they can provide.

wildman wrote:

bobdist wrote:Yes, some of the questions are pretty complex. And there's lots of interesting issues to think about... Just as an example, one of the requirements is that each user have their own unique login id. In our environment, where we have several clerks all accessing the same two registers many, many times per day, it seems impractical to have each one do a Windows login each time they want to use a register. So, I recently started assigning clerk ids, and turned on clerk tracking. But, I have no idea if that meets the intent of that requirement. I'd love to hear how other RetailEdge users handled some of these issues.

Bob

I would also like to know how this will affect us? We also have multiple users,with each having a clerk ID's, but will they have to have a separate password and log into the machine every time they make a sale. If this is a requirement, it will be a major pain in the rear, one would probably have to switch back to stand alone terminals.