Research

Today we launch our next blog series, on a topic we believe is critical to success in today’s threat environment. It is network security analysis, a rather grand and nebulous term, but consider this the next step on the path which started with Incident Response Fundamentals and continued with React Faster and Better. The issues are pretty straightforward. We cannot assume we can stop the attackers, so we have to plan for a compromise. The difference between success and failure breaks down to how quickly you can isolate the attack, contain the damage, and then remediate the issue. So we build our core security philosophy around monitoring critical networks and devices, facilitating our ability to find the root cause of any attack. Revisiting Monitor Everything Back in early 2010, we published a set of Network Security Fundamentals, one of which was Monitor Everything. If you read the comments at the bottom of the post, you’ll see some divergent opinions of what everything means to different folks, but nobody really disagrees with broad monitoring as a core tenet of security nowadays. We can thank the compliance gods for that. To understand the importance of monitoring everything, let’s excerpt some research I published back in early 2008 that is still relevant today. New attacks are happening at a fast and furious pace. It is a fool’s errand to spend time trying to anticipate where the issues are. REACT FASTER first acknowledges that all attacks cannot be stopped. Thus, focus remains on understanding typical traffic and application usage trends and monitoring for anomalous behavior, which could indicate an attack. By focusing on detecting attacks earlier and minimizing damage, security professionals both streamline their activities and improve their effectiveness. That post then discusses some data sources you can (and should) monitor, including firewalls, IDS/IPS, vulnerability scans, network flows, device configurations, and content security devices. But we are still looking at this data in terms of profiling what has happened and using that as a baseline. Then watch for variations beyond tolerance and alert when you see them. We still fundamentally believe in this approach. It’s clearly the place to start for most organizations, for which any data is more than they have now. But for maturing security organizations, let’s examine why logs are only the start. Logs are not enough Back when I was in the SIEM space, it was clear that event logs are a great basis for compliance reporting, because they effectively substantiate implemented controls. As long as the logs are not tampered with, at least. But when you are working to isolate a security issue, the logs tell you what happened, but lack the depth to truly understand how it happened. Isolating a security attack using log data requires having logs from all points in the path between attacker and target. If you aren’t capturing information from the application servers, databases, and applications themselves, visibility is severely impaired. Contrast that against the ability to literally replay an attack from a full network packet capture. You could follow along as the attacker broke your stuff. See the path they took to traverse your network, the exploits they used to compromise devices, the data they exfiltrated, and how they covered their tracks by tampering with the logs. Of course this assumes you are capturing the right network traffic along the attacker’s path, and it might not be feasible to capture all traffic all the time. But still, if you look to implement a full network packet capture sandwich (as we described in the React Faster and Better series), incident responders have much more information to work with. We’ll discuss how to deploy the technology to address some of these issues later in this series. Given that you need additional data to do your job, where should you look? The Network Doesn’t Lie For the purposes of this discussion, let’s assume time starts at the moment an attacker gains a foothold in your network. That could be by compromising a device (through whatever means) already on the network, or by having a compromised device connect to the internal network. At that point the attacker is in the house, so the clock is ticking. What do they do next? An attacker will try to move through your environment to achieve their ultimate goal, whether that be compromising a specific data store or adding to their bot army, or whatever. There are about a zillion specific things the attacker could do, and 99% of them depend on the network in some way. They can’t find another target(s) without using the network to locate it. They can’t attack the target without trying to connect to it, right? Furthermore, even if they are able to compromise the ultimate target, the attackers must then exfiltrate the data. So they will try to use the network to move the data. They need the network, pure and simple. Which means they will leave tracks, but only if you are looking. This is why we favor (as described in React Faster and Better) capturing the full network packet data as possible. Attackers could compromise network devices and delete log records. They could generate all sorts of meaningless traffic to confuse network behavioral analysis. But they can’t alter the packet stream as it’s captured, which becomes the linchpin of the data you’ll collect to perform this advanced network security analysis. Data is not information But just collecting data isn’t enough. You need to use the data to draw conclusions about what’s happening in your environment. That requires indexing the data, supplementing and enriching it with additional context, alerting on the data, and then searching through the data to pursue an investigation. This is all technically demanding. Just capturing the full network packet stream requires a purpose-built data store, which does some black magic to digest and index network traffic at sufficient speed to provide usable, actionable information to shorten the exploit window. To get an idea of the magnitude of this challenge, note

As my kids get older, fundamental aspects of their personalities become more apparent. XX1 won the “most inquisitive” award in kindergarten. 5 years later, she still asks questions. Lots of questions. A seemingly endless stream of questions. The Inquisition went into full effect when we went to the Falcons game last weekend. This is the 4th year we’ve had tickets, so it now becoming more about the game, rather than just about the ice cream and other snacks. From the opening kickoff until the last touchdown in the 4th quarter, I got a steady stream of questions. Which direction are they going? Why was that a penalty? Who would you root for if the Giants played the Falcons? Should I get a Dippin’ Dots or frozen lemonade? What’s pass interference? Questions, questions, questions. Now I like watching my football. I don’t like to talk during the game. If I do talk, it’s about soft zones, off tackles, and shot plays. I felt myself getting a bit frustrated under the constant barrage of questions. Then I remembered this was my evil plan in the first place. I want the kids to love watching football. I want them to have memories of going to NFL games. If they don’t understand the game they won’t want to go with me, and I’ll be sad. So I spent the time and tried to explain a few easy concepts. Like possessions (the Falcons have the ball, and they are going for that end zone), first downs, and kickoffs/punts. And she started to understand. We had a great time and that’s what it’s all about. I love that she asks questions. She wants to learn and when she doesn’t understand, she asks questions until she does. That’s a lot better than nodding like you get it, but being too proud to admit you don’t. This is a great skill, and over time we’ll work on trying to figure some stuff out herself and then ask the remaining questions. But I need to keep in mind that it’s a patience thing for me as well. I don’t have all the answers – certainly not to an endless stream of questions. So I have to get better about admitting I don’t know, and (given all the devices in our house) walking up to one of my magic boxes to figure it out. So as uncomfortable as the Inquisition may be at times, I wouldn’t have it any other way. -Mike Photo credits: “Spanish Inquisition torture method: the rack” originally uploaded by un_owen Incite 4 U Love and Hate, version 1: I never met Dennis Ritchie, but he certainly had a major impact on my life. As a computer science undergrad at Cal, UNIX and C were everything to me. I lived with The C Programming Language. Literally. Along with The UNIX Programming Environment – neither book ever left my backpack. They remain on my bookshelf to this day. And I hated both. I thought C was a miserable language. Pointer issues, memory leaks, awkward syntax, hard-to-find information. The FAQ for proper uses of the null pointer was 100 pages long. Clearly a language is screwed if it takes 100 pages to describe just one aspect of the language (mostly things you must not do). When I read Creators Admit UNIX, C Hoax, I laughed my ass off because I thought it was true – C was a freakin’ prank. Only years later did a couple UNIX experts really teach me C and UNIX (no, they don’t teach you languages at Cal, they just assume you’re plugged into The Matrix and will imprint them into your brain as needed). Only when they handed me a copy of Using C on the UNIX System did I really start to admire the power of the C language and the beauty of UNIX’s architecture. Both are incredibly powerful, and the essence of flexible and extensible. Ritchie’s passing is a good time to reflect on their landmark achievements and celebrate all the things that we use almost every minute of the day, which have been built on those two standards. – AL If there are so many detection techniques, why do they still suck? Lenny Z highlights the current state of the art for malware detection in a couple articles at SearchSecurity: How antivirus software works: Virus detection technique, and in the deeper Antimalware product suites: Understanding capabilities and limitations, on full endpoint suites. But he begs the question: with all this technology, why can’t we stop the bad guys? Because they have changed tactics. They are going after users and applications, preying on those who haven’t updated their devices and the simply stupid (or ignorant, which is just as good for their purposes). Yes, there are a plenty of easy targets. But whining about what we can’t do isn’t my style, so let’s step back to fundamentals. Assume that devices (at least some of them) are compromised. The ones that must not get compromised (high value assets) should be locked down – even if users squeal like stuck pigs. Monitor the hell out of everything, and do some egress filtering and/or DLP monitoring to make sure stuff doesn’t get out. But we cannot assume that anti-malware provides any security. – MR You already had to do it: There has been a lot of hubbub this week over recent guidance from the SEC that public companies should report on cyber-security risk. This is interesting, because my understanding has been that companies have always been required to report any potentially material risk, no matter its origin. We have seen companies report major breach losses for a while, and in rare cases they report some of the cyber risk (usually as an add-on to a public breach). That the SEC felt they needed to issue additional guidance means that companies were either confused (I don’t see what’s confusing – a loss is a loss), trying to play games, or simply not reporting. So I don’t

The goal of tokenization is to reduce the scope of PCI database security assessment. This means a reduction in the time, cost, and complexity of compliance auditing. We want to remove the need to inspect every system for security settings, encryption deployments, network security, and application security, as much as possible. For smaller merchants tokenization can make self-assessment much more manageable. For large merchants paying 3rd-party auditors to verify compliance, the cost savings is huge. PCI DSS still applies to every system in the logical and physical network associated with the payment transaction systems, de-tokenization, and systems that store credit cards – what the payment industry calls “primary account number”, or PAN. For many merchants this includes a major portion – if not an outright majority – of information systems under management. The PCI documentation refers to these systems as the “Cardholder Data Environment”, or CDE. Part of the goal is to shrink the number of systems encompassed by the CDE. The other goal is to reduce the number of relevant checks which must be made. Systems that store tokenized data, even if not fully isolated logically and/or physically from the token payment gateway to servers, need fewer checks to ensure compliance with PCI DSS. The ground rules So how do we know when a server is in scope? Let’s lay out the ground rules, first for systems that always require a full security analysis: Token server: The token server is always in scope if it resides on premise. If the token server is hosted by a third party, the calling systems and the API are subject to inspection. Credit card/PAN data storage: Anywhere PAN data is stored, encrypted or not, is in scope. Tokenization applications: Any application platform that requests tokenized values, in exchange for the credit card number, is in scope. De-tokenization applications: Any application platform that can make de-tokenization requests is in scope. In a nutshell, anything that touches credit cards or can request de-tokenized values is in scope. It is assumed that administration of the token server is limited to a single physical location, and not available through remote network services. Also note that PAN data storage is commonly part of the basic token server functionality, but they are separated in some cases. If PAN data storage and token generation server/services are separate but in-house (i.e., not provided as a service) then both are in scope. Always. Determining system scope For the remaining systems, how can you tell if tokenization will reduce scope, and by how much? For each of your remaining systems, here is how to tell: The first check to make for any system is for the capability to make requests to the token server. The focus is on de-tokenization, because it is assumed that every other system that has access to the token server or its server API, is passing credit card numbers and fully in scope. If this capability exists – through user interface, programmatic interface, or any other means, then PAN is accessible and the system is in scope. It is critical to minimize the number of people and programs that can access the token server or service, both for security and to redue scope. The second decision concerns use of random tokens. Suitable token generation methods include random number generators, sequence generators, one-time pads, and unique code books. Any of these methods can create tokens that cannot be reversed back to credit cards without access to the token server. I am leaving hashed-based tokens off this list because they are relatively insecure (reversible), because providers routinely fail to salt their tokens, or salt with ridiculously guessable values (i.e., the merchant ID). Vendors and payment security stakeholders are busy debating encrypted card data versus tokenization, so it’s worth comparing them again. Format Preserving Encryption (FPE) was designed to secure payment data without breaking applications and databases. Application platforms were programmed to accept credit card numbers, not huge binary strings, so FPE was adopted to improve security with minimum disruption. FPE is entrenched at many large merchants, who don’t want the additional expense of moving to tokenization, and so are pushing for acceptance of FPE as a form of tokenization. The supporting encryption and key management systems are accessible – meaning PAN data is available to authorized users, so FPE cannot remove systems from the audit scope. Proponents of FPE claim they can segregate the encryption engine and key management, so therefore it’s just as secure as random numbers. Only the premise is a fallacy. FPE advocates like to talk about logical separation between sensitive encryption/decryption systems and other systems which only process FPE-encoded data, but this is not sufficient. The PCI Council’s guidance does not exempt systems which contain PAN (even encrypted using FPE) from audit scope, and it is too easy for an attacker or employee to cross that logical separation – especially in virtual environments. This makes FPE riskier than tokenization. Finally, strive to place systems containing tokenized data outside the “Cardholder Data Environment” using network segmentation. If they are in the CDE, they need to be in scope for PCI DSS – if for no other reason than because they provide an attacker point for access to other card storage, transaction processing, and token servers. Configure firewalls, network configuration, and routing, to separate CDE systems from non-CDE systems which don’t directly communicate with them. Systems that are physically and logically isolated from the CDE, provided they meet the ground rules and use random tokens, are completely removed from audit scope. Under these conditions tokenization is a big win, but there are additional advantages… Determining control scope As above, a fully isolated system with random tokens means you can remove the system from scope. Consider the platforms which have historically stored credit card data but do not need it: customer service databases, shipping & receiving, order entry, etc. This is where you can take advantage of tokenization. For all systems which can be removed from audit scope, you can