Tokenization, the Newest Horse - err, Camel - in the Stable

As the old saying goes, "a camel is a horse designed by a committee." This saying perfectly describes the recently published PCI DSS Tokenization Guidelines from the PCI SSC. While the original intent of the document was a noble one, the final version fell way short.

The problem with having multiple blogs is to post onto multiple blogs. To avoid content duplication, please go here to read my post: http://blog.shift4.com/2011/08/tokenization-the-newest-horse-err-camel-in-the-stable.html

My take on Swipe Fees

There is an ongoing debate in the restaurant and retail industries about swipe fees for debit cards. There are bills being written and debated in congress that address swipe fees and I see trade associations from both industries cheering on these new regulations. My advice:

Quit crying for government regulations and

start fixing the problem yourself!

There is no regulation that I'm aware of that says a business must accept plastic -- credit or debit. If merchants think the card brands are charging too much, organize something that would get your point across. Have a "no plastic day" or "no plastic week". If enough merchants participated, this would send a strong message to the card brands and with little risk of unforeseen consequences. To me, this debit swipe fee trivial, a much bigger issue are the different rates for reward cards vs. non-reward cards and not knowing the fee up front, during the authorization event. It seems strange to me that the reward card rates are rarely, if at all mentioned by these same trade groups and the reward rates are much more significant than the debit rates.

It’s a cliché of mediation, uttered by every mediator trying to push two unhappy parties to reach agreement on a resolution, that "a good settlement is one where both sides are unhappy." The problem is when politicians create regulations, having both sides unhappy does not buy votes so one side or the other is going to be ecstatic, while the other side is going to get screwed. In this environment things will change because both sides need to be profitable and this is where unforeseen consequences enter the picture. Many times (I would say most times when it comes to government regulations), these unforeseen consequences can be worse than the original problem that was being addressed. I strongly believe that it much better to keep politicians out than to suffer the unforeseen consequences that will ensue.

Some Recent PCI Results

I just read a report on a PCI survey quoting some PCI statistics: PCI DSS compliance generates results. According to a recent survey performed by Imperva and the Ponemon Institute, businesses tend to perceive PCI compliance as something that does not have a positive impact on their security systems. However, the survey's results indicate companies that maintain PCI-compliant systems are significantly more secure than their non-compliant counterparts.

While I think PCI is a good thing because in a round about way it forces merchants to recognize security, I question statistics like this -- particularly the first number quoted: "...64 percent of PCI compliant respondents did not experience a data breach involving credit card data during the past two years."

In the past Visa has stated "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." Based on this statement I question whether or not the 36 percent of the PCI compliant respondents that were breached were "PCI compliant?" A catch-22. The report should have said 100% of PCI compliant respondents were not breached vs. some percentage of the non-compliant respondents were breached.

Nit-picky I know, but as my blog byline states, random thoughts.

Beware Mac users - as popularity grows, so does the target on your back

It's been a while since my last post. I hope to start posting somewhat regularly again in the near future. It's been a madhouse around here as we have been building a new data center from scratch; new hardware, more hardware, new O/S, more memory, new software, new, new, more, more, better-stronger-faster everything, etc., etc. In the last few weeks we've been migrating various services and customers to it; throw in our annual PCI audit and presto -- no time. You'll hear more about this entire project in the next few weeks. For now, suffice it to say it's been a busy time.

Over the years I have posted on several forums my belief that no operating system is inherently secure simply because it is not Windows. Many anti-Windows zealots tout that Linux or Mac or whatever is much more secure based on the number of reported hacks and vulnerabilities: "Hey, simply look at the number to prove my point." And this argument always has a reference to some vulnerability report showing Windows (some big number), their O/S of choice (some little number). I always point out a very similar report showing market share: Windows (some big number), their O/S of choice (some little number). My argument is that hackers go to where the money is -- the market leader.

Well an interesting read that just came out the other day: Coming soon to a Mac near you -- serious malware. When I read this article I had to check back to the author a few times to make sure it was not me as an alias. Give it a read if you have some time.

From Europe with Love

The Peoples Republic of California is looking more and more like Europe everyday. In case you missed it: California retailers can't ask patrons for ZIP Codes, court rules.

In reading the story, the courts ruling seems like a noble one -- protect consumer privacy. But I feel this blanket decision totally ignores the rates merchants are charged processing these transaction with vs. without address verification information and all but ignores the security aspect for merchants requiring a ZIP code. To me, a ruling that merchants could not use any information associated with the processing of the payment for marketing or purposes, then it would have been fine. When I saw the headline, it was screaming: "CALIFORNIA WELCOMES ALL SCAMMERS AND FRAUDSTERS WITH OPEN ARMS!"

As to the rate difference, California card-present merchants will need to decide what to do in the event a card cannot be swiped: Don't ask for the ZIP code and accept the higher cost and higher potential for a fraudulent transaction OR ask for another form of payment. My advice with be the latter, but this may not be the optimum advice for all merchants.

The court touched on the security aspect, but it does leave a big hole: "....allows ZIP Codes to be collected under certain circumstances, such as at gas station pumps where the information is requested for security reasons..." -- why wouldn't all merchants fall under this "certain circumstance?"

And then the biggest little line in the entire story: "The court said retailers may still ask consumers to produce a driver's license for identification purposes but may not record the personal information on it." This advice from the courts goes against most (maybe all) merchant agreements. I'm not sure if this was a simple oversight by the courts showing lack of knowledge in payment processing regulations, or if this was an intentional warning shot over the bow of the card brands?

Forced Password Changes - good or bad?

For years now there has been a debate in the security community as to whether or not users should be forced to change password at regular intervals and if so, how often. On one side there is the argument that changing passwords frequently makes it harder for hackers to acquire a users password and limits the exposure if a hacker were to acquire a user's password. On the other side you have the argument that forcing users to change password increases the chances for forgotten passwords and more dangerous, the chance that users will write down passwords on paper or post-it notes stuck to their monitor or under their keyboard.

I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.

A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:

“PCI DSS 8.5.9 Change user passwords at least every 90 days.

• 8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.
• 8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”

“PA-DSS 3.1.4 The payment application requires changes to user passwords at least every 90 days. (aligns with PCI DSS Requirement 8.5.9)”

The 2005 OWASP best practice included the following:

“Passwords are trivially broken and are unsuitable for high value systems. Therefore, ...

• Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.”

This tells me that in 2005 the OWASP people were leaning to the side of the first argument. Now, the latest 2010 OWASP states:

“Password Guidelines...

• Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely...”

While “frequently” is somewhat vague, I interpret this as OWASP is leaning toward the latter argument now.

The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:

“However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.”

But, these notes appear to have limitations, in the case of PCI DSS:

“The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published...”

and in PA-DSS:

“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”

So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.

I welcome your thoughts.

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