Visa has published List of Registered Independent Sales Organizations that are registered with Visa, currently it consists of 44 pages and ~2000 registered companies.

Download the list here: http://www.visa.com/isolisting

I’m off to Visa PIN Security Compliance Validation Training Session.

Visa is offering a series of one-day Visa Key Management Training sessions as well as a three-day Visa PIN Security Compliance Validation Training session that will provide up-to-date information on the secure management of cryptographic keys used in ATMs, point-of-sale (POS) PIN pads, encrypting PIN pads and hardware security modules. These sessions are for staff involved in the management or operation of devices that accept PINs, and for personnel who need practical knowledge about the elements of Data Encryption Standard (DES) cryptography and the management of secret encryption keys. In addition to the material covered in the one-day Visa Key Management Training session, the three-day Visa PIN Security Compliance Validation Training session offers an in-depth review of the Payment Card Industry (PCI) PIN Security Requirements, providing internal and external assessors with the tools necessary to complete a PCI PIN security compliance review.

Should be fun.

I had a friend “tweet” me a payment using twitpay this afternoon. I remember twitpay from earily in the year, but unlike my experiences with OboPay and Amazon Payments, sending a txt message or using a website to initiate a payment seem to be the easiest, thus I never signed up with twitpay, I also believe that it was in a early beta as the time as well, and honestly I thought it was silly, why would I use twitter to send payments when there are other working models that I’ve used. But with me being in the payments space and some what of an early adopter, I think I’l give it a shot the next few times I need to pay friends back for lunch.

twitpay uses the Amazon Payments Infrastructure, so you need to create an Amazon Payments Account and link your DDA and or Credit/Debit Cards Numbers to it. As a user of Amazon Payments as an alternative to using Obopay (I found it cheaper and there was less nagging verification) I didn’t need to perform this step.

How to use twitpay. It is easy — just tweet:

@dbergert twitpay $5.00 for lunch money

This would pay the user dbergert (this is me btw) $5.00 with a comment of “for lunch money”

In order for the recipient to claim their payment, they need to be a twitter user, and first follow the twitpay user, and then “Claim” your twitter account, which will result in a PIN that is DM’ed (Direct Messaged) to you from twitpay. then you can see what amounts your are owed, and then you also have the ability to send payments as well. When you want to settle up ? which doesn’t appear to be automatic, you click on the settle-up button to initiate the funds transfer from your Amazon Payments Account to the Recipients Amazon Payments Account. twitpay charges a nickel for transactions over $1.00 to settle.

Give it shot, It is a neat unique way of quickly paying a friend for something, I’m not sure if it works with DM’s so you should note that any payment that you make currently with twitpay are public to those who can read your twitter updates.

I’ve sent a few friends varying amounts between .50 and .75 this evening to see how useful it is, Honestly I’ll probably just use Amazon Payments txt or website interface, but who knows, let’s see how the experiment goes!

Photo by davethelimey

Ellen Richey, Chief Enterprise Risk Officer for Visa, Inc said the following at the Visa Global Security Summit

"As we’ve all read, the company had validated PCI compliance. But it was the lack of ongoing vigilance in maintaining compliance that left the company vulnerable to attack. Based on our findings following the compromise, Visa has taken the necessary step of removing Heartland from its online list of PCI DSS compliant service providers."

I remember someone asking me when news of this breach first hit the news –  "But weren’t they PCI compliant ?" "How could they have been breached, weren’t they secure" ? 

I’ve discussed this here before here (PCI Compliant Control Breakdown) and here (Compliance != Security - the Titanic illustration).

I really think the the Heartland Breach is the linchpin event to people of these three important concepts:

1. PCI is a baseline of minimum controls that need to be implemented to generally reasonably protect data across the broad spectrum.
2. Security goes "above and beyond" the minimum required for compliance and should use a risk based approach specific to your business and operating environment.
3. Maintaining compliance must be a ongoing process, it is not a once a year thing.

Case in Point: - a sales professional that I work with, attended the Prepaid Expo USA recently and shared this from his notes on one of the sessions on Prepaid Card Processing:

PCI is NOT enough. It is an ongoing process and we are all playing the "catch up game" much like the anti-virus world.

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.

I ordered a set of tickets for an event this summer from a website and was surprised to see my clear text CVC2 (CVC2 is for Mastercard, CVV2 is for VISA).

Not a real good design, in my opinion, to display the entered card security code

I read about a new Anti-Skimming device for ATM readers here

In a matter of seconds, criminals can place a skimming device on an ATM card reader that blends in with the machine’s appearance and does not interfere with its operation. A small wireless camera, concealed near the ATM fascia, is also used to capture the user’s personal identification number (PIN) as it is entered. Information from the device and camera is sent wirelessly to the criminal’s laptop computer. The ATM user typically has no idea that his or her information has been compromised.

…

To help reduce ATM skimming, the ADT solution is installed inside an ATM near the card reader, making it invisible from the outside. The technology helps prevent card-skimming attempts by interrupting the operation of the illegal card reader. The solution also detects the presence of foreign devices placed over or near an ATM card entry slot, without disrupting the customer transaction or operation of most ATMs. For effective, layered ATM security, the ADT solution can trigger a silent alarm for command center response and can coordinate video surveillance of all skimming activities.

Look interesting.

There are a few different ways of implementing "encryption" from the POS/Payment Device/Terminal, I though I’d look at a few in a short post:

1) Tunneling - using existing applications and their connections over an encrypted tunnel   e.g.over a VPN, SSH, stunnel, etc. This approach doesn’t require any changes to devices or message formats or the payment "server"

2) Transport level - using TLS/SSL over TCP/IP Sockets - or at a higher level (web server/web service) using HTTPS. - devices needs to support the ability and make this type of connection, message formats are not modified.

3) Data Element or Field level — if you only want to encrypt the PAN or other specific fields, and these fields are defined to support the increased length required of the encrypted payload  — this requires changes to the message formats, devices and payment "server" software. Consider truncating the Account Number/Track Data in DE 2 or DE 35 in ISO8583  for use of displaying purposes on the terminals screen or receipt and consider using another Private ISO field for the payload.

The approach will depending on what the "devices" sending the transaction can support, both from a connection perspective as well as a software perspective. I’d also recommend consider using asymmetric encryption rather than symmetric here, as then the devices would not have the ability to "decrypt" as they would not have the private/secret key, and would help with eliminating private key storage at the device level if you choose option 3. There are implementations that use HSM’s and the DUKPUT algorithm as well.

We have an implementation of #3 that I wrote about here. — relevant paragraph below:

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 plan to write more on E2EE (End to End Encryption) in the coming weeks as well, so stay tuned !

I’ve been working some batch file based jobs for a project here for OLS. There are two sides of this; sending "clearing" files of transactions in a defined format to third party which I will call the extract, and receiving "refresh" or table updates from this third party, I’ll refer to this as the import. The extract file contains financial transaction records, and the import file contains entity information such as merchant information. The Extract File Layout is quite standard an looks something like:

The File Layout for Import is a list of fields per record, nothing real fancy here.

I don’t want to spend too much time about the actual mechanics of the Extract and Import jobs themselves, but rather the Operational Considerations of this and others that we have performed:

Validity — You need to decide how to handle invalid records in a file or valid records without proper supporting data (transactions for a merchant that wasn’t setup in your system) ? You can write off the bad record to an exception file, and address it later, or you can reject the full file, the approach depends by implementation and requirements. We also mark files with a .bad extension if we detect they are invalid to help prevent subsequent processing steps, like transmitting a half-baked file. We also perform duplicate file checking as well as other validation steps.

Completeness — You need to make sure that you read in the entire file or extract a complete file. Monitoring controls such as checking the number of lines and file size in an Extract file, as well as checking the last time of a file for a specific record such as a File Trailer. Reconciliation between hash totals and amounts is also a good practice. On the import side you can count the number of lines or records in a totals from a trailer record and compare that to what was imported.

Timeliness — Some extracts take minutes and others hours, scheduling and monitoring the process is essential to perform data processing on a timely basis to other parties. Monitoring "check-points" in the process as well as a % of records completed help here to detect problems proactively with monitoring. Collect job performance metrics, it is valuable to keep track of and chart the total run time of each job and compare it to its history, to detect slowdown’s or to correlate increase or decrease in process times with external events or transaction growth.

Delivery — Consideration for the delivery of the file must be made. File Transfer procedures that address file naming conventions, steps to upload a complete file (upload as a .filepart extension and the rename to the full name upon complete transfer) as well as secure delivery as well as archiving locally or remotely, compression, and any file level encryption. It is also a good practice to reconnect to the file server and perform a directory listing on the files that you uploaded to confirm that they were transferred successfully.

Security — While account numbers and such are encrypted in databases (column level, file level, internal database level) the file specifications don’t allow for encrypted card-numbers, so both file level asymmetric encryption using the public key of the recipient as well as transport level encryption to send the file (see Delivery above) need to be considered. Archival files stored on disk will also need to be stored encrypted as well.

Troubleshooting/Restart Procedures — You need to develop procedures to support the following:

· re-sending failed files

· re-running the extract or import process for a specific date

· preventing duplication or invalid files or data.

The End is Just the Beginning — Operations is just the start of a process that has no end, it requires daily care and maintenance. These processes and controls need to work in harmony on a continuous basis and be able to be enhanced based upon the results of monitoring and other operational tasks.

I was looking for an old file on an old computer and ran across some old documents. 

Here is something that I put together in 2003:

(Click for full sized version)