"Merchants who are processing, storing or transmitting cardholder data as part of authorization or settlement are required to comply with the terms of the Payment Card Industry Data Security Standard (PCI-DSS). The PCI-DSS requires Merchants to use only PA-DSS compliant payment processing applications. Therefore, any Merchants using a payment processing application that is not PA-DSS compliant are also not PCI-DSS compliant. Any Merchants who are compromised and found not to be PCI-DSS compliant at the time could be subject to significant fines and penalties by the Cardholder Industry. For more information on the PA-DSS, please refer to the following link on the Payment Card Industry Security Standards Council (PCI-SSC) web site: https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml. For more information on the PCI-DSS, please refer to the following link on the Payment Card Industry Security Standards Council (PCI-SSC) web site: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml."
Holy crap Batman, is this saying what I think it is saying? All point-of-sale applications running on older non-current operating systems out of compliance! 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; 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).
The above quote was from a POS vendor's letter to it's merchants. It is blunt, to the point, and details dire consequences of being out of compliance when Microsoft stops patching Windows 2000. The problem is, it's crap and nothing more than a FUD marketing campaign. To prove my point, let's refer to the documents that this vendor referenced. The PA-DSS document states the following on page iv under the section "Scope of PA-DSS":
The following list, while not all inclusive, illustrates applications that are NOT payment applications for purposes of PA-DSS (and therefore do not need to undergo PA-DSS reviews):
- Operating systems onto which a payment application is installed (for example, Windows, Unix)
- Database systems that store cardholder data (for example, Oracle)
- Back-office systems that store cardholder data (for example, for reporting or customer service purposes)
Hmm, operating systems are specifically stated as "out of scope" for PA-DSS compliance purposes. Let's continue this expedition and look at PCI-DSS:
6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.
6.1.a For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security patch list, to verify that current vendor patches are installed.
6.1.b Examine policies related to security patch installation to verify they require installation of all critical new security patches within one month.
6.1.a For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security patch list, to verify that current vendor patches are installed.
6.1.b Examine policies related to security patch installation to verify they require installation of all critical new security patches within one month.
A little vague -- "latest vendor-supplied security patches." If a vendor is no longer supplying patches, as long as you have the latest patch, aren't you compliant? I'm so confused. Let's check the PCI-SSC web site for clarification. On the web site we find a FAQ:
Would older operating systems that are no longer supported by the vendor be deemed non-compliant with the PCI DSS?
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. Exploit of legacy code is the main risk posed by an older operating system. Since well-known exploits are typically included as signatures to anti-virus, IDS/IPS and firewall filtering, a compensating control to consider is performing an exhaustive search to ensure that all known exploits for that operating system are identified, and that anti-virus, IDS/IPS and firewall rules are all updated to address those exploits. 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. The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so. For more help with compensating controls, and for questions about whether a specific implementation is consistent with the standard or is 'compliant', please contact a Qualified Security Assessor.
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. Exploit of legacy code is the main risk posed by an older operating system. Since well-known exploits are typically included as signatures to anti-virus, IDS/IPS and firewall filtering, a compensating control to consider is performing an exhaustive search to ensure that all known exploits for that operating system are identified, and that anti-virus, IDS/IPS and firewall rules are all updated to address those exploits. 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. The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so. For more help with compensating controls, and for questions about whether a specific implementation is consistent with the standard or is 'compliant', please contact a Qualified Security Assessor.
So PCI-SSC states specifically that unsupported operating systems are not automatically deemed out of compliance. In other words, this vendor letter is nothing more than a FUD marketing letter designed to scare merchants into upgrading to the latest version of the vendors software and paying the associated fees.
This is an excellent example of what some unscrupulous, ill-advised, or naive marketing departments do to generate revenue. What makes this even more disturbing is that this vendor, who's name shall remain anonymous, sits on the PCI board -- It's no wonder that there is so much confusion about PCI and why so many merchants cringe at mere utterance of those three letters. While here I zeroed in on one vendor's letter, this vendor is not unique as I've seen several.
To merchants that receive letters like this from their POS vendor: Do some research. Talk to you a QSA if you're unsure. A little research time may save you thousands of dollars.
1Correction -- see follow-up post POS Ending Event - Redux.
This blog post makes me very sad. How many merchants are you enabling to cling to outdated software and further increase their risk of compromise? I would cut the POS vendor some serious slack on this. Personally, I applaud vendors that are pushing their merchants to update. I believe them to be in the right. Here's why...
ReplyDeleteA merchant running software (OS included) with known vulnerabilities and no way to patch takes on additional risk. In the case of an OS as popular as Windows, we're talking a high risk because history has shown that these vulnerabilities are in fact exploited by malware. Sure, the vulnerabilities CAN be handled with compensating controls, but the lack of updated software removes a layer of defense.
Have you considered the very real possibility that this vendor knows their customer base and knows that proper implementation of compensating controls is outside of their capabilities? How many merchants are truly capable of managing IDS and proper configuration of a firewall? Even if a merchant has talented staff to do these things, AV signatures catch a small percentage of modern malware designed to evade signature detection. Network IDS/IPS has its limits, many time also related to that same dependence upon signatures. Firewall rules will only stop network vulnerabilities if the network service is not opened to untrusted networks. What happens if there's a business need? I assume the PCI SSC understands the risk of running software that receives no updates which is why they're pushing for updated OS as well. Did you read the PCI FAQ? "The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so."
If merchants are breached due in part to a software vulnerability by the ever increasing criminal hacking and related crimeware, no amount of pointing at this PCI FAQ and claiming they had a plan to eventually update will stop their pain. They will still be found non-compliant to the PCI DSS because they couldn't understand and properly implement VERY complex, high maintenance compensating controls that are less effective than not having the vulnerabilities int he first place. At the end of the day, those compromised merchants will pay fines. They will face other costs like loss of business after their name is in the local paper. They may go out of business. This is not FUD. I've been on calls with these merchants.
POS vendors and VARs want their merchants to be safe. In a time when merchants sue their POS vendors for breaches, they have even more reason to push for security. I don't blame them one bit for pushing merchants to update their systems to a version that still receives security updates.
I ask you to please reconsider your understanding of the PCI FAQ entry and your position on vendors that tell merchants to update. If a vendor is at fault here, it's for how their message was delivered.
Lucas,
ReplyDeleteYou make some valid points. My focus here in the post is on vendor scare tactics and their ramifications. In your argument you accurately detail some the complexities of being secure. I would argue that these complexities exist today and the only difference is some arbitrary date: A merchant being breached on June 30th, 2010 using Windows 2000 would be compliant whereas the same breach on July 1, 2010 would be out-of-compliance?
There is big difference in "compliance" and "secure"; sometimes the two meet, many times they do not. But there are compensating controls that can address both compliance and security. I would argue that there are compensating controls that exist today that would better address cardholder data security than whether or not Microsoft or any OS vendor provides patches.
My point here is that vendor need to stop scaring merchants with misinformation as it only hurts PCI as a whole. The three letters PCI is already rivaling the three letters IRS in making merchants cringe. In today's economy, if a merchant must decide between a compensating control to secure his environment vs. a costly POS upgrade that he can't afford, then the merchant reads something like this saying upgrade or be out-of-compliance because PCI says so, the vendor might choose nothing because what's the point -- out-of-compliance is out-of-compliance and a compensating control won't help me.
In the case I used as an example, if the letter stated that "we can no longer support our application running on older OS and therefore cannot guarantee your PCI compliance" (well, vendors usually don't "guarantee" anything as far as PCI goes, but that's another story), then I would not have an issue because the vendor would no longer be blaming PCI. The refocus from "PCI says" to "we say" makes a big difference -- the first being you have no choice vs. the latter being it's on you.
There is one last point I would like to touch. With older and unsupported versions operating systems, an argument could be made that many pose a lower risk profile than the latest and greatest supported version. There are two primary reasons for this: 1) most of the vulnerabilities are known and compensating controls or procedures have been developed to address them and 2) most OS versions come with more features than the prior version and the chance for vulnerabilities increase exponentially as features were added.
RE: If a vendor is at fault here, it's for how their message was delivered.
ReplyDeleteIf you read my follow-up, you'll see I did back off quite a bit from my initial posting. And I don't know if you read the story on StorefrontBacktalk.com by Evan Schuman, but he does even a better job than I on possible reasons for letters like these.
I agree that Evan's response is good and muses other possible reasons for the letter. Thanks for posting the follow-up which I thought was noble of you.
ReplyDeleteBy commenting on this post, I intended to provide in-line perspective from the other side of the argument. Is it similar to the argument presented by the QSA you were discussing this issue with?
The QSA's stance was that someone higher up the corporate chain of command interpreted PCI this way and that was the way of the world. We weren't thinking of ourselves here, after all our scope is limited -- we know how many servers and PC's we have and we easily estimate a cost and timeline for the project. Instead, we immediately were thinking of our merchant base and knew the 7/1/2010 deadline was not possible if this was the interpretation -- both in cost and in time. After finding the FAQ, they changed their interpretation but for some reason, we didn't query the FAQ sooner and this turned into a big project.
ReplyDeleteWell said Lucas!
ReplyDeleteLet's not forget that it is in Shift4's interest to convince Merchants not to upgrade their POS system to the latest PA-DSS validated version. Instead, Shift4 wants Merchants to install the Shift4 product on top of their old legacy POS. Not what I would call a sound IT strategy.
You might say this blog post is a bit self-serving on the part of Shift4.
So who is really the unscrupulous and deceptive vendor here? You decide.
Umm, Jim,
ReplyDeleteThe intent of my post was not to single out one vendor but to address your post...
If Shift4 benefited from convincing customers to not upgrade, then you might have a point. Shift4 does not benefit. Yes, Shift4 offers compensating controls to secure cardholder data and these compensating control can be used on legacy versions, but Shift4 can be used in the latest version as well as legacy and there is no cost difference to the merchant. Shift4 is a merchant advocate, and I fail to see how that can be construed as unscrupulous or deceptive.
In my opinion, POS vendors and VARs should not be thrown under the bus when they push merchants to keep up to date. Merchants look to them for guidance to begin with and sue them if they feel they didn’t receive guidance. POS vendors and VARs are in a tough situation. They see these lawsuits filed by compromised businesses. The last Visa payment app security mandate is around the corner that requires "PA-DSS compliance." Only recently did Visa state that PABP compliance meets the mandates specifically. Even then, that same FAQ urges vendors to keep merchants up to date with POS software compliant to the latest version of the PA-DSS standard. What happens when a vendor doesn’t push their merchant to keep up to date and that merchant is compromised? In the letter you present, the vendor is trying to get merchants to keep up to date like they’re supposed to be doing. Sure there’s technically a way to get around the Win2k EOL that they use for extra push, but that’s only going to be a practical workaround for miracle merchants that have information system security experts working for them.
ReplyDelete"Instead, we immediately were thinking of our merchant base and knew the 7/1/2010 deadline was not possible if this was the interpretation -- both in cost and in time."
Deadline for being PCI DSS compliant 24/7/365 and not getting hacked is long overdue. And I do mean compliant, not validated. Sticks have always come out post compromise for non-compliance. Software patching or compensating controls fall into this compliance bucket. After vulnerabilities are discovered and not patched, I hope merchants running older software are properly implement compensating controls and know without a doubt that the unpatched vulnerabilities will not be part of a compromise event.
All the misguided focus on due dates is an unfortunate side effect of card brand mandates designed to provide a thin slice of strategic proactive enforcement. Proactively enforcing the entire PCI DSS on millions of level 4 merchants is more difficult than replacing the entire electronic payments infrastructure.
For a merchant lacking compliance in several areas, I totally agree that there’s other items higher in priority. That does not however excuse the PCI DSS requirement to keep software up to date in order to protect from known vulnerabilities. Vulnerabilities that will undoubtedly be exploited in the wild by malware written with polymorphic attributes and packed for obfuscation to evade signature detection. What happens when a merchant employee that doesn’t understand security browses NY Times and inadvertently picks one of these up due to an unpatched W2k vulnerability? Will the merchant’s legal representation turn on their vendor or VAR for not keeping them up to date?
Lucas,
ReplyDeleteYou're keeping me busy and you make very valid arguments. I dread bringing in lawsuits into any argument because once you introduce them, all bets are off. People can sue for any reason. If a merchant gets breached, there is a good chance there will be a lawsuit whether or not the merchant had the latest OS patch; whether or not the merchant was advised, forced, coerced, whatever; whether or not the merchant was compliant; whether or not the merchant failed every other aspect of PCI beyond the control of the vendor. I find it hard to believe the example letter would prevent the vendor from being sued if a merchant were breached.
I fully agree that the deadline for being compliant has already passed and it's a 24/7/365 project. Where we disagree is in the means for compliance and more importantly, security. While the mythical goal of security is to be 100% secure, 100% of the time, this is not a realistic goal because security is a three way balancing act between security, usability and cost. A merchant can achieve 100% security by flipping off the power switch; of course usability is 0% but cost is $0. You can also approach 100% security and 100% usability, but the cost would be infinite. To me, you have a better chance to convince merchant to move towards that mythical 100% security if they can afford it. Many will ignore security entirely if they think they can't afford it or if they think it is an endless sump for money. I think letters like this simply turn merchant off -- many will simply chalk it up as another Y2K scare.
In the old days (just a few years back), merchants calculated their ROI for a POS over 10-15 years. The problem is, merchants realize that OS versions come out every 2-3 years. With this interpretation the ROI calculation changes dramatically. Not only do you risk turning people off to security, now you can change the whole POS industry dynamic and basically change it into a commodity. Why would any merchant pay many thousands of dollars for a POS upgrade, millions if you're talking about a franchise, for a POS that will only be compliant for 2-3 years at best?
I do not usually subscribe to the "ends justify the means" way of thinking. As you can tell, definitely not in this case. Also, thus far, someone has to convince me that the latest Windows OS (in this case) is any safer than a properly configured W2K with the latest patches. As I mentioned previously, the more features OS vendor adds to the OS, the more possibilities there are for vulnerabilities.