Heartland Payment Systems Breach


EDIT: See my on personal thoughts here.

EDIT: check the comments from Joshua Nieuwsma at the bottom of this Wired Blog Post - Appears to be a Heartland Employee defending and providing some commentary on this situation.

EDIT: more detail at Security Fix : Payment Processor Breach May Be Largest Ever

A data breach last year at Princeton, N.J., payment processor Heartland Payment Systems may have led to the theft of more than 100 million credit and debit card accounts, the company said today.


… it wasn’t until last week that investigators uncovered the source of the breach: A piece of malicious software planted on the company’s payment processing network that recorded payment card data as it was being sent for processing to Heartland by thousands of the company’s retail clients.

The data stolen includes the digital information encoded onto the magnetic stripe built into the backs of credit and debit cards. Armed with this data, thieves can fashion counterfeit credit cards by imprinting the same stolen information onto fabricated cards.


I saw this “Heartland uncovers malicious software” Press Release: Some relevant paragraphs snagged:

“We found evidence of an intrusion last week and immediately notified federal law enforcement officials as well as the card brands,” said Robert H.B. Baldwin, Jr., Heartland’s president and chief financial officer. “We understand that this incident may be the result of a widespread global cyber fraud operation, and we are cooperating closely with the United States Secret Service and Department of Justice.”

No merchant data or cardholder Social Security numbers, unencrypted personal identification numbers (PIN), addresses or telephone numbers were involved in the breach. Nor were any of Heartland’s check management systems; Canadian, payroll, campus solutions or micropayments operations; Give Something Back Network; or the recently acquired Network Services and Chockstone processing platforms.


Heartland has created a website - www.2008breach.com - to provide information about this incident and advises cardholders to examine their monthly statements closely and report any suspicious activity to their card issuers. Cardholders are not responsible for unauthorized fraudulent charges made by third parties.

I met the CSO (Chief Security Officer) of Heartland Payment Systems at a Society of Payment Security Professionals - CPISM/A Training Boot Camp in late 2008. I have to say that I was pretty impressed with his knowledge of the Payment Industry, and his more related to this security posture and knowledge of PCI.

What does this mean to you ? If you are a cardholder that shopped at a merchant that HPS was the processor for(you wont know this, unless the merchant contacts you) you need to monitor your statements for fraudulent unauthorized activity. If you are merchant then you need to contract HPS if they haven’t contacted your already. The good news is that HPS was PCI Compliant - let this serve as an example that PCI Compliance does not prevent breaches, and that Compliance is a snapshot in time, Compliance != Security, and Security is a process.

But although this statement:

“After being alerted by Visa® and MasterCard® of suspicious activity surrounding processed card transactions, Heartland enlisted the help of several forensic auditors to conduct a thorough investigation into the matter. Last week, the investigation uncovered malicious software that compromised data that crossed Heartland’s network.”

Suggests that account numbers were compromised and used to be alerted by Visa and MC.

However, I applaud HPS for alerting the public via a Press Release as well as to create a website for more information. However, I do like others, question the timing the the release.

Also: In case you are wondering if Heartland was PCI Compliant: Listed by Visa as PCI compliant April 30/2008 by QSA Trustwave :

1-20-2009 2-01-18 PM

OLS.Switch on PA-DSS Validated Payment Applications List

A while ago I wrote this post: PA-DSS Validated Applications Published. Where I noted that our software application was on a PABP List but not on the PA-DSS List. Well we made it - it took the PCI Co a while to invoice us for inclusion on the list, but we received the invoice and promptly paid, and here we are:


* Well other then the “Validated by PA-QSA” is currently incorrect: we used K3DES.

Link to PA-DSS Validated Payment Applications:


Link to PABP Validated Payment Applications:


PA-DSS Validated Applications Published

I read that the PA-DSS Validated Application List has been published by the PCI Council. This is expected as PABP is now know as PA-DSS and the PCI Council is taking ownership of the program.The PA-DSS List of Validated Applications is viewable here:

We are Visa PABP compliant, ( see the VISA PABP List and screen capture below ) but I am a little disappointed in the PCI Council, because we are not listed on that list… looks like it is time to make a few phone calls to see why and rectify the issue. I know the the PCI Council now grants us the opportunity to pay $1250 a year to be listed, but we have not received any communication or such invoice from the PCI Council.

I’ve also asked our auditor and received this reply:

“You are not the only one to be affected by this. When I looked at the list, there were only 85 applications listed out of the many hundreds that were listed on the Visa PABP site. So it appears to me that the PCI SSC has not completed their migration”


LastPass.com asks to store CVV2 code for Automatic Form Filling

I’ve been enjoying LastPass for generating and secure storing and synchronization of passwords between web browsers and my machines. LastPass also has a feature called Automatic Form Filling, I was a little surprised when I saw a spot to store the following information:

Look at the “Credit Card Number” Section:

12-2-2008 8-28-50 AM

Notice the spot for Security Code ? PCI considers the Security Code (CAV2,CVC2,CVV2,CID) Sensitive Authentication Data, and does not permit the storage of Sensitive Authentication Data, even if it is encrypted. This is PCI DSS requirement 3.2: also see this “PCI Data Storage Do’s and Don’ts”

So if a user enters in their Security Code and saves it in their “Form Fill Profile” the encrypted Security Code in stored in encrypted format on your computer (when you log-in to Lastpass.com), the LastPass.com servers and Amazon S3 (where LastPass stores its backups). [1] Interesting.

I’ve decided that I can type in my Social Security Number, Credit Card Number, Exp Date and Security on the websites that I frequent :) (Actually the main card number that I use for e-commerce sites I have memorized anyway.

It should also be noted that PCI 3.2 language states “Do not Store sensitive authentication data after authorization (even if encrypted) — With LastPass.com it acts more like a password manager or eWallet, and does not participate in the authorization process - Also the information in the user’s account is solely the cardholder’s.

[1] https://lastpass.com/technology.php

CPISM Study Guide

CPISMdummiesIn preparation for the CPISM certification, I spent about 3 hours a few weeks ago going through the May 2008 CPISM Study Guide and created files of the material referenced in the CPISM Study Guide in pdf form.

Here is a link to the CPISM Study Guide Materials [~20 MB]

You can read more about the CPISM here.

A PABP compliance press release that raises some concerns...

While scanning though my RSS feeds this morning (Which I have neglected in the past few weeks), I ran into a PABP product release. Let me just include the relevant portions here and not list the company name.

___ is a PCI PABP v1.4 (Payment Application Best Practices) validated payment application, Visa USA accepted ___ as validated based on the review by Trustwave, a well known QSR. ___ runs on Windows 98 through Windows Vista and supports _____.

Two things that struck me.

  • Trustwave is a QSA ( actually PA-QSA in this role) not a QSR - (Quick Service Restaurant ? )
  • Windows 98 ? Windows 98 is not secure, and is at End-of-Life (July 2006), does not receive new security patches, and is not something that I would recommend to anyone implementing a new payment application.

How can a a payment application be PABP compliant on an non-secure, not supported, EOL’ed OS ? Interesting….

IIA GAIT-R to Scope PCI Compliance

I was at my local chapter meetings of a combined ISACA and IIA group. The topic of the meeting was The Institute of Internal Auditors GTAG and GAIT programs that was presented by Hussain Hasan -of RSM McGladrey, Inc., who is also a member for the IIA’s Advanced Technology Committee.

Hussain pointed me to a case study on using GAIT for Business and IT Risk or GAIT-R to assist in with scope of PCI Compliance.

The GAIT-R methodology comprises eight steps:

  1. Identify the business process and objectives for which the controls are to be assessed.
  2. Identify the key business controls required to provide reasonable assurance that the business objectives will be achieved.
  3. Identify the critical IT functionality relied upon, from among the key business controls.
  4. Identify the significant applications where ITGCs need to be tested.
  5. Identify ITGC process risks and related control objectives.
  6. Identify the key ITGCs to test that address identified risk and related control objectives.
  7. Perform a reasonable person holistic review of all key controls.
  8. Determine the scope of the review and build an appropriate design and effectiveness testing program

Here are the two Case Studies of Using GAIT-R to Scope PCI Compliance.

Why is your company storing credit card numbers?

Martin writes a great post titled: Why is your company storing credit card numbers?

Many of the merchants I’ve dealt with keep everything and I do mean everything. I’ve run into systems that have card numbers in their databases that date back to the first time they opened up an e-commerce site in the late 80’s. The majority of the card numbers in these systems have long since expired, but the merchant steadfastly refuses to purge any of the data ‘just in case it might be useful some day’. In most cases, they don’t actually use the stored credit card numbers in any way, shape or form, but they feel the need to have the data just to have the data. After all, we all know data is valuable, and what’s more valuable than a potential customer’s credit card number?

I have had similar experiences as well, even more so on the development side where “log everything” you never know when you will need it” was the mentality – you should be able to see why this is a problem.

What Martin writes about is something that you *should* be doing anyway per PCI 3.1 – If you look at the testing procedures however, there is no test to tie the retention period documented in the policies to the actually data that is retained.

10-14-2008 2-13-56 PM

PCI DSS 1.2 (PCI Data Security Standard) released today

pcilogoPCI DSS version 1.2 was released today, I blogged a little about the changes based upon a earlier PCI 1.2 summary document here and rather then duplicate the excellent work of others, I’ll point you to Mike over at www.pcianswers.com who does a great breakdown on the changes between PCI DSS version 1.1 and PCI DSS version 1.2 audit procedures.

From the PCI SSC Press release on PCI 1.2:

This latest version is the culmination of two years of feedback and suggestions from its industry stakeholders and is designed to clarify and ease implementation of the foremost standard for cardholder account security. Version 1.2 is effective immediately and version 1.1 of the standard will sunset on Dec. 31, 2008.

Go read the changes here.

ATM reprogramming arrests.

tranax-1500 I guess it has been almost two years now, that a news story and security researcher blog post, pointed out a vulnerability in certain types of ATM Machines. The vulnerability relates to “PCI requirement #2 - Do not use vendor-supplied defaults for system passwords and other security parameters” with a few brands of ATM machines ( generally the smaller standalone ATM’s you see in convenience stores and sold by ATM ISO’s and their agents ) whose service manuals were accessible online, and ATM operators failing to setup the ATM’s in a secure manner. I remember googling and finding the default passwords and instructions for these. With the service manual and passwords, a person was able to reprogram the value of the ATM cassettes. telling the ATM Machine that the $5 cassettes had $20’s and doing a withdrawal

Today - Wired notes that the first bust for ATM Reprogramming Scan netted its first two arrests.

It took a high-speed chase and some gunplay, but two men in Lincoln, Nebraska, are the first to face felony charges for using default passcodes to reprogram retail cash machines to dispense free money.

Jordan Eske and Nicolas Foster, both 21, are in Lancaster County Jail pending an October 1st arraignment. They’re each charged with four counts of theft by deception, and one count of computer fraud, for allegedly pulling cash from privately owned ATMs at four stores in the area. The pair allegedly reprogrammed the machines to believe they were loaded with one-dollar bills instead of tens and twenties. A withdrawal of $20 would thus net $380.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now