Research

So far we have discussed the EMV requirement, covered the players in the payment landscape, and considered merchant migration issues. It is time to get into the meat of this series. Our next two posts will discuss the liability shift in detail, and explain why it is not as straightforward as its marketing. Next I will talk about the EMV specification’s application of tokenization, and how it changes the payment security landscape. What Is the Liability Shift? As we mentioned earlier the card brands have stated that in October of 2015 liability for fraudulent transactions will shift to non-EMV-compliant merchants. If an EMV ‘chipped’ card is used at a terminal which is not EMV-capable for a transaction which is determined to be counterfeit or fraudulent, liability will reside with merchants who are not fully EMV compliant. In practical terms this means merchants who do not process 75% or more of their transactions through EMV-enabled equipment will face liability for fraud losses. But things are seldom simple in this complex ecosystem. Who Is to Blame? Card brands offer a very succinct message: Adopt EMV or accept liability. This is a black-and-white proposition, but actual liability is not always so clear. This message is primarily targeted at merchants, but the acquirers and gateways need to be fully compliant first, otherwise liability does not flow downstream past them. The majority of upstream participants are EMV ready, but not all, and it will take a while for the laggards to complete their own transition. At least two firms we interviewed suggested much of the liability shift is actually from issuing bank to acquiring bank and related providers, so losses will be distributed more evenly through the system. Regardless, the card brands will blame anyone who is not EMV compliant, and as time passes that is more likely to land on merchants. Do Merchants Currently Face Liability? That may sound odd, but it’s a real question which came up during interviews. Many of the contracts between merchants and merchant banks are old, with much of their language drafted decades ago. The focus and concerns of these agreements pre-date modern threats, and some agreements do not explicitly define responsibility for fraud losses, or discuss certain types of fraud at all. Many merchants have benefitted from the ambiguity of these agreements, and not been pinched by fraud losses, with issuers or acquirers shouldering the expense. There are a couple cases of the merchants are dragging their feet because they are not contractually obligated to inherit the risk. Most new contracts are written to level the playing field, and push significant the risk back onto merchants – liability waivers from card brands not withstanding. So there is considerable ambiguity regarding merchant liability. How Do Merchants Assess Risk? It might seem straightforward for merchants to calculate the cost-benefit ratio of moving to EMV. Fraud rates are fairly well known, and data on fraud losses is published often. It should be simple to calculate the cost of fraud over a mid-term window vs. the cost of migration to new hardware and software. But this is seldom the case. Published statistics tend to paint broad strokes across the entire industry. Mid-sized merchants don’t often know their fraud rates or where fraud is committed. Sometimes their systems detect it and provide first-hand information, but in other cases they hear from outsiders and lack detail. Some processors and merchant banks share data, but that is hardly universal. A significant proportion of merchants do not understand these risks to their business well, and are unable to assess risk. Without P2PE, Will I Be Liable Regardless? The EMV terminal specification does not mandate the use of point-to-point encryption. If – as in the case of the Target breach – malware infects the PoS systems and gathers PAN data, will the courts view merchants as liable regardless of their contracts? At least one merchant pointed out that if they are unlucky enough to find themselves in court defending their decision to not encrypt PAN after a breach, they will have a difficult time explaining their choice. PCI <> EMV The EMV specification and the PCI-DSS are not the same. There is actually not much overlap. That said, we expect merchants who adopt EMV compliant terminals to have reduced compliance costs in the long run. Visa has stated that effective October 2015, Level 1 and Level 2 merchants who process at least 75% of transactions through EMV-enabled POS terminals (which support both contact and contactless cards) will be exempt from validating PCI compliance that year. They will still be officially required to comply with PCI-DSS, but can skip the costly audit for that year. MasterCard offers a similar program to Visa. This exemption is separate from the liability shift, but offers an attractive motivator for merchants. Our next post will discuss current and future tokenization capabilities in EMV payment systems. Share:

Security practitioners have been falling behind their adversaries, who launch new attacks using new techniques daily. Furthermore, defenders remain hindered by the broken negative security model of looking for attacks they have never seen before (well done, compliance mandates), and so consistently missing these attacks. If your organization hasn’t seen the attack or updated your controls and monitors to look for these new patterns… oh, well. Threat Intelligence has made a significant difference in how organizations focus their resources. Our Applied Threat Intelligence paper highlighted how organizations can benefit from the misfortune of others and leverage this external information in use cases such as security monitoring/advanced detection, incident response, and even within some active controls to block malicious activity. These tactical uses certainly help advance security, but we ended Applied Threat Intelligence with a key point: the industry needs to move past tactical TI use cases. The typical scenario goes something like this: Get hit with attack. Ask TI vendor whether they knew about attack before you did. Buy data and pump into monitors/controls. Repeat. But that’s not how we roll. Our philosophy drives a programmatic approach to security. So it’s time to advance the use of threat intelligence into the broader and more structured TI program to ensure systematic, consistent, and repeatable value. We believe this Building a Threat Intelligence Program report can act as the map to build this program and leverage threat intelligence within your security program. That’s what this new series is all about: turning tactical use cases into a strategic TI capability. We’d like thank our potential licensee on this project, BrightPoint Security, who supports our Totally Transparent Methodology for conducting and publishing research. As always we’ll post everything to the blog first, and take feedback from folks who know more about this stuff than we do (yes, you). The Value of TI We have published a lot of research on TI, but let’s revisit the basics. What do we even mean when we say “benefiting from the misfortune of others”? Odds are that someone else will be hit by any attack before you. By leveraging their experience, you can see attacks without being directly attacked first, learning from higher profile targets. Those targets figure out how they were attacked and how to isolate and remediate the attack. With that information you can search your environment to see if that attack has already been used against you, and cut detection time. Cool, huh? If you haven’t seen the malicious activity yet, it’s likely just a matter of time; so you can start looking for those indicators within your active controls and security monitors. Let’s briefly revisit the use cases we have highlighted for Threat Intelligence: Active Controls: In this use case, threat intelligence gives you the information to block malicious activity using your active controls. Of course since you are actually blocking traffic, you’ll want to be careful about what you block versus what you merely alert on, but some activities are clearly malicious and should be stopped. Security Monitoring: An Achilles’ Heel of security monitoring is the need to know what you are looking for. TI balances the equation a bit by expanding your view. You use the indicators found by other organizations to look for malicious activity within your environment, even if you’ve never seen it. Incident Response: The last primary use case is streamlining incident response with TI. Once adversary activity is detected within your environment, you have a lot of ground to cover to find the root cause of the attack and contain it quickly. TI provides clues as to who is attacking you, their motives, and their tactics – enabling the organization to focus its response. The TI Team As mentioned above, TI isn’t new. Security vendors have been using dynamic data within their own products and services for a long time. What’s different is treating the data as something separate from the product or service. But raw data doesn’t help detect adversaries or block attacks, so mature security organizations have been staffing up threat intelligence groups, tasking them with providing context for which of the countless threats out there actually need to be dealt with now; and what needs to be done to prevent, detect, and investigate potential attacks. These internal TI organizations consume external data to supplement internal collection and research efforts, and their willingness to pay for it, which has created a new market for security data. The TI Program Organizations which build their own TI capability eventually need a repeatable process to collect, analyze, and apply the information. That’s what this series is all about. We’ll outline the structure of the program here, and dig into each aspect of the process in subsequent posts. Gathering Threat Intelligence: This step involves focusing your efforts on reliably finding intelligence sources that can help you identify your adversaries, as well as the most useful specific data types such as malware indicators, compromised devices, IP reputation, command and control indicators, etc. Then you procure the data you need and integrate it into a system/platform to use TI. A programmatic process involves identifying new and interesting data sources, constantly tuning the use of TI within your controls, and evaluating sources based on effectiveness and value. Using TI: Once you have aggregated the TI you can put it into action. The difference when structuring activity within a program is the policies and rules of engagement that govern how and when you use TI. Tactically you can be a little less structured about how data is used, but when evolving to a program this structure becomes a necessity. Marketing the Program: When performing a tactical threat intelligence initiative you focus on solving a specific problem and then moving on to the next. Broadening the use of TI requires specific and ongoing evaluation of effectiveness and value. You’ll need to define externally quantifiable success for the program, gather data to substantiate results, and communicate those results – just like any other business function. Sharing Intelligence: If there is one thing that tends to be overlooked when focusing on how the intelligence can help you, it is how sharing