Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=222002549
Data thieves target intellectual property, credit card data, and your customers' personally identifiable information. Data loss prevention products aim to identify where such information resides in your organization, and help prevent it from falling into the wrong hands. When used properly, DLP technology can be a critical part of a risk management program. But there's an ugly truth that DLP vendors don't like to talk about: Managing DLP on a large scale can drag your staff under like a concrete block tied to their ankles.
Don't believe us? Consider how far and wide a comprehensive data loss product extends its reach through your organization. User end points must run (and you must support) a new agent. E-mail and network communications will be scanned for content, and data repositories, such as file shares, databases, and PCs, will be interrogated for violations. All this technology requires policies tailored to your environment and level of risk tolerance.
And regardless of how automated you make it, DLP systems will set off alarms. The end result is more work for your administrators.
How much more work? The answer depends on the size of your organization and the level of deployment, but we've identified four areas where DLP technology will make demands on your resources.
Before you fire off your first scan to see just how much sensitive data is floating around the network, you'll need to create the policies that define appropriate use of corporate information. Some policies are fairly obvious--there's no good business reason for an employee to upload a spreadsheet full of Social Security numbers to his Facebook profile. But other policies will have to go through some contortions to accommodate workflows. For example, you may generally forbid employees from e-mailing customer information outside the organization--except for five people in one business unit who have to send records to seven employees at a business partner, but only on the last Friday of every month and never without sign-off from at least three lawyers from in-house counsel.
Out of the box, most DLP systems come with pre-built policies, especially for regulations such as PCI and HIPAA. However, you'll most likely need to build new policies or customize existing ones to meet your particular security needs, risk profile, and regulatory landscape. While many DLP vendors provide graphical, wizard-driven tools for this process, creating and tweaking policies is rarely a point-and-click exercise.
And once you have a set of policies written, it's unlikely they'll go unchanged for long. New compliance mandates may arise, new kinds of information will need to be protected, and new business practices may emerge. As a result, it's important to continually update your policies to ensure that they match all the requirements you have to meet for protecting sensitive data.
Once your policies are in order, the next step is data discovery, because to properly protect your data, you must first know where it is. In midsize to large environments, you'll have at least one appliance dedicated to data discovery and content analysis. In addition, if you need to scan massive amounts of data in parallel for information that violates your appropriate use policy, you'll need to deploy additional servers for scanning. Fortunately, many top-tier systems now support scanning huge data stores with grid technology, but the fact remains that if you have many terabytes of data that you need to scan on an ongoing basis, then you're going to have to manage more servers to do it.
Then there's the issue of accuracy. Consider the challenge of identifying a simple credit card number. That number could be stored in many different formats, and it could contain variations of numbers mixed with spaces, hyphens, or other characters. Because the DLP appliance can't determine context, you'll need to programmatically describe exactly what data you're looking for, and account for all of the different formats. Often you can do this graphically using easy-to-construct Boolean logic, but sometimes you'll need a scripting language like Perl to develop advanced data description policies.
Be prepared to test the data identification capabilities you've enabled. The last thing you want is to wade through a boatload of false-positive alerts every morning because of a paranoid signature set. You also want to make sure that critical information isn't flying right past your DLP scanners because of a lax signature set. This is particularly important if you plan to use DLP technology for unstructured information, such as sensitive documents, diagrams, or source code. Also note that your signature database is going to grow and will have to be managed.
In some cases, your DLP products will need to integrate with other security systems. In particular, many network-based DLP products must work with third-party ICAP proxies to prevent sensitive information from leaking out via communication channels such as HTTP/S, FTP, and IM.
Another likely integration area involves encrypted e-mail. For instance, if your company handles the personally identifiable information of a Massachusetts resident, as of March 1, 2010, you're subject to the new Massachusetts Data Privacy Law (CMR-201). Among the requirements of this new legislation is the rule to encrypt any personally identifiable information that must traverse the public Internet during the course of business. With a fine of $5,000 per customer record exposed or lost, this privacy law puts a significant price tag on even a small number of exposed records.
If your business practices require you to e-mail personally identifiable information within your organization, as well as to third parties or business partners, you might need to have your DLP appliance to forward e-mail to an encryption appliance. Unfortunately, not only have you just introduced another two hops into your e-mail routing process, but you've also introduced products from two separate vendors that you must now configure, manage, and troubleshoot. The same issues often apply on the end point, where organizations may run DLP as well as software that can encrypt files, folders, or the entire hard drive.
As mentioned earlier, network-based DLP technology can log and deny data transfers or communications that violate policy. However, as with intrusion-detection systems, not all actions can be automated, and network-based DLP will generate events that must be investigated and adjudicated by humans. The more aggressively you set your protection parameters, the more time administrators will spend reviewing events to decide which communications can proceed and which should be blocked.
In addition to administrators, your help desk staff may also see an uptick in calls because your employees are used to doing whatever they want with company data--attaching Excel files to Web mail accounts to download to a home laptop, saving loads of customer records to a USB drive, and so on.
If you're deploying DLP technology that prevents such behavior, be prepared to field complaints.
The range of features and reporting that you get from a robust DLP suite is impressive, and can be a critical part of a risk management strategy. But don't expect your DLP products to run themselves. Be sure your IT and security operations teams understand what they're getting into with a DLP rollout, and that sufficient resources, both human and financial, can be committed to ongoing maintenance. DLP must be managed consistently to minimize the burden on employees while ensuring solid security. Finding that balance requires work, but the benefits outweigh the drawbacks.