Wednesday, January 27, 2010

POS Ending Event - Redux II

In my prior POS Ending Event posting and it's Redux, some read them as a vilification of a POS vendor. The intent of the posts were to warn merchants that they need to do their own research and just because materials reference PCI does not make it fact. In the original post I used one vendor's letter as an example and some interpreted this as an attack on this vendor as opposed to this is something vendors, or marketing departments sometimes do. I gave some reasons for this but even my reasons were misinterpreted as "stupid vendor."

Apparently I was naive in that my definition of naive was wrong. My understanding of naive was "an innocent misunderstanding or innocently believing incorrect information." In referencing dictionary.reference.com, their closest definition is "having or showing a lack of experience, judgment, or information" -- well, now I've really stepped in it as that was not my intention. Sorry. Someday I hope to have this English stuff down.

Anyway, I'm hearing second hand that this particular vendor has written proof from PCI SSC that clearly states that "they (PCI SSC) will immediately deem any products that only operate on an O/S that is no longer supported by the O/S vendor as non compliant." I'm also told this was backed up by one of the major card brands and the vendor's QSA.

I'm hoping to get a copy of this letter because if so, this changes everything. I can see an incorrect interpretation by a QSA, after all, this was the seed that started me on this topic. I can also see one of the major card brands stating something like this -- these are huge organizations and many times you'll get a variety of answers based on who you happen to ask. But PCI SSC?! If this is what they are telling their members and QSA's, then this is a real POS Ending Event and this vendor is simply an innocent victim of PCI. Stay tuned...

Monday, January 25, 2010

POS Ending Event - Redux

Over the weekend I received several emails on my prior blog entry, POS Ending Event - July 1, 2010!!! Based on the response, this posting appears to be my most popular thus far. Most were favorable and many had guesses: "was it this vendor or that vendor because I have received similar letters." An interesting point is that of all the guesses, none guessed the vendor that I used in my example. This confirms my belief that marketing campaigns like this one are as wide-spread as I thought.

The vendor who I used as the example also contacted me and in hind sight, 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. 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. Anyway, the intent of Friday's post was not to finger point to one particular vendor as there are many in the same situation. The real intent was to make merchants aware of some of the misconceptions that plague PCI.

The reason for my ire last Friday dealt with this exact same topic. We (the company I work for) were having several days of debate with a QSA (again, who shall remain anonymous) about the July 1, 2010 patch cutoff date by Microsoft. The QSA's corporate party line was that as of 7/1/2010, Windows 2000 will no longer be compliant under PCI. We obviously did not agree and didn't know if they realized the scope or magnitude of their interpretation: A majority of the POS merchants are currently out-of-compliance because there are many POS applications running on non-current operating systems: old Unix, old Linux, old Windows. I would venture to guess that a large percentage of existing firewalls use old o/s as well and would also be deemed out-of-compliance based on this same interpretation. On 7/1/2010 another huge segment of merchants would be out-of-compliance overnight as Microsoft stops patching Windows 2000. Take all those pats on the back that the cards brands and PCI-SSC have been giving themselves about industry wide PCI acceptance and compliance percentages and throw them out the window. After several to and fro emails and walking up the chain of command, using the same references given in my post, we finally got our point across. At the end of this, I felt I had to write something about this experience and this vendor's letter happened to be within my reach. I apologize if my posting came across as anti-XYZ vendor.

As I ended my last post, do your research. The correct information is out there. With Friday's example, the information was not all that hard to find.

Friday, January 22, 2010

POS Ending Event -- July 1, 2010!!!

Example vendor letter...
"Effective July 1, 2010, Microsoft will discontinue their 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.

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


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.


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.

Thursday, January 21, 2010

Yet Another Conflict in the PCI World

I'm really getting tired of all the conflicts in the world; there are conflicts everywhere. But there is one that does not get much press attention. You don't hear about this on Fox News, CNN or other media outlets, at least not yet. It's a secret conflict that for the most part, only has one side! Huh? you ask. How can a conflict only have one side? Well here is the latest conflict I am referring to: Trustwave acquires BitArmor. The conflict? Interest -- QSA's selling security solutions.

Thus far, the PCI Security Council has all but ignored the conflict of interest in QSA's selling security wares. I predict that this will eventually give PCI a big black eye. If I'm not mistaken, wasn't it similar conflicts that toppled Enron and WorldCom -- CPA's auditing the books as well as maintaining the books? I don't see much of a difference in this example with CPA's vs. QSA's for auditing security compliance while providing the security services and solutions being used.

My prediction is that these conflicts will make headlines in the near future. I have to imagine that if Heartland or TJ-Max were not only stamped as PCI compliant by their QSA, but were also relying on their QSA's products or services to become compliant, that this little conflict of interest would gained as much attention as the breach itself.