Over the last few months there has been various webEx, gotoMeeting, Live Meeting, etc of product demonstrations that I’ve been a part of as a participant.

Some General Thoughts:

• If you are showing a web based application use a SSL Certificate and https:// If you are going to show a web-interface that you log in with a username and password or shows account numbers please do this- you can used a self-signed cert, but I get nervous about demo’s without this- It is just sloppy not to do.
• Mask Account Numbers when they are displayed. I get really nervous about this type of stuff and question your security posture.
• Don’t use account numbers and PIN as authentication method, (although there are certain instances where this is acceptable) don’t make this the default option.
• If you are showing a payment system – understand what PABP and PA-DSS are – and if you have customers that are "PCI Complaint" running it, this isn’t the same to me.
• Show a finished product, links that go to "Not yet completed" or pages that are not consistent in look and feel confuse me.
• When I ask how many ‘Live Customers’ use this product, I want to know about in production, not in the sales pipeline.
• If it is a MS Windows/SQL Server based product, don’t list Windows Std. Edition and MSSQL Standard Edition as required software – We need enterprise level software, there is a huge delta in TCO in licensing fees.

Things to do right:

• Simulate a live transaction against a simulator or other tool showing that it is a real system and is functional.
• Walk me through the life-cycle of certain processes that I care about.
• Be able to explain "how you would implement X" or modify Y, or how your system deals with "Z"
• I know that a product won’t solve all of my needs, so I’m looking for synergies with your team to be partners with a relationship to get your product to fit my needs.
• Be able to speak my language, and have a few competent people driving the demo.
• Show me how "someone would use this" application in the real world.

Here is a list in no particular order:

Gateways:

• MerchantWarehouse MerchantWare
• Shift4 – 4go
• Element Payment Services
• Trust Commerce – TC Smart
• Network Merchants, Inc.
• eProcessing Network

(contact me and I’ll add you if you are not listed)

Most of these are ISO’s that sell you a merchant account and access to their gateway that uses "end-to-end" encryption and that it will shift the PCI and PA-DSS burden from you to them, if you are a merchant, some claim you don’t even need to go through PCI compliance because you don’t have access to the card numbers or the encryption keys to decrypt the cards (Please also see this post on this subject).  This is all really good stuff, I’ve written about End-to-End Encryption before and am a big proponent of it. This can help prevent "sniffers" and card capturing malware from capturing track data and account numbers in the clear as they traverse your internal network. Attackers would either need to install card skimmers or gain access to encryption keys, or use brute force methods against captured encrypted data to capture data at your store.

But it isn’t really End-to-End Encryption.

Let look at two examples:

1. A typical small merchant using a payment gateway
2. A large retailer or processor/gateway that uses a payment switch

A typical small merchant that uses a payment gateway:

A large retailer or processor/gateway that uses a payment switch

( uses leased lines to connect directly to a Payment Processor (FDR, Chase/PaymentTech, Fifth Third, MPS, etc ) or Interchange Network (VisaNet, BankNet, etc )

Let’s say that you are using a gateway or even a switch that supports an encrypted message format from the point-of-sale (POS). The area in RED in each diagram shows where the account number traverses the payment networks in clear text. At the small merchant example from the Gateway to the rest of the network – the account number and track data and CVV2/CVC2 data is sent in the clear. In the direct connect model with the Payment Switch (which actually just operates as a local gateway) from the payment switch to the rest of the network. So End-to-End is really not End-to-End at all. (it depends on where you define end   This should also explain why End-to-End Encryption in its current state would not of prevented the breach at Heartland Payment Systems – as a processor they need to connect and communicate over the interchange networks using TCP/IP connection and ISO-8583 messages to these endpoints.

Why is this ?  The Payment interchange networks and message formats that processors and the Interchange networks use does not support this in their current message formats (primarily ISO-8583) There is no room in the current implementations of Visa’s Base1, MasterCard’s MIP, or FDR’s message formats for example. Data Elements can be added to support this, but would require massive changes to Payment Systems infrastructures and systems.

Does any one have any solutions for this ? Please provide comments below — I’ll provide a follow-up blog post with some of my ideas.

Remember that End-to-End is really not End-to-End, it may shift or transfer some of the compliance "burden"  from the merchant to that of the processor, but still exists in clear text on private networks and at processors.  Oh, and tokenization and secure card vaults would work the same way here, the cards need to be translated to their raw value to ride the payment networks.

* Well other then the "Validated by PA-QSA" is currently incorrect: we used K3DES.

Link to PA-DSS Validated Payment Applications:

https://www.pcisecuritystandards.org/security_standards/vpa/

Link to PABP Validated Payment Applications:

http://usa.visa.com/download/merchants/validated_payment_applications.pdf

We are Visa PABP compliant, ( see the VISA PABP List and screen capture below  ) but I am a little disappointed in the PCI Council, because we are not listed on that list…  looks like it is time to make a few phone calls to see why and rectify the issue.  I know the the PCI Council now grants us the opportunity to pay $1250 a year to be listed, but we have not received any communication or such invoice from the PCI Council.

I’ve also asked our auditor and received this reply:

"You are not the only one to be affected by this. When I looked at the list, there were only 85 applications listed out of the many hundreds that were listed on the Visa PABP site. So it appears to me that the PCI SSC has not completed their migration"

Here is a link to the CPISM Study Guide Materials [~20 MB] 

You can read more about the CPISM here.

Lately I’ve been hearing reports of processors that are starting to charge their customers $15 per month for not being PCI compliant. To fix this problem, these processors are requiring their customers to install some PC based scanning software that is supposed to magically make the business PCI compliant, thereby allowing them to avoid the monthly charge.

Let me start out by saying: This is a bunch of crap!

There is nothing that you can just put on your PC that will make your business PCI compliant. This is so far off course that it hardly can be related to PCI. PCI compliance is in reference to networks, computers, hardware and software that play a part in the processing, storage, or transfer of a credit card transaction.

Check out the rest of the post here: Forcing Software for PCI Compliance
Unbelievable. I don’t think I could of put it any better myself and really hits on the theme that a product (even if it is PABP or PA-DSS certified), or PCI Scan, or any other service, CANNOT make you PCI compliant — I have a blog post brewing on this very theme.

On May 1st, a payment processor modified their message formats as a part of their PCI compliance to not send Field 35 in SAF Advice transactions and would just send the PAN in field 2 and Expiration Date in field 14, instead of DE 35.

Also, from a forum post from “andrewj”

Another update on this (if you are from Australia) – there is a change being made to AS2805.2 to change the track 2 field from mandatory to optional in 04×0 messages. This should be released sometime this month.

This is a good trend in the industry, hopefully others will take this example and continue to trend.