Dlp

LHF: Quick Wins with DLP—the Conclusion

By Rich

In the last two posts we covered the main preparation you need to get quick wins with your DLP deployment. First you need to put a basic enforcement process in place, then you need to integrate with your directory servers and major infrastructure. With these two bits out of the way, it's time to roll up our sleeves, get to work, and start putting that shiny new appliance or server to use.

The differences between a long-term DLP deployment and our "Quick Wins" approach are goals and scope. With a traditional deployment we focus on comprehensive monitoring and protection of very specific data types. We know what we want to protect (at a granular level) and how we want to protect it, and we can focus on comprehensive policies with low false positives and a robust workflow. Every policy violation is reviewed to determine if it's an incident that requires a response.

In the Quick Wins approach we are concerned less about incident management, and more about gaining a rapid understanding of how information is used within our organization. There are two flavors to this approach -- one where we focus on a narrow data type, typically as an early step in a full enforcement process or to support a compliance need, and the other where we cast a wide net to help us understand general data usage to prioritize our efforts. Long-term deployments and Quick Wins are not mutually exclusive -- each targets a different goal and both can run concurrently or sequentially, depending on your resources.

Remember: even though we aren't talking about a full enforcement process, it is absolutely essential that your incident management workflow be ready to go when you encounter violations that demand immediate action!

Choose Your Flavor

The first step is to decide which of two general approaches to take:

• Single Type: In some organizations the primary driver behind the DLP deployment is protection of a single data type, often due to compliance requirements. This approach focuses only on that data type.
• Information Usage: This approach casts a wide net to help characterize how the organization uses information, and identify patterns of both legitimate use and abuse. This information is often very useful for prioritizing and informing additional data security efforts.

Choose Your Deployment Type

Depending on your DLP tool, it will be capable of monitoring and protecting information on the network, on endpoints, or in storage repositories -- or some combination of these. This gives us three pure deployment options and four possible combinations.

• Network Focused: Deploying DLP on the network in monitoring mode provides the broadest coverage with the least effort. Network monitoring is typically the fastest to get up and running due to lighter integration requirements. You can often plug in a server or appliance over a few hours or less, and instantly start evaluating results.
• Endpoint Focused: Starting with endpoints should give you a good idea of which employees are storing data locally or transferring it to portable storage. Some endpoint tools can also monitor network activity on the endpoint, but these capabilities vary widely. In terms of Quick Wins, endpoint deployments are generally focused on analyzing stored content on the endpoints.
• Storage Focused: Content discovery is the analysis of data at rest in storage repositories. Since it often requires considerable integration (at minimum, knowing the username and password to access a file share), these deployments, like endpoints, involve more effort. That said, it's scan major repositories is very useful, and in some organizations it's as important (or even more so) to understand stored data than to monitor information moving across the network.

Network deployments typically provide the most immediate information with the lowest effort, but depending on what tools you have available and your organization's priorities, it may make sense to start with endpoints or storage. Combinations are obviously possible, but we suggest you roll out multiple deployment types sequentially rather than in parallel to manage project scope.

Define Your Policies

The last step before hitting the "on" switch is to configure your policies to match your deployment flavor.

In a single type deployment, either choose an existing category that matches the data type in your tool, or quickly build your own policy. In our experience, pre-built categories common in most DLP tools are almost always available for the data types that commonly drive a DLP project. Don't worry about tuning the policy -- right now we just want to toss it out there and get as many results as possible. Yes, this is the exact opposite of our recommendations for a traditional, focused DLP deployment.

In an information usage deployment, turn on all the policies or enable promiscuous monitoring mode. Most DLP tools only record activity when there are policy violations, which is why you must enable the policies. A few tools can monitor general activity without relying on a policy trigger (either full content or metadata only). In both cases our goal is to collect as much information as possible to identify usage patterns and potential issues.

Monitor

Now it's time to turn on your tool and start collecting results.

Don't be shocked -- in both deployment types you will see a lot more information than in a focused deployment, including more potential false positives. Remember, you aren't concerned with managing every single incident, but want a broad understanding of what's going on on your network, in endpoints, or in storage.

Analyze and PROFIT!

Now we get to the most important part of the process -- turning all that data into useful information.

Once we collect enough data, it's time to start the analysis process. Our goal is to identify broad patterns and identify any major issues. Here are some examples of what to look for:

• A business unit sending out sensitive data unprotected as part of a regularly scheduled job.
• Which data types broadly trigger the most violations.
• The volume of usage of certain content or files, which may help identify valuable assets that don't cleanly match a pre-defined policy.
• Particular users or business units with higher numbers of violations or unusual usage patterns.
• False positive patterns, for tuning long-term policies later.

All DLP tools provide some level of reporting and analysis, but ideally your tool will allow you to set flexible criteria to support the analysis.

What Did We Achieve?

If you followed this process, by now you've created a base for your ongoing DLP usage while achieving valuable short-term goals. In a short amount of time you have:

1. Established a flexible incident management process.
2. Integrated with major infrastructure components.
3. Assessed broad information usage.
4. Set a foundation for later focused efforts and policy tuning to support long-term management.

Thus by following the Quick Wins process you can show immediate results while establishing the foundations of your program, all without overwhelming yourself by forcing unprepared action on all possible alerts before you understand information usage patterns.

Not bad, eh?

–Rich

LHF: Quick Wins in DLP, Part 2

By Rich

In Part 1 of this series on Low Hanging Fruit: Quick Wins with DLP, we covered how important it is to get your process in place, and the two kinds of violations you should be immediately prepared to handle. Trust us -- you will see violations once you turn your DLP tool on.

Today we'll talk about the last two pieces of prep work before you actually flip the 'on' switch.

Prepare Your Directory Servers

One of the single most consistent problems with DLP deployments has nothing to do with DLP, and everything to do with the supporting directory (AD, LDAP, or whatever) infrastructure. Since with DLP we are concerned with user actions across networks, files, and systems (and on the network with multiple protocols), it's important to know exactly who is committing all these violations. With a file or email it's usually a straightforward process to identify the user based on their mail or network logon ID, but once you start monitoring anything else, such as web traffic, you need to correlate the user's network (IP) address back to their name.

This is built into nearly every DLP tool, so they can track what network addresses are assigned to users when they log onto the network or a service.

The more difficult problem tends to be the business process; correlating these technical IDs back to real human beings. Many organizations fail to keep their directory servers current, and as a result it can be hard to find the physical body behind a login. It gets even harder if you need to figure out their business unit, manager, and so on.

For a quick win, we suggest you focus predominantly on making sure you can track most users back to their real-world identities. Ideally your directory will also include role information so you can filter DLP policies violations based on business unit. Someone in HR or Legal usually has authorization for different sensitive information than people in IT and Customer Service, and if you have to manually figure all this out when a violation occurs, it will really hurt your efficiency later.

Integrate with Your Infrastructure

The last bit of preparation is to integrate with the important parts of your infrastructure. How you do this will vary a bit depending on your initial focus (endpoint, network, or discovery). Remember, this all comes after you integrate with your directory servers.

The easiest deployments are typically on the network side, since you can run in monitoring mode without having to do too much integration. This might not be your top priority, but adding what's essentially an out of band network sniffer is very straightforward. Most organizations connect their DLP monitor to their network gateway using a SPAN or mirror port. If you have multiple locations, you'll probably need multiple DLP boxes and have to integrate them using the built-in multi-system management features common to most DLP tools.

Most organizations also integrate a bit more directly with email, since it is particularly effective without being especially difficult. The store-and-forward nature of email, compared to other real-time protocols, makes many types of analysis and blocking easier. Many DLP tools include an embedded mail server (MTA, or Mail Transport Agent) which you can simply add as another hop in the email chain, just like you probably deployed your spam filter.

Endpoint rollouts are a little tougher because you must deploy an agent onto every monitored system. The best way to do this (after testing) is to use whatever software deployment tool you currently use to push out updates and new software.

Content discovery -- scanning data at rest in storage -- can be a bit tougher, depending on how many servers you need to scan and who manages them. For quick wins, look for centralized storage where you can start scanning remotely through a file share, as opposed to widely distributed systems where you have to manually obtain access or install an agent. This reduces the political overhead and you only need an authorized user account for the file share to start the process.

You'll notice we haven't talked about all the possible DLP integration points, but instead focused on the main ones to get you up and running as quickly as possible. To recap:

• For all deployments: Directory services (usually your Active Directory and DHCP servers).
• For network deployments: Network gateways and mail servers.
• For endpoint deployments: Software distribution tools.
• For discovery/storage deployments: File shares on the key storage repositories (you generally only need a username/password pair to connect).

Now that we are done with all the prep work, in our next post we'll dig in and focus on what to do when you actually turn DLP on.

–Rich

Low Hanging Fruit: Quick Wins with Data Loss Prevention

By Rich

Two of the most common criticisms of DLP that comes up in user discussions are a) its complexity and b) the fear of false positives. Security professionals worry that DLP is an expensive widget that will fail to deliver the expected value -- turning into yet another black hole of productivity. But when used properly DLP provides rapid assessment and identification of data security issues not available with any other technology.

I don't mean to play down the real complexities you might encounter as you roll out a complete data protection program. Business use of information is itself complicated, and no tool designed to protect that data can simplify or mask the underlying business processes. However, there are steps you can take to obtain significant immediate value and security gains without blowing your productivity or wasting important resources.

Over the next few posts I'll highlight the lowest hanging fruit for DLP, refined in conversations with hundreds of DLP users. These aren't meant to incorporate the entire DLP process, but to show you how to get real and immediate wins before you move on to more complex policies and use cases.

Establish Your Process

Nearly every DLP reference I've talked with has discovered actionable offenses committed by employees as soon as they turn the tool on. Some of these require little more than contacting a business unit to change a bad process, but quite a few result in security guards escorting people out of the building, or even legal action. One of my favorite stories is the time the DLP vendor plugged in the tool for a lunchtime demonstration on the same day a senior executive decided to send proprietary information to a competitor. Needless to say, the vendor lost their hard drives that day, but they didn't seem too unhappy.

Even if you aren't planning on moving straight to enforcement mode, you need to put a process in place to manage the issues that will crop up once you activate your tool. The kinds of issues you need to figure out how to address in advance fall into two categories:

• Business Process Failures: Although you'll likely manage most business process issues as you roll out your sustained deployment, the odds are high some will be of such high concern they will require immediate remediation. These are often compliance related.
• Egregious Employee Violations: Most employee-related issues can be dealt with as you gradually shift into enforcement mode, but as in the example above, you will encounter situations requiring immediate action.

In terms of process, I suggest two tracks based on the nature of the incident. Business process failures usually involve escalation within security or IT, possible involvement of compliance or risk management, and engagement with the business unity itself. You are less concerned with getting someone in trouble than stopping the problem.

Employee violations, due to their legal sensitivity, require a more formal process. Typically you'll need to open an investigation and immediately escalate to management while engaging legal and human resources (since this might be a firing offense). Contingencies need to be established in case law enforcement is engaged, including plans to provide forensic evidence to law enforcement without having them walk out the door with your nice new DLP box and hard drives. Essentially you want to implement whatever process you already have in place for internal employee investigations and potential termination.

In our next post we'll focus more on rolling out the tool, followed by how to configure it for those quick wins I keep teasing you with.

–Rich

RSAC 2010 Guide: Data Security

By Rich

Over the next 3 days, we'll be posting the content from the Securosis Guide to the RSA Conference 2010. We broke the market into 8 different topics: Network Security, Data Security, Application Security, Endpoint Security, Content (Web & Email) Security, Cloud and Virtualization Security, Security Management, and Compliance. For each section, we provide a little history and what we expect to see at the show. Next up is Data Security.

Data Security

Although technically nearly all of Information Security is directed at protecting corporate data and content, in practice our industry has historically focused on network and endpoint security. At Securosis we divide up the data security world into two major domains based on how users access data -- the data center and the desktop. This reflects how data is managed far more practically than "structured" and "unstructured". The data center includes access through enterprise applications, databases, and document management systems. The desktop includes productivity applications (the Office suite), email, and other desktop applications and communications.

What We Expect to See

There are four areas of interest at the show relative to data security:

• Content Analysis: This is the ability of security tools to dig inside files and packets to understand the content inside, not just the headers or other metadata. The most basic versions are generally derived from pattern matching (regular expressions), while advanced options include partial document matching and database fingerprinting. Content analysis techniques were pioneered by Data Loss Prevention (DLP) tools; and are starting to pop up in everything from firewalls, to portable device control agents, to SIEM systems.

The most important questions to ask identify the kind of content analysis being performed. Regular expressions alone can work, but result in more false positives and negatives than other options. Also find out if the feature can peer inside different file types, or only analyze plain text. Depending on your requirements, you may not need advanced techniques, but you do need to understand exactly what you're getting and determine if it will really help you protect your data, or just generate thousands of alerts every time someone buys a collectable shot glass from Amazon.

• DLP Everywhere: Here at Securosis we use a narrow definition for DLP that includes solutions designed to protect data with advanced content analysis capabilities and dedicated workflow, but not every vendor marketing department agrees with our approach. Given the customer interest around DLP, we expect you'll see a wide variety of security tools with DLP or "data protection" features, most of which are either basic content analysis or some form of context-based file or access blocking. These DLP features can be useful, especially in smaller organizations and those with only limited data protection needs, but they are a pale substitute if you need a dedicated data protection solution.

When talking with these vendors, start by digging into their content analysis capabilities and how they really work from a technical standpoint. If you get a technobabble response, just move on. Also ask to see a demo of the management interface -- if you expect a lot of data-related violations, you will likely need a dedicated workflow to manage incidents, so user experience is key. Finally, ask them about directory integration -- when it comes to data security, different rules apply to different users and groups.

• Encryption and Tokenization: Thanks to a combination of PCI requirements and recent data breaches, we are seeing a ton of interest in application and database encryption and tokenization. Tokenization replaces credit card numbers or other sensitive strings with random token values (which may match the credit card format) matched to real numbers only in a central highly secure database. Format Preserving Encryption encrypts the numbers so you can recover them in place, but the encrypted values share the credit card number format. Finally, newer application and database encryption options focus on improved ease of use and deployment compared to their predecessors.

You don't really need to worry about encryption algorithms, but it's important to understand platform support, management user experience (play around with the user interface), and deployment requirements. No matter what anyone tells you, there are always requirements for application and database changes, but some of these approaches can minimize the pain. Ask how long an average deployment takes for an organization of your size, and make sure they can provide real examples or references in your business, since data security is very industry specific.

• Database Security: Due partially to acquisitions and partially to customer demand, we are seeing a variety of tools add features to tie into database security. Latest in the hit parade are SIEM tools capable of monitoring database transactions and vulnerability assessment tools with database support. These parallel the dedicated Database Activity Monitoring and Database Assessment markets. As with any area of overlap and consolidation, you'll need to figure out if you need a dedicated tool, or if features in another type of product are good enough. We also expect to see a lot more talk about data masking, which is the conversion of production data into a pseudo-random but still usable format for development.

–Rich

What Do DLP and Condoms Have in Common?

By Rich

They both work a heck of a lot better if you use them ahead of time.

I just finished reading the Trustwave Global Security Report, which summarizes their findings from incident response and penetration tests during 2009.

In over 200 breach investigations, they only encountered one case where the bad guy encrypted the data during exfiltration. That's right, only once. 1. The big uno.

This makes it highly likely that a network DLP solution would have detected, if not prevented, the other 199+ breaches.

Since I started covering DLP, one of the biggest criticisms has been that it can't detect sensitive data if the bad guys encrypt it. That's like telling a cop to skip the body armor since the bad guy can just shoot them someplace else.

Yes, we've seen cases where data was encrypted. I've been told that in the recent China hacks the outbound channel was encrypted. But based on the public numbers available, more often than not (in a big way) encryption isn't used. This will probably change over time, but we also have other techniques to try to detect such other exfiltration methods.

Those of you currently using DLP also need to remember that if you are only using it to scan employee emails, it won't really help much either. You need to use promiscuous mode, and scan all outbound TCP/IP to get full value. Also make sure you have it configured in true promiscuous mode, and aren't locking it to specific ports and protocols. This might mean adding boxes, depending on which product you are using. Yes, I know I just used the words 'promiscuous' and 'condom' in a blog post, which will probably get us banned (hopefully our friends at the URL filtering companies will at least give me a warning).

I realize some of you will be thinking, "Oh, great, but now the bad guys know and they'll start encrypting." Probably, but that's not a change they'll make until their exfiltration attempts fail -- no reason to change until then.

–Rich

You Have to Buy Data Security Tools

By Rich

When Mike was reviewing the latest Pragmatic Data Security post he nailed me on being too apologetic for telling people they need to spend money on data-security specific tools. (The line isn't in the published post).

Just so you don't think Mike treats me any nicer in private than he does in public, here's what he said:

Don't apologize for the fact that data discovery needs tools. It is what it is. They can be like almost everyone else and do nothing, or they can get some tools to do the job. Now helping to determine which tools they need (which you do later in the post) is a good thing. I just don't like the apologetic tone.

As someone who is often a proponent for tools that aren't in the typical security arsenal, I've found myself apologizing for telling people to spend money. Partially, it's because it isn't my money... and I think analysts all too often forget that real people have budget constraints. Partially it's because certain users complain or look at me like I'm an idiot for recommending something like DLP.

I have a new answer next time someone asks me if there's a free tool to replace whatever data security tool I recommend:

Did you build your own Linux box running ipfw to protect your network, or did you buy a firewall?

The important part is that I only recommend these purchases when they will provide you with clear value in terms of improving your security over alternatives. Yep, this is going to stay a tough sell until some regulation or PCI-like standard requires them.

Thus I'm saying, here and now, that if you need to protect data you likely need DLP (the real thing, not merely a feature of some other product) and Database Activity Monitoring. I haven't found any reasonable alternatives that provide the same value.

There. I said it. No more apologies -- if you have the need, spend the money. Just make sure you really have the need, and the tool you are looking at really delivers the value, since not all solutions are created equal.

–Rich

Pragmatic Data Security: Discover

By Rich

In the Discovery phase we figure where the heck our sensitive information is, how it's being used, and how well it's protected. If performed manually, or with too broad an approach, Discovery can be quite difficult and time consuming. In the pragmatic approach we stick with a very narrow scope and leverage automation for greater efficiency. A mid-sized organization can see immediate benefits in a matter of weeks to months, and usually finish a comprehensive review (including all endpoints) within a year or less.

Discover: The Process

Before we get into the process, be aware that your job will be infinitely harder if you don't have a reasonably up to date directory infrastructure. If you can't figure out your users, groups, and roles, it will be much harder to identify misuse of data or build enforcement policies. Take the time to clean up your directory before you start scanning and filtering for content. Also, the odds are very high that you will find something that requires disciplinary action. Make sure you have a process in place to handle policy violations, and work with HR and Legal before you start finding things that will get someone fired (trust me, those odds are pretty darn high).

You have a couple choices for where to start -- depending on your goals, you can begin with applications/databases, storage repositories (including endpoints), or the network. If you are dealing with something like PCI, stored data is usually the best place to start, since avoiding unencrypted card numbers on storage is an explicit requirement. For HIPAA, you might want to start on the network since most of the violations in organizations I talk to relate to policy violations over email/web/FTP due to bad business processes. For each area, here's how you do it:

• Storage and Endpoints: Unless you have a heck of a lot of bodies, you will need a Data Loss Prevention tool with content discovery capabilities (I mention a few alternatives in the Tools section, but DLP is your best choice). Build a policy based on the content definition you built in the first phase. Remember, stick to a single data/content type to start. Unless you are in a smaller organization and plan on scanning everything, you need to identify your initial target range -- typically major repositories or endpoints grouped by business unit. Don't pick something too broad or you might end up with too many results to do anything with. Also, you'll need some sort of access to the server -- either by installing an agent or through access to a file share. Once you get your first results, tune your policy as needed and start expanding your scope to scan more systems.
• Network: Again, a DLP tool is your friend here, although unlike with content discovery you have more options to leverage other tools for some sort of basic analysis. They won't be nearly as effective, and I really suggest using the right tool for the job. Put your network tool in monitoring mode and build a policy to generate alerts using the same data definition we talked about when scanning storage. You might focus on just a few key channels to start -- such as email, web, and FTP; with a narrow IP range/subnet if you are in a larger organization. This will give you a good idea of how your data is being used, identify some bad business process (like unencrypted FTP to a partner), and which users or departments are the worst abusers. Based on your initial results you'll tune your policy as needed. Right now our goal is to figure out where we have problems -- we will get to fixing them in a different phase.
• Applications & Databases: Your goal is to determine which applications and databases have sensitive data, and you have a few different approaches to choose from. This is the part of the process where a manual effort can be somewhat effective, although it's not as comprehensive as using automated tools. Simply reach out to different business units, especially the application support and database management teams, to create an inventory. Don't ask them which systems have sensitive data, ask them for an inventory of all systems. The odds are very high your data is stored in places you don't expect, so to check these systems perform a flat file dump and scan the output with a pattern matching tool. If you have the budget, I suggest using a database discovery tool -- preferably one with built in content discovery (there aren't many on the market, as we'll mention in the Tools section). Depending on the tool you use, it will either sniff the network for database connections and then identify those systems, or scan based on IP ranges. If the tool includes content discovery, you'll usually give it some level of administrative access to scan the internal database structures.

I just presented a lot of options, but remember we are taking the pragmatic approach. I don't expect you to try all this at once -- pick one area, with a narrow scope, knowing you will expand later. Focus on wherever you think you might have the greatest initial impact, or where you have known problems. I'm not an idealist -- some of this is hard work and takes time, but it isn't an endless process and you will have a positive impact.

We aren't necessarily done once we figure out where the data is -- for approved repositories, I really recommend you also re-check their security. Run at least a basic vulnerability scan, and for bigger repositories I recommend a focused penetration test. (Of course, if you already know it's insecure you probably don't need to beat the dead horse with another check). Later, in the Secure phase, we'll need to lock down the approved repositories so it's important to know which security holes to plug.

Discover: Technologies

Unlike the Define phase, here we have a plethora of options. I'll break this into two parts: recommended tools that are best for the job, and ancillary tools in case you don't have a budget for anything new. Since we're focused on the process in this series, I'll skip definitions and descriptions of the technologies, most of which you can find in our Research Library

Recommended Tools

1. Data Loss Prevention (DLP): This is the best tool for storage, network, and endpoint discovery. Nothing else is nearly as effective.
2. Database Discovery: While there are only a few tools on the market, they are extremely helpful for finding all the unexpected databases that tend to be floating around most organizations. Some offer content discovery, but it's usually limited to regular expressions/keywords (which is often totally fine for looking within a database).
3. Database Activity Monitoring (DAM): A couple of the tools include content discovery (some also include database discovery). I only recommend DAM in the discover phase if you also intend on using it later for database monitoring -- otherwise it's not the right investment.

Ancillary Tools

1. IDS/IPS/Deep Packet Inspection: There are a bunch of different deep packet inspection network tools -- including UTM, Web Application Firewalls, and web gateways -- that now include basic regular expression pattern matching for "poor man's" DLP functionality. They only help with data that fits a pattern, they don't include any workflow, and they usually have a ton of false positives. If the tool can't crack open file attachments/transfers it probably won't be very helpful.
2. Electronic Discovery, Search, and Data Classification: Most of these tools perform some level of pattern matching or indexing that can help with discovery. They tend to have much higher false positive rates than DLP (and usually cost more if you're buying new), but if you already have one and budgets are tight they can help.
3. Email Security Gateways: Most of the email security gateways on the market can scan for content, but they are obviously limited to only email, and aren't necessarily well suited to the discovery process.
4. FOSS Discovery Tools: There are a couple of free/open source content discovery tools, mostly projects from higher education institutions that built their own tools to weed out improper use of Social Security numbers due to a regulatory change a few years back.

Discover: Case Study

Frank from Billy Bob's Bait Shop and Sushi Outlet decides to use a DLP tool to help figure out where any unencrypted credit card numbers might be stored. He decides to go with a full suite DLP tool since he knows he needs to scan his network, storage, servers in the retail outlets, and employee systems.

Before turning on the tool, he contacts Legal and HR to set up a process in case they find any employees illegally using these numbers, as opposed to the accidental or business-process leaks he also expects to manage. Although his directory servers are a little messy due to all the short-term employees endemic to retail operations, he's confident his core Active Directory server is relatively up to date, especially where systems/servers are concerned.

Since he's using a DLP tool, he develops a three-tier policy to base his discovery scans on:

1. Using the one database with stored unencrypted numbers, he creates a database fingerprinting policy to alert on exact matches from that database (his DLP tool uses hashes, not the original values, so it isn't creating a new security exposure). These are critical alerts.
2. His next policy uses database fingerprints of all customer names from the customer database, combined with a regular expression for generic credit card numbers. If a customer name appears with something that matches a credit card number (based on the regex pattern) it generates a medium alert.
3. His lowest priority policy uses the default "PCI" category built into his DLP tool, which is predominantly basic pattern matching.

He breaks his project down into three phases, to run during overlapping periods:

1. Using those three policies, he turns on network monitoring for email, web, and FTP.
2. He begins scanning his storage repositories, starting in the data center. Once he finishes those, he will expand the scans into systems in the retail outlets. He expects his data center scan to go relatively quickly, but is planning on 6-12 months to cover the retail outlets.
3. He is testing endpoint discovery in the lab, but since their workstation management is a bit messy he isn't planning on trying to install agents and beginning scans until the second year of the project.

It took Frank about two months to coordinate with other business/IT units before starting the project. Installing DLP on the network only took a few hours because everything ran through one main gateway, and he wasn't worried about installing any proxy/blocking technology.

Frank immediately saw network results, and found one serious business process problem where unencrypted numbers were included in files being FTPed to a business partner. The rest of his incidents involved individual accidents, and for the most part they weren't losing credit card numbers over the monitored channels.

The content discovery portion took a bit longer since there wasn't a consistent administrative account he could use to access and scan all the servers. Even though they are a relatively small operation, it took about 2 months of full time scanning to get through the data center due to all the manual coordination involved. They found a large number of old spreadsheets with credit card numbers in various directories, and a few in flat files -- especially database dumps from development.

The retail outlets actually took less time than he expected. Most of the servers, except at the largest regional locations, were remotely managed and well inventoried. He found that 20% of them were running on an older credit card transaction system that stored unencrypted credit card numbers.

Remember, this is a 1,000 person organization... if you work someplace with five or ten times the employees and infrastructure, your process will take longer. Don't assume it will take five or ten times longer, though -- it all depends on scope, infrastructure, and a variety of other factors.

–Rich

The Network Forensics (Full Packet Capture) Revival Tour

By Rich

I hate to admit that of all the various technology areas, I'm probably best known for my work covering DLP. What few people know is that I 'fell' into DLP, as one of my first analyst assignments at Gartner was network forensics. Yep -- the good old fashioned "network VCRs" as we liked to call them in those pre-TiVo days.

My assessment at the time was that network forensics tools like Niksun, Infinistream, and Silent Runner were interesting, but really only viable in certain niche organizations. These vendors usually had a couple of really big clients, but were never able to grow adoption to the broader market. The early DLP tools were sort of lumped into this monitoring category, which is how I first started covering them (long before the term DLP was in use).

Full packet capture devices haven't really done that well since my early analysis. SilentRunner and Infinistream both bounced around various acquisitions and re-spin-offs, and some even tried to rebrand themselves as something like DLP. Many organizations decided to rely on IDS as their primary network forensics tool, mostly because they already had the devices. We also saw Network Behavior Analysis, SIEM, and deep packet inspection firewalls offer some of the value of full capture, but focused more on analysis to provide actionable information to operations teams. This offered a clearer value proposition than capturing all your network data just to hold onto it.

Now the timing might be right to see full capture make a comeback, for a few reasons. Mike mentioned full packet capture in Low Hanging Fruit: Network Security, and underscored the need to figure out how to deal with these new more subtle and targeted attacks. Full packet capture is one of the only ways we can prove some of these intrusions even happened, given the patience and skills of the attackers and their ability to prey on the gaps in existing SIEM and IPS tools. Second, the barriers between inside and outside aren't nearly as clean as they were 5+ years ago; especially once the bad guys get their initial foothold inside our 'walls'. Where we once were able to focus on gateway and perimeter monitoring, we now need ever greater ability to track internal traffic.

Additionally, given the increase in processing power (thank you, Moore!), improvement in algorithms, and decreasing price of storage, we can actually leverage the value of the full captured stream. Finally, the packet capture tools are also playing better with existing enterprise capabilities. For instance, SIEM tools can analyze content from the capture tool, using the packet captures as a secondary source if a behavioral analysis tool, DLP, or even a ping off a server's firewall from another internal system kicks off an investigation. This dramatically improves the value proposition.

I'm not claiming that every organization needs, or has sufficient resources to take advantage of, full packet capture network forensics -- especially those on the smaller side. Realistically, even large organizations only have a select few segments (with critical/sensitive data) where full packet capture would make sense. But driven by APT hype, I highly suspect we'll see adoption start to rise again, and a ton of parallel technologies vendors starting to market tools such as NBA and network monitoring in the space.

–Rich

The State of Web Application and Data Security—Mid 2009

By Rich

One of the more difficult aspects of the analyst gig is sorting through all the information you get, and isolating out any inherent biases. The kinds of inquiries we get from clients can all too easily skew our perceptions of the industry, since people tend to come to us for specific reasons, and those reasons don't necessarily represent the mean of the industry. Aside from all the vendor updates (and customer references), our end user conversations usually involve helping someone with a specific problem -- ranging from vendor selection, to basic technology education, to strategy development/problem solving. People call us when they need help, not when things are running well, so it's all too easy to assume a particular technology is being used more widely than it really is, or a problem is bigger or smaller than it really is, because everyone calling us is asking about it. Countering this takes a lot of outreach to find out what people are really doing even when they aren't calling us.

Over the past few weeks I've had a series of opportunities to work with end users outside the context of normal inbound inquiries, and it's been fairly enlightening. These included direct client calls, executive roundtables such as one I participated in recently with IANS (with a mix from Fortune 50 to mid-size enterprises), and some outreach on our part. They reinforced some of what we've been thinking, while breaking other assumptions. I thought it would be good to compile these together into a "state of the industry" summary. Since I spend most of my time focused on web application and data security, I'll only cover those areas:

When it comes to web application and data security, if there isn't a compliance requirement, there isn't budget -- Nearly all of the security professionals we've spoken with recognize the importance of web application and data security, but they consistently tell us that unless there is a compliance requirement it's very difficult for them to get budget. That's not to say it's impossible, but non-compliance projects (however important) are way down the priority list in most organizations. In a room of a dozen high-level security managers of (mostly) large enterprises, they all reinforced that compliance drove nearly all of their new projects, and there was little support for non-compliance-related web application or data security initiatives. I doubt this surprises any of you.

"Compliance" may mean more than compliance -- Activities that are positioned as helping with compliance, even if they aren't a direct requirement, are more likely to gain funding. This is especially true for projects that could reduce compliance costs. They will have a longer approval cycle, often 9 months or so, compared to the 3-6 months for directly-required compliance activities. Initiatives directly tied to limiting potential data breach notifications are the most cited driver. Two technology examples are full disk encryption and portable device control.

PCI is the single biggest compliance driver for web application and data security -- I may not be thrilled with PCI, but it's driving more web application and data security improvements than anything else.

The term Data Loss Prevention has lost meaning -- I discussed this in a post last week. Even those who have gone through a DLP tool selection process often use the term to encompass more than the narrow definition we prefer.

It's easier to get resources to do some things manually than to buy a tool -- Although tools would be much more efficient and effective for some projects, in terms of costs and results, manual projects using existing resources are easier to get approval for. As one manager put it, "I already have the bodies, and I won't get any more money for new tools." The most common example cited was content discovery (we'll talk more about this a few points down).

Most people use DLP for network (primarily email) monitoring, not content discovery or endpoint protection -- Even though we tend to think discovery offers equal or greater value, most organizations with DLP use it for network monitoring.

Interest in content discovery, especially DLP-based, is high, but resources are hard to get for discovery projects -- Most security managers I talk with are very interested in content discovery, but they are less educated on the options and don't have the resources. They tell me that finding the data is the easy part -- getting resources to do anything about it is the limiting factor.

The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client -- While it's hard to fully quantify, we think the source code tools cost more per implementation, but WAFs are in slightly wider use.

WAFs are a quicker hit for PCI compliance -- Most organizations deploying WAFs do so for PCI compliance, and they're seen as a quicker fix than secure source code projects.

Most WAF deployments are out of band, and false positives are a major problem for default deployments -- Customers are installing WAFs for compliance, but are generally unable to deploy them inline (initially) due to the tuning requirements.

Full drive encryption is mature, and well deployed in the early mainstream -- Full drive encryption, while not perfect, is deployable in even large enterprises. It's now considered a level-setting best practice in financial services, and usage is growing in healthcare and insurance. Other asset recovery options, such as remote data destruction and phone home applications, are now seen as little more than snake oil. As one CISO told us, "I don't care about the laptop, we just encrypt it and don't worry about it when it goes missing".

File and folder encryption is not in wide use -- Very few organizations are performing any wide scale file/folder encryption, outside of some targeted encryption of PII for compliance requirements.

Database encryption is hard, and not widely used -- Most organizations are dissatisfied with database encryption options, and do not deploy it widely. Within a large organization there is likely some DB encryption, with preference given to file/folder/media protection over column level encryption, but most organizations prefer to avoid it. Performance and key management are cited as the primary obstacles, even when using native tools. Current versions of database encryption (primarily native encryption) do perform better than older versions, but key management is still unsatisfactory. Large encryption projects, when initiated, take an average of 12-18 months.

Large enterprises prefer application-level encryption of credit card numbers, and tokenization -- When it comes to credit card numbers, security managers prefer to encrypt it at the application level, or consolidate numbers into a central source, using representative "tokens" throughout the rest of the application stack. These projects take a minimum of 12-18 months, similar to database encryption projects (the two are often tied together, with encryption used in the source database).

Email encryption and DRM tend to be workgroup-specific deployments -- Email encryption and DRM use is scattered throughout the industry, but is still generally limited to workgroup-level projects due to the complexity of management, or lack of demand/compliance from users.

Database Activity Monitoring usage continues to grow slowly, mostly for compliance, but not quickly enough to save lagging vendors -- Many DAM deployments are still tied to SOX auditing, and it's not as widely used for other data security initiatives. Performance is reasonable when you can use endpoint agents, which some DBAs still resist. Network monitoring is not seen as effective, but may still be used when local monitoring isn't an option. Network requirements, depending on the tool, may also inhibit deployments.

My main takeaway is that security managers know what they need to do to protect information assets, but they lack the time, resources, and management support for many initiatives. There is also broad dissatisfaction with security tools and vendors in general, in large part due to poor expectation setting during the sales process, and deliberately confusing marketing. It's not that the tools don't work, but that they're never quite as easy as promised.

It's an interesting dilemma, since there is clear and broad recognition that data security (and by extension, web application security) is likely our most pressing overall issue in terms of security, but due to a variety of factors (many of which we covered in our Business Justification for Data Security paper), the resources just aren't there to really tackle it head-on.

–Rich

Is the Term “DLP” Finally Meaningless?

By Rich

As most of you know, I've been covering DLP for entirely too long. It's a major area of our research, with an entire section of our site dedicated to it.

To be honest, I never really liked the term "Data Loss Prevention". When this category first appeared, I used the term Content Monitoring and Filtering. The vendors didn't like it, but since I wrote (with a colleague) the Gartner Magic Quadrant, they sort of rolled with it. The vendors preferred DLP since it sounded better for marketing purposes (I have to admit, it's sexier than CMF). Once market momentum took over and end users started using DLP more than CMF, I rolled with it and followed the group consensus.

I never liked Data Loss Prevention since, in my mind, it could mean pretty much anything that "prevents data loss". Which is, for the most part, any security tool on the market. My choice was to either jump on the DLP bandwagon, or stick to my guns and use CMF, even though no one would know what I was talking about. Thus I transitioned over, started using DLP, and focused my efforts on providing clear definitions and advice related to the technology.

Over the past 2 weeks I've come to realize that DLP, as a term for a specific category of technology, is pretty much dead. I've been invited to multiple DLP conferences/speaking opportunities, none of which are focused on what I'd consider DLP tools. I've been asked to help work on DLP training materials that don't even have a chapter on DLP tools. I've had multiple end-user conversations on DLP... almost always referring to a different technology.

The DLP vendors did such a good job of coming up with a sexy name for their technology that the rest of the world decided to use it... even when they had nothing to do with DLP. Thus, any vendor reading this can consider this post my official recommendation that you drop the term DLP, and move to Content Monitoring and Protection (CMP -- a term Chris Hoff first suggested that I've glommed onto). Or just make something else up.

I'll continue using DLP on this site, but the non-DLP vendors have won and the term is completely diluted and no longer refers to a specific technology. Thus I'll stop being incredibly anal about it, and you might see me associated with "DLP" when it has nothing to do with pure-play DLP as I've historically defined it.

That said, when I'm writing about it I still intend to use the term DLP in my personal writing in accordance with my very specific definition (below), and will start using 'CMP' more heavily.

Data Loss Prevention/Content Monitoring and Protection is:

Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis.

For the record, I get all uppity about mangled definitions because all too often they're used to create market confusion, and reduce value to users. People end up buying things that don't do what they expected.

–Rich

The Pragmatic Data (Information-Centric) Security Cycle

By Rich

Way back when I started Securosis, I came up with something called the Data Security Lifecycle, which I later renamed the Information-Centric Security Cycle. While I think it does a good job of capturing all the components of data security, it's also somewhat dense. That lifecycle was designed to be a comprehensive outline of protective controls and information management, but I've since realized that if you have a specific data security problem, it isn't the best place to start.

In a couple weeks I'll be speaking at the TechTarget Financial Information Security Decisions conference in New York, where I'm presenting Pragmatic Data Security. By "pragmatic" I mean something you can implement as soon as you get home. Where the lifecycle answers the question, "How can I secure all my data throughout its entire lifecycle?" pragmatic data security answers, "How can I protect this specific data at this point in time, in my existing environment?"

It starts with a slimmed down cycle:

1. Define what information you want to protect (specifically, not general data classification)
2. Discover where it's located (various tools/techniques, preferably automated, like DLP, rather than manual)
3. Secure the data where it's stored, and/or eliminate data where it shouldn't be (access controls, encryption)
4. Monitor data usage (various tools, including DLP, DAM, logs, SIEM)
5. Protect the data from exfiltration (DLP, USB control, email security, web gateways, etc.)

For example, if you want to protect credit card numbers you'd define them in step 1, use DLP content discovery in step 2 to locate where they are stored, remove it or lock the repositories down in step 3, use DAM and DLP to monitor where they're going in step 4, and use blocking technologies to keep them from leaving the organization in step 5.

All too often I'm seeing people get totally wrapped up in complex "boil the ocean" projects that never go anywhere, vs. defining and solving a specific problem. You don't need to start your entire data security program with some massive data classification program. Pick one defined type of data/information, and just go protect it. Find it, lock it down, watch how it's being used, and stop it from going where you don't want.

Yeah, parts are hard, but hard != impossible. If you keep your focus, any hard problem is just a series of smaller, defined steps.

–Rich

Security Inevitabilities

By Rich

Despite my intensive research into cryonics, I have to accept that someday I will die. Permanently. I don't know when, where, or how, but someday I will cease to exist. Heck, even if I do manage to freeze myself (did you know one of the biggest cryonincs companies is only 20 minutes from my house?), get resurrected into a cloned 20-year-old version of myself, and eventually upload my consciousness into a supercomputer (so I can play Skynet, since I don't really like most people) I have to accept that someday Mother Entropy will bitch slap me with the end of the universe.

There are many inevitabilities in life, and it's often far easier to recognize these end results than the exact path that leads us to them. Denial is often closely tied to the obscurity of these journeys; when you can't see how to get from point A to point B (or from Alice to Bob, for you security geeks), it's all too easy to pretend that Bob Can't Ever Happen. Thus we find ourselves debating the minutiae, since the result is too far off to comprehend.

(Note that I'd like credit for not going deep into an analogy about Bob and Alice inevitably making Charlie after a few too many mojitos).

Security includes no shortage of inevitabilities. Below are just a few that have been circling my brain lately, in no particular order. It's not a comprehensive list, just a few things that come to mind (and please add your own in the comments). I may not know when they'll happen, or how, but they will happen:

• Everyone will use some form of NAC on their networks.
• Despite PCI, we will move off credit card numbers to a more secure transaction system. It may not be chip and PIN, but it definitely won't be magnetic strips.
• Everyone will use some form of DLP, we'll call it CMP, and it will only include tools with real content analysis.
• Log management and SIEM will converge into single products. Completely.
• UTM will rule the day on the perimeter, and we won't buy separate boxes for every function anymore.
• Virtualization and information-centric security will totally fuck up network security, especially internally.
• Any critical SCADA network will be pulled off the Internet.
• Database encryption will be performed inside the database with native functionality, with keys managed externally.
• The WAF vs. secure development debate will end as everyone buys/implements both.
• We'll stop pretending web application and database security are different problems.
• We will encrypt all laptops. It will be built into the hardware.
• Signature AV will die. Mostly.
• Chris Hoff will break the cloud.

–Rich

Friday Summary: April 10, 2009

By Rich

–Rich

Is There Any DLP or Data Security On Mac/Linux?

By Rich

Had a very interesting call today with a client in the pharma research space. They would like to protect clinical study data as it moves to researcher's computers, but are struggling with the best approach. On the call, I quickly realized that DLP, or a content tracking tool like Verdasys (who also does endpoint DLP) would be ideal. The only problem? They need Windows, Mac, and Linux support.

I couldn't remember offhand of any DLP/tracking tool (or even DRM) that will work on all 3 platforms. This is an open call for you vendors to hit me up if you can help.

For you end users, where we ended up was with a few potential approaches:

1. Switch to a remote virtual/hosted desktop for handling the sensitive data... such as Citrix or VMWare.
2. Use Database Activity Monitoring to track who pulls the data.
3. Endpoint encryption to protect the data from loss, but it won't help when it's moved to inappropriate locations.
4. Network DLP to track it in email, but without the endpoint coverage it leaves a really big hole.
5. Content discovery to keep some minimal tracking where it ends up (for managed systems), but that means opening up SMB/CIFS file sharing on the endpoint for admin access, which is in itself a security risk.
6. Distributed encryption, which *does* have cross platform support, but still doesn't stop the researcher from putting the data someplace it shouldn't be, which is their main concern.

While this is one of those industries (research) with higher Mac/cross platform use than the average business, this is clearly a growing problem thanks to the consumerization of IT.

This situation also highlights how no single-channel solution can really protect data well. It's the mix of network, endpoint, and discovery that really allows you to reduce risk without killing business process.

–Rich

Do You Use DLP? We Should Talk

By Rich

As an analyst, I've been covering DLP since before there was anything called DLP. I like to joke that I've talked with more people that have evaluated and deployed DLP than anyone else on the face of the planet. Yes, it's exactly as exciting as it sounds.

But all those references were fairly self-selected. They've either been Gartner clients, or our current enterprise clients, that were/are typically looking for help in product selection or dealing with some sort of problem. Many of the rest are vendor-supplied references. This combination skews the conversations towards people picking products, people with problems, or those a vendor think will make them look good.

I'm currently working on an article for Information Security magazine on "Real-World DLP", and I'm hunting for some new references to expand that field a bit. If you are using DLP, successfully or not, and are willing to talk confidentially, please drop me a line. I'm looking for real-world stories, good and bad. If you are willing to go on the record, we're also looking for good quote sources. The focus of the article is more on implementation than selection, and will be vendor-neutral.

To be honest, one reason I'm putting this out in the open is to see if my normal reference channels are skewed. It's time to see how our current positions and assumptions play out on the mean streets of reality.

Of course I'll be totally pissed if I've been wrong this entire time and have to retract everything I've ever written on DLP.

**Update - Oh yeah, my email address is rmogull, that is with two 'L's, at securosis dot com. Please let me know.

–Rich