Heartland response – Minimizing the damage of breached data
Bruce Schneier often talks about the response to data breaches, like the recent Heartland incident. In a recent post, Bruce discussed how data breach notification laws encourage companies to improve their security.
While I’m all for encouraging companies to improve their security and see how breach notification laws can help with that, now that a breach has occurred, the next step should be to try to minimize the subsequent damage.
One method for minimizing data loss might be a bit controversial, but could also have a major impact on identifying the use of the stolen cards. Here’s the idea (try not to judge it until you read the rest of the post): The credit card companies that cancel the impacted cards should privately publish the canceled card numbers to merchants.
This probably needs more explanation. If the credit card companies had a certain set of merchants where they had very good working relationships – maybe some of the large online merchants, for example – they could give those merchants the list of card numbers that had been canceled. Then those merchants could look for the canceled cards being used and flag that activity – and anything associated with it – as suspicious. Since it is likely the bad actors will use the cards in batches and they won’t know which cards were canceled versus which were not, this is one way the credit card companies could help minimize the damage to the merchants.
Some people may be concerned about the privacy of credit card companies sending out credit card numbers. There are three things to keep in mind about this. First, the credit card numbers they would send out would not have any other information associated with them – they would just be card numbers. Second, since the cards themselves would have been canceled, they are no longer owned by any person but are, instead, owned by the credit card companies themselves. So there shouldn’t be any privacy concerns. Third, I am not advocating that the card numbers be published on the internet for everyone to see. Instead, they should be delivered via a secure mechanism only to merchants that are well known, trusted, and are interested in using them to take action.
What would be the right way to make this collaboration happen?
3 Comments »
Leave a comment
About
Silver Tail is leading the fight against business logic abuse with 3rd generation fraud prevention.
Hackers are no longer high school kids trying to one-up their friends or criminals trying to just break-in to sites. Instead, today’s sophisticated hacker is organized crime, strategically targeting websites, stealing billions of dollars from companies and their customers. Vendors providing web application security and intrusion prevention have forced hackers to become much more innovative in their means of attacking websites. These hackers now target the legitimate business logic of websites to perpetrate their fraud, including hijack threats, velocity attacks and gaming schemes. Silver Tail is using the deep domain expertise of its team to provide software that combat business logic abuse in real-time.
Silver Tail was founded by a team of fraud prevention experts who built anti-fraud and anti-phishing tools at eBay and PayPal. Through their experience and proprietary algorithms, they have built a system that is scalable, minimizes false positive rates, and is extremely flexible to adapt to changing attack vectors.
Feedburner
RSS Feed
-
Archives
- January 2010 (1)
- December 2009 (6)
- November 2009 (7)
- October 2009 (8)
- September 2009 (7)
- August 2009 (8)
- July 2009 (7)
- June 2009 (6)
- May 2009 (6)
- April 2009 (14)
- March 2009 (8)
- February 2009 (5)
-
Categories
- behavior analysis
- business logic abuse
- Business Logic Flaw
- Business Process Abuse
- Compliance
- Cost of fraud
- Data Loss
- Detection
- education
- Fraud
- Gaming
- General
- information security
- Investigation
- Man-in-the-Browser
- Online Fraud
- Payment
- Phishing
- Prevention
- risk management
- Social engineering
- Social Networks
- Trust
- Uncategorized
- web logic abuse
- Zeus
-
RSS
Entries RSS
Comments RSS
This collaboration is not necessary, as there is the authorization process of the credit card transaction. For the merchant, before the authorization request there is no difference between a credit card number generated by a “credit card number generator” (easily downloaded from the Internet) and a card that was actually issued by a valid Issuer. Cancelled cards will have all the authorization requests denied, so the merchant doesn’t need a list to check them against.
In fact, the major credit card brands do what you are proposing already, as all authorization requests go through their networks before reaching the Issuer (who authorizes the transaction). Several cases of card compromise are detected through that process. Merchants (or merchant employees) that work together with fraudsters to help on the usage of the stolen numbers are frequently identified by this process too.
Great points. Unfortunately, for the customers we work with, this is not enough. The majority of the benefit in the federation you describe is seen by the credit card issuers. Large online merchants are still kept largely in the dark on breach issues like this one. Although the merchants can see that a given CC# is invalid, and look to see what other CC#s came from the same IP / UserAgent / Cookie / XXX, there’s still more information around a large breach they don’t have that would enable them to do a better job of protecting themselves against fraud. Remember… in the case where a merchant accepts a stolen credit card (one that is not marked invalid by the issuer), the merchant is the one liable for the loss… not the card issuer. Knowing that a particular card is invalid because of a breach will help merchants understand the impact of the breach on their systems, and overall enable them to do better fraud decisioning.
Hey, nice tips. Perhaps I’ll buy a bottle of beer to that man from that chat who told me to go to your blog