Research

As we wrap up this series on Threat Detection Evolution, we’ll work through a quick scenario to illustrate how these concepts come together to impact on your ability to detect attacks. Let’s assume you work for a mid-sized super-regional retailer with 75 stores, 6 distribution centers, and an HQ. Your situation may be a bit different, especially if you work in a massive enterprise, but the general concepts are the same. Each of your locations is connected via an Internet-based VPN that works well. You’ve been gradually upgrading the perimeter network at HQ and within the distribution centers by implementing NGFW technology and turning on IPS on the devices. Each store has a low-end security gateway that provides separate networks for internal systems (requiring domain authentication) and customer Internet access. There are minimal IT staff and capabilities outside HQ. A technology lead is identified for each location, but they can barely tell you which lights are blinking on the boxes, so the entire environment is built to be remotely managed. In terms of other controls, the big project over the past year has been deploying whitelisting on all fixed function devices in distribution centers and stores, including PoS systems and warehouse computers. This was a major undertaking to tune the environment so whitelisting did not break systems, but after a period of bumpiness the technology is working well. The high-profile retail attacks of 2014 freed up budget for the whitelisting project, but aside from that your security program is right out of the PCI-DSS playbook: simple logging, vulnerability scanning, IPS, and AV deployed to pass PCI assessment; but not much more. Given the sheer number of breaches reported by retailer after retailer, you know that the fact you haven’t suffered a successful compromise is mostly good luck. Getting ahead of PoS attacks with whitelisting has helped, but you’ve been doing this too long to assume you are secure. You know the simple logging and vulnerability scanning you are doing can easily be evaded, so you decide it’s time to think more broadly about threat detection. But with so many different technologies and options, how do you get started? What do you do first? Getting Started The first step is always to leverage what you already have. The good news is that you’ve been logging and vulnerability scanning for years. The data isn’t particularly actionable, but it’s there. So you can start by aggregating it into a common place. Fortunately you don’t need to spend a ton of money to aggregate your security data. Maybe it’s a SIEM, or possibly an offering that aggregates your security data in the cloud. Either way you’ll start by putting all your security data in one place, getting rid of duplicate data, and normalizing your data sources, so you can start doing some analysis on a common dataset. Once you have your data in one place, you can start setting up alerts to detect common attack patterns in your data. The good news is that all the aggregation technologies (SIEM and cloud-based monitoring) offer options. Some capabilities are more sophisticated than others, but you’ll be able to get started with out-of-the-box capabilities. Even open source tools offer alerting rules to get you started. Additionally, security monitoring vendors invest significantly in research to define and optimize the rules that ship with their products. One of the most straightforward attack patterns to look for involves privilege escalation after obvious reconnaissance. Yes, this is simple detection, but it illustrates the concept. Now that you have server and IPS logs in one place, you can look for increased network port scans (usually indicating reconnaissance) and then privilege escalation on a server on one of the networks being searched. This is a typical rule/policy that ships with a SIEM or security monitoring service. But you could just as easily build this into your system to get started. Odds are that once you start looking for these patterns you’ll find something. Let’s assume you don’t because you’ve done a good job so far on security fundamentals. After starting by going through your first group of alerts, next you can look for assets in your environment which you don’t know about. That entails either active or passive discovery of devices on the network. Start by scanning your entire address space to see what’s there. You probably shouldn’t do that during business hours, but a habit of checking consistently – perhaps weekly or monthly – is helpful. In between active scans you can also passively listen for network devices sending traffic, by either looking at network flow records or deploying a passive scanning capability specifically to look for new devices. Let’s say you discover your development shop has been testing out private cloud technologies to make better use of hardware in the data center. The only reason you noticed was passive discovery of a new set of devices communicating with back-end datastores. Armed with this information, you can meet with that business leader to make sure they took proper precautions to securely deploy their systems. Between alerts generated from new rules and dealing with the new technology initiative you didn’t know about, you feel pretty good about your new threat detection capability. But you’re still looking for stuff you already know you should look for. What really scares you is what you don’t know to look for. More Advanced Detection To look for activity you don’t know about, you need to first define normal for your environment. Traffic that is not ‘normal’ provides a good indicator of potential attack. Activity outliers are a good place to start because network traffic and transaction flows tend to be reasonably stable in most environments. So you start with anomaly detection by spending a week or so training your detection system, setting baselines for network traffic and system activity. Once you start getting alerts based on anomalies, you will spend a bit of time refining thresholds and decreasing the noise you see from alerts. This tuning time may be irritating, but it’s a necessary evil to optimize

This is the second post in our series on the “liability shift” proposed by EMVCo – the joint partnership of Visa, Mastercard, and Europay. Today we will cover the basics of what the shift is about, requirements for merchants, and what will happen to those who do not comply. But to help understand we will also go into a little detail about payment providers behind the scenes. To set the stage, what exactly are merchants being asked to adopt? The EMV migration, or the EMV liability shift, or the EMV chip card mandate – pick your favorite marketing term – is geared toward US merchants who use payment terminals designed to work only with magnetic stripe cards. The requirement to adopt terminals capable of validating payment cards with embedded EMV compliant ‘smart’ chips. This rule goes into effect on October 1, 2015, and – a bit like my tardiness in drafting this research series – I expect may merchants to be a little late adopting the new standards. Merchants are being asked to replace their old magstripe-only specific terminals with more advanced, and significantly more expensive, EMV chip compatible terminals. EMVCo has created three main rules to drive adoption: If an EMV ‘chipped’ card is used in a fraudulent transaction with one of the new EMV compliant terminals, just like today the merchant will not be liable. If a magnetic stripe card is used in a fraudulent transaction with a new EMV compliant terminals, just like today the merchant will not be liable. If a magnetic stripe card is used in a fraudulent transaction with one of the old magstripe-only terminals, the merchant – instead of the issuing bank – will be liable for the fraud. That’s the gist of it: a merchant that uses an old magstripe terminal pays for any fraud. There are a few exceptions to the basic rules – for example the October date I noted above only applies to in-store terminals, and won’t apply to kiosks and automated systems like gas pumps until 2017. So what’s all the fuss about? Why is this getting so much press? And why has there been so much pushback from merchants against adoption? Europe has been using these terminals for over a decade, and it seems like a straightforward calculation: projected fraud losses from card-present magstripe cards over some number of years vs. the cost of new terminals (and software and supporting systems). But it’s not quite that simple. Yes, cost and complexity are increased for merchants – and for the issuing banks when they send customers new ‘chipped’ credit cards. But it is not actually clear that merchant will be free of liability. I will go into reasons later in this series, but for now I can say that EMV does not fully secure the Primary Account Number, or PAN (the credit card number to you and me) sufficiently to protect merchants. It’s also not clear what data will be shared with merchants, and whether they can fully participate in affiliate programs and other advanced features of EMV. And finally, the effort to market security under threat of US federal regulation masks the real advantages for merchants and card brands. But before I go into details some background is in order. People within the payment industry who read this know it all, but most security professionals and IT practitioners – even those working for merchants – are not fully conversant with the payment ecosystem and how data flows. Further, it’s not useful for security to focus solely on chips in cards, when security comes into play in many other places in the payment ecosystem. Finally, it’s not easy to understand the liability shift without first understanding where liability might shift from. As these things all go hand in hand – liability and insecurity – so it’s time to talk about the payment ecosystem, and some other areas where security comes into play. When a customer swipes a card, it is not just the merchant who is involved in processing the transaction. There are potentially many different banks and service providers who help route the request and who send money to the right places. And the merchant never contacts your bank – also know as the “issuing bank” directly. When you swipe your card at the terminal, the merchant may well rely on a payment gateway to connect to their bank. In other cases the gateway may not link directly to the merchant’s bank; instead it may enlist a payment processor to handle transactions. The payment processor may be the merchant bank or a separate service provider. The processor collects funds from the customer’s bank and provides transaction approval. Here is a bit more detail on the major players. Issuing Bank: The issuer typically maintains customer relationships (and perhaps affinity branding) and issues credit cards. They offer affiliate branded payment cards, such as for charities. There are thousands of issuers worldwide. Big banks have multiple programs with many third parties, credit unions, small regional banks, etc. And just to complicate things, many ‘issuers’ outsource actual issuance to other firms. These third parties, some three hundred strong, are all certified by the card brands. Recently cost and data mining have been driving some card issuance back in-house. The banks are keenly aware of the value of customer data, and security concerns (costs) can make outsourcing less attractive. Historically most smart card issuance was outsourced because EMV was new and complicated, but advances in software and services have made it easier for issuing banks. But understand that multiple parties may be involved. Payment Gateway: Basically a leased gateway linking a merchant to a merchant bank for payment processing. Their value is in maintaining networks and orchestrating process and communication. They check with the merchant bank whether the CC is stolen or overdrafted. They may check with anti-fraud detection software or services to validate transactions. Firms like PayJunction are both gateway and processor, and there are hundreds of Internet-only gateways/processors. Payment Processor: A company appointed by a merchant to handle credit card