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…