Research

  Threat Intelligence remains one of the hottest areas in security. With its promise to help organizations take advantage of information sharing, early results have been encouraging. We have researched Threat Intelligence deeply; focusing on where to get TI and the differences between gathering data from networks, endpoints, and general Internet sources. But we come back to the fact that having data is not enough – not now and not in the future. It is easy to buy data but hard to take full advantage of it. Knowing what attacks may be coming at you doesn’t help if your security operations functions cannot detect the patterns, block the attacks, or use the data to investigate possible compromise. Without those capabilities it’s all just more useless data, and you already have plenty of that. Our Applied Threat Intelligence paper focuses on how to actually use intelligence to solve three common use cases: preventative controls, security monitoring, and incident response. We start with a discussion of what TI is and isn’t, where to get it, and what you need to deal with specific adversaries. Then we dive into use cases.   We would like to thank Intel Security for licensing the content in this paper. Our licensees enable us to provide our research at no cost to you, so we should all thank them. As always, we developed this paper using our objective Totally Transparent Research methodology. Visit the Applied Threat Intelligence landing page in our research library, or download the paper directly (PDF). Share:

Rich here. A few things this week got me thinking about customer service. For whatever reason, I have always thought the best business decision is to put the needs of the customer first, then build your business model around that. I’m enough of a realist to know that isn’t always possible, but combine that with “don’t make it hard for people to give you money” and you sure tilt the odds in your favor. First is the obvious negative example of Oracle’s CISO’s blog post. It was a thinly-veiled legal threat to customers performing code assessments of Oracle, arguing this is a violation of Oracle’s EULA and Oracle can sue them. I get it. That is well within their legal rights. And really, the threat was likely more directed towards Veracode, via mutual customers as a proxy. Why do customers assess Oracle’s code? Because they don’t trust Oracle – why else? It isn’t like these assessments are free. That is a pretty good indicator of a problem – at least customers perceiving a problem. Threatening independent security researchers? Okay, dumb move, but nothing new there. Threatening, sorry ‘reminding’, your customers in an open blog post (since removed)? I suppose that’s technically putting the customer first, but not quite what I meant. On the other side is a company like Slack. I get periodic emails from them saying they detected our usage dropped, and they are reducing our bill. That’s right – they have an automated system to determine stale accounts and not bill you for them. Or Amazon Web Services, where my sales team (yes, they exist) sends me a periodic report on usage and how to reduce my costs through different techniques or services. We’re getting warmer. Fitbit replaces lost trackers for free. The Apple Genius Bar. The free group runs, training programs, yoga, and discounts at our local Fleet Feet running store. There are plenty of examples, but let’s be honest – the enterprise tech industry isn’t usually on the list. I had two calls today with a client I have been doing project work with. I didn’t bill them for it, and those calls themselves aren’t tied to any prospective projects. But the client needs help, the cost to me is relatively low, and I know it will come back later when the sign up for another big project. Trust me, we still have our lines (sorry, investment firms, no more freebies if we have never worked together), but in every business I’ve ever run those little helpful moments add up and pay off in the end. Want some practical examples in the security industry? Adjusting pricing models for elastic clouds. Using soft service limits so when you accidentally scan that one extra server on the network, you don’t lock down the product, and you get a warning and an opportunity to up your license. Putting people on the support desk who know what the hell they are talking about. Paying attention to the product’s user experience – not merely focusing on one pretty dashboard to impress the CIO in the sales meeting. Improving provisioning so your product is actually relatively easy to install, instead of hacking together a bunch of scripts and crappy documentation. We make security a lot harder on customers than it needs to be. That makes exceptions all the more magical. (In other news, go watch Mr. Robot. If you work in this industry, it’s like a documentary). On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted at PC World on Dropbox adding FIDO key support. Mike over at CSO Online on security spending focus. Rich in the Wall St. Journal on Apple and Google taking different approaches to smart agents like Siri and Google Now. Yep, Rich keeps press whoring with comments on Black Hat. It never ends. You know who on some Apple vulnerabilities at the Guardian. And lastly, one Rich actually wrote for TidBITS about that crappy Wired article on the Thunderstrike 2 worm. Favorite Securosis Posts Mike Rothman: Firestarter: Karma – You M.A.D., bro? It seems the entire security industry is, and justifiably so. Oracle = tone deaf. Rich: Incite 8/12/2015: Transitions. My kids are about a decade behind Mike’s, just entering kindergarten and first grade, but it’s all the same. Other Securosis Posts Incite 7/29/2015: Finding My Cause. Building a Threat Intelligence Program: Gathering TI. EMV and the Changing Payment Space: Mobile Payment. EMV and the Changing Payment Space: Systemic Tokenization. EMV and the Changing Payment Space: The Liability Shift. Building a Threat Intelligence Program [New Series]. EMV and the Changing Payment Space: Migration. Favorite Outside Posts Mike: Gossip to Grown Up: How Intelligence Sharing Developed – Awesome post on the RSAC blog by Wendy about the history and future of TI. The key issue is “getting trust to scale”. Rich: How Hackers Steal Data From Websites. Oh, my. The Onion has us dead to rights. Research Reports and Presentations Endpoint Defense: Essential Practices. Cracking the Confusion: Encryption and Tokenization for Data Centers, Servers, and Applications. Security and Privacy on the Encrypted Network. Monitoring the Hybrid Cloud: Evolving to the CloudSOC. Security Best Practices for Amazon Web Services. Securing Enterprise Applications. Secure Agile Development. Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. Top News and Posts No, You Really Can’t (Mary Ann Davidson Blog). In case you missed it, here’s the archive. Fun, eh? Oracle’s security chief made a big gaffe in a now-deleted blog post. More on the story. Software Security: On the Wrong Side of History. Chris Wysopal of Veracode responds. Guess who used to be one of their advisors? Popcorn ensues. Cisco Warns Customers About Attacks Installing Malicious IOS Bootstrap Images. Researchers reveal electronic car lock hack after 2-year injunction by Volkswagen. Stagefright: new Android vulnerability dubbed ‘heartbleed for mobile’. Stagefright Patch Incomplete Leaving Android Devices Still Exposed. Friends don’t let friends… Hack-Fueled ‘Unprecedented’ Insider Trading Ring Nets $100M. Share:

The depths of summer heat in Atlanta can only mean one thing: the start of the school year. The first day of school is always the second Monday in August, so after a week of frenetic activity to get the kids ready, and a day’s diversion for some Six Flags roller coaster goodness, the kids started the next leg of their educational journey. XX1 started high school, which is pretty surreal for me. I remember her birth like it was yesterday, but her world has got quite a bit bigger. She spent the summer exploring the Western US and is now in a much bigger school. Of course her world will continue to get bigger with each new step. It will expand like a galaxy if she lets it. The twins also had a big change of scene, starting middle school. So they were all fired up about getting lockers for the first time. A big part of preparing them was to make sure XX2’s locker was decorated and that the Boy had an appropriately boyish locker shelf. The pink one we had left over from XX1 was no bueno. Dark purple shelves did the trick.   Their first day started a bit bumpy for the twins, with some confusion about the bus schedule – much to our chagrin, when we headed out to meet the bus, it was driving right past. So we loaded them into the car and drove them on the first day. But all’s well that ends well, and after a couple days they are settling in. As they transition from one environment to the next, the critical thing is to move forward understanding that there will be discomfort. It’s not like they have a choice about going to the next school. Georgia kind of mandates that. But as they leave the nest to build their own lives they’ll have choices – lots of them. Stay where they are, or move forward into a new situation, likely with considerable uncertainty. A quote I love is: “In any given moment we have two options: to step forward into growth or to step back into safety.” If you have been reading the Incite for any length of time you know I am always moving foward. It’s natural for me, but might not be for my kids or anyone else. So I will continue ensuring they are aware that during each transition that they can decide what to do. There are no absolutes; sometimes they will need to pause, and other times they should jump in. And if they take Dad’s lead they will keep jumping into an ever-expanding reality. –Mike Photo credit: “Flickrverse, Expanding Ever with New Galaxies Forming” originally uploaded by cobalt123 Thanks to everyone who contributed to my Team in Training run to support the battle against blood cancers. We have raised over $5,000 so far, which is incredible. I am overwhelmed with gratitude. You can read my story in a recent Incite, and then hopefully contribute (tax-deductible) whatever you can afford. Thank you. The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. Aug 12 – Karma July 13 – Living with the OPM Hack May 26 – We Don’t Know Sh–. You Don’t Know Sh– May 4 – RSAC wrap-up. Same as it ever was. March 31 – Using RSA March 16 – Cyber Cash Cow March 2 – Cyber vs. Terror (yeah, we went there) February 16 – Cyber!!! February 9 – It’s Not My Fault! January 26 – 2015 Trends January 15 – Toddler December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Building a Threat Intelligence Program Gathering TI Introduction EMV and the Changing Payment Space Mobile Payment Systemic Tokenization The Liability Shift Migration The Basics Introduction Network Security Gateway Evolution Introduction Recently Published Papers Endpoint Defense: Essential Practices Cracking the Confusion: Encryption & Tokenization for Data Centers, Servers & Applications Security and Privacy on the Encrypted Network Monitoring the Hybrid Cloud Best Practices for AWS Security Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Future of Security Incite 4 U Business relevance is still important: Forrester’s Peter Cerrato offers an interesting analogy at ZDNet about not being a CISO dinosaur, and avoiding extinction. Instead try to be an eagle, whose ancestors survived the age of the dinosaurs. How do you do that? By doing a lot of the things I’ve been talking about for, um, 9 years at this point. Be relevant to business? Yup. Get face time with executives and interface with the rank and file? Yup. Plan for failure? Duh. I don’t want to minimize the helpfulness or relevance of this guidance. But I do want make clear that the only thing new here is the analogy. – MR The Dark Tangent is right: What did I learn at Black Hat? That people can hack cars. Wait, I am pretty sure I already knew this was possible. Maybe it was the new Adobe Flash bugs? Or IoT vulnerabilities? Mobile hacks or browser vulnerabilities? Yeah, same old parade of vulnerable crap. What I really learned is that Jeff Moss is right: Software liability is coming. Few vendors – Microsoft being the notable exception – have really put in the effort to address vulnerable software. Mary Ann Davidson’s insulting rant reinforces that vendors really don’t want to fix vulnerabilities –

Way back in 2004 Rich wrote an article over at Gartner on the serious issues plaguing Oracle product security. The original piece is long gone, but here is an article about it. It lead to a moderately serious political showdown, Rich flying out to meet with Oracle execs, and eventually their move to a quarterly patch update cycle (due more to the botched patch than Rich’s article). This week Oracle’s 25-year-veteran CISO Mary Ann Davidson published a blog post decrying customer security assessments of their products. Actually she threatened legal action for evaluation of Oracle products using tools that look at application code. Then she belittled security researchers (for crying wolf, not understanding what they are talking about, and wasting everybody’s time – especially her team’s), told everyone to trust Oracle because they find nearly all the bugs anyway (not that they seem to patch them in a timely fashion), and… you get it. Then, and this is the best part, Oracle pulled the post and basically issued an apology. Which never happens. So you probably don’t need us to tell you what this Firestarter is about. The short version is that the attitudes and positions expressed in her post closely match Rich’s experiences with Oracle and Mary Ann over a decade ago. Yeah, this is a fun one. Share:

When you have resources you are supposed to give back. That’s what they teach you as a kid, right? There are folks less fortunate than you, so you help them out. I learned those lessons. I dutifully gave to a variety of charities through the years. But I was never passionate about any cause. Not enough to get involved beyond writing a check. I would see friends of mine passionate about whatever cause they were pushing. I figured if they were passionate about it I should give, so I did. Seemed pretty simple to me, but I always had a hard time asking friends and associates to donate to something I wasn’t passionate about. It seemed disingenuous to me. So I didn’t. I guess I’ve always been looking for a cause. But you can’t really look. The cause has to find you. It needs to be something that tugs at the fabric of who you are. It has to be something that elicits an emotional response, which you need to be an effective fundraiser and advocate. It turns out I’ve had my cause for over 10 years – I just didn’t know it until recently. Cancer runs in my family. Mostly on my mother’s side or so I thought. Almost 15 years ago Dad was diagnosed with Stage 0 colon cancer. They were able to handle it with a (relatively) minor surgery because they caught it so early. That was a wake-up call, but soon I got caught up with life, and never got around to getting involved with cancer causes. A few years later Dad was diagnosed with Chronic Lymphocytic Leukemia (CLL). For treatment he’s shied away from western medicine, and gone down his own path of mostly holistic techniques. The leukemia has just been part of our lives ever since, and we accommodate. With a compromised immune system he can’t fly. So we go to him. For big events in the South, he drives down. And I was not exempt myself, having had a close call back in 2007. Thankfully due to family history I had a colonoscopy before I was 40 and the doctor found (and removed) a pre-cancerous polyp that would not have ended well for me if I hadn’t had the test. Yet I still didn’t make the connection. All these clues, and I was still spreading my charity among a number of different causes, none of which I really cared about. Then earlier this year another close friend was diagnosed with lymphoma. They caught it early and the prognosis is good. With all the work I’ve done over the past few years on being aware and mindful in my life, I finally got it. I found my cause – blood cancers. I’ll raise money and focus my efforts on finding a cure. It turns out the Leukemia and Lymphoma Society has a great program called Team in Training to raise money for blood cancer research by supporting athletes in endurance races. I’ve been running for about 18 months now and already have two half marathons under my belt. This is perfect. Running and raising money! I signed up to run the Savannah Half Marathon in November as part of the TNT team. I started my training plan this week, so now is as good a time as any to gear up my fundraising efforts. I am shooting to run under 2:20, which would be a personal record.   Given that this is my cause, I have no issue asking you to help out. It doesn’t matter how much you contribute, but if you’ve been fortunate (as I have) please give a little bit to help make sure this important research can be funded and this terrible disease can be eradicated in our lifetime. Dad follows the research very closely as you can imagine, and he’s convinced they are on the cusp of a major breakthrough. Here is the link to help me raise money to defeat blood cancers: Mike Rothman’s TNT Fund Raising Page. I keep talking about my cause, but this isn’t about me. This is about all the people suffering from cancer and specifically blood cancers. I’m raising money for all the people who lost loved ones or had to put their lives on hold as people they care about fight. Again, if you can spare a few bucks, please click the link above and contribute. –Mike The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. July 13 – Living with the OPM Hack May 26 – We Don’t Know Sh–. You Don’t Know Sh– May 4 – RSAC wrap-up. Same as it ever was. March 31 – Using RSA March 16 – Cyber Cash Cow March 2 – Cyber vs. Terror (yeah, we went there) February 16 – Cyber!!! February 9 – It’s Not My Fault! January 26 – 2015 Trends January 15 – Toddler December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Building a Threat Intelligence Program Gathering TI Introduction EMV and the Changing Payment Space Mobile Payment Systemic Tokenization The Liability Shift Migration The Basics Introduction Network Security Gateway Evolution Introduction Recently Published Papers Endpoint Defense: Essential Practices Cracking the Confusion: Encryption & Tokenization for Data Centers, Servers & Applications Security and Privacy on the

As we close out this series on the EMV migration and changes in the payment industry, we are adding a section on mobile payments to clarify the big picture. Mobile usage is invalidating some long-held assumptions behind payment security, so we also offer tips to help merchants and issuing banks deal with the changing threat landscape. Some of you reading about this for the first time will wonder why we are talking about mobile device payments, when the EMV migration discussion has largely centered on chipped payment cards supplant the magstripe cards in your wallet today. The answer is that it’s not a question of whether users will have smart cards or smartphones in the coming years – many will have both. At least in the short term. American Express has already rolled out chipped cards to customers, and Visa has stated they expect 525 million chipped cards to be in circulation at the end of 2015. But while chipped cards form a nice bridge to the future, a recurring theme during conversations with industry insiders was that they see the industry inexorably headed toward mobile devices. The transition is being driven by a combination of advantages including reduced deployment costs, better consumer experience, and increased security both at endpoint devices and within the payment system. Let’s dig into some reasons: Cost: Issuers have told us chipped cards cost them $5-12 per card issued. Multiplied by hundreds of millions of cards in circulation, the switch will cost acquirers a huge quantity of money. A mobile wallet app is easier and cheaper than a physical card with chip, and can be upgraded. And customers select and purchase the type of device they are comfortable with. User Experience: Historically, the advantage of credit cards over cash was ease of use. Consumer are essentially provided a small loan for their purchase, avoiding impediments from cash shortfalls or visceral unwillingness to hand over hard-earned cash. This is why credit cards are called financial lubricant. Now mobile devices hold a similar advantage over credit cards. One device may hold all of your cards, and you won’t even have to fumble with a wallet to use one. When EMVCo tested smart cards — as they function slightly differently than mag stripe — one in four customers had trouble on first use. Whether they inserted the card into the reader wrong, or removed it before the reader and chip had completed their negotiaton, the transaction failed. Holding a phone near a terminal is easier and more intuitive, and less error-prone – especially with familiar feedback on the customer’s phone. Endpoint Protection: The key security advantage of smart cards is that they are very difficult to counterfeit. Payment terminals can cryptographically verify that the chip in the card is valid and belongs to you, and actively protect secret data from attackers. That said, modern mobile phones have either a “Secure Element” (a secure bit of hardware, much like in a smart card) or “Host Card Emulation” (a software virtual secure element). But a mobile device can also validate its state, provide geolocation information, ask the user for additional verification such as a PIN or thumbprint for high-value transactions, and perform additional checks as appropriate for the transaction/device/user. And features can be tailored to the requirements of the mobile wallet provider. Systemic Security: We discussed tokenization in a previous post: under ideal conditions the PAN itself is never transmitted. Instead the credit card number on the face of the card is only known to the consumer and the issuing bank – everybody else only uses a token. The degree to which smart cards support tokenization is unclear from the specification, and it is also unclear whether they can support the PAR. But we know mobile wallets can supply both a payment token and a customer account token (PAR), and completely remove the PAN from the consumer-to-merchant transaction. This is a huge security advance, and should reduce merchants’ PCI compliance burden. The claims of EMVCo that the EMV migration will increase security only make sense with a mobile device endpoint. If you reread the EMVCo tokenization specification and the PAR token proposal with mobile in mind, the documents fully make sense and many lingering questions are address. For example, why are all the use cases in the specification documents for mobile and none for smart cards? Why incur the cost of issuing PINs, and re-issuing them when customers forget, when authentication can be safely delegated to a mobile device instead? And why is there not a discussion about “card not present” fraud – which costs more than forged “card present” transactions. The answer is mobile, by facilitating two-factor authentication (2FA). A consumer can validate a web transaction to their bank via 2FA on their registered mobile device. How does this information help you? Our goal for this post is to outline our research findings on the industry’s embrace of smartphones and mobile devices, and additionally to warn those embracing mobile apps and offering them to customers. The underlying infrastructure may be secure, but adoption of mobile payments may shift some fraud liability back onto the merchants and issuing banks. There are attacks on mobile payment applications which many banks and mobile app providers have not yet considered. Account Proofing When provisioning a payment instrument to mobile devices, it is essential to validate both the user and the payment instrument. If a hacker can access an account they can associate themself and their mobile device with a user’s credit card. A failure in the issuing bank’s customer Identification and Verification (ID&V) process can enable hackers to link their devices to user cards, and then used to make payments. This threat was highlighted this year in what the press called the “Apple Pay Hack”. Fraud rates for Apple Pay were roughly 6% of transactions in early 2015 (highly dependent on the specifics of issuing bank processes), compared to approximately 0.1% of card swipe transactions. The real issue was not in the Apple Pay system, but instead that banks allowed attackers to link stolen credit cards to arbitrary mobile devices. Merchants who attempt to tie credit cards,

This post covers why I think tokenization will radically change payment security. EMV-compliant terminals offer several advantages over magnetic stripe readers – notably the abilities to communicate with mobile devices, validate chipped credit cards, and process payment requests with tokens rather than credit card numbers. Today’s post focuses on use of tokens in EMV-compliant payment systems. This is critically important, because when you read the EMV tokenization specification it becomes clear that its security model is to stop passing PAN around as much as possible, thereby limiting its exposure. You do not need to be an expert on tokenization to benefit fully from today’s discussion, but you should at least know what a token is and that it can fill in for a real credit card number without requiring significant changes to payment processing systems. For those of you reading this paper who need to implement or manage payment systems, you should be familiar with two other documents: the EMV Payment Tokenization Specification version 1.0 provides a detailed technical explanation of how tokenization works in EMV-compliant systems, and the Payment Account Reference addendum to the specification released in May 2015. If you want additional background, we have written plenty about tokenization here at Securosis. It is one of our core coverage areas because it’s relatively new for data security, poorly understood by the IT and security communities, but genuinely promising technology. If you’re not yet up to speed and want a little background before we dig in, there dozens of posts on the Securosis blog. Free full research papers available include Understanding and Selecting Tokenization as a primer, Tokenization Guidance to help firms understand how tokenization reduces PCI scope, Tokenization vs. Encryption: Options for Compliance to help firms understand how these technologies fit into a compliance program, and Cracking the Confusion: Encryption and Tokenization for Data Centers, Servers and Application to help build these technologies into systems. Merchant Side Tokenization Tokenization has proven its worth to merchants by reducing the scope of PCI-DSS (Payment Card Industry Data Security Standard) audits. Merchants, and in some cases their payment processors, use tokens instead of credit card numbers. This means that they do not need to store the PAN or any associated magstripe data, and a token is only a reference to a transaction or card number, so they don’t need to worry that it might be lost of stolen. The token is sufficient for a merchant to handle dispute resolution, refunds, and repayments, but it’s not a real credit card number, so it cannot be used to initiate new payment requests. This is great for security, because the data an attacker needs to commit fraud is elsewhere, and the merchant’s exposure is reduced. We are focused on tokenization because the EMV specification relies heavily on tokens for payment processing. These tokens will come from issuing banks via a Token Service Provider (rather than from a merchant); the TSP tracks tokens globally. That is good security, but a significant departure from the way things work today. Additionally, many merchants have complained because without a PAN or some way to uniquely identify users, many of their event processing and analytics systems break. This has created significant resistance to EMV adoption, but this barrier is about to be broken. With Draft Specification Bulletin No. 167 of May 2015, EMVCo introduced the Payment Account Reference. This unique identification token solves many of the transparency issues that merchants have with losing access to the PAN. The Payment Account Reference and Global Tokenization Merchants, payment gateways, and acquirers want – and in some cases need – to link customers to a payment instrument presented during a transaction. This helps with fraud detection, risk analytics, customer loyalty programs, and various other business operations. But if a PAN is sensitive and part of most payment fraud, how can we enable all those use cases while limiting risk? Tokenization. EMVCo’s Payment Account Reference (PAR) is essentially a token to reference a specific bank account. It is basically a random value representing a customer account at an issuing bank, but cannot be reverse-engineered back to a real account number. In addition to this token, the EMV Payment Tokenization Specification also specifies token replacement for each PAN to reduce the use and storage of credit card numbers throughout the payment ecosystem. This will further reduce fraud by limiting the availability of credit card numbers for attackers to access. Rather than do this on a merchant-by-merchant basis, it is global and built into the system. The combination of these two tokens enables unambiguous determination of a customer’s account and payment card, so everyone in the payment ecosystem can leverage their current anti-fraud and analytics systems – more on this later. Let’s look at PARs in more detail: PAR is a Payment Account Reference, or a pointer to (what people outside the banking industry call) your bank account. PAR is itself a token with a one-to-one mapping to the bank account, intended to last as long as the bank account. You may have multiple mobile wallets, smart cards or other device, but that PAR will be consistent across each. The PAR will remain the same for each value of PAN; as a payment account may have multiple PANs associated with it, the PAR will always be the same. The PAR token will be passed, along with the credit card number or token, to the merchant’s bank or payment processor. A PAR should be present for all transactions, regardless of whether the PAN is tokenized or not. PAR tokens are generated from a Token Service Provider, requested from and provided via the issuing bank. A PAR will enable merchants and acquirers to consistently link transactions globally, and to confirm that a Primary Account Number (PAN) (your credit card number) is indeed associated with that account. A PAR has a one-to-one relationship with the issuing bank account, but a one-to-many relationship with payment cards or mobile devices. For the geeks out there, a PAR cannot be reverse-engineered into a bank account number or a credit card number, and cannot be used to find either of those values without special knowledge. Token Service

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

Moving to EMV compliant terminals is not a plug-and-play endeavor. You can’t simply plug them in, turn them on and expect everything to work. Changes are needed to the software for supporting point-of-sale systems (cash registers). You will likely need to provision keys to devices; if you manage keys internally you will also need to make sure everything is safely stored in an HSM. There are often required changes to back-office software to sync up with the POS changes. IT staff typically need to be trained on the new equipment. Merchants who use payment processors or gateways that manage their terminals for them face less disruption, but it’s still a lot of work and rollouts can take months. Much of the merchant pushback we heard was due to the cost, time, and complexity of this conversion. Merchants see basically the old payment system they have today, with one significant advantage: that cards can be validated at swipe. But merchants have not been liable for counterfeit cards, so have had little motivation to embrace this cumbersome change. PINs vs. Signatures Another issue we heard was the lack of requirement for “Chip and PIN”, meaning that in conjunction to the chipped card, users must punch in their PIN after swiping their card. This verifies that the user using the card owns it. But US banks generally do not use PINs, even for chipped cards like the ones I carry. Instead in the US signatures are typically required for purchases over a certain dollar amount, which has proven to be a poor security control. PINs could be required in the future, but the issuers have not published any such plans. Point to Point Encryption The EMV terminal specification does not mandate the use of point-to-point encryption (P2PE). That means that, as before, PAN data is transferred in the clear, along with any other data being passed. For years the security community has been asking merchants to encrypt the data from card swipe terminals to ensure it is not sniffed from the merchant network or elsewhere as the PAN is passed upstream for payment processing. Failure to activate this basic technology, which is built into the terminals, outrages security practitioners and creates a strong impression that merchants are cavalier with sensitive data; recent breaches have not improved this perception. But of course it is a bit more complicated. Many merchants need data from terminals for fraud and risk analytics. Others use the data to seed back-office customer analytics for competitive advantage. Still others do not want to be tied to a specific payment provider, such as by provisioning gateways or provider payment keys. Or the answer may be all of the above, but we do not anticipate general adoption of P2PE any time soon. Why Move? The key question behind this series is: why should merchants move to EMV terminals? During our conversations each firm mentioned a set of goals they’d like to see, and a beef with some other party in the payment ecosystem. The card brands strongly desire any changes that will make it easier for customers to use their credit cards and grease the skids of commerce, and are annoyed at merchants standing in the way of technical progress. The merchants are generally pissed at the fees they pay per transaction, especially for the level of service they receive, and want the whole security and compliance mess to go away because it’s not part of their core business. These two factors are why most merchants wanted a direct Merchant-Customer Exchange (MCX) based system that did away with credit cards and allowed merchant to have direct connections with customer bank accounts. The acquirers were angry that they have been forced to shoulder a lot of the fraud burden, and want to maintain their relationships with consumers rather than abdicating it to merchants. And so on. Security was never a key issue in any of these discussions. And nobody is talking about point-to-point encryption as part of the EMV transition, so it will not really protect the PAN. Additionally, the EMV transition will not help with one of the fastest growing types of fraud: Card Not Present transactions. And remember that PINs are not required – merely recommended, sometimes. For all these reasons it does not appear that security is driving the EMV shift. This section will be a bit of a spoiler for our conclusion, but I think you’ll see from the upcoming posts where this is all heading. There are several important points to stress here. First, EMV terminal adoption is not mandatory. Merchants are not being forced to update. But the days of “nobody wanting EMV” are past us – especially if you take a broad view of what the EMV specifications allow. Citing the lack of EMV cards issued to customers is a red herring. The vast majority of card holders have smart phones today, which can be fully capable “smart cards”, and many customers will happily use them to replace plastic cards. We see it overseas, especially in Africa, where some countries process around 50% of payments via mobile devices. Starbucks has shown definitively that consumers will use mobile phones for payment, and also do other things like order via an app. Customers don’t want better cards – they want better experiences, and the card brands seem to get this. Security will be better, and that is one reason to move. The liability waiver is an added benefit as well. But both are secondary. The payment technology change may look simple, but the real transition underway is from magnetic plastic cards to smartphones, and it’s akin to moving from horses to automobiles. I could say this is all about mobile payments, but that would be gross oversimplification. It is more about what mobile devices – powerful pocket computers – can and will do to improve the entire sales experience. New technology enables complex affinity and pricing plans, facilitates the consumer experience, provides geolocation, and offers an opportunity to bring the underlying system into the modern age (with modern security). If