Will Old OS Cause PCI Violation? No, But Marketing Still Says So

For your overflowing folder marked "Ludicrous PCI Scare Tactics That Too Many People Believe" comes a renewed effort from some security vendors to say that out-of-date operating systems this year will cause instant PCI non-compliance. The cure: Give the vendor a lot more money. (Funny how that “cure” seems to treat so many ills in these letters. It's the Penicillin of PCI.)

This latest example comes courtesy of a security vendor. But in this case, the vendor is calling out others for the tactic. A Shift4 executive posted on its blog a copy of a letter from a POS vendor making the rounds, a letter that specifically warns retailers—under the headline "Information Security Advisory"—that "effective July 1, 2010, Microsoft will discontinue its support of the Windows 2000 operating system. The Payment Card Industry Payment Application Data Security Standard (PA-DSS) requires all components of the payment processing system to be supported by the vendors with security updates. Therefore, effective July 1, 2010, any payment processing products operating only on the Windows 2000 operating system will become non-compliant with the terms of PA-DSS."

Shift4's commentary correctly took the threat raised in the letter to the next logical point: "Think of the scope: All POS's running on Windows 2000 as of 7/1/2010, all applications running on prior version of Windows are already out of compliance. Come to think of it, the requirement does not mention Windows specifically so the scope is even bigger: All POS's running on various older Unix flavors, PIC O/S, even older Mac O/S (albeit, I'm not aware of any POS running on Mac O/S)." (Editor's Note: Sure you are. The iPhone checkout app that is being used at Apple Stores. OK, so it's not precisely Mac OS but it's close.)

Impressive stuff, especially when considering that this particular vendor sits on the PCI board. The only problem is that it's not true. (Details, details.) As the Shift4 blog properly points out—with some nice documentation—PCI explicitly excludes out-of-date OSs from generating automatic non-compliance. It cleanly establishes that OSs are out-of-scope for PA-DSS.

Indeed, an FAQ on PCI's own site directly negates the "old OS automatic non-compliance" scheme: "Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM or developer are not necessarily out of compliance. Compensating controls could address risks posed by using older operating systems," it says. "Other compensating controls could include monitoring IDS/IPS and firewall logs more frequently than required (for example, the requirement is for daily log reviews, so more frequently may be continuously and automated), or isolating and segmenting their POS systems via firewalls from the Internet and other systems in the cardholder data environment."

Sure, PCI recommends that merchants should eventually upgrade ("The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so"). But what chain wouldn't already plan to do that? Note how the vendor scare letter seemed to skip over that part.

The Shift4 post, though, was interesting for another reason. The executive who wrote it--Steve Sommers--is Shift4's senior vice president for applications development. Sommers is one of the more knowledgeable and opinionated PCI folk out there, and he took the unusual step of modifying his post and backing off of a word he had originally used."The vendor who I used as the example also contacted me and, in hindsight, I may have been a little harsh in use of the word 'unscrupulous.' Instead, what I should have said was that letters like this could be the result of either unscrupulous, ill-advised or simply naive marketing departments with a cursory knowledge of PCI," Sommers wrote. "Heck, I've had to do some postmortem clean-up after some naive statements from a prior marketing department of my company, and I would not have classified their intent as unscrupulous." Drat! He fessed up before we had a chance to remind folk.

But his clarification is a valid one. Vendors are businesses designed to make a profit, and marketing and other departments are invariably not as plugged into the details as those departments directly involved in the process. (I'll avoid saying that those who do stuff know much more than those who just write about it. Hits a little too close to home.) A lot of mis-statements are the result of ignorance and, much more critically, the failure of someone to closely check the text of letters, news releases, ads and Web posts for reality.

This creeps into an ethical quicksand. Did someone fail to check it at all? Did someone deliberately fail to check it because they subscribed to the "no see, no hear" school of management? In other words, if they believe that marketing/sales will advance the company's interests, perhaps it's best if they "inadvertently" forget to look at that letter. "No see, no hear" mixes well with "permission versus forgiveness."

The rapid movement today of social networks and general blogging will make this problem much worse. How many companies truly require that every blog post—or even Twitter tweet—be reviewed and approved? When those are routinely issued without oversight, is a marketing E-mail that much different? And then a quick marketing letter?

Are ads reviewed by the technical group or just senior management? Don't forget that, for this purpose, the COO is likely to be as hazy on the details as a marketing copy writer. An approval is meaningless if someone truly knowledgeable about the specifics isn't forced to read it thoroughly and sign off on its accuracy.

Many seasoned execs have developed an excellent “BS Detector.” But the problem with a BS Detector is the same as the problem with a lie detector: At best, it will flag people who are saying false things and who know they are saying something false. If the writer or speaker truly believes the truth of what is being communicated, a BS Detector won't help.

The bottom line for retailers is hardly news: You need to take any vendor PCI claim these days with several tons of SALT (Slick Advertising Ludicrousness Test).