Small businesses should not expect to fly under the radar forever.
The easiest way for small businesses to address the information security requirements imposed by credit card companies is the wrong way. I'm talking about lying and praying.
In 2004 the major credit card companies got together to define a common Payment Card Industry Data Security Standard (PCI DSS, often referred to as just PCI). They are gradually ratcheting up the pressure on merchants of all sizes to comply. Large companies, and some smaller ones that process a large volume of transactions (particularly if they're doing it on the Web), are required to have an independent review of their processes and systems by a security professional credentialed as a qualified security assessor (QSA). Most small businesses can instead complete a self-assessment questionnaire, where they essentially grade themselves. That's where the lying comes in. It's not so hard to check off all the right answers ("Sure, I review my e-commerce server logs on a daily basis.") without actually making them true.
If you're lying, you had better also be praying. If caught, you could be fined for non-compliance, to the tune of tens or hundreds of thousands of dollars--enough to put many a small organization out of business. Expect even harsher treatment if someone hacks your systems and downloads card data you claimed you weren't even storing.
Most of the requirements are basic security, like making sure there is a firewall between your Internet connection and any system that stores credit card numbers. Factory default passwords on your network equipment must be changed, so that no one can log on as user "admin," password "admin." And so on. More specifically, you're responsible for protecting card holder data, and there's some data you're never supposed to store--like the full contents of a card's magnetic strip.
Many small businesses are still under the impression that the rules don't apply to them because they're too small, or because they don't conduct e-commerce. Actually, the rules apply to any business--and even any nonprofit--that takes credit card payments. You can look for ways to lighten the compliance burden, but you can't get yourself off the hook entirely. Even if no one has yet compelled you to complete a questionnaire or conduct an automated scan of your networks, you're still supposed to be locking down your systems.
Some businesses complain this all sounds too complicated and expensive. But they are missing the point, says Anton Chuvakin, author of PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. The PCI rules really represent theminimum security standards businesses must meet to be fair to their customers, who, after all, are trusting the merchant every time they hand over a credit card number. In the wake of a card security breach, a larger business might suffer from the fines, damages and adverse publicity resulting from a card security breach. By contrast, "a small business is more likely to be GONE," Chuvakin said. "Businesses that endanger their customers really do deserve to die."
If your organization is not equipped to handle credit card data securely, maybe you should not be handling it at all. Look for ways to shift as much of the burden as possible onto a service provider that specializes in secure payment processing. Services such as PayPal and Authorize.net let you forward customers to their websites for payment processing; credit card numbers never pass through your hands at all.
Small businesses such as restaurants that use an older generation of countertop credit card terminals may be breaking the rules inadvertently because the device stores magnetic stripe data or otherwise violates the PCI requirements. So consider upgrading to a payment device that is certified PCI compliant. Basic terminals capable of encrypting Personal Identification Number (PIN) codes and protecting other sensitive information are available for as little as $100 and might even be offered free by merchant account services trying to win your business. The PCI Security Standards Council publishes a list of approved devices. Just remember that using a compliant device is only one element of making your business compliant.
Even if you're not storing anything explicitly prohibited, you may be storing more credit card data than you need to. Small merchants typically store a day's worth of credit card numbers on a card swipe terminal, then process all the transactions in a batch at the end of the day. Bigger retailers may record the card numbers in a centralized database so they can track all a customer's purchases, and so they can retrieve the number if they need to issue a refund. But do you need to retain those numbers at all?
Perhaps not. Martin McKeay, a QSA and author of the Network Security Blog, recommends looking at new strategies for using end-to-end encryption and "tokenization."
For example, payment processor First Data ( FDC - news -people ) and security software firm RSA Security have developed a product called TransArmor that allows merchants to get authorization for a credit card number and then immediately dispose of the card number, replacing it with a token. The token is another number that acts as a stand-in for the credit card number itself. First Data keeps track of which tokens correspond with which credit card numbers. So if you're executing previously authorized transactions at the end of the day, you send First Data a batch of tokens, and it relays the card numbers on to the bank. But if the tokens are stolen, by themselves they are worthless to anyone else.
"With this, the only time you need the true credit card number is when you do the authorization," says Craig Tieken, First Data vice president of merchant product management. "The merchant, in our opinion, no longer needs the card number." TransArmor is still in beta testing, scheduled for release in the summer of 2010.
David F. Carr is Forbes' columnist on technology for small to midsize businesses. Contact him at david@carrcommunications.com.
Source: http://alturl.com/wipe
