Security as a Strategy (SaaS)

Risky Behavior: Securing Credit Card Data

Over 234 million consumer credit card records with sensitive information have been breached since January 2005, according to Privacy Rights Clearinghouse.org. The seriousness of this problem begs us to examine the gap between meeting industry compliance requirements and the securing of confidential data.

A survey of businesses in the U.S. and Europe reveals activities that may put cardholder data at risk: 81% store payment card numbers; 73% store payment card expiration dates; 71% store payment card verification codes; 57% store customer data from the payment card magnetic stripe; 16% store other personal data.  Source: Forrester Consulting: The State of PCI Compliance (commissioned by RSA/EMC)

As a result of this behavior by merchants, vulnerabilities were created in the card-processing ecosystem. Information security breaches occurred in point-of-sale devices; personal computers or servers; wireless hotspots, ecommerce applications; paper-based storage systems; and unsecured transmission of cardholder data to service providers.

To combat this trend, a PCI Data Security Standard (DSS) was created by the PCI Security Council whose founding members include: American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. To any security manager, these standards are very familiar as they mirror corporate best practices for network security. Here are the 12 requirements for PCI DSS.

Requirement 1: Install and maintain a firewall and router configuration to protect cardholder data

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. Change your passwords often.

Requirement 3: Protect stored cardholder data. Anything stored should be encrypted and cardholder data should not be retained or if retained then only for a limited time period.

Requirement 4: Encrypt transmission of cardholder data across open, public networks. Use strong cryptography and security protocols such as SSL/TLS or IPSEC.

Requirement 5: Use and regularly update anti-virus software or programs. Many vulnerabilities and malicious viruses enter the network via employees' e-mail and other online activities.

Requirement 6: Develop and maintain secure systems and applications. Security vulnerabilities in systems and applications may allow criminals to access cardholder account numbers and other cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches.

Requirement 7: Restrict access to cardholder data by business need-to-know. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need-to-know and according to job responsibilities. Role-based authentication is helpful here.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Requirement 9: Restrict physical access to cardholder data. Any physical access to data or systems that house cardholder data provides the opportunity for persons to access and/or remove devices, data, systems or hardcopies, and should be appropriately restricted.

Requirement 10: Track and monitor all access to network resources and cardholder data. Logging mechanisms and the ability to track user activities are critical for effective forensics and vulnerability management.

Requirement 11: Regularly test security systems and processes. Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security is maintained over time.

Requirement 12: Maintain a policy that addresses information security for employees and contractors. A strong security policy sets the tone for security affecting an organization's entire company, and it informs employees of their expected duties related to security.

Will The Responsible Party Please Step Forward?

In a recent article posted to Dark Reading, a couple is suing their bank for failure to protect their account resulting in a fraudulent wire transfer. Apparently someone stole the logon credentials to the couple's on-line account, obtained a loan of ~$26,000 which was deposited into the couple's business account. From there the money was transferred to a bank in Hawaii and on to Austria.

The couple is suing the bank largely based on allegations that the bank failed to properly secure the couple's account. In the article, Mr. Bruce Schneier states, "But it makes no sense that the customer should be responsible for [banking] fraud...The only way to improve security is for the person with the ability to mitigate it [like a bank] to take responsibility for this. Even if it's the customer's fault, the bank should be liable."

This intrigued me and so I went to his blog (http://www.schneier.com/blog/archives/2009/09/eliminating_the.html) to find out more. It is, or was at the time of the blog entry, Mr. Schneier's opinion that the only way to combat this type of fraud is to make the bank liable for fraudulent transactions. With all due respect, I have to disagree. Promoting this point, in this particular case, is a bit like putting the cart before the horse.

What the article does not tell you are at least a few important points regarding this case:

• How did the thieves obtain the logon credentials? Did either the man or woman (both?) write them down in plain sight; was their PDA stolen; did they use something easily guessable; etc.? It seems that no one is contesting the validity of the credentials so my first question is how they were obtained. If the couple did not take adequate risk protections then where is their responsibility and liability?
• Were there other, similar transactions (obtaining a loan of similar amounts) in the banking history of this couple? Maybe the bank's fraud transaction system did notice it, but since others had occurred (with similar characteristics) it was not ,a red flag.
• Were there any regulatory or legal statutes broken by the bank? If not, then that could imply they were doing their due diligence. We don't know the results of their last security audit from regulators - did they pass with flying colors, were there shortcomings in on-line security measures and/or countermeasures?

Mr. Schneier goes onto suggest that banks become more like credit card companies with regard to identifying and stopping fraudulent transactions. As he correctly points, out credit card companies have "...developed and fielded an array of security technologies designed to detect and prevent fraudulent transactions. They've pushed most of the actual costs onto the merchants." And you can bet that these security technologies are a large investment - money that many banks don't have. I don't know exactly how Citizen's Financial Bank ranks in terms of revenue but it is probably a safe bet they are not as large as major credit card companies. And while the credit card companies may not be drowning in fraudulent transaction losses, their feet are not completely dry. Their solutions and technologies do reduce the chance of fraud but they are not perfect - especially if someone has a legitimate credit card number.

Suppose someone stole a credit card that you (against all advice) had not signed. A thief uses the card to purchase a big-ticket item and when you get the bill, you rightfully contest the charge. Is it the credit card companies fault that a legitimate card was used? No. Is it the fault of the store clerk who did not check for a signature? Maybe. If they had questioned the "card holder" they probably would have forged the signature anyway. Is it the fault of the original card holder who should have signed the card, thereby giving the clerk an opportunity to compare signatures, making the purchase more difficult? That's my belief.

Without knowing the extent to which the original bank account holders did their own due diligence to protect their account, and without knowing the extent of the banks security measures, I don't think we can just put the blame on the bank.

I do agree with Mr. Schneier on one point: "It's an important security principle: ensure that the person who has the ability to mitigate the risk is responsible for the risk." My point exactly. If it turns out the account holders (who have a major role in protecting their account) did not do this, then they should be held responsible.

The full article can be found here regarding this case: http://www.darkreading.com/database_security/security/attacks/showArticle.jhtml?articleID=220100950