Research

Storage deployment From a technical perspective, deploying storage DLP is even easier than the most basic network DLP. You can simply point it at an open file share, load up the proper access rights, and start analyzing. The problem most people run into is figuring out which servers to target, which access rights to use, and whether the network and storage repository can handle the overhead. Remote scanning All storage DLP solutions support remotely scanning a repository by connecting to an open file share. To run they need to connect (at least administrator-only) to a share on the server scan. But straightforward or not, there are three issues people commonly encounter: Sometimes it’s difficult to figure out where all the servers are and what file shares are exposed. To resolve this you can use a variety of network scanning tools if you don’t have a good inventory to start. After you find the repositories you need to gain access rights. And those rights need to be privileged enough to view all files on the server. This is a business process issue, not a technical problem, but most organizations need to do a little legwork to track down at least a few server owners. Depending on your network architecture you may need to position DLP servers closer to the file repositories. This is very similar to a hierarchical network deployment but we are positioning closer to the storage to reduce network impact or work around internal network restrictions (not that everyone segregates their internal network, even though that single security step is one of the most powerful tools in our arsenal). For very large repositories which you don’t want to install a server agent on, you might even need to connect the DLP server to the same switch. We have even heard of organizations adding a second network interfaces on a private segment network to support particularly intense scanning. All of this is configured in the DLP management console; where you configure the servers to scan, enter the credentials, assign policies, and determine scan frequency and schedule. Server agents Server agents support higher performance without network impact, because the analysis is done right on the storage repository, with only results pushed back to the DLP server. This assumes you can install the agent and the server has the processing power and memory to support the analysis. Some agents also provide additional context you can’t get from remote scanning. Installing the server agent is no more difficult than installing any other software, but as we have mentioned (multiple times) you need to make sure you test to understand compatibility and performance impact. Then you configure the agent to connect to the production DLP server. Unless you run into connection issues due to your network architecture, you then move over to the DLP management console to tune the configuration. The main things to set are scan frequency, policies, and performance throttles. Agents rarely run all the time – you choose a schedule, similar to antivirus, to reduce overhead and scan during slower hours. Depending on the product, some agents require a constant connection to the DLP server. They may compress data and send it to the server for analysis rather than checking everything locally. This is very product-specific, so work with your vendor to figure out which option works best for you – especially if their server agent’s internal analysis capabilities are limited compared to the DLP server’s. As an example, some document and database matching policies impose high memory requirements which are infeasible on a storage server, but may be acceptable on the shiny new DLP server. Document management system/NAS integration Certain document management systems and Network Attached Storage products expose plugin architectures or other mechanisms that allow the DLP tool to connect directly, rather than relying on an open file share. This method may provide additional context and information, as with a server agent. This is extremely dependent on which products you use, so we can’t provide much guidance beyond “do what the manual says”. Database scanning If your product supports database scanning you will usually make a connection to the database using an ODBC agent and then configure what to scan. As with storage DLP, deployment of database DLP may require extensive business process work: to find the servers, get permission, and obtain credentials. Once you start scanning, it is extremely unlikely you will be able to scan all database records. DLP tools tend to focus on scanning the table structure and table names to pick out high-risk areas such as credit card fields, and then they scan a certain number of rows to see what kind of data is in the fields. So the process becomes: Identify the target database. Obtain credentials and make an ODBC connection. Scan attribute names (field/column names). (Optional) Define which fields to scan/monitor. Analyze the first n rows of identified fields. We only scan a certain number of rows because the focus isn’t on comprehensive realtime monitoring – that’s what Database Activity Monitoring is for – and to avoid unacceptable performance impact. But scanning a small number of rows should be enough to identify which tables hold sensitive data, which is hard to do manually. Endpoint deployment Endpoints are, by far, the most variable component of Data Loss Prevention. There are massive differences between the various products on the market, and far more performance constraints required to fit on general-purpose workstations and laptops, rather than on dedicated servers. Fortunately, as widely as the features and functions vary, the deployment process is consistent. Test, then test more: I realize I have told you to test your endpoint agents at least 3 times by now, but this is the single most common problem people encounter. If you haven’t already, make sure you test your agents on a variety of real-world systems in your environment to make sure performance is acceptable. Create a deployment package or enable in your EPP tool: The best way to deploy the DLP agent is to use whatever software distribution

Yesterday we posted the key themes we expect to see at the upcoming RSA Conference. Now we’ll starting digging into our main coverage areas. Today we’ll start with network security. Firewalls are (still) dead! Long live the perimeter security gateway! Shockingly enough, similar to the past three years at RSAC, you’ll hear a lot about next generation firewalls (NGFW). And you should, as ports and protocol-based firewall rules will soon go the way of the dodo bird. If by soon, we mean 5+ years anyway, but corporate inertia remains a hard game to predict. The reality is that you need to start moving toward a deeper inspection of both ingress and egress traffic through your network, and the NGFW is the way to do that. The good news is that every (and we mean every) vendor in the network security space will be showing a NGFW at the show. Some are less NG than a bolted-on IPS to do the application layer inspection, but at the end of the day they can all claim to meet the NGFW market requirements, as defined by the name-brand analysts anyway. Which basically means these devices are less firewalls and more perimeter security gateways. So we will see two general positioning tactics from the vendors: Firewall-centric vendors: These folks will pull a full frontal assault on the IPS business. They’ll talk about how there is no reason to have a stand-alone IPS anymore and that the NGFW now does everything the IPS does and more. The real question for you is whether you are ready for the forklift that moving to a consolidated perimeter security platform requires. IPS vendors: IPS vendors have to protect their existing revenue streams, so they will be talking about how the NGFW is the ultimate goal, but it’s more about how you get there. They’ll be talking about migration and co-existence and all those other good things that made customers feel good about dropping a million bucks on an IPS 18 months ago. But no one will be talking about how the IPS or yesterday’s ports & protocols firewall remains the cornerstone of the perimeter security strategy. That sacred cow is slain, so now it’s more about how you get there. Which means you’ll be hearing a different tune from many of the UTM vendors. Those same brand-name analysts always dictated that UTM only met small company needs and didn’t have a place in an enterprise network. Of course that wasn’t exactly true but the UTM vendors have stopped fighting it. Now they just magically call their UTM a NGFW. It actually makes sense (from their perspective) as they understand that an application-aware firewall is just a traditional firewall with an IPS bolted on for application classification. Is that a ‘NGFW’? No, because it still runs on firewall blocking rules based on ports and protocols (as opposed to applications), but it’s not like RSA attendees (or most mid-market customers) are going to really know the difference. Control (or lack thereof) Another batch of hyperbole you’ll hear at the conference is about control. This actually plays into a deeply felt desire on the part of all security professionals, who don’t really control much of anything on a daily basis. So you want to buy devices that provide control over your environment. But this is really just a different way of pushing you towards the NGFW, to gain ‘control’ over the applications your dimwit end users run. But control tends to put the cart ahead of the horse. The greatest impact of the NGFW is not in setting application-aware policies. Not at first. The first huge value of a NGFW is gaining visibility over what is going on in your environment. Basically, you probably have no idea what apps are being used by whom and when. The NGFW will show you that, and then (only then) are you in a position to start trying to control your environment through application-centric policies. While you are checking out the show floor remember that embracing application-awareness on your perimeter is about more than just controlling the traffic. It all starts with figuring out what is really happening on your network. Network-based Malware Detection gains momentum Traditional endpoint AV doesn’t work. That public service message has been brought to you by your friend Captain Obvious. But even though blacklists and signatures don’t work anymore, there are certain indicators of malware that can be tracked. Unfortunately that requires you to actually execute the malware to see what it does. Basically it’s a sandbox. It’s not really efficient to put a sandbox on every endpoint (though the endpoint protection vendors will try), so this capability is moving to the perimeter. Thus a hot category you’ll see at RSA is “network-based malware detection” gear. These devices sit on the perimeter and watch all the files passing through to figure out which of them look bad and then either alert or block. They also track command and control traffic on egress links to see which devices have already been compromised and trigger your incident response process. Of course these monitors aren’t a panacea for catching all malware entering your network, but you can stop the low hanging fruit before it makes its way onto your network. There are two main approaches to NBMD, which are described ad nauseum in our recently published paper, so we won’t get into that here. But suffice it to say, we believe this technology is important and until it gets fully integrated into the perimeter security gateway, it’s a class of device you should be checking out while you are at the show. Big security flexes its muscle Another major theme related to network security we expect to see at the show is Big Security flexing its muscles. Given the need for highly specialized chips to do application-aware traffic inspection, and the need to see a ton of traffic to do this network-based malware detection and reputation analysis, network security is no longer really a place for start-ups (and no, Palo Alto is no

I had this fraternity brother back in college named Lucas. We gave him a pretty hard time, mostly because he was the nicest guy you’d ever want to meet. Turns out he didn’t know what jobs just sucked. We’d ask Luke to clean the grease trap, a typical task when we were pledges. Not a problem for him, and that was probably the nicest thing we asked him to do. Remember that when you live in a house with 40+ guys, you tend to share a lot of things. Get your heads out of the gutter. I’m talking about things like toiletries. It wouldn’t be a surprise to see your brand new shampoo bottle in the gang shower 80% gone. Nor should it have surprised anyone to find their toothpaste ravaged by the cheap slugs I lived with. I always figured it was a decent investment because most of these guys wouldn’t have brushed their teeth at all, if it weren’t for my toothpaste. But Luke would have none of that. He went berserk one day when he found his toothpaste mostly gone. He proceeeded to write his name on everything he owned, as if that would make a difference. He was ranting and raving. Of course, once we knew that bothered him, we hit the gas. We’d still take his toothpaste, but we’d put it back in his room – empty. We’d hide his stuff all over the house. Come on, you would have done the same thing when you were 20. But slowly I’ve become Luke in terms to my stuff. I live with 4 other people and they are constantly using my stuff. I know when the Boss has been in my toothpaste because she squeezes from the top, not the bottom like I do. Yeah, that annoys me, so I put a new tube in her drawer, hoping she won’t screw with mine. But it’s the brush that really annoys me. I know instantly when one of the girls has polluted my brush. There are all sorts of long hairs tickling my ears when I brush my hair. So I peek at my brush and sure enough there is a ton of long brown hair in my brush. My hair is short and gray – I know it’s not mine. I don’t know why, but it annoys me. In a fit of rage, I did consider lighting the brush on fire, as that seemed like the only way I could ever keep everyone else from using it. Now that would be a cool brushfire. So I did what any person does when annoyed. I bought about 10 other brushes. I put extra brushes in each girl’s room and a few downstairs. Just in case. But amazingly enough, even with the extra brush inventory, half the time we can’t find a brush when we need it. There must be some kind of gremlin with long hair in the house who keeps taking our brushes. So time and time again, they go to the only place where they can be absolutely sure there is always a brush in the house. Right, my drawer. Either that, or maybe they are just screwing with me, because they know finding hair in my brush annoys me. I annoy them enough that I probably deserve to be messed with a bit. I guess karma balances out in the long run. But who could have guessed it would be in the form of a brush? -Mike Photo credits: “Hairy Brush” originally uploaded by Ashley Coombs Heavy Research After a bit of a blogging hiatus, we are back at it. The Heavy Research feed is hopping, and here are a couple of links of our latest stuff. So check them out and (as always) let us know what you think via comments. We posted a new paper earlier this week, assembling the Network-based Malware Detection series into a spiffy document. Check it out. And we have started posting our annual RSA Conference Guide. The first post was on our Key Themes. It seems over the past year we haven’t lost our snark, so our themes include stuff like “Is that a Cloud in Your Pocket?” “#OccupyRSA,” “Ha-Duped about Security BigData,” and “Data Olestra.” Yes, we insist on having fun if we have to write. We’ll be doing 1-2 a day over the next week, and then we’ll package it up as a paper you can take with you to the conference. Here’s the other stuff we have been up to: Implementing and Managing a Data Loss (DLP) System: Index of Posts. Rich is still at it, so check out his latest on deploying DLP. Malware Analysis Quant: Take the Survey (and win fancy prizes!) We need your help to understand what you do (and what you don’t) for malware analysis. And you can win some nice gift cards from Amazon for your trouble. Remember, you can get our Heavy Feed via RSS, where you can access all our content in its unabridged glory. Incite 4 U Behold the Nortel ostrich: Great expose in the WSJ about Nortel being totally and utterly compromised for over a decade. Seems there was no part of their infrastructure that the attackers didn’t have access to. But that’s kind of an old, tired story. What’s more interesting is the reaction from former Nortel folks. As the carcass of what used to be Nortel has been auctioned off from bankruptcy, the folks acquiring the assets play stupid. The old CEOs play stupid. And then they mention one of the main forensics guys would cry wolf. But he wasn’t crying wolf, was he? But this is the kind of institutional disregard we, alas, expect to see. It’s not like Nortel had anything interesting to state-sponsored hackers, right? Like the signaling software that runs a huge fraction of the national voice networks. This is just a reminder: your organization is pwned. The question is whether you know it or not. Or want to know it, I guess. – MR Probing the unprobable: I have to admit that