What is a Stolen Credit Card Worth?

Solution Providers for Retail
Guest blog by A.N. Ananth

Cybercrime and stealing credit cards has been a hot topic all year. From the Target breach to Sony, the classic motivation for cybercriminals is profit. So how much is a stolen credit card worth?

The reason it is important to know the answer to this question is that it is the central motivation behind the criminal. If you could make it more expensive for a criminal to steal a card than what the thief would gain by selling them, then the attackers would find an easier target. That is what being a hard target is all about.

This article suggests prices of $35-$45 for a stolen credit card depending upon whether it is a platinum or corporate card. It is also worth noting that the viable lifetime of a stolen card is at most one billing cycle. After this time, the rightful owner will most likely detect its loss or the bank fraud monitor will pick up irregularities and terminate the account.

Why is a credit card with a high spending limit (say $10K) worth only $35? It is because monetizing a stolen credit card is difficult and requires a lot of expensive effort on part of the criminal. That is contrary to popular press which suggest that cybercrime results in easy billions. At the Workshop on Economics of Information Security, Herley and Florencio showed in their presentation, “Sex, Lies and Cybercrime Surveys,” that widely circulated estimates of cybercrime losses are wrong by orders of magnitude.For example:

Far from being broadly-based estimates of losses across the population, the cyber-crime estimates that we have appear to be largely the answers of a handful of people extrapolated to the whole population. A single individual who claims $50,000 losses, in an N = 1000 person survey, is all it takes to generate a $10 billion loss over the popu- lation. One unverified claim of $7,500 in phishing losses translates into $1.5 billion. …Cyber-crime losses follow very concentrated distributions where a representative sample of the pop- ulation does not necessarily give an accurate estimate of the mean. They are self-reported numbers which have no robustness to any embellishment or exaggeration. They are surveys of rare phenomena where the signal is overwhelmed by the noise of misinformation. In short they produce estimates that cannot be relied upon.

That’s a rational, fact based explanation as to why the most basic of information security is unusually effective in most cases. Pundits have been screaming this from the rooftops for a long time. What are your thoughts?

Read more at Solution Provider for Retail guest blog.

Are honeypots illegal?

In computer terminology, a honeypot is a computer system set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of IT systems. Generally, a honeypot appears to be part of a network, but is actually isolated and monitored, and which seems to contain information or a resource of value to attackers.

Lance Spitzner covers this topic from his (admittedly) non-legal perspective.

Is it entrapment?
Honeypots are not a form of entrapment. For some reason, many people have this misconception that if they deploy honeypots, they can be prosecuted for entrapping the bad guys. Entrapment, by definition is “a law-enforcement officer’s or government agent’s inducement of a person to commit a crime, by means of fraud or undue persuasion, in an attempt to later bring a criminal prosecution against that person.”

Does it violate privacy laws?
Privacy laws in the US may limit your right to capture data about an attacker, even when the attacker is breaking into your honeypot but the exemption under Service Provider Protection is key. What this exemption means is that security technologies can collect information on people (and attackers), as long as that technology is being used to protect or secure your environment. In other words, these technologies are now exempt from privacy restrictions. For example, an IDS sensor that is used for detection and captures network activity is doing so to detect (and thus enable organizations to respond to) unauthorized activity. Such a technology is most likely not considered a violation of privacy as the technology is being used to help protect the organization, so it falls under the exemption of Service Provider Protection. Honeypots that are used to protect an organization would fall under this exemption.

Does it expose us to liability?
Liability is not a criminal issue, but civil. Liability implies you could be sued if your honeypot is used to harm others. For example, if it is used to attack other systems or resources, the owners of those may sue. The argument being that if you had taken proper precautions to keep your systems secure, the attacker would not have been able to harm my systems, so you share the fault for any damage occurred to me during the attack. The issue of liability is one of risk. First, anytime you deploy a security technology (even one without an IP stack), that technology comes with risk. For example, there have been numerous vulnerabilities discovered in firewalls, IDS systems, and network sniffers. Honeypots are no different.

Obviously this blog entry is not legal advice and should not be construed as such.

SIEM or Log Management?

Security Information and Event Management (SIEM) is a Gartner coined term to describe solutions which monitor and help manage user and service privileges, directory services, and other system configuration changes in addition to providing log auditing, and review and incident response.

SIEM differs from Log Management, which refers to solutions which deal with large volumes of computer-generated log messages (also known as audit records, event-logs, etc.)

Log management is aimed at general system troubleshooting or incident response support. The focus is on collecting all logs for various reasons. This “input-driven” approach tries to get every possible bit of data.

This model fails with SIEM-focused solutions. Opening the floodgates, admitting any/all log data into the tool first, then considering what (if any) use is there for the data, reduces tool performance as it struggles to cope with the flood. More preferable is an “output-driven” model where data is admitted if and only if its usage is defined. This use can be defined to include alerts, dashboards, reports, behavior profiling, threat analysis, etc..

Buying a SIEM solution and using it as log management tool is a waste of money. Forcing a log management solution to act like a SIEM is folly.

4 Fundamentals of Good Security Log Monitoring

Effective security log monitoring is a very technical challenge that requires a lot of arcane knowledge and it is easy to get lost in the details. Over the years, there are 4 things that stand out to me as fundamentals when it comes to keeping the big picture and meeting the challenge:

1. Just do it
Sometimes organizations prevaricate about implementing a SIEM/log management solution because they aren’t sure they will be able to fully utilize it because of staff or skill shortage and a host of other reasons. Making sure someone is watching your SIEM and follow up on what it finds is certainly important but don’t let that hold you back from implementing SIEM and log management. There are multiple levels on the security monitoring maturity model and you can’t necessarily start off where you’d like to. But you need to be collecting and securely archiving logs no matter what – even if no one is looking at them at all. If you don’t capture logs when they are created you lose them forever; logs will only be there when you need them if you’ve at least been collecting and securely archiving them. That may be the first step on the maturity model but without it you lose accountability and the ability to conduct critical forensics to determine the history and extent of security incidents.

2. Let your environment inform your monitoring
Security analytics technology like SIEMs is getting better and better at recognizing malicious activity out of the box. But there will always be a limit to what shrink wrapped analytics can find. At some point you need to analyze your environment and tailor your monitoring and alerting criteria to take into account what makes your environment different. How is your network divided internally as far as security zones? Which systems should be making outbound connections to the Internet? Which shouldn’t? Which PCs should be making administrative connections to other systems – which shouldn’t. Those are just a few examples. But the more local intelligence you build into your monitoring the better your SIEM will be at recognizing stuff you should investigate.

3. The more secure and clean your environment – the easier it is to detect malicious activity
Here’s a couple examples of what I’m talking about. First a security example: let’s say you lock down your servers so that they can only accept remote desktop connections from a “jump box” you set up which also requires multi-factor authentication. That’s a great step. Now leverage that restriction by teaching your SIEM to alert you when it sees remote desktop connection attempts to those servers from unauthorized systems. APT and other malicious outsiders will likely be unaware of your setup at first and will trip the alarm. Here’s a cleanliness example. Let’s say you have a naming convent for user accounts that allows you to distinguish end user accounts, privileged admin accounts and non-human accounts for services and applications. If you strictly follow that convention you now have all kinds of opportunities to catch bad things as they happen in your environment. For instance if you see a non-human service account trying to logon interactively or via Remote Desktop you may very well have an insider misusing that account or an external attacker who has successfully ran a pass-the-hash attack on that account. Or if you see an administrative account created that doesn’t match naming conventions – that may be a tipoff of an APT creating a back-door account.

4. Leverage a SIEM solution that is intelligent and automates as much as possible
If you are going to follow through on my #2 and #3 recommendations you need a SIEM that frees you up from doing all the obvious stuff that can be packaged by the vendor. EventTracker has been around a long time and has a huge amount of knowledge and support already built into it for many, many different log sources as well as intelligent behavior analysis.

Log monitoring is a rigorous, technical exercise but good SIEM technology frees you up to focus on what makes your environment different and how to leverage those differences to recognize malicious activity as it happens. But if you aren’t at the point to get truly sophisticated in your monitoring don’t let that hold you back from at least collecting and archiving those logs that they are secure and available.