Product Security

I spend a lot of thinking about how money is changing. To be specific, I’m curious and concerned about the security of our digital money. Along with my team, I’ve found flaws in BitCoin and compromised chip-enabled EMV card readers. But what I’m writing about today isn’t the ways you’ll be attacked in the future but one of the oldest tricks in the card thief’s toolset: a skimmer.

Russian hacker Roman Seleznev has been sentenced to 27 years in prison following his conviction on 38 counts relating to fraud and theft. If that name looks familiar to Seattle resident it’s because he was behind Broadway Grill’s bankruptcy[1] and related ATM and Point of Sale (PoS) hacks worth an estimated $169M in losses across 3,700 financial institutions. Over the course of four years, he perpetrated numerous successful skimmer and malware installations, then trading the stolen information on carding websites to other criminals and organizations who would in turn counterfeit the cards and go on costly spending sprees.

Skimming, responsible for an estimated 97 to 98% of all ATM fraud losses, has been around for some time now. And in case you thought you could wish it away, this persistent threat is actually experiencing a sharp rise. FICO reported a 574% increase in incidents between 2014 and 2015 alone. As skimming equipment becomes cheaper and more available, and adapts to newer technologies, the crime will likely continue to become more common.

These incidents are geographically widespread, affecting ATMs and other EMV terminals throughout the U.S. and elsewhere. Recently, police warnings were issued in Texas, Indiana, Glasgow (Scotland) and Victoria (BC, Canada), just to name a few hotspots.

Two recent incidents further emphasized that we aren’t immune to this scourge in Washington First, a few months ago, one of my company’s credit cards fell prey to skimmer and was used by a fraudster at area Apple and Microsoft Stores (thankfully we were able to reverse the charges). Second, in the last few weeks a security-conscious citizen reported a suspected skimmer installed on an ATM they occasionally used (See photo).

So, what is Skimming?

At its simplest, skimming is placing a device on an ATM or EMV terminal that is hidden from the user’s perspective. The intruding device executes a passive Man in the Middle (MITM) attack to read and store card numbers and other sensitive card information that can be later retrieved, downloaded, and sold illegally – often online. The end result of these compromises netted Seleznev an estimated $2.9 million over four years as just one (albeit extreme) example. In some cases, the devices are paired with some method of PIN extraction: counterfeit PIN pads and pinhole cameras installed in the facade of the machine being two examples.

An ATM Skimmer found in Seattle

By capturing this data, cybercriminals expose a consumer to more than just financial loss. Victims of this crime may find themselves at direct risk of identity theft, impersonation, additional data breaches, and ruined credit history. Anywhere that those debit or credit card numbers are used, they can also be leveraged against the consumer. Oh yeah, criminals can place a skimmer in seconds (seriously, watch the video).

Defenses Against Skimming

Typically, this how a skimmer may be discovered. You visit an ATM, and notice that something ‘feels off’ about the machine. A physical inspection may reveal nothing of note. It’s not until you feel the card reader and notice an unusual protrusion that makes confirms your suspicion. You then notify the bank’s customer service and immediately cancel your card

This is the advice I give to my friends and family about using an ATM:

●      Avoid unfamiliar and standalone ATMs
●      Use familiar ATMs recessed into the building that houses them
●      Look for physical signs of tampering to the card reader, PIN pad, or ATM in general
●      Pay attention to how much force it takes to swipe or insert your card
●      Give the card reader a tug — it should remain solidly fixed in place
●      Always cover the PIN pad while you enter your PIN
●      If you’re unsure, trust your gut. Don’t be afraid to walk away and use another ATM or the teller window.

Mostly, don’t use debit cards unless you must. Apple Pay, Google Wallet are more secure than your debit card.

You may also be wondering: what can organizations do about this? After all, it wasn’t just customers that got hit in the wallet, but Broadway Grill and other businesses and financial institutions.  Recommendations are a little more involved at the organizational level. I’d recommend the following basic steps:

●      Add anti-skimmer protections, such as those recommended by the ATM Security Association
●      Designate and post a clear contact responsible for security issues
●      Ensure strict compliance with data encryption and storage requirements
●      Monitor access and to the device
●      Regularly inspect the device for tampering

Countering the rise of skimming and related criminal techniques for stealing sensitive card-encoded data is vital, and not as difficult as it may first seem. Combined with increased awareness and vigilance, the techniques above can help you regain your financial peace of mind.

“The more precisely the position is determined, the less precisely the momentum is known in this instant, and vice versa.”
–Heisenberg, uncertainty paper, 1927

The Uncertainty principle is related to the observer effect. In physics, the term observer effect refers to changes that the act of observation will make on the phenomenon being observed.

Ok, now to get to the point. Leaders are often asked to produce several performance metrics or revenue metrics. Some of these metrics are simple and straightforward  Key Performance Indicators (KPIs). KPIs can include net revenue, profit, # of new customers or in our case customer satisfaction numbers.

The problem with metrics crops up when we need to measure a property and no mechanism exists to measure it quickly or the metric is not representative of the property being measured. In general this happens when the following scenarios arise:

1. Metric is not available: No mechanism is in place to measure the property at that time.
2. Property is not measurable: No metrics are available to capture the property.
3. Deliver unplanned metrics quickly: Metrics that the system was not designed to capture need to be measured quickly.
4. CSF masquerading as KPI: Critical Success Factors are vital elements for a strategy to be successful and should not be confused with KPIs which quantify strategic performance.  The metric being asked for is a CSF not a KPI.

In simple words, the amount of effort required to measure the metric changes the amount of effort we can dedicate to create the metric. The act of measuring the metric changes it.  For example, in the economic downturn several teams have had to reduce headcount. If this barebones team is now asked to capture  information on how a recently released tool is being used by customers without that mechanism already in place, then they cannot deliver that metric without additional effort that will impact the overall KPIs.The problem that arises is what I’ve dubbed the Akshay’s Uncertainty Principle:

In a resource constrained environment, a new or modified metric cannot be measured without impacting the metric itself.

– Akshay Aggarwal

Finally, an explanation the kxcd way

Several enterprises are increasingly investing time and money in building application security tasks into their existing SDLCs. Some of them have also reached the conclusion that proactive approaches , like threat modeling, have more ROI than reactive approaches. As a result, some enterprises with nascent appsec programs have turned to threat modeling as a panacea for their security problems. However, threat modeling may not be the solution to their immediate problems. Now I recognize that this may be a controversial statement.

Recently, I have been involved in several situations where organizations with their heart in the right place have made threat modeling mandatory as part of the development process, with limited success. My point is that threat modeling as part of a mature SDLC is a desired end state though not necessarily the initial step. Let’s examine this argument.

Firstly, threat modeling depends on several elements of a SDLC to be fairly mature. Most importantly it depends on requirement and specification gathering process to be rigorous. Also, an enterprise must have well defined standards and policies in place to act as input into the threat modeling process. Without these elements of the SDLC in place, the threat modeling process will be isolated and have a reduced impact.

Secondly, a threat model is a security plan only and is useless without any committed follow-up action as part of development and testing. Most enterprises do not allocate sufficient time and resources to implement the findings of the threat model. A large portion of organizations don’t even have a security assessment team in place. These teams are consumers of the threat modeling process that actual carry out the most crucial task of reducing risk by implementing countermeasures.

Thirdly, it is practically feasible to create threat models only for new projects or those undergoing incremental changes. As a result, legacy applications do not benefit from threat modeling. This leaves a huge gap in the enterprises’ risk profile.

Finally, most nascent application security programs need quick and demonstrable ROI. The threat modeling process ROI can take several months or even years to be quantifiable because it is an incremental process that is dependant on several other SDLC processes to be effective. There are other areas where investment can bring in more immediate ROI. These areas include security assessment team, security training for developers and definition of countermeasures for common vulnerabilities.

For organizations with nascent application security processes, I recommend that they us the following framework to evaluate if they are ready to adopt threat modeling:

• Does a security baseline exist?
• Is the SDLC process fairly well defined and followed during development?
• Has the organization agreed upon countermeasures for common vulnerabilities?
• Are developers trained to avoid common vulnerabilities?
• Do developers do a self review of code for security vulnerabilities?
• Does a security assessment team exist?

If the answer to more than two of the questions above is no then the organization is probably not ready for adopting threat modeling.