Jaime from The Merchant Account Blog writes:

Lately I’ve been hearing reports of processors that are starting to charge their customers $15 per month for not being PCI compliant. To fix this problem, these processors are requiring their customers to install some PC based scanning software that is supposed to magically make the business PCI compliant, thereby allowing them to avoid the monthly charge.

Let me start out by saying: This is a bunch of crap!

There is nothing that you can just put on your PC that will make your business PCI compliant. This is so far off course that it hardly can be related to PCI. PCI compliance is in reference to networks, computers, hardware and software that play a part in the processing, storage, or transfer of a credit card transaction.

Check out the rest of the post here: Forcing Software for PCI Compliance
Unbelievable. I don’t think I could of put it any better myself and really hits on the theme that a product (even if it is PABP or PA-DSS certified), or PCI Scan, or any other service, CANNOT make you PCI compliant — I have a blog post brewing on this very theme.

If you read the PCI standards carefully and hang out with PCI geeks here or here you will notice that PCI applies to post-auth data and not necessarily pre-authorization data. — I think the official language is “subsequent to the authorization”

On May 1st, a payment processor modified their message formats as a part of their PCI compliance to not send Field 35 in SAF Advice transactions and would just send the PAN in field 2 and Expiration Date in field 14, instead of DE 35.

Also, from a forum post from “andrewj”

Another update on this (if you are from Australia) - there is a change being made to AS2805.2 to change the track 2 field from mandatory to optional in 04×0 messages. This should be released sometime this month.

This is a good trend in the industry, hopefully others will take this example and continue to trend.

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.

If an attacker acquires the database or database records AND you store a truncated cardnumber and an non-salted hashed accountnumber (which is a pci compliant approach, BTW) it take ~3 minutes per card to acquire the plaintext value and generated ~ 9MB file

Hashed account numbers are typically stored to assist in the lookup of card’s in the database, the quering application would calculate a hash on the accountnumber and query that hash to find the related transactions without using the account number.

Let’s use the following test card as an example:

4111111111111111

This would be stored or displayed as:

411111______1111

I wrote a small program that iterates through the missing digits, calculating the checksum (Luhn), and then calculating the MD5, SHA1 and SHA-256 hashes and stores it in a file, This program took approx 3 minutes to run per truncated card:

You would typically see a data record that would look like this:

Masked Account Number
411111______1111

Hashed Account Number(*)
68BFB396F35AF3876FC509665B3DC23A0930AAB1

Encrytped Card Number(**)
4888e25d9d01532e343dd261cbcebc91ccb17d029496b8c5

(*) #SHA1 hash of 4111111111111111
(**) 3des of 4111111111111111 with “forum.aegenis.com” as the key

With my program:

dbergert@debian:~$ bin/bruteforce.bsh 411111______1111

.. takes ~ 3 minutes to run

dbergert@debian:~$ grep “68BFB396F35AF3876FC509665B3DC23A0930AAB1″ bruteforce.txt

4111111111111111,5910F4EA0062A0E29AFD3DCCC741E3CE, 68BFB396F35AF3876FC509665B3DC23A0930AAB1,9BBEF1947 6623CA56C17DA75FD57734DBF82530686043A6E491C6D71BEF E8F6E

I guess the key lesson to use salted hashes, and just because you can show the first six and last four, if you don’t have a business need, only show the first for card type and last four. (which would only add required time to this process…)

*** Please don’t email me for the code, you are not getting it.

Update: Just for fun I calcuatlated how long it would take to bruteforce if you only stored the first digit and last four. i.e. — 4____________1111

You are looking at it taking a single processor 347 days, with a file that is is 1.47 terabytes in size, but remember that this only needs to be calculated once and that the timing can further be reduced by using well known BIN’s,

From reducing what numbers are displayed from 10 to 5, changes the timing from 3 minutes to 347 days.

I wonder when we will see longer account numbers.