Payment Systems / Application Demos and Presentation thoughts

Photo by The Eggplant

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.

When End-to-End Encryption is really not End-to-End.

I’m reading a lot about solutions that implement end-to-end encryption, where account numbers and track data is encrypted and can utilize a Hardware Security Module (HSM) and DUKPT or other encryption algorithms from the point-of-sale. I thought it important to share what data is actually encrypted in the payment system.


Here is a list in no particular order:


(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.

OLS.Switch on PA-DSS Validated Payment Applications List

A while ago I wrote this post: PA-DSS Validated Applications Published. Where I noted that our software application was on a PABP List but not on the PA-DSS List. Well we made it – it took the PCI Co a while to invoice us for inclusion on the list, but we received the invoice and promptly paid, and here we are:



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

Link to PA-DSS Validated Payment Applications:

Link to PABP Validated Payment Applications:

PA-DSS Validated Applications Published

I read that the PA-DSS Validated Application List has been published by the PCI Council. This is expected as PABP is now know as PA-DSS and the PCI Council is taking ownership of the program.The PA-DSS List of Validated Applications is viewable here:


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"


A PABP compliance press release that raises some concerns…

While scanning though my RSS feeds this morning (Which I have neglected in the past few weeks), I ran into a PABP product release. Let me just include the relevant portions here and not list the company name.

_______________ is a PCI PABP v1.4 (Payment Application Best Practices) validated payment application, Visa USA accepted _______________ as validated based on the review by Trustwave, a well known QSR. _______________ runs on Windows 98 through Windows Vista and supports _________________________________________________________.

Two things that struck me.

  • Trustwave is a QSA ( actually PA-QSA in this role) not a QSR – (Quick Service Restaurant ? )
  • Windows 98 ?  Windows 98 is not secure, and is at End-of-Life (July 2006), does not receive new security patches, and is not something that I would recommend to anyone implementing a new payment application.

How can a a payment application be PABP compliant on an non-secure, not supported, EOL’ed OS ? Interesting….

Forcing Software for PCI Compliance

Jaime from The Merchant Account Blog writes:

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.

PCI PA-DSS – Changes to Store and Forward processing

If you read the PCI standards carefully and hang out with PCI geeks here or here you will notice that PCI applies to post-auth data and not necessarily pre-authorization data. — I think the official language is “subsequent to the authorization”

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.

Free tools to Find Cardholder Data for PCI or PABP


Just a quick post to list some help tools for detecting cardholder data on your systems, or tools to setup for ongoing controls to monitor for cardholder data.

1) ccsrch

ccsrch is a tool that searches for and identifies unencrypted and contiguous credit card numbers (PAN) and track data on windows and UNIX operating systems. It will also identify the location of the PAN data in the files and record MAC times

2) Senf: The Sensitive Number Finder

Senf is a fast, portable tool (written in Java, runnable just about everywhere) for finding sensitive numbers. Use this tool to identify files on your system that may have Social Security Numbers (SSNs) or Credit Card Numbers (CCNs).

3) Spider (Windows) (Linux)

Spider’s purpose is to identify files that may contain confidential data. It scans a collection of files, searching for patterns of numbers or letters that resemble Social Security numbers or credit card numbers (additional search patterns can be created using Unix regular expressions).

4) Tenable’s Ron Gula’s blog using Nessus to find Senstive Data:

Detecting Credit Cards, SSNs and other Sensitive Data at rest with Nessus

5) Snort – using the Bleeding EdgeEmerging Threat Snort rules, (see BLEEDING-EDGE Credit Card Number Detected ET POLICY Credit Card Number Detected in Clear) You might be using snort as and IDS – or using a product or appliance that uses it as its engine. This tool is also very handy to check for email that contains CC data as well. (EDIT: Bob writes to say the that Emerging Threats have replaced the Bleeding Edge project as it died. Thanks !)

6) Strings

using the parameter    Strings -n min-len

Let me know of others that are useful.

Encrypted Traffic from within the PCI Zone

securitylockThe first thing that typically happens with the design of PCI network configuration is that an inventory of all systems/processes involved in the storage, processing, or transmitting cardholder information is performed, and a network diagram that shows where these systems live is produced. The prevailing wisdom over the last few years has been to create a “PCI Zone” using network segmentation which is basically a separate network zone (QSA’s like to say VLAN ) where all of the cardholder systems are that has stateful firewalls and well defined firewall rules for both incoming and outgoing traffic. This is a very important scope reduction technique, that lets you focus on implementing the security controls that are mandated by PCI in the environment of the data and systems that need protection.

Within the PCI Zone – PCI requirements allow for non-encrypted card numbers to be sent across the internal network. (Requirement 4: Encrypt transmission of cardholder data across open, public networks )

I think Rich Mogull said it best: “Corporate networks are like candy bars: hard on the outside, soft and chewy on the inside,”. The PCI Zone is still soft and chewy in some regards.

There are some rumors and speculation that a PCI Compliant merchant, Hannaford supermarket chain’s POS system (like many other merchants) does not send encrypted data between the point of sale and the branch server.

Some of our implementations of OLS.Switch supports field or data element level encryption that is passed on from the Point of Sale system to our switch. The main thing that allow us to perform this is that:

We or our customer “own/control” the POS message format to us and can adapt and handle the programming of the POS System and POS message formats — our account number fields are not limited to 16 digits – we can handle a much large encrypted value. So over the wire – these implementations are “protected” from eavesdropping or sniffing.

I wouldn’t be surprised that if in future revisions of the PCI DSS – traffic from POS systems on private networks will be required to be transport encrypted in a tunnel or require encrypted fields/data elements.

Also related to this subject: Dr. Neal Krawetz has a very good White Paper called Point-of-Sale Vulnerabilities. Read it!!!