Research

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

It’s hard to believe, but we are two weeks out from the RSA Conference. As in previous years, your pals at Securosis have put together our 3rd annual RSA Guide, which we will distribute next week. But we will give you blog reading faithful, an early look at what we expect to see at the show. So let’s with the key themes… #OccupyRSA… It’s hard to believe, but the RSA breach was less than a year ago. Feels like forever, doesn’t it? At last year’s RSA Conference we heard a lot of marketing puffery about stopping the APT, and guess what? We’re in for another week of baseless claims and excessive FUD about targeted attacks, advanced malware, and how to detect state-sponsored attackers. As long as you remember that you can’t stop a targeted attack, and continue to focus on Reacting Faster and Better, you’ll have plenty to look at. Especially given that our conference hosts acquired the leading network forensics company (NetWitness) last spring. Just remember to laugh as you walk around the show floor in your Red Army uniform. But there is another return engagement we expect to witness at this year’s RSA: the Guy-Fawkes-mask-wearing crew from Anonymous. Though they have kept busy over the past year occupying every park in the nation, we figure they’ll make some kind of splash at RSA. If only because their boy Topiary’s trial is scheduled to start in May. Obviously it’ll be hard for them to top the grand entrance they made on the back of Aaron Barr and HBGary at last year’s conference, but we figure they’re up to something. Given the continuing rise of chaotic actors, and our inability to build a reasonable threat model against attackers who have no clear motive, it’ll be interesting to see them #OccupyRSA. Is That a Cloud in Your Pocket? Or are you just happy to see us? We’ve said it before and we’ll say it again – the overlapping rapid adoption of cloud computing and mobility make this the most exciting time to be in technology since the start of the Internet bubble. I find today far more interesting, because these two trends affect our lives more fundamentally than the early days of the Internet. Then again, avalanches, earthquakes, and someone pointing an assault rifle at your nose are also pretty exciting, but from a different perspective. Unlike the past two years, at this year’s conference we will see far more real cloud security solutions. Up until now most of what we’ve seen was marketecture or cloudwashing, but merely printing a pretty pamphlet or tossing your existing product into a virtual appliance doesn’t make a real cloud security tool. Of course we see plenty of make-believe, but we see the emergence of new and exciting tools designed from the ground up for cloud security. Our biggest problem is that we still need more people who understand practical cloud architectures, but most of the people I meet at security conferences are more interested in writing policy. Unless you know how this stuff works you won’t be able to tell which is which – it all looks good on paper. But here’s a hint – if it’s the same product name as an appliance on your network, odds are it’s an old product that’s been dipped in a bath of cloudy paint. And then there’s mobility. I can securely access every file I have on every computer through my phone or tablet, but for everyone like me there are dozens of less paranoid folks doing the same thing with no thought for protecting their data. IT lost the battle to fully control all devices entering the enterprise long ago, and combined with the current dramatic growth in local storage on laptops, even barely-technical users can snarf down all the storage they can choke down from the cloud. You’ll see consumerization and mobility themes at nearly every booth, even the food vendors, but for good reason. Everyone I know is forced to adapt to all those friggin’ iPhones and iPads coming in the door, as well as the occasional malware magnet (Android) and the very pretty, can’t-figure-out-why-she’s-being-ignored Windows Mobile. Ha-Duped about Security BigData Yep, it looks like security has gotten intelligence and business-style analysis religion. So you’ll see and hear a lot of BigData, massive databases, NoSQL, Hadoop, and service-based architectures that enable analysis of ginormous data stores to pinpoint attacks. And there is plenty of value in applying ‘BigData’ tactics to security analytics and management. But we clearly aren’t there yet. You will see a bunch of vendors talking about their new alerting engines taking advantage of these cool new data management tactics, but at the end of the day, it’s not how something gets done – it’s still what gets done. So a Hadoop-based backend is no more inherently helpful than that 10-year-old RDBMS-based SIEM you never got to work. You still have to know what to ask the data engine to get meaningful answers. Rather than being blinded by the shininess of the BigData backend focus on how to use the tool in practice. On how to set up the queries to alert on stuff that maybe you don’t know about. Unless the #OccupyRSA folks are sending you their attack plans ahead of time. Then you don’t have to worry… Data Olestra It’s supposed to be good for you. It’s in lots of the products you buy. Marketing documents advertise how you’ll stay slender while enjoying tasty goodness. It’s a miracle product and everyone uses it! Yep, I am talking about Olestra! The irony here is that the product actually makes you fatter. Worse, eat too much, and you’ll ‘leak’ like crazy in your pants. Yuck! Notice any similarities between that and IT products? We buy solutions that are supposed to keep us secure, but don’t. These products suck up all your budget and personnel resources. And the coup de grace is your boss – the person who gave you the budget to buy these security tools – has the deluded conviction that your data is secure. You’re leaking like

Deploying on the network is usually very straightforward – especially since much of the networking support is typically built into the DLP server. If you encounter complications they are generally: due to proxy integration incompatibilities, around integrating with a complex email infrastructure (e.g., multiple regions), or in highly distributed organizations with large numbers of network egress points. Passive sniffing Sniffing is the most basic network DLP monitoring option. There are two possible components involved: All full-suite DLP tools include network monitoring capabilities on the management server or appliance. Once you install it, connect it to a network SPAN or mirror port to monitor traffic. Since the DLP server can normally only monitor a single network gateway, various products also support hierarchical deployment, with dedicated network monitoring DLP servers or appliances deployed to other gateways. This may be a full DLP server with some features turned off, a DLP server for a remote location that pulls policies and pushes alerts back to a central management server, or a thinner appliance or software designed only to monitor traffic and send information back to the management server. Integration involves mapping network egress points and then installing the hardware on the monitoring ports. High-bandwidth connections may require a server or appliance cluster; or multiple servers/appliances, each monitoring a subset of the network (either IP ranges or port/protocol ranges). If you don’t have a SPAN or mirror port you’ll need to add a network tap. The DLP tool needs to see all egress traffic, so a normal connection to a switch or router is inadequate. In smaller deployments you can also deploy DLP inline (bridge mode), and keep it in monitoring mode (passthrough and fail open). Even if your plan is to block, we recommend starting with passive monitoring. Email Email integrates a little differently because the SMTP protocol is asynchronous. Most DLP tools include a built-in Mail Transport Agent (MTA). To integrate email monitoring you enable the feature in the product, then add it into the chain of MTAs that route SMTP traffic out of your network. Alternatively, you might be able to integrate DLP analysis directly into your email security gateway, if your vendors have a partnership. You will generally want to add your DLP tool as the next hop after your email server. If you also use an email security gateway, that means pointing your mail server to the DLP server, and the DLP server to the mail gateway. If you integrate directly with the mail gateway your DLP tool will likely add x-headers to analyzed mail messages. This extra metadata instructs the mail gateway how to handle each messages (allow, block, etc.). Web gateways and other proxies As we have mentioned, DLP tools are commonly integrated with web security gateways (proxies) to allow more granular management of web (and FTP) traffic. They may also integrate with instant messaging gateways, although that is very product specific. Most modern web gateways support something called the ICAP protocol (Internet Content Adaptation Protocol) for extending proxy servers. If your web gateway supports ICAP you can configure it to pass traffic to your DLP server for analysis. Proxying connections enable analysis before the content leaves your organization. You can, for example, allow someone to use webmail but block attachments and messages containing sensitive information. So much traffic now travels over SSL connections that you might want to integrate with a web gateway that performs SSL interception (also called a “reverse proxy”). These work by installing a trusted server certificate on all your endpoints (a straightforward configuration update) and performing a “man-in-the-middle” interception on all SSL traffic. Traffic is encrypted inside your network and from the proxy to the destination website, but the proxy has access to decrypted content. Note: this is essentially attacking and spying on your own users, so we strongly recommend notifying them before you start intercepting SSL traffic for analysis. If you have SSL interception up and running on your gateway, there are no additional steps beyond ICAP integration. Additional proxies, such as instant messaging, have their own integration requirements. If the products are compatible this is usually the same process as integrating a web gateway: just turn the feature on in your DLP product and point both sides at each other. Hierarchical deployments Until now we have mostly described fairly simple deployments, focused on a single appliance or server. That’s the common scenario for small and some mid-size organizations, but the rest of you have multiple network egress points to manage – possibly in very distributed situations, with limited bandwidth in each location. Hopefully you all purchased products which support hierarchical deployment. To integrate, you place additional DLP servers or appliances on each network gateway, then configure them to slave to the primary DLP server/appliance in your network core. The actual procedure varies by product, but here are some things to look out for: Different products have different management traffic bandwidth requirements. Some work great in all situations, but others are too bandwidth-heavy for some remote locations. If your remote locations don’t have a VPN or private connection back to your core network, you will need to establish them for handle management traffic. If you plan on allowing remote locations to manage their own DLP incidents, now is the time to set up a few test policies and workflow to verify that your tool can support this. If you don’t have web or instant messaging proxies at remote locations, and don’t filter that traffic, you obviously lose a major enforcement option. Inconsistent network security hampers DLP deployments (and isn’t good for the rest of your security, either!). We are only discussing multiple network deployments here, but you might use the same architecture to cover remote storage repositories or even endpoints. The remote servers or appliances will receive policies pushed by your main management server and then perform all analysis and enforcement locally. Incident data is sent back to the main DLP console for handling unless you delegated to remote locations. As we have mentioned repeatedly, if hierarchical

We know it’s a shock, but your endpoint protection suite isn’t doing a good enough job of blocking malware attacks. So the industry has resorted additional layers of inspection, detection, and even protection to address its shortcomings. One place focus is turning, which is seeing considerable innovation, is the network. We see a new set of devices and enhancements to existing perimeter platforms, focused on detecting and blocking malware. A paragraph from Network-Based Malware Detection: Filling the Gaps of AV says it best: We have been doing anti-virus for years and it hasn’t worked. Malware detection moving forward is about really understanding what the files are doing, and then determining whether that behavior is bad. By leveraging the collective power of the network we can profile bad stuff much more quickly. With the advancement of network security technology we can start to analyze those files before they make their way onto our devices. Can we actually prevent an attack? Under the right circumstances, yes. We would like to thank Palo Alto Networks for sponsoring this research, and making sure you can read it for a remarkably fair price. You can download the paper directly: Network-Based Malware Detection: Filling the Gaps of AV The paper is based on several posts: Introduction Identifying Today’s Malware Where to Detect the Bad Stuff? The Impact of the Cloud Share:

They say it takes 10,000 hours of practice at a task to become an expert. This isn’t idle supposition, but something that’s been studied scientifically – if you believe in that sorts of things. (I’d like to provide a reference, but I’m in the process of becoming an expert at sitting in an Economy Class seat without wireless). 10,000 hours translates, roughly, to practicing something for 40 hours a week for around 5 years. Having racked up that many hours in a couple different fields, my personal experience tells me (if you believe that sorts of things) that the 10K threshold only opens up the first gate to a long path of mastery. I can’t remember exactly what year I became an analyst, but I think it was right around a decade ago. This would put me well past that first gate, but still with a lot of room to learn and grow in front of me. That’s assuming you consider analysis a skill – I see it as more a mashup of certain fundamental skills, with deep knowledge and experience of the topic you focus on. Some analysts think the fundamental tools of analysis apply anywhere, and it’s only a matter of picking up a few basics on any particular topic. You can recognize these folks, as they bounce from area to coverage area, without a real passion or dedication to any primary focus. While I do think a good analyst can apply the mechanics to multiple domains, being handy with a wrench doesn’t make a plumber a skilled car mechanic. You have to dig deep and rip apart the fundamentals to truly contribute to a field. In a bit of cognitive bias, I’m fascinated by the mechanics of analysis. Like medicine or carpentry, it’s not a field you can learn from a book or class – you really need to apprentice somewhere. One of the critical skills is the ability to change your position when presented with contradictory yet accurate evidence. Dogma is the antithesis of good analysis. Unfortunately I’d say over 90% of analysts take religious positions, and spend more time trying to make the world fit into their intellectual models than fixing their models to fit the world. When you are in a profession where you’re graded on “thought leadership”, it’s all too easy to interpret that as “say something controversial to get attention and plant a flag”. Admitting you were wrong – not merely misinterpreted – is hard. I sure as hell don’t like it, and my natural reaction is usually to double down on my position like anyone else. I don’t always pull my head out of my ass, but I really do try to admit when I get something wrong. Weirdly, a certain fraction of the population interprets that as a fault. Either I’m an idiot for saying something wrong in the first place, or unreliable for changing my mind – even in the face of conflicting evidence. The easiest way to tell whether an analyst sucks is to see how they react when the facts show them wrong. Or whether they use facts to back up their positions. I don’t claim to always get it right – I’m as human as everyone else, and often feel an emotional urge to defend my turf. This is a skill that takes constant practice – it’s handy for everyone, but critical for anyone who sells knowledge for a living. And I believe it takes a heck of a lot more than 10,000 hours to master. I’m at double that and not even close. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR post: A Response To NoSQL Security Concerns. Rich quoted by Bloomberg on the Symantec hack. Favorite Securosis Posts Mike Rothman: Understanding and Selecting a Database Security Platform: Defining DSP. Database security has evolved. Rich and Adrian start fleshing this out by describing how the Database Security Platform is a superset of DAM. Other Securosis Posts Incite 2/7/2012: The Couch. Implementing and Managing a Data Loss Prevention (DLP) Solution: Index of Posts. Understanding and Selecting a Database Security Platform: Defining DSP. Implementing DLP: Starting Your Integration. Implementing DLP: Integration Priorities and Components. Favorite Outside Posts Mike Rothman: Executive Breakfast Briefing with Former DHS Secretary Michael Chertoff. Bejtlich lists 3 questions that you need to be asking yourself in this summary of an event they did with Secretary Chertoff. This seriously cuts to the heart of what security is supposed to be doing… Adrian Lane: Terrorism, SOPA And Zombies. Our Canadian brothers nailed this one. Cabal – cracks me up! Rich: Hoff gets all touchy-feely. Project Quant Posts Malware Analysis Quant: Monitoring for Reinfection. Malware Analysis Quant: Remediate. Malware Analysis Quant: Find Infected Devices. Malware Analysis Quant: Defining Rules. Malware Analysis Quant: The Malware Profile. Malware Analysis Quant: Dynamic Analysis. Malware Analysis Quant: Static Analysis. Malware Analysis Quant: Build Testbed. Research Reports and Presentations [New White Paper] Network-Based Malware Detection: Filling the Gaps of AV. Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Tokenization Guidance. Applied Network Security Analysis: Moving from Data to Information. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Top News and Posts Sorry, I didn’t have WiFi on my flights today and got home late, so I couldn’t compile a good list of stories. It doesn’t help that I’ve been slammed all week and haven’t read as much as usual. I suspect someone disclosed something, someone got hacked, and someone else tried to cover something up. That cover it? Oh – and there was a privacy violation by Google/Facebook/some social media service. Share:

Do you ever stumble upon a show from the old days, perhaps on Boomerang or TVLand, where the doting wife meets the hubby as he comes home from work? It’s just like my deal. I come home from that tough day writing at Starbucks and the Boss is waiting with my smoking jacket, pipe, and slippers, and the trusty glass of brandy to take the edge off a tough day. And then I wake up. What about those scenes where the entire family sits down to dinner and discusses current events? We don’t either. When I come home has more to do with which kid needs to be shuttled to which activity. The Boss has to ride herd on play dates, homework, and all those other balls she keeps in the air every day. We have sit down dinners a few times a month, usually when we go out to dinner as a family. But most of the time we don’t have time to breathe until the kids are in bed, numbing the pain with some inane show on TV. For years we had a great couch we bought from Crate and Barrel. It wasn’t cheap, but it lasted for 10 years. Maybe more. It held up well, but it wasn’t new and we didn’t worry about eating on it. So we’d park on the couch, eat our dinner, talk, and wind down from the day. I know she wanted a new couch, but the old one was fine, so I was pretty resistant to dropping a bunch of coin for something I didn’t think we really needed. But then my overly generous in-laws decided they can’t take it with them, so they gave us a new couch. It was a floor model, and we got a great deal on it. I’m not one to be ungrateful so I said thank you and moved on. Of course, the Boss was very happy, so it was all good. Until I got home. At that point I was suddenly transported back into the 50’s, when we had a virtual sheet of plastic wrap on the couch. Not literally a cover like your grandparents had on their couches, but it might as well have been. I mean, we couldn’t get close to the couch. I was kind of scared to sit on it unless I had just jumped out of the shower. The kids had to change their clothes if they were outside and wanted to sit down. Eating on the new couch? No chance. So we set up some other chairs in front of the couch, so we could still eat in the family room, but the priority was protecting the sanctity of our virginal couch. But we still had to deal with the elephant in the (family) room. That was our annual Super Bowl party. We host about 100 folks on my favorite day of the year. They eat pizza and wings and buffalo chicken dip and all sorts of other things that don’t look very good when spilled on your couch. It was quite a problem, and the Boss even threatened to cancel the party. But as my stepfather says, if it’s a problem that can be solved with money it’s not really a problem. So we went over to the store and bought about 8 huge cushy throw blankets and wrapped the couch from top to bottom. OK, it’s not plastic wrap, but it worked. No spills on the couch. The Giants won, and a good time was had by all, especially me. But Lord knows I wasn’t drinking my Guinness on the new couch. I was willing to take the chance of someone spilling something, so long as it wasn’t me. -Mike Photo credits: “frakkin’ plastic!” originally uploaded by wotthe7734 Heavy Research After a bit of a hiatus from blogging we are back at it. The Heavy Research feed is hopping, and here are a couple links of our latest stuff. So check them out and (as always) let us know what you think via comments. Implementing and Managing a Data Loss (DLP) Solution: Index of Posts. Rich will be updating this post with the latest in his ongoing series on DLP. Here are the posts so far: Implementing and Managing a DLP Solution Implementing DLP: Getting Started Implementing DLP: Picking Priorities and a Deployment Process Implementing DLP: Final Deployment Preparations Implementing DLP: Integration, Part 1 Implementing DLP: Integration Priorities and Components Implementing DLP: Starting Your Integration Understanding and Selecting a Database Security Platform: Defining DSP Bridging the Mobile Security Gap: Operational Consistency: 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. You can get our Heavy Feed via RSS, where you can access all our content in its unabridged glory. Incite 4 U Yamatough lost the negotiating handbook… I won’t say the T word but the rules are the same. Did Symantec really think it would end well when they tried to buy back the source code to Norton and pcAnywhere? They really didn’t think the emails would end up on Pastebin? That email thread is actually quite entertaining – the funniest part is Symantec’s condition that yamatough lie about the hack of the source code. And then SYMC wants to put them on a payment plan. Totally ridiculous. I get they wanted to protect customers – code for minimizing a PR fiasco. But they should have come clean immediately, fixed whatever the issue was, and moved on. I don’t think these folks follow the Negotiating 101 handbook. – MR Security Bowl: Last Sunday’s Super Bowl was a heck of a good game. I’m just sad I had to turn the TV off after the first quarter, record it on the TiVo, and then watch it later mostly in fast forward mode thanks to both kids melting down. Many years ago I had the chance to go work physical security

We’re pretty deep into our series on Implementing DLP, so it’s time to put together an index to tie together all the posts. I will keep this up to date as new content goes up, and in the end it will be the master list for all eternity. Or until someone hacks our site and deletes everything. Whichever comes first. Implementing and Managing a DLP Solution Implementing DLP: Getting Started Implementing DLP: Picking Priorities and a Deployment Process Implementing DLP – Final Deployment Preparations Implementing DLP: Integration, Part 1 Implementing DLP: Integration Priorities and Components Implementing DLP- Starting Your Integration Share:

With priorities fully defined, it is now time to start the actual integration. The first stop is deploying the DLP tool itself. This tends to come in one of a few flavors – and keep in mind that you often need to license different major features separately, even if they all deploy on the same box. This is the heart of your DLP deployment and needs to be in place before you do any additional integration. DLP Server Software: This is the most common option and consists of software installed on a dedicated server. Depending on your product this could actually run across multiple physical servers for different internal components (like a back-end database) or to spread out functions. In a few cases products require different software components running concurrently to manage different functions (such as network vs. endpoint monitoring). This is frequently a legacy of mergers and acquisitions – most products are converging on a single software base with, at most, additional licenses or plugins to provide additional functions. Management server overhead is usually pretty low, especially in anything smaller than a large enterprise, so this server often handles some amount of network monitoring, functions as the email MTA, scans at least some file servers, and manages endpoint agents. A small to medium sized organization generally only needs to deploy additional servers for load balancing, as a hot standby, or to cover remote network or storage monitoring with multiple egress points or data centers. Integration is easy – install the software and position the physical server wherever needed, based on deployment priorities and network configuration. We are still in the integration phase of deployment and will handle the rest of the configuration later. DLP Appliance: In this scenario the DLP software comes preinstalled on dedicated hardware. Sometimes it’s merely a branded server, while in other cases the appliance includes specialized hardware. There is no software to install, so the initial integration is usually a matter of connecting it to the network and setting a few basic options – we will cover the full configuration later. As with a standard server, the appliance usually includes all DLP functions (which you might still need licenses to unlock). The appliance can generally run in an alternative remote monitor mode for distributed deployment. DLP Virtual Appliance: The DLP software is preinstalled into a virtual machine for deployment as a virtual server. This is similar to an appliance but requires work: to get up and running on your virtualization platform of choice, configure the network, and then set the initial configuration options up as if it were a physical server or appliance. For now just get the tool up and running so you can integrate the other components. Do not deploy any policies or turn on monitoring yet. Directory Server Integration The most important deployment integration is with your directory servers and (probably) the DHCP server. This is the only way to tie activity back to actual users, rather than to IP addresses. This typically involves two components: An agent or connection to the directory server itself to identify users. An agent on the DHCP server to track IP address allocation. So when a user logs onto the network, their IP address is correlated against their user name, and this is passed on to the DLP server. The DLP server can now track which network activity is tied to which user, and the directory server enables it to understand groups and roles. This same integration is also required for storage or endpoint deployment. For storage the DLP tool knows which users have access to which files based on file permissions – not that they are always accurate. On an endpoint the agent knows which policies to run based on who is logged in. Share:

As I stated in the intro, Database Security Platform (DSP, to save us writing time and piss off the anti-acronym crowd) differs from DAM in a couple ways. Let’s jump right in with a definition of DSP, and then highlight the critical differences between DAM and DSP. Defining DSP Our old definition for Database Activity Monitoring has been modified as follows: Database Security Platforms, at a minimum, assess database security, capture and record all database activity in real time or near real time (including administrator activity); across multiple database types and platforms; and alert and block on policy violations. This distinguishes Database Security Platforms from Database Activity Monitoring in four key ways: Database security platforms support both relational and non-relational databases. All Database Security Platforms include security assessment capabilities. Database Security Platforms must have blocking capabilities, although they aren’t always used. Database Security Platforms often include additional protection features, such as masking or application security, which aren’t necessarily included in Database Activity Monitors. We are building a new definition due to the dramatic changes in the market. Almost no tools are limited to merely activity monitoring any more, and we see an incredible array of (different) major features being added to these products. They are truly becoming a platform for multiple database security functions, just as antivirus morphed into Endpoint Protection Platforms by adding everything from whitelisting to intrusion prevention and data loss prevention. Here is some additional detail: The ability to remotely audit all user permissions and configuration settings. Connecting to a remote database with user level credentials, scanning the configuration settings, then comparing captured data against an established baseline. This includes all external initialization files as well as all internal configuration settings, and may include additional vulnerability tests. The ability to independently monitor and audit all database activity including administrator activity, transactions, and data (SELECT) requests. For relational platforms this includes DML, DDL, DCL, and sometimes TCL activity. For non-relational systems this includes ownership, indexing, permissions and content changes. In all cases read access is recorded, along with the meta-data associated with the action (user identity, time, source IP, application, etc). The ability to store this activity securely outside the database. The ability to aggregate and correlate activity from multiple, heterogeneous Database Management Systems (DBMS). These tools work with multiple relational (e.g., Oracle, Microsoft, and IBM) and quasi-relational (ISAM, Terradata, and Document management) platforms. The ability to enforce separation of duties on database administrators. Auditing activity must include monitoring of DBA activity, and prevent database administrators from tampering with logs and activity records – or at least make it nearly impossible. The ability to protect data and databases – both alerting on policy violations and taking preventative measure to prevent database attacks. Tools don’t just record activity – they provide real-time monitoring, analysis, and rule-based response. For example, you can create a rule that masks query results when a remote SELECT command on a credit card column returns more than one row. The ability to collect activity and data from multiple sources. DSP collects events from the network, OS layer, internal database structures, memory scanning, and native audit layer support. Users can tailor deployments to their performance and compliance requirements, and collect data from sources best for their requirements. DAM tools have traditionally offered event aggregation but DSP requires correlation capabilities as well. DSP is, in essence, a superset of DAM applied to a broader range of database types and platforms. Let’s cover the highlights in more detail: Databases: It’s no longer only about big relational platforms with highly structured data – but now also in non-relational platforms. Unstructured data repositories, document management systems, quasi-relational storage structures, and tagged-index files are being covered. So the number of query languages being analyzed continues to grow. Assessment: “Database Vulnerability Assessment” is offered by nearly every Database Activity Monitoring vendor, but it is seldom sold separately. These assessment scans are similar to general platform assessment scanners but focus on databases – leveraging database credentials to scan internal structures and metadata. The tools have evolved to scan not only for known vulnerabilities and security best practices, but to include a full scan of user accounts and permissions. Assessment is the most basic preventative security measure and a core database protection feature. Blocking: Every database security platform provider can alert on suspicious activity, and the majority can block suspect activity. Blocking is a common customer requirement – it is only applied to a very small fraction of databases, but has nonetheless become a must-have feature. Blocking requires the agent or security platform to be deployed ‘inline’ in order to intercept and block incoming requests before they execute. Protection: Over and above blocking, we see traditional monitoring products evolving protection capabilities focused more on data and less on database containers. While Web Application Firewalls to protect from SQL injection attacks have been bundled with DAM for some time, we now also see several types of query result filtering. One of the most interesting aspects of this evolution is how few architectural changes are needed to provide these new capabilities. DSP still looks a lot like DAM, but functions quite differently. We will get into architecture later in this series. Next we will go into detail on the features that define DSP and illustrate how they all work together. Share:

It might be obvious by now, but the following charts show which DLP components, integrated with which existing infrastructure, you need based on your priorities. I have broken this out into three different images to make them more readable. Why images? Because I have to dump all this into a white paper later, and building them in a spreadsheet and taking screenshots is a lot easier than mucking with HTML-formatted charts Between this and our priorities post and chart you should have an excellent idea of where to start, and how to organize, your DLP deployment. Share: