The Hannaford PCI Fallout
Written by Evan SchumanMarch 19th, 2008
Shortly after reports surfaced that the Hannaford grocery chain had been PCI compliant at the time of its data breach attack, the Web has been crawling with those questioning the value of PCI, even as the confusing preliminary details of the breach are being sorted out.
As one who has frequently used this column to point out the many flaws within PCI, please allow me to stand up and say to those PCI critics: What planet are you from that tolerates only perfect security systems? Do they conclude from one successful burglary of a house protected by a top-notch burglar alarm and high-security deadbolts that burglar alarms and deadbolts are worthless? Read more.
-Marc
March 20th, 2008 at 11:09 am
…the negative fallout for PCI DSS initiative from this will be severe. Hannaford is not the only high-profile merchant involved in a large data breach that claims to have been PCI compliant at the time of the breach(es). (see TJX court filings re their breach.
The details of the Hannaford breach will be critical here in understanding the on-going relevance of PCI DSS. If the breaches occurred among “in-scope” items, the legitimacy of PCI DSS takes a major blow and there is little wiggle room. If it is determined that the breaches occurred on “out of scope” items, PCI DSS may find some place to hide but it will bring attention to some wide-open holes in this standard (eg, no physical security for mag-stripe data at the point of capture similar to what is done for PIN data.)
(btw, this notion of “out of scope” and “in scope” as a means of justifying various security solution’s gaps has got to be driven out of our collective nomenclature. It serves no purpose to lock the doors (in-scope), but keep the windows unlocked (out of scope.)
PCI DSS is (was?) one of the best things to happen to payment card security and is worthwhile for sure. I hope the PCI DSS is proactive in acknowledging the shortcomings and gaps in it’s standard and moves quickly to close those gaps…otherwise they will lose critical momentum as they try to extend this standard into the millions of small merchants out there.
March 20th, 2008 at 11:16 am
Excellent explanation of the distinction between being “validated” and being “compliant”: one does not guarantee the second. Also, as you point out, neither one guarantees “security.” We are going to be reading a lot about this one and enduring a lot of speculation. Meanwhile PCI, even if it isn’t perfect or installed in 100% of merchants, has done a lot just by raising both security and awareness of the risks to the brand.
March 20th, 2008 at 2:28 pm
While most security practitioners would most certainly agree with Evan and Patrick that PCI (albeit, not perfect), has tremendous value, a more pressing question is; what value has the organization placed on the intent of PCI?
This incident may expose a more fundamental question. Are retailers ignoring the true value and/or intent of a given control, to satisfy the auditor? As the details of this compromise emerge don’t be surprised if we find that Hannaford was nothing more than a “PCI Paper Tigerâ€â€¦
Kent Tugo
March 21st, 2008 at 11:58 am
I understand what you’re saying about “in-scope†vs. “out-of-scope.†The problem is that I don’t see it going away as long as there is a battle between “compliance†vs. “security.†I feel we offer one of the most secure solutions on the market that provide end-to-end encryption as close to the swipe as possible (and we’re working with hardware manufacturers to include our technology in the swipe to bridge that final gap). But PCI only recognizes this solution in terms of “out-of-scope.†We tokenize the data at the swipe thereby taking all other merchant applications between the swipe reader and our data center out-of-scope. Until PCI recognizes, classifies and possibly pre-certifies specific technologies, the only place for this and other technologies is the catch-all “out-of-scope†bucket.
This is only a single point where out-of-scope is here to stay, at least for the foreseeable future. But I also see the term being used to justify security weaknesses and I think this was your primary concern — and with this concern I agree.
March 21st, 2008 at 3:42 pm
No disresect intended here Steve, but any firm who is suggesting that tokenization on its own creates a meaningful or sustainable delta in overall security for a merchant is literally making a living off of confusion between “compliance and security”.
(as an aside, it would be interesting (and useful) for this forum to see an (QSA)auditor’s report that sustains claims that tokenization takes downstream apps or merchants “out of scope.”)
The PCI DSS council does not need to pre-certify anything. All they need to do is define the physical and logical architectures that take merchants (or apps or devices) out of scope, the let the industry build to those hurdles.
March 21st, 2008 at 6:53 pm
Patrick, you are not understanding our technology and the different layers of tokenization. I fully agree with your statements if I was talking about “traditional” tokenization where card holder data (CHD) is collected and sent with the authorization request made by the POS and subsequently a token is returned to the POS for storage.
The solution I was referring to that takes POS applications out-of-scope is our 4Go product. It intercepts the swipe, secures the CHD, generates faux CHD and sends this to the POS — the POS never sees real card holder data. This solution secures the data and is compliant.
This debate right here is why I am in favor of the PCI-DSS council recognizing, classifying and possibly pre-certifying specific technologies. I’m not saying that these “certified” would be the only technologies used, I’m just suggesting some sort of fast track for merchants provided it’s proven secure.
My concern is that as PCI becomes bulkier and as annual audits become requirements for more and more merchants, that the whole program will collapse under its own weight and merchant costs. A perfect example is a couple PABP audit reports that Visa has right now for us. They have been in the approval process for over two months now. The only delay here is Visa’s PABP backlog. I can only imagine the QSA backlog if all of a sudden the level 3 and 4 merchants were brought into the fold and required to do annual audits. Something will need to be done to streamline this process for merchants. I’m not promoting to stick some unproven technology in place with a “secure” stamp.
March 21st, 2008 at 8:33 pm
Hi Steve,
Sorry for the insinuation in my post. Not called for. Look, what you have created for the market with your technology is very thoughtful and particularly useful in this era of PCI DSS compliance hysteria. The technical “dispute” is whether or not any POS environment is secure if card data is in the clear at any point no matter how briefly. If a mag-stripe reader captures data and that mag-stripe reader is not physically secure (ala HSM’s or even at a PED compliance level of physical security for PINS), then the total environment is not secure.
Even if a mag-stripe reader is executing encryption “at the swipe” (actually after the swipe as the ASIC chip behind the reader reads off of the coil)mag stripe data is in the clear (it is also in the clear as it heads for the comm) and can be physically attacked through a variety of very low cost means. This is why PED’s are theoretically tamper proof and operate with their own isolated crypto module. Even the PED level of security is may not be enough as we are now hearing of physical attacks since PED 1.3 where the devices are compromised. What’s needed is “CRED 2.0”, to deal with the physical security of data capture devices like mag-stripe readers.)
If your goal is to reduce the burden of PCI compliance (a noble goal!)via an approach that takes portions of the merchant enterprise out of scope (ie, apps, back end systems, etc) via removing card data from the enterprise (another noble and wise goal!), then be prepared for an avalanche of questions from very smart security people questioning how you resolve the issue of physical card data security in your architecture. These are legitimate questions and go to the heart of the matter.
You guys have shown you are out in front on this one, so take the next step and resolve what appears to be the remaining piece of the puzzle.
PH
March 21st, 2008 at 11:11 pm
Hardware level encryption at the swipe reader is the next phase for us. As of right now, this requirement is not part of PCI and this is where I beleive your original out-of-scope comments were directed — “out-of-scope” used to justify a security weakness. But we are looking toward the future and feel it’s just a matter of time before PCI does address this hole. Don’t be surprised if you get a call from us in the near future…
April 17th, 2008 at 1:23 pm
Excellent explanation of the PCI reality. PCI has never been billed as a guarantee. It has always been a practical guideline to prevent most attacks. There is one group that could do more to help solve the problem. That group is Issuers. They could employ technology that changes the card number with each use. Such technology is offered by Qsecure and Privasys.