Will Old OS Cause PCI Violation? No, But Marketing Still Says So
Written by Evan SchumanFor 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.
-Marc
January 26th, 2010 at 2:36 pm
The PCI FAQ entry referenced says that merchants should have a plan for upgrading to a newer OS and use compensating controls to mitigate risk in the meantime.
IDS, anti-virus, and network firewalls can only prevent so much. Segmentation provides additional protection. The FAQ entry basically points to other PCI DSS requirements that provide additional layers of security. At the end of the day, the business is still running software with known vulnerabilities after it reaches end of life and new vulns are discovered. In the case of MS Windows, we’re talking about an OS that is highly targeted by criminal elements. Businesses that continue to run the EOL version of Windows are missing a critical layer of protection. If a business is compromised, they will be found to be non-compliant with PCI DSS and will suffer. Pointing to the FAQ will not provide any relief when they received targeted malware that evades signature detection which then offloaded 3 months of sensitive cardholder data using DNS tunneling to bypass egress filters before they were notified of a breach by the Secret Service.
Many of these vendors deal with merchants that they know are not capable of managing compensating controls. They also know that these merchants will not upgrade unless they absolutely have to. Also consider that there are merchants suing their POS software vendors and VARs. If you were in the shoes of the software vendor or VAR, what would you do?
In my opinion, the only thing the vendor did wrong was they didn’t know of that FAQ entry. Even if they did, it changes nothing about the need for merchants to update software that no longer receives updates.
January 26th, 2010 at 4:21 pm
There are compensating controls that encrypt the swipe at the driver level as it enter the PC, there are hardware encrypting card swipes so the cardholder data is already encrypted before it comes to the PC — either of these, especially the second, would remove the OS entirely from a cardholder data risk profile.
January 26th, 2010 at 7:16 pm
I would argue against software level encryption. Modern malware runs as a driver, meaning ring 0 kernel level access. Combined with memory scraping techniques seen implemented against SMB in the wild, card data should be considered vulnerable at point of entry on the system running the encryption driver. The PCI FAQ entry on end to end encryption supports this by focusing on point of encryption and point of decryption.
That said, I love solutions that encrypt at a peripheral that acts as a tamper resistant module and isn’t decrypted until it is outside of the merchant environment and in the systems of a Service Provider contractually liable for that decrypted data. If only a standard would emerge so companies don’t end up locked-in with a vendor technology that loses the format war and dies out like HD-DVD. I don’t know if that’ll happen though. Businesses have to decide for themselves when they invest and what e2e implementation to use.
January 27th, 2010 at 4:27 pm
Why would one automatically upgrade to a “new” OS — some of the older versions of certain OS-es are more stable and more robust than the crap being peddled today.
This is yet another clear example of PCI SSC being out of touch with reality. Rather than requiring a “current” OS, the requirement should be to demonstrate the OS in use is stable and robust, and is adequately hardened against threats. Whether or not I accomplish this with a decade-old version of an OS or via the most recent release should be irrelevant to the issue.
It’s these types of FUD issues that make one wonder if the PCI SSC has bothered to read anything about standards in other industries where there are even more stringent and robust requirements. Standards which are far more viable, mature, and robust than PCI DSS have all realized that dictating a specific technical solution is inane. PCI DSS seems to be too focused / enamored with current trendy technologies rather than outcomes.
January 27th, 2010 at 6:54 pm
Cranston, this is something I touch on in one of my replies but you expanded on even further. I fully agree and I don’t believe that the latest OS is necessarily the greatest in the context of security.
January 27th, 2010 at 9:50 pm
This is an interesting issue, because there’s more to it than what’s apparent on the surface. First, while the SSC’s web site does speak to the issue of operating systems no longer supported by the vendor, their answer isn’t exactly a ringing endorsement. They state that in such a case, a compensating control could be used to resolve the compliance issue. A compensating control has a few major elements: the organization must, after a risk assessment, show a legitimate technical or business constraint against meeting the requirement as stated (hint: “It’s too hard” generally isn’t legit), the control must meet the intent and rigor of the original requirement and it must go above and beyond the existing PCI DSS requirements. It’s not enough to say that you have anti-virus software and an intrusion detection system; you already need those to meet the PCI DSS. The examples mentioned in the FAQ talk about going beyond the existing log review and IDS requirements as a means of catching what amounts to the entire set of known attacks against the vulnerable operating system in question. I’m struggling to find a word that adequately describes such a task. Daunting or onerous come to mind.
Secondly it’s easy, I think, to conflate certain elements of PCI DSS and PA-DSS. An exhaustive look through the PA-DSS requirements document or the PA-DSS program guide shows no mention of compensating controls for payment applications undergoing a PA-DSS assessment. There’s probably a reason for this. The purpose of PA-DSS is to facilitate and not preclude compliance with the PCI DSS (see the first bullet at the bottom of page vii in the PA-DSS itself). Because PA-DSS-validated applications can be deployed into a variety of environments and because compensating controls are *always* specific to a given situation, a PA-DSS assessment cannot make use of compensating controls in the way a PCI DSS assessment can.
Long story short, PA-DSS requires supported and patched operating systems and other software components (e.g., databases, libraries, Java, etc.) per PA-DSS
7.1.b and 8.1, and the option for compensating controls simply isn’t there. Merchants can make use of compensating controls for most PCI DSS requirements, but only when legitimate constraints exist and only in ways that meet the intent and rigor of the requirement and go above and beyond the other PCI DSS requirements.
January 28th, 2010 at 5:22 pm
There’s an old saying that might be somewhat relevant to the second half of this post: the difference between a lawyer and a software saleman is that the lawyer knows that he’s lying to you.
February 3rd, 2010 at 2:38 am
While embedded and highly “cut down” Windows 2000 can be “made secure” (with whatever definition: secure enough to run while directly connected to the Internet) even in the absence of patches (especially if some whitelisting software is deployed), I personally will trust neither a typical merchant nor a typical PoS vendor to actually do it. If I were a QSA in this case, I’d accept heavy OS changes plus no user access plus host firewalling plus application whitelisting as adequate compensating controls. However, I doubt that this is the case for most of those “W2K holdouts.” So, IMHO, that outdated stuff “must die” since it puts everyone at risk (think: botnets). If their W2K install dies together with the merchant – then so be it.
Overall, many security folks treat merchants resisting PCI DSS as either stupid or malicious and irresponsible (or both). The merchants, on the other hand, are simply trying to survive and run their businesses. However, at what cost to society? Every one of those W2K boxes CAN BE (and, in many cases, probably IS) used to attack other sites (think: SCADA …well, I am pushing it a bit here) and spread malware. Still, is lying the right tactic to get them to upgrade?