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)

We connect and interface to about 20 different endpoints, each has its own message formats, connection methodologies, protocols, and different implementations of payment transactions sets, encryption and key management considerations, On-Line vs Offline transactions, Store and Forward (SAF), and flat file based reconciliation and clearing files among other details.

Here is a basic list of steps that we perform that assist us in getting the endpoint integration right:

1) Acquire the Host Message Format specifications and communication/protocol specifications that describe the communication and connection e.g: 2||4 byte length header, other header(s), length in network or host byte order, etc. and  read  and understand them.  Perform this same task for batch flat file based formats and file transfers.

2) Request sample dumps/files of some messages as well as for online transactions, network traces that show the communication bytes of the message, manually parse them and map them back to the spec. These should include samples of request/response exchanges.  [These should be from a test system.]  Examples often reveal nuances not documented or kept up to date in the spec.

3) Determine which message set and transactions are in play, There are many types of transactions that will be different depending on the type (e.g Debit, Credit, Gift) and characteristics of the transaction (e.g Manual, Swiped, MOTO). You need to determine which ones map to your business requirements and which ones will be used.

4) Request and/or develop certification scripts for your implementation (it helps to see what the other side thinks is important).

5) Schedule a walkthrough – This is the key event: the probability of our success is increased by scheduling and holding one or more walkthroughs.  The idea is to comb through the spec(s) and complementary material page by page, field by field and get complete alignment on the task.  It’s the absolute truth that the real nature of the interface comes out in the walkthrough. 

6) Develop and test your code to the specs and sample messages dumps. (Which is a small part of the project)

7) Use tools such as netcat  and wireshark as well as your application logs to confirm that you are sending what you think you are, and can provide detailed information to someone on the ‘other’ end of the endpoint to help troubleshoot integration. Don’t assume that you think you are sending what your think your code does, verify it locally first.

Develop a good or rather great working relationships with someone on the ‘other’ end of the endpoint, that can help assist with message format questions, perform traces, and check what you are sending to what they expect, and setup regular communication throughout the project.

Netcat is described as the Swiss Army Knife for TCP/IP. I use it in two different ways:

1) Build a small server that dumps the contents it receives to a file. (Helpful for reverse engineering and debugging purposes)

$ nc -l -p 10000 > out.txt

This will set netcat to listen on port 10000 and redirect the output to the file out.txt

For Instance, I configured a client program that sends messages to a server and connected to my localhost:10000 instead:

$hd out.txt

00000000 00 4d 30 31 30 30 70 2000 00 00 c0 00 00 31 36  |.M0100p ……16|

00000010 34 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 |4111111111111111|

00000020 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 |0000000000000001|

00000030 30 30 31 32 33 34 35 36 31 32 33 34 35 36 30 31 |0012345612345601|

00000040 31 32 33 34 35 36 30 31 30 31 30 31 30 31 20      |12345601010101 |

This shows me that there is a 2 byte header (00 4d) of 77 bytes in front of this ISO8583 0100 (30 31 30 30) message.

2) Use it as a client to send message dumps. (Helpful for a quick and dirty method to send data over TCP/IP)

$ cat out.txt | nc localhost 10000

This will send the contents of out.txt and ‘pipe’ it to netcat that will attempt to connect to localhost on port 10000 and send the contents of out.txt.