This is page 2 of:
Will Old OS Cause PCI Violation? No, But Marketing Still Says So
“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).
-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?