Security and Payment Hubs

Security is a broad generic term and I need to define my usage of it here in this blog. Security means (for the purposes of this blog) detection and prevention of the intercept of banking data. I define the term only for electronic movement of money.  Banking data means accounts and associated routing numbers to those accounts or substitutions (mappings) for accounts and associated data. 

Data typically associated with security such as personal identification numbers, personal information, and other data used for identity protection are not the subject of this blog because these types of data need validation and verification outside the flow of payment information.

If my faithful reader(s) recall(s) the interface between a payment application (software resident on any device with a processor able to execute the software) and a point of presence (POP) for a SVGRTP then diagram 5 shows just the pertinent part of early diagrams except the destination POP fronts a payment hub not a SVGRTP.

Diagram 5: Payment App and POP interface

Diagram 5 shows no transmission of banking data to the payment hub. However, if the same data shows up at the POP ordering a push of the amount from the account associated with the device number to an account associated with the payee number,  then an attacker does not need the banking data, interception of  substitute data suffices to commit a theft.

The purpose of removing account data from the initiating command is not to prevent identity theft; it is to prevent the intercept of bank account data, exactly as I defined security at the beginning of this article.  By placing the verification of identity at the payment application level and not at the payment hub level we remove a one size fits all approach to electronic payments and allow consumers to pay for the security they need when accessing various sized payment hubs.  Diversity of security approaches also hampers professional ne’er-do-wells. Yet transmission of information from a device to a POP requires a minimum level of security to protect the data, and prevent unauthorized access to the POP. At a minimum then (in my view, and I am not claiming to be a security analyst, so I hope I have dissent), the POP validates the device, the device validates the POP, the device sends one encrypted message, and tears down the circuit. Notification of results goes to the POP that then delivers result notifications to addresses registered with the bank account data.

I have met some amazing professional security analysts over the years and they know all the tricks down to the nodes on a chip card. And yet cold analytic reasoning on risks and vulnerabilities accompanied with statistics, false positives, false negatives, and attack history, lacks a key ingredient. There are two questions needed to approach security, one quite rightly is how to prevent an intercept by detecting it, but the other approach, how I can intercept the data to commit a theft, remains the road very much less traveled.

So, I thought it might entertain my dear reader(s) to look at the universe of payment hubs and see it as a group of potential targets, not as potential vulnerability. Figure 6 shows payment hubs as I imagine a thief might see them.

Figure 6: Payment Hubs as Targets

A budget is primary element for a thief and certainly there is likely a relationship between the size of the thief’s budget and the size of the transaction flow between payment hubs.  If that is true, and I sincerely hope it is true, then just like the rest of society there are only a few whale thieves in the cyber ocean.

I am going to state an equation that shows my understanding of the relationship between a thief’s budget and transaction flow. Before writing such an equation that rips humanity from individuals, let me state that if these types of equations work at all, they only work on aggregate human behavior such as military units, or sociological categories, and are still suspect.

Leaving the thorny problem of determinism alone let there be a fixed sum B_T (Thief’s budget) that is a dollar value equal to the highest minimum amount for a successful attack, the flow itself (T_F )_, and C equal to the cost of an efficient detection system. (Examples of efficient detection systems abound see for example:  Philip K. Chan, Florida Institute of Technology, Wei Fan, Andreas L. Prodromidis, and Salvatore J. Stolfo, Columbia University; “Distributed Data Mining in Credit Card Fraud Detection”; (November, 1999) http://cs.fit.edu/~pkc/papers/ieee-is99.pdf; or for an opposing view:  Clifton Phua, Vincent Lee , Kate Smith, Ross Gayler ; “A Comprehensive Survey of Data Mining-based Fraud Detection Research” (November, 2007) http://arxiv.org/ftp/arxiv/papers/1009/1009.6119.pdf).

Then:

B_T  ≥ C/T_F at an instant of time, t, for a successful attack.  

Thus if T_{F =} $1.00/sec the thief’s budget must exceed the cost, say $1.00 at time t, and the thief’s budget must be greater than or equal to $1 multiplied by the entire time of the attack (including planning stages).

It is a hypothesis with absolutely no data to confirm it, and there likely never will be such evidence unless we can get a hold of a statistically valid sample of thieves’ budgets and pry bank fraud data from banks ( to the wag muttering under your breath, they are indeed separate things). I press on, undaunted by lack of facts.

 

Let C = P*(ʃ T_F) where P ≤ .1 (and preferably a lot less)

If C is greater than the fraud suffered by a payment hub, then clearly it is a waste of money, so if F is the dollar value of successful attacks over a set period of time C ideally has bounds namely:

B_T  ≤ C ≤ F at any instant of time, t.

Note that F increases with each successful attack.

Armed with a budget and looking at the seams between payment hubs, non-whale thieves will target transaction flows that have lower value T_F but with a high throughput (high number of transactions regardless of value). If thieves need to make two separate attacks, one to intercept bank data or substitute bank data, and another attack to intercept user validation data, then the thief’s budget must increase but the cost for defense of bank data remains the same.

By insisting on having two way traffic (requests and responses) using third parties without a reason to gain access to bank account data, the payment system providers recklessly create unnecessary risks for the entire payment infrastructure.  We have quite recently seen a myriad of successful attacks against moderate sized payment hubs, and instead of recognizing why these attacks succeeded, the payment system providers insist on keeping the request/response with banking data methodology in place and will continue to do so until successful attacks overwhelm the costs of security, and F (aggregate amounts of successful attacks) undermines the trust of electronic payments and consumers substitute less expensive means to conduct trade.

Next Blog: Analysis of the Target attack and payment industry response, or an alternate payment system model using current data