Research

Rich here. I’m going to pull an Adrian this week, and cover a few unrelated things. Nope, no secret tie-in at the end, just some interesting things that have hit over the past couple weeks, since I wrote a Summary. We are absolutely blowing out the registration for this year’s cloud security training at Black Hat. I believe we will be the best selling class at Black Hat for the second year in a row. And better yet, all my prep work is done already, which has never happened before. Bigger isn’t necessarily better when it comes to training, so we are pulling out all the stops. We have a custom room configuration and extra-special networking so we can split the class apart as needed to cover different student experience levels. James Arlen and I also built a mix of labs (we are even introducing Azure for the first time) to cover not only different skill levels, but different foci (network security, developers, etc.). For the larger class we also have two extra instructors who are only there to wander the room and help people out (Mike and Adrian). Switching my brain around from coding and building labs, to regular Securosis work, can be tough. Writing prose takes a different mindset than writing code and technical work, and switching is a bit more difficult than I like. It’s actually easier for me to swap from prose to code than the other way around. This is my first week back in Phoenix after our annual multi-week family excursion back to Boulder. This trip, more than many others, reminded me a bit of my roots and who I am. Two major events occurred. First was the OPM hack, and the fact that my data was lost. The disaster response team I’m still a part of is based out of Colorado and part of the federal government. I don’t have a security clearance, but I still had to fill out one of the security forms that are now backed up, maybe in China. Yes, just to be an EMT and drive a truck. I spoke for an hour at our team meeting and did my best to bring our world of cybersecurity to a group of medical professionals who suddenly find themselves caught up in the Big Game. To provide some understanding of what’s going on, why not to trust everything they hear, and how to understand the impact this will have on them for the rest of their lives. Because it sure won’t be over in 18 months after the credit monitoring term end (which they won’t even need if it was a foreign adversary). This situation isn’t fair. These are volunteers willing to put themselves at physical risk, but they never signed up for the intangible but very real risks created by the OPM. A few days before that meeting an air medical helicopter crashed. The pilot was killed, and a crew member badly injured. I didn’t know them well (barely at all), but had worked with both of them. I may have flown with the pilot. I debated mentioning this at all, since it really had nothing to do with me. I’m barely a part of that community any more, although I did spend over 15 years in it. Public safety, like any profession, can be a small world. Especially as we all bounced around different agencies and teams in the mountains of Colorado. I suppose it hits home more when it’s someone in your tribe, even if you don’t have a direct personal relationship. I’m barely involved in emergency services any more, but it is still a very important part of my life and identity. Someday, maybe, life will free up enough that I can be more active again. I love what I do now, but, like the military, you can’t replace the kinds of bonds built when physical risk is involved. For a short final note, I just started reading a Star Wars book for the first time in probably over 20 years. I’m incredibly excited for the new film, and all the new books and comics are now officially canon and part of the epic. The writing isn’t bad, but it really isn’t anything you want to read unless you are a huge Star Wars nerd. But I am, so I do. There you go. Black Hat, rescue, and Star Wars. No linkage except me. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich at SearchSecurity on the needed death of Flash Rich quoted in CSO by Ben Rothke on the role of the Cloud Security Architect Favorite Securosis Posts Mike: Firestarter: Living with the OPM. Rich has been affected by the OPM breach and that sucks. We discuss what it means for him. Other Securosis Posts Incite 7/15/15 – On Top of the Worlds. Incite 7/1/2015: Explorers. New Series: EMV, Tokenization, and the Changing Payment Space. EMV and the Changing Payments Space: the Basics. Threat Detection: Analysis. Threat Detection Evolution: Quick Wins. Favorite Outside Posts Mike: Why start-up rules don’t apply to security. VC Sam Myers points out that security is different than other tech markets. Right. But I’m not sure every security company needs to target the large enterprise to be successful. Adrian: Lowering Defenses to Increase Security I like Mike King’s take, and bringing the human side into the security story. A good post and worth reading! Rich: FBI Director to Silicon Valley: ‘Try Harder’ to Find ‘Going Dark’ Solution. This isn’t my favorite, but it’s something I think everyone needs to read. The FBI director either wants us to invent magic, or is deliberately being disingenuous in an attempt to force political hands. Flip a coin. 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

And yep, thanks to his altruistic streak even Rich is affected. We don’t spend much time on blame or history, but more on the personal impact. How do you move on once you know much of your most personal information is now out there, you don’t know who has it, and you don’t know how they might want to use it? Watch or listen: Share:

I discussed my love of exploring in the last Incite, and I have been fortunate to have time this summer to actually explore a bit. The first exploration was a family vacation to NYC. Well, kind of NYC. My Dad has a place on the Jersey shore, so we headed up there for a couple days and took day trips to New York City to do the tourist thing. For a guy who grew up in the NY metro area, it’s a bit weird that I had never been to the Statue of Liberty. The twins studied the history of the Statue and Ellis Island this year in school, so I figured it was time. That was the first day trip, and we were fortunate to be accompanied by Dad and his wife, who spent a bunch of time in the archives trying to find our relatives who came to the US in the early 1900s. We got to tour the base of Lady Liberty’s pedestal, but I wasn’t on the ball enough to get tickets to climb up to the crown. There is always next time.   A few days later we went to the new World Trade Center. I hadn’t been to the new building yet and hadn’t seen the 9/11 memorial. The memorial was very well done, a powerful reminder of the resilience of NYC and its people. I made it a point to find the name of a fraternity brother who passed away in the attacks, and it gave me an opportunity to personalize the story for the kids. Then we headed up to the WTC observation deck. That really did put us on top of the world. It was a clear day and we could see for miles and miles and miles. The elevators were awesome, showing the skyline from 1850 to the present day as we rose 104 stories. It was an incredible effect, and the rest of the observation deck was well done. I highly recommend it for visitors to NY (and locals playing hooky for a day). Then the kids went off to camp and I hit the road again. Rich was kind enough to invite me to spend the July 4th weekend in Boulder, where he was spending a few weeks over the summer with family. We ran a 4K race on July 4th, and drank what seemed to be our weight in beer (Avery Brewing FTW) afterwards. It was hot and I burned a lot of calories running, so the beer was OK for my waistline. That’s my story and I’m sticking to it. The next day Rich took me on a ‘hike’. I had no idea what he meant until it was too late to turn back. We did a 2,600’ elevation change (or something like that) and summited Bear Peak. We ended up hiking about 8.5 miles in a bit over 5 hours. At one point I told Rich I was good, about 150’ from the summit (facing a challenging climb). He let me know I wasn’t good, and I needed to keep going. I’m glad he did because it was both awesome and inspiring to get to the top.   I’ve never really been the outdoorsy type, so this was way outside my comfort zone. But I pushed through. I got to the top, and as Rich told me would happen before the hike, everything became crystal clear. It was so peaceful. The climb made me appreciate how far I’ve come. I had a similar feeling when I crossed the starting line during my last half marathon. I reflected on how unlikely it was that I would be right there, right then. Unlikely according to both who I thought I was and what I thought I could achieve. It turns out those limitations were in my own mind. Of my own making. And not real. So now I have been to the top of two different worlds, exploring and getting there via totally different paths. Those experiences provided totally different perspectives. All I know right now is that I don’t know. I don’t know what the future holds. I don’t know how many more hills I’ll climb or races I’ll run or businesses I’ll start or places I’ll live, or anything for that matter. But I do know it’s going to be very exciting and cool to find out. –Mike Photo credit: “One World Trade Center Observatory (5)” originally uploaded by Kai Brinker and Mike Selfie on top of Bear Peak. 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 – [] 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 August 18 – You Can’t Handle the Gartner 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. Threat Detection Evolution Quick Wins Analysis Data Collection Why Evolve? Network-based Threat Detection Operationalizing Detection Prioritizing with Context Looking for Indicators Overcoming the Limits of Prevention Network Security Gateway Evolution Introduction Recently

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

When I take a step back I see I am pretty lucky. I’ve seen a lot of very cool places. And experienced a lot of different cultures through my business travels. And now I’m at a point in life where I want to explore more. Not just do business hotels and see the sights from the front seat of a colleague’s car or taxi. I want to explore and see all the cool things this big world has to offer. It hasn’t always been this way. For the first two decades of my career, I was so focused on getting to the next rung on the career ladder that I forgot to take in the sights. And forget about smelling the roses. That would take time away from my plans for world domination. In hindsight that was ridiculous. I’m certainly not going to judge others who still strive for world domination, but that does not interest me any more. I’m also at a point in life where my kids are growing up, and I only have a few more years to show them what I’ve learned is important to me. They’ll need to figure out what’s important to them, but in the meantime I have a chance to instill a love of exploration. An appreciation of cultures. And a yearning to see and experience the world. Not from the perspective of their smartphone screen, but by getting out there and experiencing life.   XX1 left for a teen tour last Saturday. Over the next month she’ll see a huge number of very cool things in the Western part of the US. The itinerary is fantastic, and made me wonder if I could take a month off to tag along. It’s not cheap and I’m very fortunate to be able to provide her with that opportunity. All I can do is hope that she becomes an explorer, and explores throughout her life. I have a cousin who just graduated high school. He’s going to do two years of undergrad in Europe to learn international relations – not in a classroom on a sheltered US campus (though there will be some of that), but out in the world. He’s also fortunate and has already seen some parts of the world, and he’s going to see a lot more over the next four years. It’s very exciting. You can bet I’ll be making at least two trips over there so we can explore Europe together. And no, we aren’t going to do backpacks and hostels. This boy likes hotels and nice meals. Of course global exploring isn’t for everyone. But it’s important to me, and I’m going to try my damnedest to impart that to my kids. But I have multiple goals. First, I think individuals who see different cultures and different ways of thinking are less likely to judge people with different views. Every day we sees the hazards of judgmental people who can’t understand other points of view and think the answer is violence and negativity. But it’s also clear that we move in a global business environment. Which means to prosper they will need to understand different cultures and appreciate different ways of doing things. It turns out the only way to really gain those skills is to get out there and explore. Coolest of all is the fact that we all need travel buddies. I can’t wait for the days when I explore with my kids – not as a parent/child thing, but as friends going to check out cool places. –Mike Photo credit: “Dora the Explorer” originally uploaded by Hakan Dahlstroem 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. 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 August 18 – You Can’t Handle the Gartner 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. Threat Detection Evolution Analysis Data Collection Why Evolve? Network-based Threat Detection Operationalizing Detection Prioritizing with Context Looking for Indicators Overcoming the Limits of Prevention Applied Threat Intelligence Building a TI Program Use Case #3, Preventative Controls Use Case #2, Incident Response/Management Use Case #1, Security Monitoring Defining TI 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 Polishing the crystal ball: Justin Somaini offers an interesting perspective on The Future of Security Solutions. He highlights a lot of disruptive forces poised to fundamentally change how security happens over the next couple of. To make the changes somewhat tangible and less overwhelming, Justin breaks the security world into a few buckets: Network Controls Management, Monitoring and Threat Response, Software Development, Application Management, Device Management, and Risk Management/GRC. Those buckets are

October 1st, 2015, is the deadline for merchants to upgrade “Point of Sale” and “Point of Swipe” terminals to recommended EMV compliant systems. To quote Wikipedia, “EMV (Europay MasterCard Visa), is a technical standard for smart payment cards and for payment terminals and automated teller machines which can accept them.” These new terminals can validate an EMV specific chip in a customer’s credit card on swipe, or validate a secure element in a mobile device when it is scanned by a terminal. The press is calling this transition “The EMV Liability Shift” because merchants who do not adopt the new standard for payment terminals are being told that they – not banks – will be responsible for fraudulent transactions. There are many possible reasons for this push. But why should you care? I know some of you don’t care – or at least don’t think you should. Maybe your job does not involve payments, or perhaps your company doesn’t have payment terminals, or you could be a merchant who only processes “card not present” transactions. But the reality is that mobile payments and their supporting infrastructure will be a key security battleground in the coming years. Talking about the EMV shift and payment security is difficult; there is a lot of confusion about what this shift means, what security is really being delivered, and the real benefits for merchants. Some of the confusion stems from the press focusing on value statement marketing by card brands, rather than digging into what these specifications and rollouts really involve. Stated another way, the marketed consumer value seldom matches the business intent driving the effort. So we are kicking off this new research series to cover the EMV shift, its impact on security and operations for merchants, and what they need to do beyond the specifications for security and business continuity – as part of the shift and beyond. Every research paper we write at Securosis has the core goal of helping security practitioners get their jobs done. It’s what we do. And that’s usually a clear task when we are talking about how to deploy DLP, what DAM can and cannot do, or how to get the most out of your SIEM platform. With this series, it’s more difficult. First, payment terminals are not security appliances, but transaction processing devices which depend on security to work properly. The irony is that – from the outside – technologies that appear security-focused are only partially related to security. They are marketed as security solutions, but really intended to solve business problems or maintain competitive advantages. Second, the ecosystem is highly complex, with many different companies providing services along the chain, each having access to payment information. Third, we will discuss some security issues you probably haven’t considered – perhaps in the news or on the horizon, but likely not yet fully in your sphere of influence. Finally, many of the most interesting facets of this research, including details we needed to collect so we could write this series, are totally off the record. We will do our best to provide insights into issues merchants and payment service providers are dealing with behind the scenes (without specifically describing the scenarios that raised the issues) to help you make decisions on payment deployment options. To amass sufficient background for this series we have spoken with merchants (both large and mid-sized), merchant banks, issuing banks, payment terminal manufacturers, payment gateway providers, card manufacturers, payment security specialists, and payment security providers. Each stakeholder has a very different view of the payment world and how they want it to work. We remain focused on helping end users get their (security) jobs done, but some of this research is background to help you understand how the pieces all fit together – and just as importantly, the business issues driving these changes. The Stated Goals: We will set the stage by explaining what EMV is, and what they are demanding of merchants. We will discuss how EMV and “smart card” technologies have changed the threat landscape in Europe and other parts of the world, and the card brands’ vision for the US. This is the least interesting part of the story, but it is necessary to understand the differences between what is being requested and what is being required – between security benefits and other things marketed as security benefits. The Landscape: We will sketch out the complicated payment landscape and where the major players fit. We do not expect readers to know the difference between an issuing bank and a merchant bank, so we will briefly explain the major players (merchants, gateways, issuers, acquirers, processors, and affiliates); showing where data, tokens, and other encrypted bits move. We will introduce each party along with their role. Where appropriate we will share public viewpoints on how each player would like access to consumer and payment data for various business functions. The Great EMV Migration: We will discuss the EMV-mandated requirements in some detail, the security problems they are intended to address, and how merchants should comply. We will examine some of the issues surrounding adoption, along with how deployment choices affect security and liability. We will also assess concerns over Chip & PIN vs. Chip & Signature, and why merchants and consumers should care. The P2P Encryption Conundrum: We will consider P2P encryption and the theory behind it. We will consider the difference between theory and practice, specifically between acquirer-based encryption solutions and P2P encryption, and the different issues when the endpoint is the gateway vs. the processor vs. the acquirer. We will explain why P2P is not part of the EMV mandate, and show how the models create weak links in the chain, possibly creating liability for merchants, and how this creates opportunities for fraud and grey areas of responsibility. The Tokens: Tokenization is a reasonably new subject in security circles, but it has demonstrated value for credit card (PAN) data security. With recent mobile payment solutions, we do not see new types of tokens to obfuscate account numbers or other pieces of financial data.

As discussed in our last post, evolved threat detection’s first step is gathering internal and external security data. Once you have the data aggregated you need to analyze it to look for indications that you have compromised devices and/or malicious activity within your organization. Know Your Assets You know the old business adage: you can’t manage it if you can’t see it. In security monitoring parlance, you need to discover new assets – and changes to existing ones – to monitor them, and ultimately to figure out when a device has been compromised. A key aspect to threat detection remains discovery. The enemy of the security professional is surprise, so it is essential to always be aware of network topology and devices on the network. All devices, especially those pesky rogue wireless access points and other mobile devices, provide attack surface to adversaries. How can you make sure you are continuously discovering these devices? You scan your address space. Of course there is active scanning, but that runs periodically. To fill in between active scans, passive scanning watches network traffic streaming by to identify devices you haven’t seen or which have changed. Once a device is identified passively, you can launch an active scan to figure out what it’s doing (and whether it is legitimate). Don’t forget to discover your entire address space – which means both IPv4 and IPv6. Most discovery efforts focus on PCs and servers on the internal network. But that may not be enough anymore; it is typically endpoints that end up compromised, so you might want to discover both full computers and mobile devices. Finally, you will need to figure out how to discover assets in your cloud computing environments. This requires integration with cloud consoles to ensure you know about new cloud-based resources and can monitor them appropriately. After you have a handle on the devices within your environment, the next step is to classify them. We recommend a simple classification, involving roughly 4 groupings. The most important bucket includes critical devices with access to private information and/or valuable intellectual property. Next look for devices behaving maliciously. These devices may not have sensitive information, but adversaries can move laterally from compromised devices to critical devices. Then you have dormant devices, which may have connected to a command and control infrastructure but aren’t currently doing anything malicious. Finally, there are all the other devices which aren’t doing anything suspicious – which you likely don’t have time to worry about. We introduced this categorization in the Network-based Threat Detection series – check it out if you want more detail. Finally, we continue to harp on the criticality of a consistent process for threat detection. This includes discovery and classification. As with data collection, your technology environment is dynamic, so what you saw 10 minutes ago will have changed by 20 minutes in the future – or sooner. You need a strong process to ensure you always understand what is happening in your environment. The C Word Correlation has always been a challenge for security folks. It’s not because the math doesn’t work. Math works just fine. Event correlation has been a challenge because you needed to know what to look for at a very granular level. Given the kinds of attacks and advanced adversaries many organizations face, you cannot afford to count on knowing what’s coming, so it’s hard to find new and innovative attacks via traditional correlation. This has led to generally poor perceptions of SIEMs and IDS/IPS. But that doesn’t meant correlation is useless for security. Quite the opposite. Looking for common attributes, and linking events together into meaningful models of possible attacks, provides a meaningful way to investigate security events. And you don’t want to succumb to the same attacks over and over again, so it is still important to look for indicators of attacks that have been used against you. Even better if you can detect indicators reported by other organizations, via threat intelligence, and avoid those attacks entirely. Additionally you can (and should) stage out a number of reasonable attack patterns via threat modeling to look for common attacks. In fact, your vendor or service provider’s research team has likely built in some of these common patterns to kickstart your efforts at building out correlation rules, based on their research. These research teams also keep their correlation rules current, based on what they see in the wild. Of course you can never know all possible attacks. So you also need to apply behavioral and other advanced analytical techniques to catch attacks you have not seen. Looking for Outliers Technology systems have typical activity patterns. Whether network traffic, log events, transactions, or any other kind of data source, you can establish an activity profile for how systems normally behave. Once the profile is established you look for anomalous activity, or outliers, that may represent malicious activity. Theses outliers could be anything, from any data source you collect. With a massive trove of data, you can take advantage of advanced “Big Data” analytics (no, we don’t like that overly vague term). New technologies can reduce a huge amount of data to scan for abnormal activity patterns. You need an iterative process to refine thresholds and baseline over time. Yes, that means ongoing care and feeding of your security analytics. Activity evolves over time, so today’s normal might be anomalous in a month. Setting up these profiles and maintaining the analytics typically requires advanced skills. The new term for these professionals is data scientists. Yes, it’s a shiny term, and practitioners are expensive. But a key aspect of detecting threats is looking for outliers, and that requires data scientists, so you’ll need to pay up. Just ensure you have sufficient resources to investigate alerts coming from your analytics engine, because if you aren’t staffed to triage and validate alerts, you waste the benefit of earlier threat detection. Alternatively, organizations without these sophisticated internal resources should consider allowing a vendor or service provider to update and tune their correlation rules and analytics for detection. This

Rich here, Yep, it looks very likely my personal data is now in the hands of China, or someone pretending to be China, or someone who wants it to look like China. While I can’t go into details, as many of you know I’ve done things with the federal government related to my rescue work. It isn’t secret or anything, but I never feel comfortable talking specifics because it’s part-time and I’m not authorized to represent any agency. I haven’t been directly notified, but I have to assume that any of my records OPM had, someone… else… has. To be honest, based on what details have come out, I’d be surprised if it wasn’t multiple someone elses – this level of nation-state espionage certainly isn’t limited to any one country. Now, on the upside, if I lose my SSN, I have it backed up overseas. Heck, I’m really bad at keeping copies of all my forms, which I seem to have to resubmit every few years, so hopefully whoever took them will set up a help desk I can call to request copies. I’d pay not to have to redo that stuff all over. Like many of you, my data has been breached multiple times. The worst so far was the student health service at the University of Colorado, because I know my SSN and student medical records were in that one (mostly sprained ankles and a bad knee, if you were wondering – nothing exciting). That one didn’t seem to go anywhere but the OPM breach is more serious. There is a lot more info than my SSN in there, Including things like my mother’s maiden name. This will hang over my head for the rest of my life. Long beyond the 18 months of credit monitoring I may or may not receive. I’m not worried about a foreign nation mucking with my credit, but they may well have enough to compromise my credentials for a host of services. Not by phishing me, but by walking up the long chain of identity and interconnected services until they can line up the one they want. I am now officially a security risk for any organization I work with. Even mine. And now on to the Summary… We are deep into the summer, with large amounts of personal and professional travel, so this week’s will be a little short – and you probably already noticed we’ve been a bit inconsistent. Hey, we have lives, ya know! Webcasts, Podcasts, Outside Writing, and Conferences Rich’s webinar for Adallom on managing SaaS There might be more, but GoGo on this flight is terrible, and I can’t perform a news search. Securosis Posts My 2015 Personal Security Guiding Principles and the New Rand Report. Incite 6/10/2015: Twenty Five. Threat Detection Evolution: Why Evolve? [New Series]. Contribute to the Cloud Security Alliance Guidance: Community Drives, Securosis Writes. Network Security Gateway Evolution [New Series]. We Don’t Know Sh–. You Don’t Know Sh–.. 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 Major zero-day security flaws in iOS & OS X allow theft of both Keychain and app passwords Hard to Sprint When You Have Two Broken Legs Second OPM Hack Revealed: Even Worse Than The First Report: Hack of government employee records discovered by product demo How I Learned to Stop Worrying and Embrace the Security Freeze Stepson of Stuxnet stalked Kaspersky for months, tapped Iran nuke talks Courts docs show how Google slices users into “millions of buckets” Factory Reset On Millions of Android Devices Doesn’t Wipe Storage Share:

The first post in this series set the stage for the evolution of threat detection. Now that we’ve made the case for why detection must evolve, let’s work through the mechanics of what that actually means. It comes down to two functions: security data collection, and analytics of the collected data. First we’ll go through what data is helpful and where it should come from. Threat detection requires two main types of security data. The first is internal data, security data collected from your devices and other assets within your control. It’s the stuff the PCI-DSS has been telling you to collect for years. Second is external data, more commonly known as threat intelligence. But here’s the rub: there is no useful intelligence in external threat data without context for how that data relates to your organization. But let’s not put the cart before the horse. We need to understand what security data we have before worrying about external data. Internal Data You’ve likely heard a lot about continuous monitoring because it is such a shiny and attractive term to security types. The problem we described in Vulnerability Management Evolution is that ‘continuous’ can have a bunch of different definitions, depending on who you are talking to. We have a rather constructionist view (meaning, look at the dictionary) and figure the term means “without cessation.” But in many cases, monitoring assets continually doesn’t really add much value over regular and reliable daily monitoring. So we prefer consistent monitoring of internal resources. That may mean truly continuous, for high-profiles asset at great risk of compromise. Or possibly every week for devices/servers that don’t change much and don’t access high-value data. But the key here is to be consistent about when you collect data from resources, and to ensure the data is reliable. There are many data sources you might collect from for detection, including: Logs: The good news is that pretty much all your technology assets generate logs in some way, shape, or form. Whether it’s a security or network device, a server, an endpoint, or even mobile. Odds are you can’t manage to collect data from everything, so you’ll need to choose which devices to monitor, but pretty much all devices generate log data. Vulnerability Data: When trying to detect a potential issue, knowing which devices are vulnerable to what can be important for narrowing down your search. If you know a certain attack targets a certain vulnerability, and you only have a handful of devices that haven’t been patched to address the vulnerability, you know where to look. Configuration Data: Configuration data yields similar information to vulnerability data for providing context to understand whether a device could be exploited by a specific attack. File Integrity: File integrity monitoring provides important information for figuring out which key files have changed. If a system file has been tampered with outside of an authorized change, it may indicate nefarious activity and should be checked out. Network Flows: Network flow data can identify patterns of typical (normal) network activity; which enables you to look for patterns which aren’t exactly normal and could represent reconnaissance, lateral movement, or even exfiltration. Once you decide what data to collect, you have figure out from where and how much. This involves selecting logical collection points and where to aggregate the data. This depends on the architecture of your technology stack. Many organization opt for a centralized aggregation point to facilitate end-to-end analysis, but that is contingent on the size of the organization. Large enterprises may not be able to handle the scale of collecting everything in one place, and should consider some kind of hierarchical collection/aggregation strategy where data is stored and analyzed locally, and then a subset of the data is sent upstream for central analysis. Finally, we need to mention the role of the cloud in collection and aggregation, because almost everything is being offered either in the cloud or as a Service nowadays. The reality is that cloud-based aggregation and analysis depend on a few things. The first is the amount of data. Moving logs or flow records is not a big deal because they are pretty small and highly compressible. Moving network packets is a much larger endeavor, and hard to shift to a cloud-based service. The other key determinant is data sensitivity – some organizations are not comfortable with their key security data outside their control in someone else’s data center/service. That’s an organizational and cultural issue, but we’ve seen a much greater level of comfort with cloud-based log aggregation over the past year, and expect it to become far more commonplace inside a 2-year planning horizon. The other key aspect of internal data collection is integration and normalization of the data. Different data sources have different data formats, which creates a need to normalize data to compare datasets. That involves compromise in terms of granularity of common data formats, and can favor an integrated approach where all data sources are already integrated into a common security data store. Then you (as the practitioner) don’t really need to worry about making all those compromises – instead you can bet that your vendor or service provider has already done the work. Also consider the availability of resources for dealing with these disparate data sources. The key issue, mentioned in the last post, remains the skills shortage; so starting a data aggregation/collection effort that depends on skilled resources to manage normalization and integration of data may not be the best idea. This doesn’t really have much to do with the size of the organization – it’s really about the sophistication of staff – security data integration is an advanced function that can be beyond even large organizations with less mature security efforts. Ultimately your goal is visibility into your entire technology infrastructure. An end-to-end view of what’s happening in your environment, wherever your data is, gives you a basis for evolving your detection capabilities. External Data We have published a lot of research on threat intel to date, most recently a series on Applied Threat Intelligence, which summarized the three main use cases we see for external data. There