Dave & Busters (aka Chuck e Cheese for adults and with adult beverages) appears to be the latest in news stories of Data Breaches including magnetic stripe and track 2 data.
From Wired “International Hackers Indicted for Sniffing Credit Cards from Dave & Busters”

“The government said the Dave & Buster’s hackers illegally accessed 11 of the national chain’s servers and installed packet sniffers at each location. The sniffers vacuumed up “Track 2″ data from the credit card magstripes as it traveled from the restaurant’s servers to Dave & Buster’s headquarters in Dallas, according to the indictment.”

In my post titled, “Encrypted Traffic from within the PCI Zone” I discuss that we have adapted OLS.Switch’s point-of-sale (POS) TCP/IP interface to accept POS payment messages across the store’s PCI Zone (Protected network zone where CC Data would transverse) but include an encrypted account number field or data element instead of the clear text PAN (Primary Account Number), in the PAN field.  So this would act as a deterrent to network sniffing

That being said — it appears that there was a lack of montioring or mis-configuration or lax physical security around the POS, wiring closet, and network cable runs.

Again: 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.

BTW, Dave & Busters does have a pretty cool private stored value system and game card that you place in their games inorder to play and reload to play more.

EDIT:  CIO has an article here:   This is probably the best quote from the article.

Unfortunately for the criminals, Gonzalez’s code had some problems

In April 2007 it bombed its first test, on a point-of-sale server at the Dave & Buster’s in Arundel, Maryland. “The packet sniffer malfunctioned … and no credit or debit card account information was captured, ” Lynch said.

Even when the packet sniffer worked, the hackers were forced to keep returning to the Dave & Buster’s network and restarting their malicious software, Lynch said. A bug in the packet sniffer caused it to shut down whenever the computer it was monitoring rebooted.

As a financial payment switch and switch vendor, we need to be agile, adaptable and expandable to support different formats that are required by our customers. See The New Normal - for one of our more complex acquirer side integrations.

One of these initiatives consisted of developing an interface to switch incoming MethCheck Pseudoephedrine Inquiry transactions from the Point-of-Sale to OLS.Switch, and then switched out to another end-point for further processing.

While most message formats in the payment space follow the ISO-8583 standard, we do have many end-points that we need to interface with that are either fixed length or variable length, we call these FSD messages. In the MethCheck implementation we used a FSD based message format for request and response messages. Our role here was to pass a customer defined buffer from the POS system to the end-point, though our switch and pass a response buffer back to the POS system

FSD Request

<schema>
<field id="header" type="K" length="7">OLSMETH</field>
<field id="0" type="N" length="2">    <!--tran type -->
<field id="41" type="A" length="5">    <!--store number -->
<field id="46" type="N" length="19">   <!--tran id -->
<field id="meth-trans-info" type="AFS" length="452">
</schema>

FSD Response

<?xml version="1.0" encoding="UTF-8"?>
<schema>
<field id="header"             type="K" length="7" >OLSMETH</field>
<field id="0"                  type="N" length="2" /> <!--tran type -->
<field id="41"                 type="A" length="5" />  <!--store number-->
<field id="46"                 type="N" length="19" /> <!--tran id-->
<field id="39"                 type="A" length="2"/>    <!-- Result Code-->
<field id="meth-trans-reply"    type="AFS" length="255" />
</schema>

We have a very easy way of creating and populating these messages.

FSDMsg fsd = new FSDMsg ("file:cfg/meth-");
        FSDMsg msg = (FSDMsg) ctx.tget (REQUEST);

        fsd.set ("0", msg.get("transaction-code"));
        String storeNumber = msg.get ("store-number");
        fsd.set ("41", storeNumber);

        TranLog tranLog = (TranLog) ctx.tget (TRANLOG);
        if (tranLog != null) {
           fsd.set ("46", ISOUtil.zeropad (Long.toString(tranLog.getId().longValue()), 19 ));
        }

        StringBuffer sb = new StringBuffer();
        sb.append (msg.get ("register-logon-nbr"));
        sb.append (msg.get ("meth-entry-mode"));
        sb.append (msg.get ("meth-id-format"));
        sb.append (msg.get ("meth-id-data"));
        sb.append (RS);
        sb.append (msg.get ("meth-person-info"));
        sb.append (RS);
        fsd.set ("meth-trans-info", sb.toString());

In less then a week’s time in development (testing and user acceptance testing will take longer) - we were able to add an interface to our switch to handle this non-payment transaction type.

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!!!