More PCI Deception. Won’t Vendors Ever Learn?
Written by Evan SchumanA PCI security software vendor issued a statement this week that retailers could avoid PCI’s requirement if it adopted a token approach the vendor was selling. The claim would have been even better if it were true.
The token approach is hardly new and it simply replaces a credit card number with a token that acts as the number throughout the payment approval cycle.
It’s fair to say that such a method—in theory—would reduce the risks of card transactions by shrinking the window of vulnerability. But it’s hardly fullproof protection and as long as retailers accept credit card payments, they are almost certainly under the PCI jurisdiction.
That didn’t stop Shift4 on Wednesday from issuing a statement that "merchants concerned about PCI DSS compliance have an option that enables them to avoid its burdensome requirements."
Shift4’s argument hangs on this line from the current PCI rules: "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."
But the product from Shift4—whose employees didn’t return a phonecall and E-mail to discuss their release—doesn’t kick in until after the credit card has been presented and introduced to the POS.
Gartner’s senior security analyst, Avivah Litan, said the vendor’s claim is pushing it.
"I think the Shift4 press release is potentially misleading. As long as a merchant is accepting a credit/debit card at the POS, the merchant must comply with PCI. There is a period of time, albeit short, when the POS device must transmit the card number to the Shift4 service so that it can create the token number," Litan said. "The merchant is therefore responsible for making sure that that POS transmission is encrypted."
Litan adds that for many retailers with older POS systems, this is more than a technicality. "Many old legacy POS terminals are incapable of encryption, making this ‘first’ and ‘last’ leg of the payment journey transaction the most vulnerable. I say ‘last’ because the POS system has to receive an authorization message back from the card networks. Security is only as strong as the weakest link. So, bottom line, in many cases, merchants won’t want to consider outsourcing data processing and electronic data storage until they upgrade their POS equipment in order to support encryption. Visa’s 2010 PABP compliance date will help make that happen, but not until 2009."
Litan, as usual, makes some excellent points. But the bigger problem here is the overall PCI confusion among retailers. Retailers overwhelmingly want to be PCI compliant (Fear? Thy name is no interchange fee discounts) but those are being flummoxed by security vendors confusing and misleading them.
This turns into a very vicious cycle. Retailers want to trust security vendors, so they can rely on them to interpret PCI and other security rules. But when reputable vendors like Shift4 get caught playing fast-and-loose with PCI interpretations, it makes it 50 times as difficult for vendors to be trusted with such interpretations.
Put another way, security vendors are in a wonderful position to not only sell software and services, but to act as trusted advisors to retailers, trying to navigate PCI. I’m not sure of the best way to kill that golden goose for all security vendors, but I think Shift4 has come up with a pretty bloody good one.
-Marc
February 22nd, 2008 at 4:58 pm
I’m sorry that you did not receive a response to your phone call and email, you should have received a response and that is being addressed outside of this forum.
Let me start out by saying PCI DSS Does Apply to Merchants Using Shift4’s 4Go Technology. The release should not have gone out with that headline and we will be publishing a correction release on Monday. With that said, while the headline of the release may have been misleading, the content of release is not exaggerated or misleading, but I admit that it was skimpy on the details of the technology. Again, Monday’s correction will add some of these missing details.
Anyway, to address “More PCI Deception. Won’t Vendors Ever Learn?†Ignoring our misleading headline, the premise that this release is misleading is “There is a period of time, albeit short, when the POS device must transmit the card number to the Shift4 service…†This assumes that all tokenization is the same and the tokenization process happens during the authorization request. It can happen this way and this is the method that we released to the public domain back in October 2005. But we have dedicated a lot of money and time to improving the technology and developing creative ways to implement tokenization at various levels in the process. 4Go for instance, which the release was about, is an application in and of itself that sits in front of the POS and tokenizes the card information prior to the POS ever seeing it therefore taking the POS completely out of PCI scope. Since the POS is out of scope, there is no requirement for encryption and various other PCI requirements so we can secure both current and legacy applications.
In a nutshell, 4Go sits in front of the POS. 4Go intercepts swipes and securely transmits this information to a back-end Shift4 piece, this process creates another form of a token that gets passed to the POS looking like a swipe, the transaction works its way through the POS, the POS talks to the back-end Shift4 piece and we marry the information back together — the POS never sees credit card data and is none the wiser.
I hope this clarifies our position and I apologize for the misleading headline.
Sincerely,
Steven M. Sommers
Vice President Applications Development
Shift4 Corporation — http://www.shift4.com
February 22nd, 2008 at 7:59 pm
Editor’s Note: Thanks so much for posting this comment. Your comments are appreciated. The story that ran was based on the statement you issued and, with the lack of response, we had to work with that.
We are looking at the particulars of Shift4’s technology to see how it does differ from others.
That all said, the point of the piece was indeed focused on the headline, which you’ve now withdrawn. The point was that there is a lot of confusion about PCI and that headlines like that from prominent vendors such as yours make the confusion worse.
February 26th, 2008 at 1:07 pm
Shift4 is to be congratulated for wading in to solve the fundamental paradox of securing card data at merchant’s locations. The paradox is that the payment network cannot be secure until all merchants are secure and, yet, the task of securing all merchants is, as a practical matter, not obtainable using conventional approaches (ie, PCI DSS standards).
Shift4 seems to understands that the only way to achieve definitive merchant level security is to eliminate entirely card data from merchant’s systems. Unfortunately, securing card data AFTER it has been captured by the merchant’s POS system via the mag-stripe reader –no matter how elaborate the data at rest encyrption, internal protocals, or other conventional security — is a fool’s errand. Shift4’s solution has this primary flaw.
Shift4’s objective is laudable, but the technical facts are that “tokenezation” is inneffective as security measure if it occurs as separate process from the actual card swipe data capture.
The technology to simultaneously capture card data and tokenize that data within a physical structure that cannot itself be compromised (think of how HSM’s work on the network) is the technical hurdle to be overcome if tokenization (and it’s very worthwhile aims) is to achieve credibility. Of course, building a miniturized FIPS certified HSM that can sit on the back of a mag-stripe reader is a substantial technical challenge and, as we have experienced, costs millions of dollars in research and development and years of lab time.
The good news is that companies like Shift4 are thinking out of the box. I’m encouraged by their efforts and hope they will continue to advance the debate about how to best secure the card payments networks.
[Disclaimer: Semtek works in a similar field to Shift4, but primarily serves large global retailers and processors.]
-Patrick Hazel, Chief Executive
Semtek Corporation
February 27th, 2008 at 12:37 pm
I’m a little confused by the statement “Unfortunately, securing card data AFTER it has been captured by the merchant’s POS system via the mag-stripe reader —no matter how elaborate the data at rest encryption, internal protocols, or other conventional security — is a fool’s errand.â€
If this is referring to the swipe data going into the POS and then tokenized, then we have not sufficiently conveyed how 4Go works. $Go sits in front of the POS. 4Go is the first application to receive the raw swipe from the reader, not the POS. Part of 4Go is installed as an O/S level kernel keyboard driver so application software wise, there is no way for the POS or any other application to receive non-tokenized information from the swipe reader (barring an O/S flaw, which is always possible — but then, all bets are off and any application would be vulnerable).
If this is referring to hardware interception directly from the swipe, then yes this is correct — this is a hole that everyone is vulnerable to now and PA DSS does not address at all and PCI DSS only indirectly addresses with the physical security rules. We have worked with a swipe reader manufacturer to solve this directly in the hardware but our initial research is that this would take a long time to take off because it would require that all hardware swipes be replaced. Merchants are already squawking over the software and training costs associated with PCI compliance, we can only imaging the outrage if all swipe readers had to be replaced by 2010 or whatever date the card associations decide.
February 27th, 2008 at 3:27 pm
“..Part of 4Go is installed as an O/S level kernel keyboard driver..†I agree can prevent PC logging functions from recording sensitive card data by intercepting all keyboard entry and selectively filtering data sent to the OS. This is basically how a malware keystroke logging root-kit works. How do you prevent a stealth root-kit key logger from inserting itself in front of the $Go keyboard driver?
A more basic question is how you make au unsecure computing platform such as a PC running an unsecure POS application secure? And if you succeed in accomplishing that feat how you do keep the solution updated when Microsoft is sending out multiple security patches daily?
While PCI DSS does not address magstripe data security PCI PED 2.0 does. A11 of the PED 2.0 specification requires that even inside a secured POS enclosure the data path from the magstripe reader to the POS processor must be protected from attack. A11 was added to PCI PED after multiple successful attacks of magstripe data in POS equipment certified to be secure under PCI PED 1.0. Since readily available hardware keyboard loggers placed in series with the MSR could collect card data PCI DSS 2.0 would require a secure reader to meet the A11 requirement. Either the wires from the reader to the PC need to be protected or the data needs to be secured prior to leaving the reader.
The only method of truly securing card data in a PC based POS application seems to be encrypting the data in a secure environment prior to entering the PC.
[Disclaimer: Semtek works in a similar field to Shift4, but primarily serves large global retailers and processors.]
-Clay von Mueller, Chief Scientist
Semtek Innovative Solutions
February 27th, 2008 at 4:24 pm
When it comes to 4Go I know the big picture and just enough of the details to be dangerous so I’ll take a stab at your questions.
RE: How do you prevent a stealth root-kit key logger from inserting itself in front of the $Go keyboard driver?
First, my initial $Go reference was a typo, it should have been 4Go. We do have a layer that detects for other keyboard filters and we require our driver to be the first. We also test if all our required components are running and for tampering. If any of these tests fail, we post the issue to the system logs and notify our back-end piece which in turn sends an alert to configured users via email. 4Go can also be configured to disable all card swipes if any of the prior tests fail.
RE: A more basic question is how you make au unsecure computing platform such as a PC running an unsecure POS application secure?
We do this by taking the POS out of scope of PCI. Since the POS application is no longer handling real cardholder data, it is out of scope. For example, 4Go might intercept “;4321098765432109=0912987654321?†It would perform its magic and stuff the following into the keyboard buffer “;4321999999992109=091299999999?†This faux card number or token is all that the POS will ever see. There is some additional logic that goes into this process but hopefully you get the point.
RE: And if you succeed in accomplishing that feat how you do keep the solution updated when Microsoft is sending out multiple security patches daily?
4Go does not address operating system patch levels, nor does it address any firewall requirements or other non-PABP or non-PA DSS requirements. This is why the initial headline was misleading and has since been corrected. We could have used the headline “PABP and PA DSS Does Apply to Applications Using Shift4’s 4Go Technology,†which would not have been misleading and probably would have described the 4Go benefit better than the revised headline of “PCI DSS Compliance Simplified for Merchants Using Shift4’s 4Go Technology.†The focus of PABP and PA DSS is at the application level and this is what 4Go addresses. PCI DSS has a much broader focus and as you’re pointing out, cannot be fully addressed by a single application.
February 29th, 2008 at 1:03 pm
I find it interesting to note how many processes have similarities obscured in the process of naming. While using a short-form reference for an often-used phrase such as POS is entirely transparent [to use the word correctly, I might note] to IT and at least somewhat to management, as it wends its way through society–however you see it structure–at some point it’s going to entirely obscure the point. My point is that there are probably a limited amount of things that can be done with data and particularly with that denoting worth–and that the catchphrase means of dealing with a process makes the assumption first of all that we know everything about the process.
–Glenn
March 25th, 2008 at 2:01 pm
Really interesting discussion, although we have wrapped ourselves up in technology, and are in danger of missing the main focus of the PCI SCC’s main objectives. 4Go has completely the right idea, although not a new one, a number of MSP’s offer a similar solution EG, Capita in the UK offer a fully managed payment service accross all payment channels (Internet, MOTO, POS) and although PCI certified never made the claim that this addresses PCI for the merchant. all it does is reduce scope massivly for the end user, enabeling them to compy with PCI using the new SAQ level (36 questions or less rather than 200+) introduced in Feb this year rather than having to answer a list of questions that were not relevent in the original document. the requirement for encryption in an unsecure environment as far as PCI is concerned is only needed when the Card Data is stored. and with any fully outsourced solution, as long as it is in a managed PCI cretified infrastructure (PCI 12.8) then your in PCI happy land… what ever you do do not implement a solution that requires an on-site APACS authorisation server…
Note.. the sooner the aquirers get their own act together the better.. any POS system that requires the data to be authorised real time has to send the information to the aquirer un encrypted.. enough said..
Best Regards
Wayne Campbell
May 5th, 2008 at 1:41 am
I don’t see the 4GO product for certified products that meet PCI/PABP.
Also what’s the point putting all your eggs in one basket? What happens if a gateway gets hacked into? Does MC/Visa shutdown every merchant that uses the gateway that was comprised?
May 22nd, 2008 at 11:10 am
4Go is currently going through the PABP process. It is more difficult than most to get through because it is a very “non-standard” payment application — in fact, since it does not perform the actual payment transaction, instead it simply secures the CHD, some have argued that it is not a payment application and should not appear on the list. But I think this has been resolved so it will be on the list soon.
The putting all your eggs in one basket is a double edged argument. Is it better to use a gateway that is depends on security to stay in business and is physically audited and scanned regularily, or should the risk be distributed to merchants and systems that may not dedicate as much resources to security and most are not physically audited?