Apathy

If you read about attacks that occurred last December on retailer point of sale equipment one point becomes quite clear, the attacks are not against the retailer, the attacks are against their customers. More precisely the attacks are against the customer’s financial institutions because they are liable for the losses. If I write a check (which I haven’t done for many years) I give the payee more than access to my demand deposit account; I give the payee critical data that they can use to rob me. If I write a check to a retailer and they put it in a drawer, and someone comes and copies it and every other check in the same drawer, then puts them back in the drawer, the retailer would never notice. When those data form the basis for a series of attacks against the retailer customers, no one may realize the point of origin of the attack, and if the origin is determined, the retailer still is not liable since they put the data in a locked drawer and otherwise handled them according to best business practices. Unless the attacks become widespread, the retailers will not worry about a future attack, nor change their practices of handling checks, and generally not concern themselves with the handling of vulnerable financial data. This apathetic response is alive and well and resident in big box retailers near you.

A point of sale (POS) device connects to an electronic cash register (ECR) through a physical port. Internally that ECR port has a buffer where the POS data goes and an interrupt vector with the address of the application that will pick up the data and process it. This buffer is a RAM address. An attacking program then needs to use either the address of the buffer, the address of the application handling the buffer, or the address of the port where the application processing the data places the processed data. The three addresses coupled with assembler instructions to move the data should only occur within the appropriate drivers (terminate and stay resident applications) and if they occur anywhere else in a program segment resident within the processing environment then clearly those exact assembler instructions show an attacking scraper.

 I am not describing anything new. Yet, the payment services industry continually lament the attack on payment data, know that retailers will be apathetic about the attack on payment data (because it only hurts their bottom line if they change their practices), and instead of protecting the vulnerable temporary holding areas, add increased protections to the tokens originating the data.

Why then force retailers to buy expensive new equipment? Good salesmanship, because it has nothing whatsoever to do with logic. What will happen this coming December? New scraper attacks will dominate the headlines, screaming banshees will claim the attacks occur because of the originating token, and then everything will settle back to normal and the most apathetic industry in the world will do absolutely nothing except collect fees for twiddling their collective thumbs. 

Next Blog: Lean and mean payment origination machines in web sites