Beware your inbox!

I just received the following highly sophisticated virus in my inbox:

DEAR RECEIVER,

You have just received a Taliban virus. Since we are not so technologicaly advanced in Afghanistan, this is a MANUAL virus. Please delete all the files on your hard disk yourself and send this mail to everyone you know.

Thank you very much for helping us.


Thanks & Regards
Miss Helen

Added humor: The originator is so techno challenged that they can't even spell technologically. Then again, maybe this was planned by the originator to make us think he was technologically challenged -- clever...

Is Disco making a comeback?

I certainly hope not. But there are a few in the payments and POS industries attempting to bring back those glory days of the 80's, when Disco the dance and disco (as in abruptly disconnected) dialup terminals were all the rage. Since my blog primarily focuses on payments and POS related tidbits, I'll leave the return of Disco, as in the dance, to social bloggers.

Let's take a quick tour in history: I remember the 80's, the days when Tranz-330 was stat-of-the-art. The Tranz-380 was the future and bankers and ISOs were giddy -- the sky was the limit, no merchant was too big. (Yes, there were other terminal manufactures at the time, but my experience is in the US marketplace and Tranz represented probably about 80% of the marketplace, quite possibly more.) Then along comes the dreaded 90's, when POS integration corrupts this terminal Utopia. Then the turn of the century when hackers start corrupting the reputation of the POS integration market. To fix this, Visa launches CISP, MasterCard launches SDP, AMEX and Discover launch their programs (sorry, I'm drawing a blank on their acronyms). A few years later, along comes PCI to combine all these programs into a single program and now you're up to date (albeit Cleft Notes of a Reader's Digest version of the payments history).

Of late I have seen POS vendors and ISO's recommending to merchants to abandon integration and install dial-up terminals -- back to the 80's. Some assume that this route removes the merchant from the burdens of PCI compliance. This could not be farther from the truth. All merchants must comply with PCI DSS if they process, transmit or store credit card data -- via terminal or otherwise. My guess is that this misassumption stems from some PCI wording that excludes stand-alone terminals from specific portions of PCI. But it never excluded the merchant from PCI.

Some argue that these devices are not susceptible to viruses, keyboard loggers, Trojans, or other malware -- I argue they are. Malware requires a CPU, an operating system, and communication ports and stand-alone CC terminals have all these requirements. So far the only thing saving these devices from the headlines is the lack of a deviant programmer with nothing better to do from writing some malware.

Enough on malware, the scariest vulnerability with this retro alternative is that most (all that I'm aware of) dial-up modem traffic from these devices to the processor is unencrypted. Insert a sniffer in the mix or update a phone number in the terminal, and the hacker has free flowing unencrypted payment information. To me, a properly secured network transmitting encrypted card information to the processor is less vulnerable to hackers than a dial-up device transmitting unencrypted card information to the same processor (and I totally ignored the other cons of returning to the 80's and using a non-integrated solution).

Is it an Audit or Assessment?

From time-to-time I see or hear someone getting bent out of shape because another person makes a reference to "PCI audit." Many times the reference is made within a heated debate about the validity of something and this obvious total lack of education opens the door for incorporating into the debate the heredity of the poor sole that mentioned "audit." Well I beg to differ -- it is an audit, not an assessment.

The basis for this mislabeling of the audit process is the title the PCI SSC gave to the auditors -- Qualified Security Assessor (QSA). But as happens often in business, titles do not always match the role.

One of these poor misguided people tried to explain it to me this way: "Assessors do not make judgments as to the validity of something, they are simply documenting and reporting their findings to the PCI SSC whereas auditors make judgments." But QSAs are judging pass or fail for each line item in the PCI DSS or PA-DSS specification and once everything passes based on their opinion, they write up a ROC for PCI SSC's final approval. Based on this definition, QSAs are performing audits.

Then you have the definitions found on Dictionary.com: 

• http://dictionary.reference.com/browse/assessment
• http://dictionary.reference.com/browse/audit

Assessment deals with assessing or appraising the value of something. Audit, on the other hand, deals with official examination, inspection or verification of something. Based on these definitions, the Assessor is doing an audit as well.

I know that most people don't care what the "A" in QSA stands for and they care even less whether it's called an audit or assessment. I'm only writing this so I can easily reference my position when someone brings in my heredity into a heated debate.

Can Never Be Too Safe

This is totally off topic but very funny. Put this in the random thoughts category:

Plaxico Burress On Gun Safety

Gift Card Act of 2009

With much fanfare, the US House of Representatives and Senate passed the Credit Card Accountability Responsibility and Disclosure Act of 2009. For the average consumer and merchant, the full benefits and ramifications have yet to be felt. One section that was mostly overlooked, was a section that specifically addressed general-use prepaid cards, gift certificates and store gift cards. Here it is:

Credit Card Accountability Responsibility & Disclosure Act of 2009

This is a portion of H.R. 627: Credit Card Accountability Responsibility and Disclosure Act of 2009 that relates specifically to gift cards and the like:

TITLE IV--GIFT CARDS

SEC. 401. GENERAL-USE PREPAID CARDS, GIFT CERTIFICATES, AND STORE GIFT CARDS.

The Electronic Fund Transfer Act (15 U.S.C. 1693 et seq.) is amended--

1. by redesignating sections 915 through 921 as sections 916 through 922, respectively; and
2. by inserting after section 914 the following:

SEC. 915. GENERAL-USE PREPAID CARDS, GIFT CERTIFICATES, AND STORE GIFT CARDS.

1. Definitions- In this section, the following definitions shall apply:
   
   1. DORMANCY FEE; INACTIVITY CHARGE OR FEE- The terms ‘dormancy fee’ and ‘inactivity charge or fee’ mean a fee, charge, or penalty for non-use or inactivity of a gift certificate, store gift card, or general-use prepaid card.
   2. GENERAL USE PREPAID CARD, GIFT CERTIFICATE, AND STORE GIFT CARD-
      
      1. GENERAL-USE PREPAID CARD- The term ‘general-use prepaid card’ means a card or other payment code or device issued by any person that is--
         
         1. redeemable at multiple, unaffiliated merchants or service providers, or automated teller machines;
         2. issued in a requested amount, whether or not that amount may, at the option of the issuer, be increased in value or reloaded if requested by the holder;
         3. purchased or loaded on a prepaid basis; and
         4. honored, upon presentation, by merchants for goods or services, or at automated teller machines.
      2. GIFT CERTIFICATE- The term ‘gift certificate’ means an electronic promise that is--
         
         1. redeemable at a single merchant or an affiliated group of merchants that share the same name, mark, or logo;
         2. issued in a specified amount that may not be increased or reloaded;
         3. purchased on a prepaid basis in exchange for payment; and
         4. honored upon presentation by such single merchant or affiliated group of merchants for goods or services.
      3. STORE GIFT CARD- The term ‘store gift card’ means an electronic promise, plastic card, or other payment code or device that is--
         
         1. redeemable at a single merchant or an affiliated group of merchants that share the same name, mark, or logo;
         2. issued in a specified amount, whether or not that amount may be increased in value or reloaded at the request of the holder;
         3. purchased on a prepaid basis in exchange for payment; and
         4. honored upon presentation by such single merchant or affiliated group of merchants for goods or services.
      4. EXCLUSIONS- The terms ‘general-use prepaid card’, ‘gift certificate’, and ‘store gift card’ do not include an electronic promise, plastic card, or payment code or device that is--
         
         1. used solely for telephone services;
         2. reloadable and not marketed or labeled as a gift card or gift certificate;
         3. a loyalty, award, or promotional gift card, as defined by the Board;
         4. not marketed to the general public;
         5. issued in paper form only (including for tickets and events); or
         6. redeemable solely for admission to events or venues at a particular location or group of affiliated locations, which may also include services or goods obtainable--
            
            1. at the event or venue after admission; or
            2. in conjunction with admission to such events or venues, at specific locations affiliated with and in geographic proximity to the event or venue.
   3. SERVICE FEE-
      
      1. IN GENERAL- The term ‘service fee’ means a periodic fee, charge, or penalty for holding or use of a gift certificate, store gift card, or general-use prepaid card.
      2. EXCLUSION- With respect to a general-use prepaid card, the term ‘service fee’ does not include a one-time initial issuance fee.
2. Prohibition on Imposition of Fees or Charges-
   
   1. IN GENERAL- Except as provided under paragraphs (2) through (4), it shall be unlawful for any person to impose a dormancy fee, an inactivity charge or fee, or a service fee with respect to a gift certificate, store gift card, or general-use prepaid card.
   2. EXCEPTIONS- A dormancy fee, inactivity charge or fee, or service fee may be charged with respect to a gift certificate, store gift card, or general-use prepaid card, if--
      
      1. there has been no activity with respect to the certificate or card in the 12-month period ending on the date on which the charge or fee is imposed;
      2. the disclosure requirements of paragraph (3) have been met;
      3. not more than one fee may be charged in any given month; and
      4. any additional requirements that the Board may establish through rulemaking under subsection (d) have been met.
   3. DISCLOSURE REQUIREMENTS- The disclosure requirements of this paragraph are met if--
      
      1. the gift certificate, store gift card, or general-use prepaid card clearly and conspicuously states--
         
         1. that a dormancy fee, inactivity charge or fee, or service fee may be charged;
         2. the amount of such fee or charge;
         3. how often such fee or charge may be assessed; and
         4. that such fee or charge may be assessed for inactivity; and
      2. the issuer or vendor of such certificate or card informs the purchaser of such charge or fee before such certificate or card is purchased, regardless of whether the certificate or card is purchased in person, over the Internet, or by telephone.
   4. EXCLUSION- The prohibition under paragraph (1) shall not apply to any gift certificate--
      
      1. that is distributed pursuant to an award, loyalty, or promotional program, as defined by the Board; and
      2. with respect to which, there is no money or other value exchanged.
3. Prohibition on Sale of Gift Cards With Expiration Dates-
   
   1. IN GENERAL- Except as provided under paragraph (2), it shall be unlawful for any person to sell or issue a gift certificate, store gift card, or general-use prepaid card that is subject to an expiration date.
   2. EXCEPTIONS- A gift certificate, store gift card, or general-use prepaid card may contain an expiration date if--
      
      1. the expiration date is not earlier than 5 years after the date on which the gift certificate was issued, or the date on which card funds were last loaded to a store gift card or general-use prepaid card; and
      2. the terms of expiration are clearly and conspicuously stated.
4. Additional Rulemaking-
   
   1. IN GENERAL- The Board shall--
      
      1. prescribe regulations to carry out this section, in addition to any other rules or regulations required by this title, including such additional requirements as appropriate relating to the amount of dormancy fees, inactivity charges or fees, or service fees that may be assessed and the amount of remaining value of a gift certificate, store gift card, or general-use prepaid card below which such charges or fees may be assessed; and
      2. shall determine the extent to which the individual definitions and provisions of the Electronic Fund Transfer Act or Regulation E should apply to general-use prepaid cards, gift certificates, and store gift cards.
   2. CONSULTATION- In prescribing regulations under this subsection, the Board shall consult with the Federal Trade Commission.
   3. TIMING; EFFECTIVE DATE- The regulations required by this subsection shall be issued in final form not later than 9 months after the date of enactment of the Credit CARD Act of 2009.’

SEC. 402. RELATION TO STATE LAWS.

Section 920 of the Electronic Fund Transfer Act (as redesignated by this title) is amended by inserting ‘dormancy fees, inactivity charges or fees, service fees, or expiration dates of gift certificates, store gift cards, or general-use prepaid cards,’ after ‘electronic fund transfers,’.

SEC. 403. EFFECTIVE DATE.

This title and the amendments made by this title shall become effective 15 months after the date of enactment of this Act.

A complete summary and full text of the entire H.R. 627: Credit Card Accountability Responsibility and Disclosure Act of 2009 can be found at http://www.govtrack.us/congress/bill.xpd?bill=h111-627.

The Steve Sommers' Readers Digest version of the federal law is as follows:

• If you use expiration dates with your gift cards:
  
  1. the expiration term cannot be less than 5 years from the time of purchase or last recharge; and
  2. you must fully disclose the expiration date policy on the card and inform the purchaser prior to the purchase of the gift card.
• If you charge service fees to your gift cards:
  
  1. you cannot charge more than a single fee per month (for most merchants, no big deal),
  2. the fees can only be charged after one year of dormancy; and
  3. you must fully disclose the fees on the card and inform the purchaser prior to the purchase of the gift card.

If you are using gift certificates instead of gift cards, reread my above summary substituting “certificate” every place I mention “card.”

Now a possible gotcha here is the term dormancy -- the law states “there has been no activity with respect to the certificate or card in the 12-month period ending on the date on which the charge or fee is imposed.” Nowhere do I see a definition of “activity.” I know that California considers a balance inquiry as activity; other state only consider adding funds or purchase usage as activity. I'm sure we'll be hearing about this in court.

My recommendation: Don't use card expiration dates and instead charge a monthly service fee sometime after one year of dormancy. To be safe, I would interpret dormancy as any activity including balance inquiries.

I've always recommended not using expiration dates because many states have laws that "expired funds" are to be turned over to the state. Also, some states like California do not allow merchants to use expiration dates. If you still want to use expiration dates, I recommendation would be to not allow recharging the cards as each recharge will add a minimum of five years to the expiration date of the card.

In either case, fully document and prominently display your terms to the purchaser prior to selling the gift card. Any and all card carriers and displays should have the terms. Your web site should have a dedicated gift card page with the terms and conditions and your card stock or gift certificates should have the URL printed on it. The more places you disclose this information, the better. You don't want to be on the receiving end of a “they didn't warn me” accusation.

This Readers Digest version and recommendation, for the most part, only considers this specific federal law. You will need to incorporate any state or local laws that also apply. On the ConsumersUnion.org I did find a summary of various state laws regarding gift cards I thought useful: State Gift Card Protection Laws

Hope this info helps someone.

Side Rant - Formatting

I'm hoping that the topic numbering scheme used in this Act was simply a translation screw-up between the source where I found the document and the real document. Otherwise, someone in our government doesn't know how to follow a numbering standard. I was taught the Harvard format which I assume is the standard since most documents I read follow the same or very similar format:

1. Topic
   
   1. Subtopic
      
      1. Major Detail
         
         1. Minor Detail
            
            1. Subdetail

Whereas this document is using the following:

1. Topic
   
   1. Subtopic
      
      1. Major Detail
         
         1. Minor Detail

Maybe this is some standard attorney format to separate common language from lawyer speak? Or just is this part of the change we were promised?

Au Contraire - Latest Gotcha from PCI SSC

Several month back many forums and blogs were discussing the (at that time) up and coming July 2010 sunset of Windows 2000. Many of these discussions included other already sunsetted operating systems. There were some heated debates over whether or not proper lock-down and compensating controls could keep a merchant compliant. Most of these discussions were settled by a posting in the PCI SCC FAQs:

PCI SSC 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.

Fast forward to today. Now, for many merchants and vendors, comes the first Windows 2000 post sunset scan from a prominent ASV - FAIL. Reason given: One or more scanned servers determined to be running Windows 2000. Upon referring this prominent ASV to the above FAQ on the PCI DSS site, they refer to the Technical and Operational Requirements for Approved Scanning Vendors (ASVs) on the same PCI DSS site:

Technical and Operational Requirements for ASVs

Obsolete environment

The ASV must report and determine as non-compliant any identified obsolete software (for example, application software or operating systems (OSs) no longer supported by the respective manufacturers. Obsolete software may expose the infrastructure to a security-related vulnerability.

The FAQ that many merchants and vendors use takes a risk assessment perspective whereas the Operating Requirements for ASVs takes a MUCH harsher authoritarian perspective -- "FAILED!" It's no wonder there is still so much confusion about PCI even after years educating the masses about PCI; people are still just as confused and pulling their hair out. I sure hope PCI SSC irons this one out quick.

An interesting side note is the wording of the Operating Requirements for ASVs: "Obsolete software may expose the infrastructure to a security-related vulnerability," yet PCI has deemed it non-compliant -- so is it vulnerable or not? If not, why is it not compliant? But this is straining at gnats -- the bigger issue is assuring people that obsolete O/Ss are not necessarily out-of-compliance while telling ASVs that obsolete O/Ss must be deemed out-of-compliance.

If you read any of my previous posts, I always harp on lowering your risk profile by eliminating card holder data from your environment. This emphasizes my belief that if you suffer a breach of card holder data, you will be found out-of-compliance no matter how compliant you thought you were. Using this as an example, if you were using Windows 2000 (post sunset) in your payment environment and your PCI assessment was based on the PCI SSC FAQ, the ASV document would deem you out-of-compliance.

Pondering the Possibilities

Currently the PCI SSC is pondering the possibility of including language that would exclude encrypted cardholder data from the merchants PCI scope if, and only if, the merchant does not have access to the encryption keys used in the process. This is to make it easier for end-to-end encryption (E2EE) solution providers to promote their wares. Security wise, I think this would be a mistake.

I've argued many times on different forums about how tokens (provided they are "true" tokens that are not derived from the PAN) and tokenization are more secure than E2EE data -- format preserving or otherwise. E2EE proponents almost always quotes some report that states a brute force attack on the encrypted data will take umpteen million years of CPU time to crack. There are a few problems with this argument. For starters, I imagine similar arguments were being made back in the single DES days; but then CPU speeds increased exponentially and umpteen million years of CPU time became months, then weeks, then days, and eventually minutes. Another issue is the potential for a yet to be discovered inherent vulnerability in the encryption algorithm or key hashing; SSL1 comes to mind, as well as MD5.

A final issue with the "umpteen million years to crack " argument is that this assumes a brute force attack. If the key is ever compromised by any means -- yes, a brute force attack is one means, but also poor key storage, memory sniffers, disgruntled ex-employee, etc. -- the encrypted data is vulnerable.

Ponder this:

1. PCI SSC adopts some form of language that removes E2EE data from PCI scope. 
2. One or more middle men handle this E2EE data between the starting end point and the final end point: POS application, merchant LAN, Internet service provider, routers, gateway, processor(assuming the gateway is not the end point), etc. 
3. One or more of these middle men log all this E2EE data in the clear -- since E2EE data is already encrypted, this data is out of PCI scope and therefore has no requirement for additional encryption, data retention periods, etc.
4. Everything works securely and flawlessly for weeks, months or years.
5. The E2EE key is compromised by whatever means (brute force, encryption algorithm vulnerability, disgruntled employee, whatever).

While the key was cracked or acquired outside the scope of the merchant, how will this play out for the merchant or any of the middle men in #2 above if it is determined that the source of the breached data was the logs containing the out-of-scope E2EE data?

Now with true tokenization, tokens cannot be cracked; no keys, no possibility of inherent tokenization algorithm vulnerability (assuming true tokenization where the token is not derived PAN). Any middle men storing or logging tokens could and should be removed from the liability equation provided they never touched the real cardholder data.

I hope the PCI SSC carefully consider this issue in it's entirety before adding any out-of-scope wording for encrypted data.

You found me!

Congratulations, you found me!

For any new viewers, I recently moved from shift4sms.blogspot.com to here, paymenttidbits.blogspot.com.

Stand Up and Be Heard

While not directly "payments related," this is something that affects all industries. Don't let the bad guys win. Stand up and let your voice be heard. In November, vote out the corruption -- from both parties.

If your politicians believe they are smarted than the people they supposedly represent - then stand up and let them know how naive¹ they really are. If your politicians believe processes defined in the Constitution are only there as barriers for the unimaginative - then voice your concern. If your politicians believe ramming things through by any means, including bribes, kick backs, favors, arm twisting, threats of prosecution - then vote them out in November. If your politicians believe that the national debit is someone else's problem so spend while the spending is good - then definitely let them know now and vote them out in November.

Lastly, if you think that government is the solution for all problems and the free stuff politicians are promising to provide is truly free, then stay at home on election day - because nothing is truly free. As the famous quote goes: "Government is not the solution to our problem; government is the problem."

¹ Ongoing theme from a previous thread; but this time I am mean the www.dictionary.com definition.

Hitler and Cloud Computing Security

Ok. I found this You Tube video via a post on Evan Schuman's StorefrontBacktalk blog which was found via a post on Bruce Schneier's blog which was found via who knows. Anyway, it's funny and a must see -- if you're a Internet nerd/junky like me:

Hitler and Cloud Computing Security

Security Hole -- Coming to a store near you!

Over the last few years Cambridge University has uncovered a few weaknesses in the EMV technology (a.k.a. Chip & PIN). Just recently they uncovered the biggest flaw yet: EMV is susceptible to a man-in-the-middle attack.

The BBC story can be found here along with a video showing the vulnerability in action: http://www.bbc.co.uk/blogs/newsnight/susanwatts/2010/02/new_flaws_in_chip_and_pin_syst.html

This latest vulnerability appears to be a devastating blow to the primary supporters of the technology -- the banks. Banks are always keeping an eye out for shifting liability from the banks, to, well anyone but the banks. Chip & PIN was the perfect vehicle for this liability shift. Virtually overnight (relative term, overnight in bank time is a 4-8 years in real time) the banks in Europe shifted fraud liability from them to the card holder or the merchant, depending on whether or not the merchant used EMV technology.

After some consumer complaints, bank regulators put some of the liability burden back onto the banks, at least requiring them to provide some proof in the event of a cardholder report of fraud. Now with this latest man-in-the-middle vulnerability, it appears that the liability is firmly back onto the banks.

Most likely a patch will be found for the latest vulnerability, but at what cost to the merchant? They just spent a big chunk of change when they were forced to upgrade to EMV. What will the fix cost them and how long will they have to implement the fix? Canada is currently in the process of forcing their merchants to implement EMV technology. How will this affect the rollout? All big unknowns.

Round 3, Tokenization vs. End-to-End Encryption

Before I get started, a disclaimer. I am a firm believer in a layered security approach. I have said several times, end-to-end encryption (E2EE) has a very important roll in the "optimum" payment security environment. E2EE, by itself, is not a silver bullet. Similarly, tokenization, by itself, is not a silver bullet either. However, if for some reason you are evaluating tokenization OR E2EE, I argue that a properly implemented front-end tokenization solution will reap more rewards than an equivalent E2EE solution.

Round 1: Tokenization enters the payment space. Shift4 releases tokenization to the public domain in October 2005. Initial document described back-end tokenization to address data storage. Since that time, technology has evolved to include front-end tokenization, which addresses data in flight as well as storage.

Round 2: End-to-End Encryption enters the payment space. In March 2008, VeriFone announces it joint end-to-end solution with Semtek. In June 2009, Heartland Payment Systems announces its entry into the E2EE arena with Voltage and E2EE, at least how we know it in the payments space is born.

Round 3: End-to-End proponents lobby PCI to deem E2EE data out-of-scope for PCI, similar to tokens. Recently PCI SSC appears to have conceded in a FAQ entry: "However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it." I believe security wise, this is a mistake and this is an example where "security" and "compliance" go separate routes.

So we are all on the same page, let me first briefly explain the difference between tokens and encrypted data. True tokens (I specify "true" because some tokenization vendors do not follow the definition of token) are not derived from the data it is protecting. A true token is simply a reference to the card data that is stored within a fully PCI compliant system. The token can be a sequential number (1=first card number swiped, 2=second card number, etc.), or it can be a time stamp, a random number, or any combination. The key is that the token is in no way derived from the card number and instead is only a reference to the card information.

Encrypted data, on the other hand, is directly derived from the original data – the card number. A key is used to encrypt the data, and either the same shared key or a related public/private key is used to decrypt the data. What keeps the data safe is the strength of the encryption method used, and the keys themselves. If the keys are ever compromised, the data is no longer safe.

The issue for me here is the decree from PCI SSC, "encrypted data may be out-of-scope." Many will read this statement and a light bulb will pop on: "silver bullet!" This type of thinking can be detrimental to the overall security risk of the card holder data.
Encrypted data can always be decrypted. Whenever I mention this, it triggers an immediate response from various encryption experts about how brute force attacks will take hundreds to billions of years to crack based on today’s technology. Maybe true, if you are only talking about brute force attacks and ignore any possibility of a encryption algorithm weakness (MD5 comes to mind). Also, a brute force attack is not the easiest way to get an encryption key. Key storage and key management are the weakest points of most encryption solutions. My point is, if the key is ever compromised by any means, the encrypted data can be decrypted and is therefore vulnerable.

Now we go back and look at how PCI SSC’s decree affects security. If E2EE data is out of scope, this information can be stored, logged and freely distributed – after all it is out-of-scope. Does this sound secure – especially if you consider encrypted data can always be decrypted?

One aspect where the jury might still be out: Will the card brands take the same stance? If and when this out-of-scope data is ever compromised, this stance would in effect be a safe harbor clause; the card brands have avoided safe harbor clauses for merchants like the plague. Breach equals fine and I don't see the card brands honoring any out-of-scope decree from PCI SSC as a safe harbor.

As I stated in the beginning, a layered security approach is the best. If it’s a one or the other decision, you know my recommendation. If you decide to go the E2EE route, my recommendation would be to ignore PCI SSC in this case and instead treat E2EE data as in-scope.

Until next time…

What a Rip!

For the most part, you can file this post in the who cares category -- Steve is just being a cry baby -- but I thought I would take a break from ticking off POS vendors, and instead tick off a competitor. If you don't have time to waste reading non-important stuff, simply come back later and I'll be sure to have a more important topic posted. Notice the byline above, "random thoughts" and "simply vent" -- this qualifies for both.

Do you ever get that feeling you're being watched? Not watched as in big brother is watching (but come to think of it, I think they are!). But more watched like in a little Chihuahua staring at you from the ground below while you are eating. But then the little rodent gets impatient, it tries whatever it can to either get your attention, or better yet, distract you in the hopes you drop some crumbs it's way.

I get that feeling with one of Shift4's competitors, X-Charge by CAM Commerce Solutions. In the past they have covertly hired employees from Shift4 -- not for their technical skills, sales prowess, or expertise, but simply for their knowledge of trade secrets and customer lists (it's strange, how these ex's move on after their information ceases to be relevant due to time). Imagine my surprise when Shift4's marketing director sends me a link to their site and now the covert is actions have switched to overt actions by ripping content straight from Shift4's site and putting it onto their site. But I'm not talking features and benefits, or even catchy phrases or graphics; ripping off stuff like this is far too often common on the Internet. No, they rip partner lists for republication and don't even have the time to reorder them or remove little asterisks that signify something on Shift4's site but not on theirs. Talk about "me too" marketing!

Shift4: http://www.shift4.com/pos_pms.htm
X-Charge: http://www.x-charge.com/products/listHospitality.asp (cut & paste the URL yourself, I don't want to give them the benefit of a search engine boost)

Some interesting points of fact, many of the partners listed on both sites have exclusive partner arrangements with Shift4. Several listed are custom interfaces that only interface to Shift4's DOLLARS ON THE NET. Some listed are no longer in business and are only listed on Shift4's site because there are customers still using the applications. Lastly, if you were to call most of the vendors on the list you'll find they never heard of X-Charge and will confirm there is no existing interface. If you call CAM Commerce, they will most likely tell you that they will work with any of the vendors listed (as opposed to they currently work with the vendors).

In a prior post, I prematurely used labeled a vendor as "unscrupulous" without considering all the possibilities for the vendor's action. In this case I don't think I would be out of line using this word -- I think this vendor is unscrupulous (not to mention lazy). If you are in the market for a payment gateway, you may want to cross these guys off your list.

Merchants beware when shopping for something as important as a payment gateway provider. If the provider gives references or lists interfaces, do some fact checking for yourself. Call some and if facts don't agree, dump them. Beware of weasel words, or more importantly, discrepancies in phrases like "we work with" vs. "we will work with." Make sure what salesmen tell you verbally or via email agree with the information on their site, "we work" vs. "we will work" is a big red flag. Make sure any reference list is their reference list. Good luck.

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

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.

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

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

¹Correction -- see follow-up post POS Ending Event - Redux.

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.