(April Fools) Tommorrow, April 1st, 2008 – Visa is expected to be sued today by the Federal Trade Commission for the loss of 990 million card numbers to an international crime ring known only as “C@rD_NO+_Pre$ent_anyMOR3” on non-English foreign language internet chat rooms as reported by the Payment Systems Blog and its Eastern European intrepreters.

“We thought that we were safe using 1970’s based technology and mainframe computers, They don’t even teach that in the schools nowadays,” states a Michael Verns, a former IBM systems programmer and night operator located in Foster City, CA. who requested anonymity and also wasn’t quite happy with his allotment of visa stock options which will force him to still work past his ideal retirement age, “I mean we don’t even get to use a mouse that much, but did state that he remembered when VisaNet bootstrap required card readers, and that while Visa DEX is pretty cool, but that is just a different front end to VisaNet.”

Martin McKeay, Security Expert and PCI auditor, speculated that nobody really knows if Visa or MasterCard are PCI compliant anyway, and he and Rich Mogull in the Network Security podcast Episode #100 suspects that “an un-patched vulnerability in the IBM hypervisor or Virtual Machine, called VM-CP running on IBM System/370, allowed state of the art malware to intercept or sniff SNA based network traffic and redirect it to a reel-to-reel tape library that wasn’t encrypted and was lost during transport to off-site storage. Jeff Hall, a Security Consultant, in a post in a PCI Forum writes — “Many people don’t know that there were Virtual Machines and Hypervisors way before VMware, System/370 and IMHO the wireshark project really should implement SNA network support so auditors can detect this type of thing in the future. Security of Virtualized systems should be covered in the next revison of PCI” (WireShark Project leaders are asking for hardware donations or instructions on how to setup http://www.hercules-390.org/ for development purposes, please help if you can)

These things can and do happen… and is why we dedicate ourseleves to the network security podcast”, state Martin and Rich, “It is simliar to the MacBook Air incident and CANSECWEST, everybody thought that OSX was secure, but we need to re-evaulate the security of all operating systems, regardless of how much market share they have.”

Security experts blame the amount of detail in Visa’s S-1 IPO filing, that provided enough detail for attacks to launch a directed attack. “They didn’t even need to do reconnaissance, it was all right there.”

Spokespersons from Visa, a publicly traded company (Quote: V) have stated that they are working with the Fed to structure a “deal” that would provide an infusion of capital for Visa to invest in a company to develop encryption software for its systems after it was decided that EBCDIC was not a reliable method to render card numbers unreadable, as well as to provide a vote of confindence in the world’s global payment networks. Investment gurus from www.bloggingstocks.com speculate that Credit Cards will be way worse than sub-prime will ever be.

Hans Morris, President of Visa states that “Remember that cardholders are not liable for any fraudulent charges and not to forget that Visa started both CISP (now PCI) and PABP and that Visa has been hacked less then the Pentagon”

Hillary Clinton has stated that under her administration PCI would become a federal initiative called – “Pay Cash Instead” and return the power to the people and away from greedy banks, and that the increased cash handling would be good economic stimulus and vechicle for job creation. Other economic experts state that compared to credit card balance tranfer mailings and card applications, the cost of re-issuing cards will not have a large impact on banks printing and postage expenese.

I will have more posts as this story develops.

According to this article Boston Globe Article: Advanced tactic targeted grocer.

A massive data breach at Hannaford Brothers Cos. was caused by a “new and sophisticated” method in which software was secretly installed on servers at every one of its grocery stores, the company told Massachusetts regulators this week.

The software was installed on computer servers at each of the roughly 300 stores operated by Hannaford and its partners. Hannaford did not say how the software might have been placed on so many servers, and company spokeswoman Carol Eleazer said the company continues to investigate how the software was installed and other specifics of the breach.

To me this raises a few questions. Where was File Integrity Monitoring (PCI 10.5.5) of the Store Servers ? Why didn’t this pick up any changes to the Store Servers ? Was it not monitored ? Was it not configured properly. Was the malware installed in a directory that wasn’t monitored by the File Integrity Monitoring software? How does software get installed on every one of its stores without detection. (Yes, that I understand that maybe no files where written to disk, and everything theoretical could done in memory – but the malware would have to run at higher privileges to sniff the network (exploit of an unpatched systems?) and there would need to be some type of outgoing network traffic (probably encrypted payloads to badguys sites.))

The data were taken “in transit for authorization from the point of sale,” the letter states, meaning as it was transmitted from the cash register to one of the institutions that Hannaford uses to process transactions. Eleazer said these include major card networks and First Data Corp. of Denver, a major processor.

When possible in OLS.Switch we don’t sent unencrypted card numbers in the message format from the POS to the switch , — from the switch to the endpoints (FDR, VISA DEX, MC Banknet) is a different story (as far as I know nothing other then a TCP/IP sockets when send data to the clear across a private network is supported. I would love to see channel encrypted tunnels here in the future. )

Just a quick post to list some help tools for detecting cardholder data on your systems, or tools to setup for ongoing controls to monitor for cardholder data.

1) ccsrch

ccsrch is a tool that searches for and identifies unencrypted and contiguous credit card numbers (PAN) and track data on windows and UNIX operating systems. It will also identify the location of the PAN data in the files and record MAC times

2) Senf: The Sensitive Number Finder

Senf is a fast, portable tool (written in Java, runnable just about everywhere) for finding sensitive numbers. Use this tool to identify files on your system that may have Social Security Numbers (SSNs) or Credit Card Numbers (CCNs).

3) Spider (Windows) (Linux)

Spider’s purpose is to identify files that may contain confidential data. It scans a collection of files, searching for patterns of numbers or letters that resemble Social Security numbers or credit card numbers (additional search patterns can be created using Unix regular expressions).

4) Tenable’s Ron Gula’s blog using Nessus to find Senstive Data:

Detecting Credit Cards, SSNs and other Sensitive Data at rest with Nessus

5) Snort - using the Bleeding EdgeEmerging Threat Snort rules, (see BLEEDING-EDGE Credit Card Number Detected ET POLICY Credit Card Number Detected in Clear) You might be using snort as and IDS – or using a product or appliance that uses it as its engine. This tool is also very handy to check for email that contains CC data as well. (EDIT: Bob writes to say the that Emerging Threats have replaced the Bleeding Edge project as it died. Thanks !)

6) Strings

http://unixhelp.ed.ac.uk/CGI/man-cgi?strings
or
http://www.microsoft.com/technet/sysinternals/miscellaneous/strings.mspx

using the parameter    Strings -n min-len

Let me know of others that are useful.

The first thing that typically happens with the design of PCI network configuration is that an inventory of all systems/processes involved in the storage, processing, or transmitting cardholder information is performed, and a network diagram that shows where these systems live is produced. The prevailing wisdom over the last few years has been to create a “PCI Zone” using network segmentation which is basically a separate network zone (QSA’s like to say VLAN ) where all of the cardholder systems are that has stateful firewalls and well defined firewall rules for both incoming and outgoing traffic. This is a very important scope reduction technique, that lets you focus on implementing the security controls that are mandated by PCI in the environment of the data and systems that need protection.

Within the PCI Zone – PCI requirements allow for non-encrypted card numbers to be sent across the internal network. (Requirement 4: Encrypt transmission of cardholder data across open, public networks )

I think Rich Mogull said it best: “Corporate networks are like candy bars: hard on the outside, soft and chewy on the inside,”. The PCI Zone is still soft and chewy in some regards.

There are some rumors and speculation that a PCI Compliant merchant, Hannaford supermarket chain’s POS system (like many other merchants) does not send encrypted data between the point of sale and the branch server.

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 wouldn’t be surprised that if in future revisions of the PCI DSS – traffic from POS systems on private networks will be required to be transport encrypted in a tunnel or require encrypted fields/data elements.

Also related to this subject: Dr. Neal Krawetz has a very good White Paper called Point-of-Sale Vulnerabilities. Read it!!!

Fail Secure – Is typically used to describe door locks. When the power is on: the door remains unlocked, if power goes out: the lock ‘Fails Secure’ and remains locked when the power is off.

Payment System should also Fail Secure

One of the things that some developers do is log data in exception cases; Hell, I’ve also seen the log everything-you-might-never-know-when-you-need-it mentality. (with some scary looking DB Schemas) (I’ve even seen payment systems in the past that logged raw request and raw responses by default for all transactions, and also logged un-parseable messages in an exception file, all of which included binary representations of the underlying message format – yes it was binary, and sometimes even EBCDIC – but opposed to some popular beliefs – this isn’t encryption, and contains data elements that are prohibited to retain, applications like these will most likely be listed on Visa’s vulnerable payment application list. (A list of vulnerable payment applications is updated quarterly and is available on Visa Online at www.us.visaonline.com/us_riskmgmt/cisp.)

There are many valid reasons for doing this: why did the exception occur, is it repeatable, is it a software bug, an invalid message that can’t be parsed properly? etcetera. This is all good and fine in test and development environments, but this is particularly a concern when dealing with payment systems that are involved in processing, storing and retaining cardholder data and with this same type of exception logic in production system in the real world.

There may even be business reasons and good intentions to do so: under an exception the cardholder may have been charged (especially a debit transaction) and if the database or storage system was down, or a response message may not be parseable, the payment system may not have any record of this transaction. The cardholder may try again or with another card – and then end up with double-charging the cardholder. But if the raw data is retained – then one can troubleshoot, and re-create the appropriate transaction, or any returns or reversal and handle the exception cases.

Payment System should also Fail Secure - On an exception scenario – make sure that you are not logging or retaining prohibited data. PCI/PABP does have provisions to allow for troubleshooting these types of problems, but the procedures and controls around enabling detailed troubleshooting must very strict and require minimal data, and have similar controls around it to include initiation, authorization, access control, montiroing, secure storage and secure disposal of when it is no longer required. The process should also not be enabled by default. Config files, database config tables, etc that are used to enabled detailed troubleshooting – should be monitored (File Integrity, DB content checks) to make sure that this functionality is off when not needed.

Payment systems contain cardholder information and must be handled differently then other applications. Make sure that you and and payment systems developers understand this as well.