I read an interesting analysis (during my morning RSS Grind) on Branden Williams blog – titled "PCI Compliant Companies Don’t Suffer Breaches"

There is a big misnomer out there that needs to be cleared up. [...] In our investigations of PCI related breaches, we have NEVER concluded that an affected company was compliant at the time of a breach. PCI Assessments are point-in-time and many companies struggle with keeping it going every day.

These leads us to the nuance between PCI compliance and PCI Validation – Mike Dahn does a great job here at this post:

Compliance vs Validation

There is a difference between ‘compliance’ and ‘validation’.  Compliance is a state of being, one that must be maintained at all times. Validation is a point-in-time check on that state of compliance.  The example I give is auto insurance.  In order to comply with state laws I must maintain auto insurance at all times.  When I go to register my car I have to show proof of insurance.  I am validating my compliance with the law.  What if I decide to cancel my insurance because it costs too much?  Am I still compliant?  No.  Now, I still validated, but remember validation is a point-in-time while compliance is measured day by day.

One of the first things that people asked when they heard about the latest cardholder breach, it was "weren’t they PCI complaint" ? If you look on the Visa List – you will note the validation date and QSA that performed the review.  It is important the understand the Validation Date – that was the last date of the review – that is a point in time where a QSA considered the organization it reviewed "compliant".

So how is this possible ?, Well an example that I can think of is brushing your teeth really well before going to the dentist, or how many companies fear auditors and get really busy before and audit because of the things they need to do because the auditors are coming ? Do people continue to brush their teeth with this vigor after the dentist visit ? perhaps they floss for a week or so, but behavior is hard to change and people go back to their normal routine. The focus of many organizations is on passing the audit.

I briefly touched on this point when I  blogged my thoughts on the Heartland Breach.

If you ever read through some of the actual audit procedures of PCI – notice what the auditors actually test: some tests are just based on Inquiry or documentation alone, furthermore some tests that do not test the operating effectiveness of some of these controls to a period of time.

The current focus is that on existence of a control and not its effectiveness.

Operating Effectiveness – that is defined as: "How an internal control was applied, the consistency with which it was applied, and by whom."    

Consistency -  Should the PCI council consider reviewing the audit procedures and testing procedures to test for consistent controls ?  Should PCI audits of large service providers or merchants require multiple visits by the QSA to test for this consistency ?  Would it even help ?

Another last thought: Do QSA’s and auditors cheat on 2nd and subsequent year follow-up reviews ? Well, they passed it last year… – does the Report on compliance (ROC) look similar to that of previous years ? Was the control still tested like it was in the first year ?  I guess some of this can be addressed (hopefully) in the PCI QSA QA program.

I agree with Branden that if one ever finds the real exploit that occurred at Heartland, it probably can be mapped ( even liberally squeezed ) to a current PCI control and is more then likely the result of a control breakdown and the controls poor operating effectiveness.

Two week ago I made of few predictions for Payment Systems in 2009 ( you can read that post here) Here are the two that I can cross off and pat myself on the back for.

Gift Cards: You or someone that you know will have a gift card, merchandise credit/refund card for a merchant that is no-longer is business in 2009. Gift givers will take note of this and consider giving cash rather then gift cards in holiday 2009 season.

From the Circuit City website: Circuit City would like to thank all of the customers who have shopped with us over the past 60 years. Unfortunately, we announced on January 16, 2009, that we are going out of business.

Will Circuit City stores continue to accept Circuit City GIFT CARDS?

Yes, customers holding Circuit City gift cards may redeem them at full
value at our stores during the liquidation sales. Once the stores are
closed and the company is out of business, the gift cards will have no
value.

PCI Data Security Breaches: There will be data breaches of cardholder data in 2009. We will see more innovative attacks that replace those that were effective before PCI compliance was a wide spread.  Even organizations that are validated "PCI Compliant" will not be exempt. We will see attacks that adapt and change around current PCI Controls.

I blogged about Heartland Payment Systems here and shared my thoughts on the situation here, Yes this breach was at a PCI Compliant and Validated service provider, and the attack appeared to be one that was sophisticated and adapted around the current PCI Controls.

You should all be aware of the Heartland Payment Systems Breach that happened on Inauguration day – had it been a different day it would be a front page story, perhaps it will be a front page story today? This post is to share my thoughts (that are speculation) based on my experience in payment systems and security rather than to re-hash the Heartland Press Release.

Let the pundits come: I can hear it now, "Was Heartland PCI Compliant ?" (They were/are btw, the QSA was Trustwave and they are listed as a compliant service provide dated April 30th, 2008) If they were PCI compliant how did a breach occur ? It is important to note (again, and again) that Compliance != Security. Compliance is a snapshot in time, PCI is not based on an organization’s own risk assessment of their environment. It is a prescriptive list of general IT Controls to be used as a baseline for "better" security then those organizations that are not compliant with the intent of reducing the risk of breaches. But you can be compliant and not secure, security is a process and constantly striving towards that end (it is like driving to infinity you never get there), is the goal, not compliance itself. I also expect to see merchants use this as an excuse — why are we spending all of this money for PCI complaint when attackers can successfully attack Processors anyway?

Processors and Service Providers are Fort Knox: Processors process for thousands of merchants and handle a large volume of transactions. Processors are in the business of processing card data, they require card numbers to communicate over the payment systems interchange networks as well as to provide settlement, clearing , and authorization files (among others) — The data of these files and message formats have account numbers, track data, cvv2 data (only the authorization messages include the last two) in the clear -but transmission is typically over a private leased line, use file level encryption, or transport level encryption, but there is a place in the "PCI-ZONE" of companies that sends this data in clear across the network – making sniffing the traffic a threat here. Can this be further controlled by further network segmentation and control at processors? I think so (topic of another post). Only the Payment Switch would need to have direct connections to these end-points not the full PCI-Zone.

Blame the QSA: Nobody has blamed the QSA yet, and I don’t know if anyone will, but I’m sure someone will try to; when breaches occur they are going to be asked what they missed ? What does that mean for QSA’s or IT auditors ? How do your work papers look ? Can a independent third party look at your work papers as evidence and come to the same conclusion as you? Did you test to the control or did you test something else ? Did you understand intent of the control ?

Issuing Banks: You don’t get to hear much of the story about the burden on Issuing Banks here. They have the cost of notifying cardholders, postage expense, customer service calls, brand perceptions problems due to confused customers, costs to reissue cards, etc. This includes both credit, debit, payroll, gift and others.

Press Release: Two things that got me about the Press Release, one was its timing, which may or may not be a coincidence, and the second was the focus was on the data that was not compromised, not the data that was. Like why not add: The cardholders’ favorite colors and cereals were also not compromised Account Numbers, Expiration Date and Track Data (Track 1 contains Name, Track 2 doesn’t) were compromised, cloned cards can be made from these "dumps" of magstripe data.

PCI Compliance: Remember that Service Providers and Processors where the very first to be scrutinized under Visa’s CISP and MasterCard’s SDP programs, and later PCI. The truth is that many processors and gateways should have close to 5 years or so of experience with PCI compliance and reviews if they are not a new service provider. Also: If you ever read through some of the actual audit procedures of PCI – notice what the auditors actually test: some tests are just based on Inquiry or documentation alone, furthermore some tests that do not test the operating effectiveness of some of these controls to a period of time.

Cost of the Breach: Anything that you hear is a guess – nobody knows for sure– (Well the card brands and affected issuers probably will) – we know that Heartland does 100 million in volume a month, and can safely assume that data was sniffed for a few months (some reports it as in place as early as May 2008) — we don’t know the unique number of card numbers nor do we know which card numbers are affected. I would guess around $600 million – based on cost of record at ~$6.00 and assuming 100 million unique card numbers were affected.

How did it Happen: Let’s look at the PR:

" 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."

There really isn’t enough information here but let’s make an educated guess: We know that malware/software was installed. So we have the threat of physical security/social engineering that would install a piece of software, an OS or Application level attack, or a targeted piece of malware that was installed in the PCI Zone accidentally. Perhaps a combination of some of these. This type of Malware (sniffers) requires administrator system or root level access in order to sniff network traffic in promiscuous mode (in most cases.) There are ways to flood network switches to make them act as a hub to broadcast traffic, and there are also VLAN hopping attacks.

PCI 1.2.1 / 1.3.5

Let’s look at PCI 1.2.1:

"Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment"

and PCI 1.3.5

"Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ"

So the data would need to be collected and re-transmitted to a drop site, the drop site was probably actually multiple drop sites, and I’m guessing a well known outgoing port such as 443/SSL was used with encrypted payloads. These two PCI controls are intended to prevent outbound access from the cardholder environment, did these systems have outbound Internet access ? or if they did was it controlled ? and if it was controlled was it able to pass though the allowed outgoing traffic ?

Anti-Virus / Firewalls / Encryption: These are terms that are used to define ones security, Security is not a product – But let’s look at each of these briefly:

Anti-Virus – The effectiveness of Anti-Virus is poor, if you are familiar with services such as VirusTotal or have read something like this <– This is why not all malware can be detected by Anti-Virus.

Firewalls – I swear I think people think that firewalls are magic devices — Hollywood  and TV Land  don’t really help here either. Understand what a firewall does – it works at the network layer and can either allow or block IP Address or ranges and port numbers, that is basically all they do. Granted, Application level firewalls and Web Application Firewalls can inspect the content of the traffic (I’m not talking about these)

Encryption: There are different types of encryption, each protects different things in different ways.So you you say something to the effect of:

"We have industry leading encryption"

Are you talking about File Level Encryption ? Disk Encryption (which only works at data at rest), Transport encryption, encrypted data elements or application level encryption, column level or transparent encryption in a database ?  Understand that Encryption is not Encryption is not Encryption.  For example using a product to encrypt a disk to store data at rest, does not provide encrypted data elements and transport level encryption. And lastly End-to-End Encryption solutions would not of prevented this either: see my post here: When End-to-End Encryption is really not End-to-End.

I’m reading a lot about solutions that implement end-to-end encryption, where account numbers and track data is encrypted and can utilize a Hardware Security Module (HSM) and DUKPT or other encryption algorithms from the point-of-sale. I thought it important to share what data is actually encrypted in the payment system.

Here is a list in no particular order:

Gateways:

• MerchantWarehouse MerchantWare
• Shift4 – 4go
• Element Payment Services
• Trust Commerce – TC Smart
• Network Merchants, Inc.
• eProcessing Network

(contact me and I’ll add you if you are not listed)

Most of these are ISO’s that sell you a merchant account and access to their gateway that uses "end-to-end" encryption and that it will shift the PCI and PA-DSS burden from you to them, if you are a merchant, some claim you don’t even need to go through PCI compliance because you don’t have access to the card numbers or the encryption keys to decrypt the cards (Please also see this post on this subject).  This is all really good stuff, I’ve written about End-to-End Encryption before and am a big proponent of it. This can help prevent "sniffers" and card capturing malware from capturing track data and account numbers in the clear as they traverse your internal network. Attackers would either need to install card skimmers or gain access to encryption keys, or use brute force methods against captured encrypted data to capture data at your store.

But it isn’t really End-to-End Encryption.

Let look at two examples:

1. A typical small merchant using a payment gateway
2. A large retailer or processor/gateway that uses a payment switch

A typical small merchant that uses a payment gateway:

A large retailer or processor/gateway that uses a payment switch

( uses leased lines to connect directly to a Payment Processor (FDR, Chase/PaymentTech, Fifth Third, MPS, etc ) or Interchange Network (VisaNet, BankNet, etc )

Let’s say that you are using a gateway or even a switch that supports an encrypted message format from the point-of-sale (POS). The area in RED in each diagram shows where the account number traverses the payment networks in clear text. At the small merchant example from the Gateway to the rest of the network – the account number and track data and CVV2/CVC2 data is sent in the clear. In the direct connect model with the Payment Switch (which actually just operates as a local gateway) from the payment switch to the rest of the network. So End-to-End is really not End-to-End at all. (it depends on where you define end   This should also explain why End-to-End Encryption in its current state would not of prevented the breach at Heartland Payment Systems – as a processor they need to connect and communicate over the interchange networks using TCP/IP connection and ISO-8583 messages to these endpoints.

Why is this ?  The Payment interchange networks and message formats that processors and the Interchange networks use does not support this in their current message formats (primarily ISO-8583) There is no room in the current implementations of Visa’s Base1, MasterCard’s MIP, or FDR’s message formats for example. Data Elements can be added to support this, but would require massive changes to Payment Systems infrastructures and systems.

Does any one have any solutions for this ? Please provide comments below — I’ll provide a follow-up blog post with some of my ideas.

Remember that End-to-End is really not End-to-End, it may shift or transfer some of the compliance "burden"  from the merchant to that of the processor, but still exists in clear text on private networks and at processors.  Oh, and tokenization and secure card vaults would work the same way here, the cards need to be translated to their raw value to ride the payment networks.

Hashing is one of the most basic constructs of Payment Systems development, as it relates to both secure storage of passwords as well as a method of rendering card numbers unreadable (PCI 3.4), you can also use the hash as a lookup or index in a database if you are performing column level encryption especially asymmetric encryption. I hope the presentation includes the difference between "secure hashing" and "naked hashing"

I encourage my readers to attend the following webcast by the Security of Payment Security Professionals, of which I am a member.

Wednesday, January 21th, 2009 the Society of Payment Security Professionals is hosting a webinar on “Secure Hashing and Scope Reduction Methods”.  You can register for this event online.

I plan to do a follow-up post on this and perhaps with a few code examples

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.

-Original-

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 :

I don’t have time this morning to write any detailed blog posts:  So let me share a few links that caught my interest for blogging topics:

• Coinstar Machines Turn Change into iTunes Credit – TibBits – get gift cards from coin counting machines
• Beware: Circuit City Gift Cards – Payment News – Use it or lose it, Retail Gift Cards for struggling retailers are best not to hold on to.
•  Discover To Participate in TARP, Becomes Bank Holding Company – Payment News – DiscoverBank
• Discover PCI Levels Defined:  See: Here (Treasury Institute), and here (GreenSheet).  The Short of it is that Discover has aligned their PCI Merchant Levels to that of MC and Visa.
• ATM Skimmers are getting sneakier – Network Security Blog – Video of an wireless ATM Card Skimmer
• MasterCard dispels myths, highlights benefits of payment networks – (GreenSheet) – MC has released a paper "Benefits of Open Payment Systems and the Role of Interchange" with some links to audio and video – some good basic stuff here on a payment transaction.

My plan to take over the world using capital financed by mobile payments (using Obopay Widgets ) has been put on hold, you see I don’t really want to share my cell phone number with you. I have a fear of getting SMS and text messages and mobile calls that I really don’t want and exorbitant fees on my mobile statement.  You see the new Obopay widgets that I blogged about here, act differently the the Obopay buttons that I used in my first campaign here:

Let’s look at the two different methods:

OboPay Buttons:

When you click on it to send me $1:

(notice – you don’t see my cell phone here)

OboPay Widgets:

When you click on it to send me $110:

(111) 222-3333 is my cell phone number (no not really) that is accessible to anyone who visits the Obopay Widget.

Why did they not implement this like they did the “buttons” ?!??!

I saw this press release: Obopay Introduces Bailout Tools for the Rest of Us:

With millions turning to friends and family for a personal bailout in the form of a little extra cash, Obopay, the pioneering service provider for payments via mobile phones, today announced three widgets — small applications that can be added to web pages such as blogs and profile pages — to help people give, donate and pay money quickly and easily. Receiving and sending money with Obopay to friends and loved ones online has never been easier.

Here is my Obopay Widget in action: 

Get code to create your Obopay widgets here.

I personally don’t like the fact that Obopay allows for anyone to view your cell phone number, after they click though the "widget" if it is configured with your cell phone number. I see SMS Spam and un-wanted cell calls with this.

I was reading Evan Schumans’ blog post Sears, OfficeMax Agree To Pay In Gift Card Patent Lawsuit, this evening.  It appears that there is a company called Card Activation Technologies that has a patent on a gift card validation process:

The Patent itself (click for full text of Patent 6,032,859) was filed in 1996, and it anticipated the next wave of gift card and phone card usage. At the time, the cards were issued for a specific value and then thrown away when emptied. The Patent envisioned POS units that could add and deduct value. Such POS processes are commonplace today, and therein lies the Patent infringement issue.

I have not read the patent in detail, I probably will – but I found this interesting. The article has stated that other companies have either settled or agreed to a  licensed agreement with Card Activation Technologies.