Micros 3700, 8700 & CISP Compliancy 1

[TobeThor]

Apparantly there are versions of the Micros 8700 & 3700 that have been made CISP compliant by a third party (Shift4). The Micros users in our area are unaware of this information. In fact, they are being told they must upgrade their Micros POS to become CISP compliant. In some cases this could cost end users over $15K.

Are there existing Micros 8700 and (3700 earlier versions below Res 3.2) that have gone this root with Shift4? Can you share your experience? Are you satisfied? Were you facing an upgrade and decided to use Shift4 instead? How much money did you save and/or avoid paying?

 

[regilobo]

Nobody? I'm very interested in this line of inquiry as well.

My understanding is that the Shift4 solution would take care of the processing and storing of credit card numbers on the system, but obviously there are other issues on the CISP checklist that are unrelated to the processing. The certified MICROS versions have some changes with respect to user logins and logging capabilities, and...?

 

[Shift4SMS]

PCI allows for compensating controls and this is how the Shift4 driver satisfies some of the requirements. The Shift4 application that hosts the CC data is fully PCI compliant and since the Shift4-Micros driver hides the the CC information from the Micros application, this falls under the compensating control clause. Just the fact that the real CC information is not passed to the Micros application, many of the Micros PABP and PCI requirements are satisfied.

For more info on the driver give Shift4 a call or fill out an information request form on the S4 site.

I'm hoping that a merchant with Shift4-Micros driver experience frequents this site and will respond. If not, I know references can be provided via the info path above.

Good luck with whatever route you decide...

Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[POSWizard]

I was under the impression that the shift4 token process wrote the data being passed in the interface log. If this is the case would this still be PCI?

 

[Shift4SMS]

There are two levels of tokenization, but neither actually write data in the POS application. For the secure Shift4-Micros driver, a software piece sits in front of the Micros application, intercepting real card information and replacing it with faux or token information. Since the Micros application is not writing real card information to the logs and in fact Micros never sees the real card information, it complies with PCI.

 

[Shift4SMS]

F.Y.I. I'm not trying to be vague here, but I am trying to only give you a taste of how the driver secures the data and makes the Micros application PCI compliant. I'm walking a tightrope here between not enough information which may be seen as vague or weasly (if that's a word) and too much information which might confuse some or be viewed as self promotional spam.

 

[pmegan]

I had a bunch of reservations about the compliancy requirements beyond the driver too. Steve and I had a bit of a discussion about it in this thread:

http://www.tek-tips.com/viewthread.cfm?qid=1410167

Getting hit for non-compliancy is a very scary thing and the PCI police won't care if it was intentional or not. Anybody who is responsible for these system should really do their homework, understand ALL the requirements and make sure the solution they choose covers all the points needed to get the POS system legal.

Pat

 

[FoodtoGo]

So does the Shift4 solution use MICROS SIM or a DLL called by SIM at all?

Because SIM is just a 3700 simple scripting language that most of us on this board have used to write data somewhere for other reasons. I could see that this approach would likely weaken the security of credit card data, not strengthen it.

Also - is a system really "compliant" if only one component, on a non-PCI version of software becomes compliant? If the forensic credit card folks take a holistic approach after a breach, you will still find yourself running a non-compliant version of POS.

I don't know how else to run an intercept-front end to these older systems other than at least a call from SIM.. If it's true, This seams to be a risk that isn't hard miss..

I hope I'm wrong in my assumptions.

 

[Shift4SMS]

Yes, the current version of our driver uses a combination of SIM and a DLL. And yes, the SIM can be modified to bypass our security features but that is where some of the other layers of PCI come in to play -- logging all access, restricting user privileges and change control. Yes, the system is really "compliant" with just one component. It does this by intercepting the credit card data at the point of entry, substitutes it with a token and presto, MICROS never sees real credit card data and thus removed from the PCI scope; Only applications that process, transport or store credit card information are in scope.

The current version of our drivers is PABP certified and we have worked directly with VISA with this project. This is a very unique solution because it is the first and only third-party driver that secures another vendors application. We have a new version that will be released shortly that removes the SIM layer all together so your concerns about this layer will soon be gone.

Hope this helps.


Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[FoodtoGo]

It appears that I'm not the only one that has this grave concern.

This is a MUST read article about PCI/DSS on these older systems that was released today.

http://storefrontbacktalk.com/story/022208shift4

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

Gartner's senior security analyst, Avivah Litan, said the vendor's claim is pushing it.

Litan adds that for many retailers with older POS systems, this is more than a technicality.


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

 

[Shift4SMS]

I urge anyone reading this thread to read the storefrontbacktalk story mentioned above and also read the comments attached to the story:

http://www.storefrontbacktalk.com/securityfraud/pci-vendors-statement-dubbed-misleading/#comments

There will be a follow-up story because when we explained the technology to the editor, while the headline was incorrect and misleading (explained in the comments), he agreed that it was the best technology he has heard addressing cardholder data security issue.

FoodToGo, why don't you enlighten us on who you are and who you represent? The handle "FoodToGo" is kind of misleading as it implies you're a restaurant owner. From your posting history it is apparent that you work for Micros.

Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[FoodtoGo]

This is great information (thanks for that).

Regarding my identity, I have been in this industry for 15+ years, starting back in the mid-90's writing SIM on a 2700 at the restaurant where I worked during college. I have since written 1000's of lines of SIM for 3700, 8700, 9700 systems.

This Credit Card Fines are really blasting some owner/operators and forcing them out of business.

I'm glad you have withdrawn the headline as the editor noted.

 

[pmegan]

Anybody looking into PCI compliancy solutions should look through these sites. They're about as exciting as watching paint dry, but getting through them is worth the time.

http://www.americanexpress.com/datasecurity

http://www.pcisecuritystandards.org

PCI compliancy for your POS system is more than just how the CC's are handled. Third party solutions may very well bring the CC handling part of the equation into compliancy, but there are a lot of other pieces that you have to look into. There are also standards for your network as a whole, minimum software and operating system versions, password rotation/customization requirements, etc...

Non-CC based issues can come from the following.
If you, as a customer, cannot change the passwords for your database.
If you can't set up automatic password expiration/rotation rules for data/report access.
If your POS software is more than 2 versions old.
If any of the computers in you POS system are running an OS that's below w2k.

I've been working exclusively on/with the Micros POS products for 15+ years so that's the basis of my concerns and comments. Squirrel, Aloha, PosiTouch and other POS systems may have different issues, but no system is exempted from these requirements. Whatever you use, make sure you know all the requirements and how the potential solution addresses them.

When you're researching POS options, don't be afraid to ask the hard questions and don't let the company trying to sell you a PCI compliancy solution off the hook; 3rd party or POS vendor. If your questions can't be answered, look at another solution. Most restaurants won't be able to make it through the forensic audit fees and resulting penalties; so you're literally talking about the future of your business.

DO NOT PUT THIS OFF! The general public is learning about these laws and there are a lot of people who think they can make a fortune by suing a restaurant or retail store.

Compliancy extends past the POS system, so I'd also recommend getting your network analyzed by one of the companies listed in the links above if you can afford it, especially if you do any business online. You can fail a forensic audit if your web host dosn't meet the standards. You can also fail if any of the office computers are considered a weak point of access for hackers.

 

[Shift4SMS]

FoodToGo, thank you for your response. You caught me on a bad day. Because our driver impacts Micros' upgrade revenue, we're not on the best of terms with the corporate hard-liners.

pmegan, very good posting. Many merchants only focus on their immediate POS compliance problem they might have and ignore the bigger picture. While I feel our drivers are more secure than the Micros latest & greatest non-Shift4 solution, if a merchant ignores any of the details you specified (and others), PCI DSS compliance could be jeopardized for merchants using any POS solution.

 

[POSWizard]

More PCI Deception. Won't Vendors Ever Learn?
Written by Evan Schuman
February 22, 2008

http://storefrontbacktalk.com/story/022208shift4

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

 

[Shift4SMS]

Hmm, Déjà vu -- As stated previously in this thread, read the comments attached to the article.

Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[Shift4SMS]

For anyone still reading this thread, you might want to also note:

http://storefrontbacktalk.com/story/030108encryption