A Special Analysis For Dark Reading
Second of Two Articles

Thwarting an attacker's attempts to exploit the metadata easily found on your company's Website, in digital documents, and in search-engine caches is hard, if not nearly impossible. The very act of sending out an Office document via e-mail, or posting an image on the Web, can give an intruder all the information he needs to attack you or your company.

Metadata is user names, path and system information (like directories on your hard drive or network share), software versions, and more. This data can be used for a brute-force attack, social engineering, or finding pockets of critical data once inside a compromised network.

In the first article of this series, we looked at how metadata can be used against you. Now we're going to examine some tips for preventing metadata from leaking out of your organization.

Step 1: The first step to preventing potentially damaging metadata leakage is all about user awareness. Educating users on the nature of the data that can be inadvertently leaked via features like "Track Changes" in Microsoft Word is important, but showing them examples of public leakages and attack scenarios is more likely to open their eyes. The simple act of spidering a site, developing a word list based on the content, and then cracking passwords to accounts pulled from the metadata is one way you can illustrate the dangers of metadata leakage.

Step 2: The second step is to create policies that go hand-in-hand with awareness. Simply knowing a risk exists is fine, but understanding that a corporate policy was created to protect metadata from leaking out of the organization will ensure users adopt and adhere to it. Policies should address the management of metadata -- what is considered sensitive and whether files should be scrubbed before being sent out.

Step 3: The third step is to provide mechanisms for employees to follow the policies. Whether on the enterprise or personal level, these mechanisms need to be easy for users and, preferably, as transparent as possible. Leaving the responsibility solely to users -- with a manual process using the document's native application, for instance -- will likely prove to be an effort in futility and lead to accidental exposures.

One possible approach is covered in Larry Pesce's "Document Metadata, The Silent Killer". Pesce recommends creating separate storage locations for sanitized and unsanitized documents. The rationale behind this is simple: It helps users know which files have been scrubbed and can be sent out.

The caveat to that is determining who is responsible for cleaning the documents, and ensuring that person keeps abreast of new document versions so that the latest version is available in the sanitized repository.

A more foolproof approach is to implement a data leakage prevention (DLP) type of solution. Just like DLP, options vary from host-based to network-based tools. Some products hook directly into the user's e-mail application and scrub documents before they're sent out. Examples of these products include Esquire Innovations' iScrub and Unedged Software's Send Shield.

Network-based solutions, like Workshare Protect Network, are much more transparent; they're really just DLP products that can scrub metadata, in addition to standard DLP capabilities (monitoring, alerting, and reporting). They sit at the network gateway, monitoring for policy violations, and scrub the documents in transit, taking the guesswork out of whether the user had done so.

Bottom line: Ask yourself what threat the information found in your metadata poses to your organization, and perform a risk analysis to measure how damaging that information would be if it became publicly available. That will determine whether a case should be made for implementing a solution that prevents metadata from leaking out of your organization.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message