Review: Top tools for preventing data leaks

Previous 1 2 Page 2

Users are also going to want to, most likely, identify specific columns within the protected data spreadsheets that will be the focus of the rules created later. There is no need to protect something like the first name fields of customers or patients, for example. Specifying the column data within those servers can help to reduce the time it takes to scan everything, though even with thousands of records, the registration process should only take a few minutes and then a few minutes each day as the DLP appliance checks to see if any new data has been added to those fields. The data itself isn’t stored on the DLP, just a hashed version of it so that the appliance itself does not become a liability.

Registering the data to be protected doesn’t actually do anything on its own. Once the DLP knows all the possible data it’s protecting, it’s time to go in and configure what uses are allowed and which should be blocked, quarantined or encrypted before being sent out.

We used a store of patient names and Social Security numbers contained within several spreadsheets. Our first rule stated that anytime five or more Social Security numbers attempted to be sent out of the network along with the last name of the accompanying patient, that the DLP was to block the transmission and alert the proper personnel.

Users could be warned about the actions that were being taken or left in the dark that anything suspicious was happening. That way we could set it up so users could be trained as to good DLP practices in some cases, or examined secretly if we suspected that, for example, a true insider was working against the host organization.

To test our new rule, we went in and grabbed 10 Social Security numbers along with 10 last names from different patients. In this scenario, the names and the Social Security numbers did not match on any of the protected spreadsheets. When we tried to send Webmail with that information, nothing was blocked, which was the correct action based on our rules. When we similarly tried to send out information using instant messaging that contained several made up Social Security numbers which were not in the spreadsheets at all, but which were obviously within Social Security numbers format, they also got through.

Only when we matched last names from the same line with Social Security numbers did our transmissions get blocked. And they were blocked despite anything we tried to do to obfuscate the relationship like putting the numbers randomly throughout a multi-page document that was nowhere near the corresponding last name.

We also got blocked when we used the Social Security numbers but retyped the last names in caps instead of cutting and pasting them into place. When we changed the fonts to something nonsensical like Wingdings, the Digital Guardian appliance still knew what we were doing and locked everything down. In fact, we even changed the extension of the file we were trying to send so that it was simply displayed in Unicode and then zipped that. But nothing we did could get around the ruleset for the DLP.

The final tweak is data tagging for true precision. Data tagging is conducted after the main rules are in place to create or modify exceptions. This is probably the most complicated thing to do within the otherwise easy to use interface, but might be necessary if something like phone numbers are triggering false positives. The data tagging is like an “if-then” statement.

Even if a rule trips, the DLP will check the data tags and if the protected IP matches a seven-digit phone number format, it will allow the communication through because it’s likely just a phone number and not a protected account within the database.

One thing to consider is that with such tightly controlled rules, it might be possible for someone to smuggle data out of an organization by keeping under the radar. In our test they could, for example, send out the information in groups of four, or send the SSNs by themselves and then send the last names at a later time. It’s one possible danger about having those types of rules in place to eliminate almost all of the false positives. Then again, the alternative for organizations with very large datasets would be to live with seemingly unending false positives every time a number or a name happened to match some type of communication across the entire enterprise. Many people’s names are also real words, like Iris, Love and Strong, while others, like Kraft or Kellogg, are companies, which could trigger problems without those safeguards.

Someone attempting to thwart the rules by keeping under the false positive threshold would need to know exactly what rules were in place. That’s highly unlikely to happen, but something to keep in mind when setting up the rules based on the balance between total security and comfort with false positives.

The Digital Guardian appliance can take several different actions once a rule has been tripped. These actions can be modified by almost any factor a user wants, like the type of data, the size of the alleged breach, the source or destination or almost anything else. Specifically, it can log, allow, prompt, quarantine, encrypt or block communications that trigger rule breaks.

For most of our testing, we used either the block or quarantine actions. Blocking is just what it sounds like; the communication is stopped. Users can then either be told what rule they broke so they can learn what they did wrong, or be kept in the dark and investigated. Quarantine is interesting because it blocks the communication temporarily, but moves it into an area where an administrator is able to see what the user was trying to accomplish. It can then later be permanently blocked or allowed to pass, which is good if an organization needs a second set of eyes on sensitive communications.

The encryption feature is somewhat unique to Digital Guardian. It can be used when, for example, employees need to send sensitive data outside of a network for partners or contractors to work with, but which should not be seen by unauthorized eyes or intercepted in transit. For data flagged that way, the Digital Guardian appliance will automatically encrypt that data and let the user know about it by default. While Digital Guardian has no native encryption, it works with many third-party programs and can even be set up to send jobs to an encryption appliance should one exist within the enterprise.

The Digital Guardian appliance is geared toward installations where very large or even Big Data sets need to be protected without instantly overloading security teams with too many false positives. It handled everything within its ruleset perfectly in all of our testing, but may require a bit of tweaking at first in order to find that perfect balance, and then further programming with data tagging to eliminate any operational problems that pop up with false positives.

Forcepoint DLP

The Forcepoint DLP protection product was the most mature solution that we reviewed. That isn’t too surprising given that it got its start in 2003 as a regulatory compliance tool. Today Forcepoint is an independent company launched as a joint venture between technology firms, with Raytheon as its majority stakeholder. The Forcepoint DLP product tested is integrated with the Triton APX product line of cybersecurity defense tools which includes Triton AP-Web, AP-Email, AP-Data and AP-Endpoint.

All Triton products share a common architecture and work with the ThreatSeeker Intelligence Cloud to identify and classify network traffic. Technically, any of the products can be installed separately or together within a single appliance, but they are so tightly integrated that it’s difficult to tell where one ends and the next begins. The DLP solution tested here is a module that can be added to either AP-Email or AP-Web, and which comes included with AP-Data. The integrated AP-Data version was the flavor tested.

Installed as an appliance, the DLP component along with the required module in the Data Security Suite is priced at $44.50 per seat for a deployment of 5,000 users. A 10% discount would apply for signing a multi-year contract.

For such a powerful tool, setting up the Forcepoint DLP was incredibly easy. The module comes pre-configured with 1,700 presets for creating data protection and regulatory compliance rules. Federal regulations as well as the individual rules for every state and most countries are included. So if your company does business in Virginia, you can check that state’s box and data protection rules specific to Virginia will be automatically applied as a policy without incorporating the rules of another state which your organization does not touch. And heavily regulated industries like finance and healthcare have many possible rules that can be selected and implemented within their trees. Each can be individually selected, or installed as a group.

The pre-written rules can be examined and modified, though some, like HIPAA in healthcare, are so well defined that doing so would be ill-advised. Still, a user is free to modify the protection offered by the DLP based on specific needs within an organization. Creating entirely new rules can be done manually or using wizards that help users define exactly how they want their protection to act. Creating a complex new rule using the wizard took us less than five minutes.

Rules can be configured with either a narrow or wide scope, and there are generally multiple versions of each type within the presets. If no DLP violations are being triggered, then administrators can choose to change from narrow to wide first before diving into the rule configuration. Likewise, if too many false positives are being discovered, a switch to the narrower definition might be a quick fix that saves time without sacrificing protection.

The Forcepoint DLP works best when agents are installed on all corporate endpoints. Forcepoint was the only product in our test that had a working OS X agent in addition to a 32- and 64-bit Windows version. Creating an agent is easy using a wizard-like interface. It took 30 seconds to make a new one for Windows 64-bit systems in our test network. Then it can be pushed out to network clients using whatever method an organization chooses.

When creating an agent, users specify a name and password which needs to be re-entered to uninstall the program from a host machine. This makes agent removal easy if such a thing is desired for individual machines, and also prevents someone from getting rid of their DLP protection without permission.

In addition to the easy creation of rules using the presets, the Forcepoint DLP can also use fingerprinting for important documents that may not be legally protected, but which are important or even critical to an operation.

Once we had the rules in place and had fingerprinted other documents, we tried to find ways of exfiltration. In every case, even using snippets or retyping data, we got blocked. Forcepoint was even able to stop a protected document from leaving the network after we hid snippets of it inside a .gif picture. Forcepoint was the only program we tested with this feature. We took protected data and placed it inside a photo, figuring that there was no way a machine would be able to recognize that method of data theft. But Forcepoint runs graphical files through an optical character recognition engine and compares the results against the fingerprinted protected data and the general compliance rules. It was able to stop screenshots of protected documents, but also a series of Social Security numbers that we cut and pasted into a photograph.

With endpoint protection in place, administrators on the main console could even control and enforce USB and printing policies at endpoints. One interesting feature is that we could restrict USB drives from copying data, but could also allow that copying to happen under certain circumstances, such as if we were using company-approved USB devices or ones that had native encryption. Our printing rules were also very flexible, allowing us to enable printing at certain machines – such as those located in a secure or monitored location – while preventing protected documents from being sent anywhere else. This level of granular security control was very impressive, and also easy to configure and monitor.

Part of the Forcepoint endpoint protection includes a native encryption engine. So administrators can allow, for example, someone to take certain files home using a USB drive, but only after forcing the files to be encrypted. This encryption can take the form of a password that needs to be entered to look at the document, or session encryption which means that the files can be opened automatically like normal, but only when running on an endpoint that also has a Forcepoint agent installed – basically keeping the data in-house and under control.

Cloud services are not left out either. The Forcepoint DLP works with the professional or corporate versions of Dropbox, Office 365 and OneDrive, allowing an administrator to scan for fingerprinted data or information protected by regulations sitting in those off-site corporate shares.

The Forcepoint DLP module is an incredibly powerful tool. When working in conjunction with the other tools in the Data Security Suite, it can do even more, like coordinating DLP alerts with other security modules to look for patterns that could potentially uncover insider threats.

The only negative aspect is that the Forcepoint DLP module tested here needs to run with another program. So it might not be the right choice for an organization that has mature and robust cybersecurity defenses in place and just needs a standalone DLP solution. However, the Forcepoint DLP is so good that it might be worth it to bring in AP-Email, AP-Web or AP-Data just to get the DLP capabilities.

Breeden is an award-winning reviewer and public speaker with over 20 years of experience. He is currently the CEO of the Tech Writers Bureau, a group of influential journalists and writers who work in government and other circles. He can be reached at jbreeden@techwritersbureau.com.

This story, "Review: Top tools for preventing data leaks" was originally published by Network World.