“Since both companies will utilize web services for the exchange of information, it is proposed that we use SSL instead of a VPN or Direct connection. SSL (https over port 443) provides security by encrypting the communications channel. This arrangement provides all the security of a VPN or Direct connection. Plus it requires less network configuration, less maintenance, greater flexibility (in case platforms move on either end) and eliminates a VPN or direct connection as a potential point of failure.”

I have a lot of problems with this.

1) Encryption isn’t security.

2) I find it hard to dispute that: Direct Connection > VPN > SSL over internet from a general security perspective.

3) SSL used in this manner lacks authentication, compared to a IP SEC point-to-point VPN (AH/ESP)

4) Exposing a web server to the internet introduces the risk of web server vulnerabilities, application layer vulnerabilities, among others ever more recent SSL vulnerabilities[1]. (Note that source based ACL’s are not recommend here either, nor are client side certificates for authentication)

5) The concept of “least privilege” from a networking perspective is not followed – only two parties need to talk to each other, why open it up to the world to attempt to connect to ? Another interface stated “We restrict all traffic by third party connections to the least access needed to support business. ” <– I like this much better.

6) SSL over the internet will require our customer to expose a secure internal system to the internet, when it was designed to have very controlled network access, as compared to a VPN and general firewall rules for network control.

7) I haven’t discussed direct connections or leased lines, mostly due to the nature and volume of this application. Normally this is our first choice for high volume, sensitive transaction data to third parties with multiple data centers. Where we use 2 leased lines on different carriers to different data-centers.

My Vote for this? SSL over a VPN – (Defense in depth) Could SSL be used ? Sure but we would need to add a list of controls around its implementation and quite possibly add a layer of applications (proxy the requests) to design around this which is more work and has a higher change of configuration failure then a standard site-to-site VPN connection.

[1] http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/print.html

Authorization

The Authorization transaction is typically used by a merchant to obtain the authorization of a transaction amount as a pre-approval for the purchase of goods or services later during the fulfillment process. Authorization transactions are typically submitted for authorization and then funds are held by the issuer until that transaction is captured or the authorization is reversed or expires. An example can be found with online retailers who initiate an Authorization transaction to guaranteed funding by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods. An “Authorization” is also referred to as an Auth-Only transaction.

Sale

A “Sale” transaction is used by merchants for the immediate purchase of goods or services. This transaction completes both the authorization and capture in a single transaction request. The Sale transaction is an Authorization and Capture transaction that if approved is automatically included for settlement.

Forced Sale

A “Forced Sale” is a transaction initiated by a merchant with the intent of forcing the posting of the transaction against the customer account without receiving prior authorization by the card issuer, or receiving a voice authorization code from the merchant acquiring call center. An example would be when a merchant’s terminal is offline, requiring the purchase of goods being completed without receiving online authorization by the card issuer. Or they received a Voice Approval. In these cases the merchant would enter the transaction details and forward this Forced Sale transaction to the card issuer with the expectation of receiving funding for the goods or services rendered. A forced sale does not require a matching authorization. Forced Sales are also known as Off-Line Sales.

Refund

A Refund allows a merchant to refund a previously settled transaction and submit the refund for processing. Refunds are only allowed for financial transactions (Sale and Captured) and are typically limited to the original authorization amount, or a lesser amount, in some cases, multiple partial refunds up to the original transaction amount. Some systems incorporate a feature called Matched Refunds. Matched Refunds must match back to an original transaction to help control fraud. “ Refunds” are also sometimes referred to as a “Credit” transaction.

Void

Void transactions can reverse transactions that have been previously authorized or approved by the card issuer and are pending settlement. Merchants will only be allowed to void transactions that are in an open batch (pending settlement). Sale or Refund transactions are the most commonly voided transaction types.

Capture

The Capture transaction will allow merchants to capture a previously authorized transaction that is pending settlement, and submit it for clearing and settlement. An example is when online retailers who initiate an Authorization transaction to reserve funds by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods, and then once fulfillment has been completed the transaction will be captured and submitted for settlement. A “Capture” is also referred to as a Pre-Authorization Completion transaction.

From Visa Bulletin today: Visa Introduces Technology Innovation Program for Merchants, Visa announces that:

Effective 31 March 2011, Visa will allow qualifying merchants outside of the United  States to discontinue their annual Payment Card Industry Data Security Standard (PCI DSS) revalidation assessment.

Note that this doesn’t mean that if you use EMV you are exempt from PCI Compliance (more on this below)

It is nice to see that Visa is rewarding investments in EMV and Card Authenication with a potential of lower PCI compliance costs:

Many merchants have invested time and money in the purchase, deployment and enablement of EMV POS terminals. These merchants have also invested in annual PCI DSS compliance assessments, which may require the use of a Qualified  Security Assessor and can be a significant expense. Visa is introducing the Technology Innovation Program to assist merchants in reducing the costs associated with annual PCI DSS validation.

If you are a non-US merchant and perform the following you are a qualified merchant:

1. The merchant must have validated PCI DSS compliance previously or have submitted to Visa (via their acquirer) adefined remediation plan for achieving compliance based on a gap analysis.

2. The merchant must have confirmed that sensitive authentication data (i.e., the full contents of magnetic stripe CVV2 or PIN data) is not stored, as defined in the PCI DSS.

3. At least 75 percent of the merchant’s transaction count must originate from enabled chip-reading device terminals (i.e., contact and/or dual interface contact/contactless terminals).

4. The merchant must not be involved in a breach of cardholder data. A breached merchant may qualify for TIP if it has subsequently validated PCI DSS compliance.

What about US Merchants ?

Visa has this to say about this program in the United States:

Despite industry interest in chip and dynamic data authentication, the program is not currently available in the United States because recent debit card regulation has cast uncertainty in the marketplace. Visa Inc. may consider implementation of TIP in the United States at a later date based on evolving environmental circumstances.

I think this announcement adds a new dynamic in the form of a potential incentive as it relates to EMV adoption in the US. US Merchants may now, in the near future, have an incentive or a discount to consider for EMV implementation (assuming implementation of  EMV processing infrastructure) in the form of less annual PCI compliance validation costs in the form of on-site audits to offset implementation of new card acceptor devices and updated payment software to support EMV.

If I use EMV we don’t need to be PCI compliant !!!

This is a fallacy that I fear that will echo. This announcement relates to the validation of compliance, not for on-going compliance to the PCI DSS, as stated by Visa below:

Although Visa may waive the annual validation requirement for qualifying merchants, all merchants are still required to maintain on-going PCI DSS compliance. Acquirers retain full responsibility for merchants’ PCI DSS compliance, as well as responsibility for any fees, fines or penalties, which may be applicable in the event of a data breach.

In the Balance Response message that you send us, can you tell me the difference between the “AvailableBalance” field and the “CurrentBalance” field?

Our response:

Current balance is the real, financial balance.
Available balance is the current balance minus any holds.
On the open loop side…
An auth does a hold – it affects only available.

A completion releases the hold and decrements both the available and current by the final transaction amount.

Sometimes you don’t get to define the requirements, they sometimes appear to serve a higher purpose that you can’t begin to understand. All you know is that they are requirements, and there were decisions made for various reasons. Sometimes you have to play the cards that you are dealt. But it is still your choice in how to play them.

I’m talking about message formats here, In a specific transaction processing system there are two requirements that we must adhere to:

1. Accept a 8,000 – 10,000 bytes incoming fixed message format.
2. Log the Raw Message Request and Responses for all interface connections

Regarding #1 I’d prefer to see a variable message format here instead, but I understand the need of an existing system to talk in the language this it is used to. Item #2 had me very concerned when I first heard of it, with my PCI background, I was ready to put my foot down and call people crazy – (Imagining the request to log raw messages that contained track data, pin blocks, card verification numbers)  To my surprise this was not for a financial transaction processing system but for one of a different purpose.  One that exists in a highly regulated word with data retention requirements and the need integrity of the raw transaction messages for compliance and legal reasons.

The challenge I had logging the raw messages where their sheer size – 10K and when you are looking at 4-6 legs of a transaction – client request, client response, endpoint request, endpoint response, and other transaction paths that sometimes seem recursive, we have 50K of logging for a single transaction – times 3 to 5 million transactions per day – that is 150 GB to 250 GB per day of logging !

The easiest solution was to look into compression – how much time would compressing the data stream before logging it take ? Would this impact transaction processing time ? How was the raw messages used ? If we compress the message, what needs to occur on applications on the other end, what language and platform are they written in, what is a portable algorithm ?

It turns out the these messages contains many repeating unused fields with default values – these compress very well:

Enter gzip – On our platform Java’s GZipInputStream and for our clients tools the .NET GZipStream.

How did this work out ?

raw_size    comp_size   Compression %
------------------------------------------
3975        393         90.1    
10599       484         95.4

How much disk storage and SAN space and upgrades were saved Priceless.

I had the opportunity recently to visit one of our OLS.Switch customer’s retail locations. This particular customer doesn’t have a presence in the region that I work in, so I was very excited to Swipe my Card.  Probably too excited, actually, because I think I explained every line of the receipt, including the myriad of transactions that occurred, the number of message formats, transaction types, database entities, application logic, and network connections to various internal and external endpoints to my wife, who after twenty minutes didn’t share the same level of enthusiasm that I maintained throughout the conversation.

It is always fun to know what happens “inside the box” and that which seems magical to others. When I started my career at a small Third party processor this exercise was quite common, after we did system maintenance in the middle of the early morning, we would drive to the nearest corner store or gas station to test our issuing systems and connections via performing transactions on cards that we issued for.  We even got to reward ourselves with transaction amounts over $25, as we couldn’t allow Stand-In-Processing to approve these transactions, we wanted to ensure that our Issuing system authorized these transactions.

It is even more exciting to have taken part in the design, development and implementation of a given transaction. The exhilaration continues when you realize that I’m only 1 of about 5 million transactions per day that our software powers here.

Let’s do a walkthrough of the transaction that I performed:

Cashier:  Hi, Welcome. Are you enrolled in our ________ rewards program ?

Me: Yes, I don’t have my card – can you lookup by phone number ? 

Cashier:  Sure  <Enters in number that I provide>

Transaction #1 : Loyalty Card Lookup based on Phone Number also includes my point balance, level

Cashier: Can you confirm your address ?,great, that’s you. Your total is $ xx.xx , Debit or Credit ?

Me:  <Swipes my Mastercard >

Transaction #2 : Transaction Market Basket Analysis, Discount calculation, interfacing to an Offering Engine, Serializing of Coupons to print on receipt for future usage and coupon validation requests.

Transaction #3 : Credit Card Authorization

Cashier: Thank you very much for shopping at _______, By using your _________ card you saved $ x.xx, Hope you have a nice day.

Me: Thank you and running outside to share the exiting world of transaction processing to my wife.

The 20 mintues that followed including me discussing the following.

• The finer points of Loyalty Card Lookups, including how to return a list of cards, and how to address multiple requests as the cashier scrolls to fetch the next batch of card numbers for folks with common names, the challenges of either cardholders or cashiers using common phone numbers.
• Card Type and BIN Based Routing to external endpoints and message translation from one interface to another
• Sending large transaction requests with detailed shopping cart detail.
• Algorithms to generate coupon numbers that are difficult to be abused by coupon generation scripts.
• Substitution logic and the template engine to display various messages and transaction variable on to cashier receipts.
• The various batch jobs and processes that are ran to import, extract various data to support the processes.

Just another day in the life of payment application software developer.

We performed load testing a of new application with a client recently and a recurring question repeatedly came up: “How long was the transaction in OLS.Switch and how long was it at the endpoint ?”

It is an important question – one that is used to monitor application performance as well as to assist in troubleshooting purposes – and one we can clearly answer – the transaction took – a total of 5.6 seconds – and we waited up to our configured endpoint timeout of 5 seconds before we timed-out the transaction. Or – the transaction took 156 ms – 26 ms of those against a local response simulator.

In our application we use a profiler to trace execution time of each of our Transaction Participants: In which we see in our application logs as:

A normal transaction:

  open [0/0]
  parse-request [7/7]
  create-*******-tranlog [9/16]
  populate-********-tranlog [1/17]
  validate-********* [42/59]
  validate-********* [1/60]
  validate-******** [0/60]
  create-*********-request [24/84]
  query-****** [26/110]
  prepare-**********-response [40/150]
  close [6/156]
  send-response [0/156]
  end [157/157]

A timed-out transaction:

  open [2/2]
  parse-request [23/25]
  create-*******-tranlog [91/116]
  populate-*******-tranlog [1/117]
  validate-******* [67/184]
  validate-*******-card [31/215]
  validate-************** [1/216]
  create-********-request [32/248]
  query-******* [5000/5248]
  prepare-***********-response [67/5315]
  close [284/5599]
  send-response [0/5599]
  end [5600/5600]

(* note these traces are from a test app running on my macbook and are for illustrative purposes only *)

While we can answer the question by reviewing application logs – it is harder to perform any analysis on a series of transactions, specifically for external duration. We can do currently for total duration, however – this is valuable from the device perspective for how long a transaction took to process.

Logging the external duration along with our total duration for switched-out transactions and we now have:

Just a short note to share that OLS has received word from our QSA via a “PCI Certificate of Validation” Letter for our newly launched hosted payment service offering OLS.Host.

Congrats to our Operations, Systems and Security Gurus for all of their hard work on this !

The TR-39 Audit Procedures state that ISO 9564–1 Format 0 (ISO-0) and Format 3 (ISO-3) are the only approved formats:

4.1.3 X9 Approved PIN Block Formats

Documented procedures exist and are followed that ensure any cleartext PIN-block format combined with a PIN encryption process has the characteristic that, for different accounts, encryption of the same PIN value under a given encryption key does not predictably produce the same encrypted result. (Note: any cleartext PIN block, formats 0 and 3 meet this requirement, as specified in X9.8-1).

Reference X9.8-1 – Sec. 4(c), Sec. 6.2, Sec. 8.3.1, Sec.8.3.2, and Sec. 8.3.5

In case you are curious here are Visa’s PIN Security Requirements

Requirement 3:

For online interchange transactions, PINs are only encrypted using ISO 9564–1 PIN block formats 0, 1 or 3. Format 2 must be used for PINs that are submitted from the IC card reader to the IC card. Other ISO approved formats may be used.

This requirement further states:

PINs enciphered using ISO format 0 or ISO format 3 must not be translated into any other PIN block format other than ISO format 0 or ISO format 3. PINs enciphered using ISO format 1 may be translated into ISO format 0 or ISO format 3, but must not be translated back into ISO format 1.

(This last paragraph addresses an attack on Pin Blocks that can be translated in to format 1 on a HSM which would expose the clear PIN)

Let’s take a look at a few Pin Block formats:

For our examples:

P – PIN Number

F – Hex 0xF

A- Last 12 digits of PAN not including check digit

R – Random Hex Character (0-9, A-F)

Let us use the account number 4111111111111111 and PIN Number 1234 (examples use a PIN Length of 4 but could be 4-12 digits)

“Pin Pad” format or IBM 3624

PPPP FFFF FFFF FFFF

our Pin Block

1234 FFFF FFFF FFFF

Notes: Not allowed and is an old legacy method – not approved to be used.

ISO-0

04PP PPFF FFFF FFFF   (0 = ISO-0 Format, 4 = length of PIN)

XOR with

0000 AAAA AAAA AAAA (Formatted PAN)

our Pin Block:

0412 34FF FFFF FFFF

XOR

0000 1111 1111 1111

=

0412 25EE EEEE EEEE

Notes: Introduces variability in the PIN block by XOR’ing with a Formatted PAN – Best practice is to use ISO-3 instead of ISO-0 as there are attacks against ISO-0

ISO-1

1412 34RR RRRR RRRR (1 = ISO-0 Format, 4 = length of PIN)

our Pin Block:

1412 348D 665A C5A3

Notes: Introduces variability in the PIN block by using Random padding chars – Best practice is not to allow HSM’s to accept or use this PIN Block format. Not allowed by TR-39 but is VISA.

ISO-3

34PP PPRR RRRR RRRR (3 = ISO-3 Format, 4 = length of PIN)

XOR with

0000 AAAA AAAA AAAA (Formatted PAN)

our Pin Block:

3412 34C8 CBA4 285C

XOR

0000 1111 1111 1111

=

3412 25D9 dAB5 394D

Notes: Introduces variability in the PIN block by using Random padding chars and  by XOR’ing with a Formatted PAN – Best practice is to use this format.