Video Screencast Help

DLP End-Point Prevent - Content cannot be interrogated

Created: 06 Jul 2011 | 2 comments

We are looking at decreasing our data threat foot-print and are looking at trying to configure an End-point Prevent policy to disallow “copying” or “moving” data that cannot be inspected (password protected, encrypted, unknown file format, etc.).

Has anyone developed a policy that detects or creates incidents when content cannot be interrogated (files, attachments, posts, etc.)?

Discussion Filed Under:

Comments 2 CommentsJump to latest comment

Keith Reynolds - ExchangeTek's picture

Hi John -

I presume you're already aware of the limitation here, which is that while you can use the File Type Match to deteremine whether the file is one of a number of encrypted/non-inspectable formats, it is by no means all inclusive of any encrypted format.  Out of the box, you have as options:

(1) Encrypted Microsoft Word, (2) Encrypted Microsoft Excel, (3) Nero Encrypted File, (4) Password Protected Zip Archive, (5) Encrypted Adobe PDF, (6) Open PGP Message Format, (7) Encrypted Microsoft Powerpoint, (8) PGP Encrypted.

So DLP won't be able to inspect a PGP Encrypted file for instance, but it will understand the file type and you could use this rule to say to say "block anyone copying a PGP encrypted document to their USB drive".  But, what happens when someone uses some other type of encryption?  If it's something you know that users use, you could create a Custom File Type using the File Type Analyzer.  BUT, you're always going to have that gap of file types that you don't have an identifier for, and your user base likey has access to a lot more tools than your comfortable with (and will admit to).

Unfortunately (at least to my knowledge), there's nothing that could be used to simply say "if this file uses ANY type of encryption or can't be read, then block it". 

So I think the easier thing to do here is reverse it...what file types do you ALLOW to be copied?  And while I'm not a huge fan of building DLP policies that aren't looking for defined, sensitive data, I could see a policy that looked something like this:

Rule: Protocol or Endpoint Monitoring = Removable Storage

Response: Endpoint Prevent Block

Exception: Message Attachment or File Type = "Microsoft Excel"

...and in this way, your blocking everything to removable storage except those file types that you have deemed appropriate (in this example, just Excel files for simplicity).  And your excepted file types list can be just those formats that you KNOW are inspectable.  Finally, you can also know that your content rules on other policies (i.e. the one looking for SSNs) are inspecting for that on everything that you've allowed to be copied by this policy.

Hope that makes sense.



John.Armga's picture

I've tossed the idea around creating a robust "allowed files" list but it presents a governance and administration issue. Having the ability to create a policy that basically indicates "if we cant read it you can't take it" provides opportunity to manage exceptions while still affording for very stringent data leakage controls.

Your input is very much appreciated.