Research

Welcome to part 3 of our series on Data Loss Prevention/Content Monitoring and Filtering. You should go read Part 1 and Part 2 before digging into this one. In this episode we’re going to spend some time looking at the various architectures we typically see in DLP products. This is a bit of a tough one since we tend to see a bunch of different technical approaches. There’s no way to cover all the options in a little old blog post, so I’ll focus on the big picture things you should look for. To structure things a bit, we’ll look at DLP for data-in-motion (network monitoring/filtering) data-at-rest (storage) and data-in-use (endpoint). For space reasons, this post will focus on data-in-motion, and the next post will drill into at-rest and in-use. Network Monitor In the heart of most DLP solutions lies a passive network monitor. This is where DLP was born and is where most of you will start your data protection adventure. The network monitoring component is typically deployed at or near the gateway on a SPAN port (or a similar tap). It performs full packet capture, session reconstruction, and content analysis in real time. Performance numbers tend to be a little messy. First, on the client expectation side, everyone wants full gigabit Ethernet performance. That’s pretty unrealistic since I doubt many of you fine readers are really running that high a level of communications traffic. Remember, you don’t use DLP to monitor your web applications, but to monitor employee communications. Realistically we find that small enterprises run well less than 50 MB/s of relevant traffic, medium enterprises run closer to 50-200 MB/s, and large enterprises around 300 MB/s (maybe as high as 500 in a few cases). Because of the content analysis overhead, not every product runs full packet capture. You might have to choose between pre-filtering (and thus missing non-standard traffic) or buying more boxes and load balancing. Also, some products lock monitoring into pre-defined port and protocol combinations, rather than using service/channel identification based on packet content. Even if full application channel identification is included, you want to make sure it’s not off by default. Otherwise, you might miss non-standard communications such as tunneling over an unusual port. Most of the network monitors are just dedicated servers with DLP software installed. A few vendors deploy as a true specialized appliance. While some products have their management, workflow, and reporting built into the network monitor, most offload this to a separate server or appliance. This is where you’ll want the big hard drives to store policy violations, and this central management server should be able to handle distributed hierarchical deployments. Email The next major component is email integration. Since email is store and forward you can gain a lot of capabilities, like quarantine, encryption integration, and filtering, without the same complexity of blocking synchronous traffic. Most products embed an MTA (Mail Transport Agent) into the product, allowing you to just add it as another hop in the email chain. Quite a few also integrate with some of the major existing MTAs/email security solutions directly for better performance. One weakness of this approach is it doesn’t give you access to internal email. If you’re on an Exchange server, internal messages never make it through the MTA since there’s no reason to send that traffic out. To monitor internal mail you’ll need direct Exchange/Notes integration, which is surprisingly rare in the market. We’re also talking true integration, not just scanning logs/libraries after the fact, which is what a few consider internal mail support. Good email integration is absolutely critical if you ever want to do any filtering, as opposed to just monitoring. Actually, this is probably a good time to drill into filtering a bit… Filtering/Blocking and Proxy Integration Nearly anyone deploying a DLP solution will eventually want to start blocking traffic. There’s only so long you can take watching all your juicy sensitive data running to the nether regions of the Internet before you start taking some action. But blocking isn’t the easiest thing in the world, especially since we’re trying to allow good traffic, only block bad traffic, and make the decision using real time content analysis. Email, as we just mentioned, is pretty easy. It’s not really real-time and is proxied by its very nature. Adding one more analysis hop is a manageable problem in even the most complex environments. Outside of email most of our communications traffic is synchronous- everything runs in real time. Thus if we want to filter it we either need to bridge the traffic, proxy it, or poison it from the outside. With a bridge we just have a system with two network cards and we perform content analysis in the middle. If we see something bad, the bridge closes the connection. Bridging isn’t the best approach for DLP since it might not stop all the bad traffic before it leaks out. It’s like sitting in a door watching everything go past with a magnifying glass- by the time you get enough traffic to make an intelligent decision, you may have missed the really good (bad) stuff. Very few products take this approach, although it does have the advantage of being protocol agnostic. Our next option is a proxy. A proxy is protocol/application specific and queues up traffic before passing it on, allowing for deeper analysis (get over it Hoff, I’m simplifying on purpose here). We mostly see gateway proxies for HTTP, FTP, and IM. Almost no DLP solutions include their own proxies; they tend to integrate with existing gateway/proxy vendors such as Blue Coat/Cisco/Websense instead. Integration is typically through the iCAP protocol, allowing the proxy to grab the traffic, send it to the DLP product for analysis, and cut communications if there’s a violation. This means you don’t have to add another piece of hardware in front of your network traffic and the DLP vendors can avoid the difficulties of building dedicated network hardware for inline analysis. A couple of gateways, like Blue Coat and Palo Alto (I may be missing

Sometimes it’s not even worth the effort. First Rothman, then Hoff decide to bring up our favorite red headed stepchild (a term I use with fondness, since I have red hair and a stepfather); all based on an SC magazine article. I suppose Jericho’s goals are admirable, but I can’t help but feel that they’re stating the blindingly obvious and doing a piss poor job of it. For those of you not familiar with Jericho, take a quick gander over here. Basically, they’ve been advocating “de-perimeterization”; pushing people into new security architectures and dropping their firewalls (yes, they really said to trash the firewall if you go back and look at some of their original press releases). These days they have a marginally better platform (speaking platform, not technology), and aren’t running around telling people to shut off firewalls quite as much. I’ll let them describe their position: The group admits ‘deperimeterisation’ isn’t the most catchy phrase to explain multiple-level security, but Simmonds calls it an “overarching phrase” that “covers everything”. So what is it? According to the Jericho Forum, it is a concept that describes protecting an enterprise’s systems and data on multiple levels using a pick’n’mix of encryption, inherently secure computer protocols and data-level authentication. At the same time, it enables the free flow of secure data wherever and whenever it is needed, in whatever medium and between dissimilar organisations — such as banks and oil companies, for example. This kicks against the notion of security via a network boundary to the internet. Or as Hoff restates: Your perimeter *is* full of holes so what we need to do is fix the problems, not the symptoms. That is the message. Chris sometimes refers to a particular colleague of ours as Captain Obvious. I guess he didn’t want Richard to be lonely. Of course the perimeter is full of holes; I haven’t met a security professional who thinks otherwise. Of course our software generally sucks and we need secure platforms and protocols. But come on guys, making up new terms and freaking out over firewalls isn’t doing you any good. Anyone still think the network boundary is all you need? What? No hands? Just the “special” kid in back? Okay, good, we can move on now. How about this- focus on one issue and stay on message. I formally submit “buy secure stuff” as a really good one to keep us busy for a while. You have some big companies on board and could use some serious pressure to kick those market forces into gear. Share:

Well, we finally know how Pfizer lost all those employee records. An employee installed P2P file sharing software on her laptop, and probably shared her entire drive. Oops. I bet I know one person that’s eating alone in the corporate lunchroom. We originally talked about this a few weeks ago. I’d like to remind people of my Top 5 Steps to Prevent Information Loss and Data Leaks. Securing endpoints is number 5. I hate having to clamp down on employees with harsh policies, but limiting P2P on corporate systems is in the category of “reasonable things”. (thanks to Alex Hutton for the pointer) Share:

Sigh. Again. More Jericho? Yep. Can’t let Hoff go without a retort, not after this. I’d like to quote my last post for a moment: I suppose Jericho”s goals are admirable, but I can”t help but feel that they”re stating the blindingly obvious and doing a piss poor job of it. For those of you not familiar with Jericho, take a quick gander over here. Basically, they”ve been advocating “de-perimeterization”; pushing people into new security architectures and dropping their firewalls (yes, they really said to trash the firewall if you go back and look at some of their original press releases). Now Hoff’s criticism of said post: The Mogull decides that rather than contribute meaningful dialog to discuss the meat of the topic at hand, he would rather contribute to the FUD regarding the messaging of the Jericho Forum that I was actually trying to wade through. … I spent my time in my last post suggesting that the Jericho Forum’s message is NOT that one should toss away their firewall. I spent my time suggesting that rather reacting to the oft-quoted and emotionally flammable marketing and messaging, folks should actually read their 10 Commandments as a framework. Quick reminder that the platform really used to be about getting rid of the perimeter. I’m a huge data security wonk, and even I think we’ll always need a perimeter, while also building better controls into the data. If you want to look, this is one of their better early presentations. It’s not too bad. But I’m an open minded guy, so I’ll drop the past and move into the present. Let’s look at the 10 commandments (Chris, I’m stealing your image to save typing time):  1. Agree. Security 101. 2. Agree, common sense. 3. Agree, seems obvious. 4. Agree, in an ideal world, we can get better and should strive towards it but not rely on it. 5. Agree, any company with a laptop is implementing this already.  6. Agree, designed a model for this back in 2002 (I’m not sure I can share it, need to check with my former employer). 7. Agree, was part of that model, and we’re already seeing some of this today. 8. Agree, see federated identity. Nothing new. 9. Agree, this could be interesting but I think it needs a lot more development. 10. Agree, but again, pretty basic. 11. Agree, no one would disagree. Chris, this messaging needs more refinement and a lot more meat. A lot of it isn’t revolutionary, yet much of the Jericho press coverage is sensationalistic and impedes their ability to get the message to the audience. They’ve built up so much baggage that they need to really work on the messaging. Quotes like this one don’t help the cause: The group admits “deperimeterisation” isn”t the most catchy phrase to explain multiple-level security, but Simmonds calls it an “overarching phrase” that “covers everything”. So what is it? According to the Jericho Forum, it is a concept that describes protecting an enterprise”s systems and data on multiple levels using a pick”n”mix of encryption, inherently secure computer protocols and data-level authentication. At the same time, it enables the free flow of secure data wherever and whenever it is needed, in whatever medium and between dissimilar organisations — such as banks and oil companies, for example. This kicks against the notion of security via a network boundary to the internet. You asked me to: Repeat after me: THIS IS A FRAMEWORK and provides guidance and a rational, strategic approach to Enterprise Architecture and how security should be baked in. Please read this without the FUDtastic taint: It isn’t the FUD in the framework that’s the problem. It’s the FUD in the press quotes, and the lack of meat in the guiding principles (the commandments aren’t really a framework). I’m happy to retract my suggestion to focus on using market forces to pressure vendors. Better yet, I’m happy to contribute to the dialog. I’ve been doing it for years, and intend to keep doing it. Take a look at my Data Security Hierarchy (which is now dated and I’m working on a new framework which is much more specific). Also look at Dynamic Trust if you can find it at Gartner (again, can’t release material I don’t own). … Spend a little time with Dr. John Meakin, Andrew Yeomans, Stephen Bo er, Nick Bleech, etc. and stop being so bloody American 😉 These guys practice what they preach and as I found out, have been for some time. I’m happy to. I’m happy to spend as many hours as they’d like talking about specific models and frameworks for improving security and protecting data. You set up the meetings and I’ll be there. Data security is here today, but harder than it should be, with some big clients out there implementing the right models we can make life easier for the rest of the world. But I disagree that they’ve refined the messaging enough yet. Too much obviousness; not enough specifics to back the really cool ideas; way too much FUD still in the press. That’s basic communications, and it needs work. I’m happy to help. You know where I am. Just shine your Stupendous Signal into the clouds and I’m on my way. Share:

Martin’s recruited me to co-host indefinitely, and I think we’re finally working out the kinks. This one is all over the map but there were some interesting things to talk about: Show Notes: Loren’s review of last week’s podcast – We answered a question from Loren in the podcast, which Rich answered on the blog but I accidentally deleted. Honest. Rich’s TD Ameritrade poll– What do you think the real culprit for the compromise was? Analysing the TD Ameritrade Disclosure TD Ameritrade’s 6 million customers hit with security breach Introducing Security Mike’s Guide to Internet Security – Good news, Mike Rothman doesn’t look at all like the guy on the cover of this book. More good news, this is an idea I think will benefit a lot of people The Ghost in My FileVault Tor madness reloaded My interview with Shava Nerad, the Executive Director of the Tor Project – Anyone interested in hearing an update from Shava? I’m sure she’d be willing to come on the show again. Tell-All PCs and Phones Transforming Divorce – Sorry if this is behind a NYT paywall, even though they’ve stated they’re going to tear it down soon. Tonight’s music: Got to have a Job by Little Charlie and the Nightcats Network Security Podcast, Episode 77  Share: