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.
A free form area where I can post random thoughts and ideas or simply vent on various current events affecting the payment industry or topics I have addressed on other forums.
Showing posts with label technology. Show all posts
Showing posts with label technology. Show all posts
Tuesday, May 3, 2011
Wednesday, November 10, 2010
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).
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).
Labels:
compliance,
PCI,
POS,
processor,
technology
Thursday, September 24, 2009
PCI SSC Community Meeting and Emerging Technologies
The PCI SSC Community Meeting just concluded. I only attended one of the three days and that was enough for me. I fully admit I have a lot of nerd like tendencies, but apparently not enough to make a three day event on security exciting. To me, there were four highlights: the food did not kill anyone, the cocktail event was hosted, Bob Russo does a decent Elvis, and the Emerging Technologies session.
Highlights 1, 2 & 3, I'll just leave it at that. If you want more details, I urge you to attend the next community meeting.
The Emerging Technologies session had several points of interest but it left me wanting more. In a nutshell, PCI SSC contracted PricewaterhouseCoopers (PwC) to evaluate and create a report on emerging technologies and how they impact PCI. The summary given at this meeting was a 100,000 foot view of various emerging technologies – yes, 100,000 foot view, not the more common 50,000 foot view. While they made it a point that the report in no way endorsed any one technology and the report was not intended to rate the technologies, they did detail the four most popular technologies: End-to-End Encryption, Tokenization, Virtual Terminal, and Magnetic Swipe Authentication.
Magnetic Swipe Authentication technologies address card present fraud, but do not really address any PCI security or scoping issues so I'll skip that one. The other three; yeah and it's about time! While I don't agree with some details of the how they rated cost vs. reward vs. impact in different categories, I gave PwC a little leeway because they were bundling multiple vendor solutions into fairly broad categories.
The only category rating that really stuck out like a sore thumb was the business impact of end-to-end encryption vs. tokenization – they gave end-to-end a less business impact rating (more favorable) than tokenization. Shift4 provides solutions that straddle all three technologies (end-to-end, tokenization, and virtual terminal) and from experience, tokenization has far less impact to the business flow than end-to-end. Reason being, the merchant systems never have access to the card number. While security wise, this is a plus for end-to-end, business impact wise there are a lot of gotchas. One example is that many risk and customer loyalty systems use the card number (or more preferably, a hash of the card number) as a key to look up the customer. Stronger forms of encryption produce non-repeatable results when the same information is encrypted so this simple process of a customer lookup becomes problematic.
All in all, just the fact that the PCI SSC is seriously looking at these emerging technologies is promising whereas heretofore, they have always brushed this off as a risk/compliance judgment call for the acquiring banks. I can't wait to see what PCI SSC does with this information and I hope they publish the PwC report.
I will mention one note that I feel was a lowlight: Some of the questions in the Q & A sessions, I'm pretty sure, were asked in similar events three and four years ago. The root cause of the biggest areas of confusion stems from the gap between security and compliance. Bob Russo is the first to state the PCI SSC has nothing to do with "compliance" – instead, PCI is the keeper of the security standards. Yet the card brands dictate that PCI compliance is mandatory.
Highlights 1, 2 & 3, I'll just leave it at that. If you want more details, I urge you to attend the next community meeting.
The Emerging Technologies session had several points of interest but it left me wanting more. In a nutshell, PCI SSC contracted PricewaterhouseCoopers (PwC) to evaluate and create a report on emerging technologies and how they impact PCI. The summary given at this meeting was a 100,000 foot view of various emerging technologies – yes, 100,000 foot view, not the more common 50,000 foot view. While they made it a point that the report in no way endorsed any one technology and the report was not intended to rate the technologies, they did detail the four most popular technologies: End-to-End Encryption, Tokenization, Virtual Terminal, and Magnetic Swipe Authentication.
Magnetic Swipe Authentication technologies address card present fraud, but do not really address any PCI security or scoping issues so I'll skip that one. The other three; yeah and it's about time! While I don't agree with some details of the how they rated cost vs. reward vs. impact in different categories, I gave PwC a little leeway because they were bundling multiple vendor solutions into fairly broad categories.
The only category rating that really stuck out like a sore thumb was the business impact of end-to-end encryption vs. tokenization – they gave end-to-end a less business impact rating (more favorable) than tokenization. Shift4 provides solutions that straddle all three technologies (end-to-end, tokenization, and virtual terminal) and from experience, tokenization has far less impact to the business flow than end-to-end. Reason being, the merchant systems never have access to the card number. While security wise, this is a plus for end-to-end, business impact wise there are a lot of gotchas. One example is that many risk and customer loyalty systems use the card number (or more preferably, a hash of the card number) as a key to look up the customer. Stronger forms of encryption produce non-repeatable results when the same information is encrypted so this simple process of a customer lookup becomes problematic.
All in all, just the fact that the PCI SSC is seriously looking at these emerging technologies is promising whereas heretofore, they have always brushed this off as a risk/compliance judgment call for the acquiring banks. I can't wait to see what PCI SSC does with this information and I hope they publish the PwC report.
I will mention one note that I feel was a lowlight: Some of the questions in the Q & A sessions, I'm pretty sure, were asked in similar events three and four years ago. The root cause of the biggest areas of confusion stems from the gap between security and compliance. Bob Russo is the first to state the PCI SSC has nothing to do with "compliance" – instead, PCI is the keeper of the security standards. Yet the card brands dictate that PCI compliance is mandatory.
Subscribe to:
Posts (Atom)