Research

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:

Since Rich is vacationing working hard at a security conference in Mexico, I figure I would write this week’s Friday Summary. I am pretty jazzed about some upcoming white papers I’ll be writing on securing data and applications at scale, understanding and selecting masking technologies, and why log management is not dead! And I am having a good time researching and writing the DAM 2.0 DSP series as well. I originally intended to write about our research agenda but changed my mind. Frankly, I have spring fever. Spring fever, you ask, in the first week of February? Yep. It’s 74 degrees here and sunny. WTF? Punxsutawney Phil weighed in with his opinion, and after burning his retinas, it looks like we are going to have another six weeks of winter. I sure hope so! Another six weeks of this type of weather would be awesome. I have been on the phone with dozens of people around the country, from Boston to San Diego, and they are all experiencing fantastic weather. Even Gunnar reports highs of 48 degrees in Minnesota. I guess the cold air jet stream has been staying north of the border. For me this means my peach trees are blooming. Blooming! On freakin’ January 30th! See for yourself: And I know some of you may not care, but the warm weather means my backyard garden is almost complete. Following up on my post last October, in just a couple short months the Vegetable Fortress is built! Overbuilt? Beauty is in the eye of the beholder. I may put some solar powered laser turrets on it. You never know when Al-Qaeda might train gophers with tig welders to attack my squash. And if the DHS threat level spikes I will have a detachment of Araucana commando chickens to beat back the attack. The price of vegetables is eternal vigilance – and $3.95 for GMO free seeds. Now call in sick and go outside to enjoy the nice weather! You’ll be glad you did. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Our Research Page with every freakin’ white paper we’ve done in the last three years. Rich, Adrian, and Shimmy discuss NoSQL Security with Couchbase and Mongo founders. Other Securosis Posts Bridging the Mobile Security Gap: Operational Consistency. Malware Analysis Quant: Take the Survey (and win fancy prizes!) Incite 2/1/2012: Bored to Tears. Implementing DLP: Integration, Part 1. Understanding and Selecting Database Security Platforms. Bridging the Mobile Security Gap: The Need for Context. Implementing and Managing a Data Loss Prevention (DLP) Solution: Index of Posts. Implementing DLP: Final Deployment Preparations. Malware Analysis Quant: Phase 1 – The Process [Check out the paper!] Favorite Outside Posts Mike Rothman: Mr. Waledac: The Peter North of Spamming. Krebs could have written this post in Swahili and it would still be my favorite outside link. Anyone that can pull off a Peter North mention in the title of a post gets my weekly vote. And it’s even a good post! Krebs digs into the intrigue of the Russian Spam Mafia. David Mortman: BSides/RSA Conference Dust Up. And the resolution. Beneficial discussion. Rich: Firewalls and SSL: More Profitable than Facebook. Gunnar’s got a great point: Firewalls, AV, and SSL sell – and very little money gets spent on innovative products. Adrian Lane: Fascinating look at Netflix’s Ephemeral Volatile Caching in the cloud. Not security related, but a good presentation of what’s possible with cloud content distribution. 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 Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. 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. Security Benchmarking: Going Beyond Metrics. Top News and Posts Paget Demonstrates Wireless Credit Card Theft. Carrier IQ Concerns. WPA2 Vulnerability Analysis. Symantec patches pcAnywhere, says it’s safe. Secure Virtual Storage – the AWS way. Missed this in last week’s summary. Low Orbit Ion Cannon DDoS Analysis. Not new, but newsworthy. Android Malware Infection. Android can be a more powerful platform as you can run more powerful apps on it. This is made possible by a lax security model. That’s the tradeoff. Google to Censor Blogger Blogs on a ‘Per Country Basis’. The tradeoff is either Google blogs get banned on a ‘Per Country Basis’ or Google bans select blogs. Revenue trumps ethics every time. Blog Comment of the Week None this week. Share:

We started the Bridging the Mobile Security Gap series by accepting that we can’t control the devices that show up on our networks any more. We followed up with a diatribe on the need for context to build and enforce policies which ensure that (only) the right users get to the right stuff at the right times. To wrap up the series we need to dig deeper into enforcement, because as we all know the chain is only as strong as its weakest link. There are various places where mobile device security policies can be enforced – including on the devices themselves (via mobile device management) and on the network (firewall/VPN, IPS, network access control, etc.). There is no one right or wrong place to enforce policies. In fact the best answer is often “all of the above”. The more places you can enforce policy, the more likely your defenses will succeed at blocking attacks. Of course complexity is the obvious downside to multiple enforcement points. Complexity has a strong negative correlation with operational consistency. You need to make sure your enforcement points work together. Why? Let’s run through a few scenarios where policies are not aligned. Yeah, they do not end well. You can implement a policy forcing device to connect through the corporate VPN to receive the protection of the enterprise network – but that only works if the VPN recognizes the device and puts it in the right trust zone, with access to what the user needs. When that doesn’t happen correctly, the user is out of business – or a risk. Likewise, preventing misconfigured smartphones from accessing the network reflects good security enforcement, right? Sure, unless it belongs to the CEO who is trying to access a letter of understanding about an acquisition – even worse if you have no way to override the control. Exceptions are part of the game of managing security, so you need the ability to adapt as needed. Both those scenarios result in users being unable to access what they need, which means a bad day for you. This is why neither MDM nor any kind of network-based control can operate in a vacuum. You can take a number of steps to attain operational consistency. Coexistence The first stop on our path to policy consistency is just making the enforcement points coexist. Do enough to make sure one tool is working contrary to the others. Unfortunately this is largely a manual process. Whenever changes are made or new policies implemented, your administrators need to run through the impact of these changes. All of them. Well, all the practical ones anyway. It’s a lot of work, but necessary, given how important mobile devices have become to business productivity. Remember the good old days, when you did a similar dance when changing firewall rules. Some folks waited for the help desk to light up, and then they knew something was broken. We don’t recommend that approach. To avoid that problem vendors starting offering built-in policy checkers, and third-party firewall management tools emerged to perform these functions at higher scale and on multiple firewalls. Unfortunately those tools don’t support mobile devices (or the relevant network controls) today, so for now you are on your own. That can be problematic, since you know (even if you don’t want to admit it) that it’s difficult to maintain operational discipline – particularly in the face of the number of changes made, exceptions managed, and other fires to fight. It’s not where you want to be, but coexistence is the start. Integration at the console The next step is console integration. In this scenario alerts funnel from one management console to the other. Integration at least gives administrators a coordinated view of what’s happening. It may even be possible to click on one console and have that link to a specific event or device in the other. Very fancy, and downright useful from an operational standpoint. A little less integration your admins need to perform in their own heads improves productivity. Of course this requires cooperation between vendors and these kinds of relationships are not commonplace. But they will be – enterprise customers will demand them. Another benefit of this initial integration is more effective compliance reporting. Vendors map from a data source to the compliance report and pump the data in. That’s pretty helpful too – you know how painful getting ready for an audit remains, especially when you need to manage 5-10 different data sources to show to the auditor that you know what you’re doing. Of course this is less than full integration – you still need to deal with multiple consoles to make policy changes, and the logic to ensure a policy in one tool doesn’t adversely impact another tool is missing. But it’s progress. True integration What you really want is the ability to manage a single policy, implemented across different devices and network controls. How cool would that be? But don’t hold your breath waiting. Like most other non-standards-based integration, we will see integration initially forced by huge customers. Some Fortune 50 company using a device-centric management product will want to implement network controls. They will call everyone together, write down on a whiteboard how much they spend with each company, and make it very clear that integration will happen, and soon. It’s the proverbial offer they can’t refuse, and they usually don’t. Over time integration gives way to consolidation, and we expect MDM to be integrated into the larger IT device management stack and eventually work with network controls that way. Obviously that’s a few years down the road, but it’s the way these things work out. It’s not a matter of if but a matter of when. But without a crystal ball there isn’t much to do about that, so the best bet is to make decisions based on available integration today, and be ready to adapt for tomorrow. Losing device specificity We used to think of mobile devices as only laptops, but the pendulum has swung back the other way, to focus

One of the coolest things about how we work at Securosis is our Totally Transparent Research approach. We always post our work to the blog first and let you folks have at it. In many cases it gets poked and prodded, ridiculed, and broken down. It’s certainly tough on the ego, but in the end makes the work better. So we are now asking for more help as we enter Phase 2 of our Malware Analysis Quant research. As we described over the weekend, Phase 1 resulted in a nice (not so) little paper breaking down the process map for studying malware infections. Now we have to match up theory against reality. And thus the MAQ survey. As with all our surveys, we have set it up so you can take it anonymously, and all the raw results (anonymized, in spreadsheet format) will be released after our analysis. By the way, unlike other folks posting surveys, we don’t know the answers before we post the survey. Click here to take the survey, and please spread the word. We know from our last few surveys that we need to consider the time you are taking to help, so we kept this one pretty short. We would be surprised if it takes you more than 10-15 minutes. We understand filling out surveys is a pain in the behind, so we are providing an incentive. We will give 3 $100 Amazon gift cards to lucky participants. You don’t need to provide an email address to take the survey, but you do to be entered into the drawing. We are also tracking where we get our responses from, so if you take the survey in response to this post, please use Securosis. as your source code. If you repost the link you can make up your own code and email it to us. We’ll let you know how many people responded to your referral. If you generate sufficient response we will be happy to send you your keycode’s slice of the data. Thanks again for your help. We’ll keep the survey open at least 2 weeks and then begin analysis. Again, here is the link: http://www.surveymonkey.com/s/MalwareAnalysisQuant-Survey Photo credit: “Survey says…” originally uploaded by hfabulous Share:

It’s unbelievable how different growing up today is. When I was in elementary school in the late 70s, Pong was state of the art and a handheld Coleco football game would keep a little kid occupied for hours. When they came up with the Head to Head innovation, two kids would be occupied for hours. That was definitely a different type of Occupy movement. We also didn’t have 300 channels on the boob tube. We had 5 channels, and the highlight of the year was Monster Week. At least for me. Most days I jumped on my bike to go play with my friends. Sometimes we played football. Okay – a lot of days we’d play football. It was easy – you didn’t need much equipment or a special field or anything. Just an even number of kids. I’m not sure what little girls did back in the day, since it was just me and my younger brother, but I’m sure it was similarly unsophisticated. We just played. Why am I getting nostalgic? Basically because I’m frustrated. Today kids don’t play. They need to be entertained. The thing that makes me cringe most is when one of my kids tells me they are bored. Bored? This usually happens after I tell them 5 hours on the iPod touch is enough over the weekend. Or that the 3 hours they watched crappy TV in the morning is more than enough. I tell them to get a book and read. I tell them to play a game. Maybe use some of the thousands of dollars of toys in the basement. Perhaps even build something with Lincoln Logs. Or break out one of the 25 different Lego contraptions we have. Mostly I tell them to get out of my hair, since I’m doing important stuff. Like reading about the Super Bowl on my iPad. But I digress. What ever happened to the 5 Best Toys of All Time? I’d add a football to that list and be good. That was my childhood in a nutshell. No more. Our kids’ minds are numbed with constant stimulation, which isn’t surprising considering that many of us are similarly numb, and it’s not helping us find happiness. Rich sent around this article over the weekend, and it’s right. We seem to have forgotten what it’s like to interact with folks, unless it’s via Words with Friends. Sometimes you need to slow down to speed up in the long run. I know you can’t stop ‘progress’. But you don’t need to just accept it either. After XX1 realized I wasn’t going to cave and let her play on the computer, she spent a few hours writing letters to her camp friends. She painstakingly colored the envelopes, and I think she even wrote English. But what she wrote isn’t the point. It’s that there was no battery, power cord, or other electronics involved. No ads were flying at her head either. Amazingly enough, she overcame her boredom and was even a little disappointed when everyone had to get ready for bed. It was a small victory, but I’ll take it. They don’t come along too often, since my kids are always right. Just ask them. -Mike Photo credits: “Mattel & Coleco H2H classics” originally uploaded by Vic DeLeon Heavy Research After a bit of a blogging hiatus we are back at it. The Heavy Research feed is hopping, so here are a couple links to our latest stuff. Please 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. Understanding and Selection Database Security Platforms: Rich and Adrian are updating their landmark DAM research from a few years ago. As with many things, what used to a single-purpose capability (DAM) is now a database security platform. Follow along as they explore exactly what that means. Bridging the Mobile Security Gap: The Need for Context: Got rid of those smartphones yet? No? Then you should be checking out this series on how to provision layered controls to maintain order, in light of the onslaught of all sorts of new devices. Malware Analysis Quant: Phase 1 – The Process: We have finished up Phase 1 of Malware Analysis Quant, and packaged up the process map and descriptions into a paper. Check it out, but please understand the process will continue to evolve as we keep digging into the research. We will launch the survey this week, so keep an eye out. You can get our Heavy Feed via RSS, where you can access all our content in its unabridged glory. Incite 4 U Privacy and Google: Google’s new privacy policy has been making waves the last few days. For me it’s not so much about the policy – I’m nonplussed about that. Sure, I don’t like the Google’s non-anonymity posture. On the other hand it’s much easier to understand Google’s consolidated policy on privacy and the intentions behind it – for that they should be commended. Essentially it comes down to “use our stuff and we’ll use your data”, which is clear enough and completely unsurprising in light of their business model. Understand that an encrypted search provides an illusion of privacy, meaning nobody on the network you traverse should be able to see the query, but it does not mean your activity is not logged and indexed by Google (or your other search provider). Good or bad – you be the judge. The real question is what are you going to do about it? For me this is an important “rubber meets the road” milestone. And that’s too bad because I like using Google’s search engine – it is clearly the the best. Gmail is free and it works – but I don’t have an easy way to encrypt email running through my Gmail account so Google can’t read it. Which means I have to get off my lazy butt and stop using these tools, or accept that Google owns an online identity

At this point all planning should be complete. You have determined your incident handling process, started (or finished) cleaning up directory servers, defined your initial data protection priorities, figured out which high-level implementation process to start with, mapped our the environment so you know where to integrate, and performed initial testing and perhaps a proof of concept. Now it’s time to integrate the DLP tool into your environment. You won’t be turning on any policies yet – the initial focus is on integrating the technical components and preparing to flip the switch. Define a Deployment Architecture Earlier you determined your deployment priorities and mapped out your environment. Now you will use them to define your deployment architecture. DLP Component Overview We have covered the DLP components a bit as we went along, but it’s important to know all the technical pieces you can integrate depending on your deployment priorities. This is just a high-level overview, and we go into much more detail in our Understanding and Selecting a Data Loss Prevention Solution paper. This list includes many different possible components, but that doesn’t mean you need to buy a lot of different boxes. Small and mid-sized organizations might be able to get everything except the endpoint agents on a single appliance or server. Network DLP consists of three major components and a few smaller optional ones: Network monitor or bridge/proxy – this is typically an appliance or dedicated server placed inline or passively off a SPAN or mirror port. It’s the core component for network monitoring. Mail Transport Agent – few DLP tools integrate directly into a mail server; instead they insert their own MTA as a hop in the email chain. Web gateway integration – many web gateways support the ICAP protocol, which DLP tools use to integrate and analyze proxy traffic. This enables more effective blocking and provides the ability to monitor SSL encrypted traffic if the gateway includes SSL intercept capabilities. Other proxy integration – the only other proxies we see with any regularity are for instant messaging portals, which can also be integrated with your DLP tool to support monitoring of encrypted communications and blocking before data leaves the organization. Email server integration – the email server is often separate from the MTA, and internal communications may never pass through the MTA which only has access to mail going to or coming from the Internet. Integrating directly into the mail server (message store) allows monitoring of internal communications. This feature is surprisingly uncommon. Storage DLP includes four possible components: Remote/network file scanner – the easiest way to scan storage is to connect to a file share over the network and scan remotely. This component can be positioned close to the file repository to increase performance and reduce network saturation. Storage server agent – depending on the storage server, local monitoring software may be available. This reduces network overhead, runs faster, and often provides additional metadata, but may affect local performance because it uses CPU cycles on the storage server. Document management system integration or agent – document management systems combine file storage with an application layer and may support direct integration or the addition of a software agent on the server/device. This provides better performance and additional context, because the DLP tool gains access to management system metadata. Database connection – a few DLP tools support ODBC connections to scan inside databases for sensitive content. Endpoint DLP primarily relies on software agents, although you can also scan endpoint storage using administrative file shares and the same remote scanning techniques used for file repositories. There is huge variation in the types of policies and activities which can be monitored by endpoint agents, so it’s critical to understand what your tool offers. There are a few other components which aren’t directly involved with monitoring or blocking but impact integration planning: Directory server agent/connection – required to correlate user activity with user accounts. DHCP server agent/connection – to associate an assigned IP address with a user, which is required for accurate identification of users when observing network traffic. This must work directly with your directory server integration because the DHCP servers themselves are generally blind to user accounts. SIEM connection – while DLP tools include their own alerting and workflow engines, some organizations want to push incidents to their Security Information and Event Management tools. In our next post I will post a chart that maps priorities directly to technical components. Share: