Data Loss Prevention

I have a policy to monitor USB Write attempts but Allow Read access.

This one policy has just one Rule using Protocol - (Protocol or Endpoint Monitoring) and the following Condition:

Detect when users move data on the endpoint to these places:  Removable Storage

Although it is picking up all Files moving to removable storage, My issue occurs with those cases where someone is READing data from a USB device.  My console is filling up with Temp file writes that seem application generated, and numerous ~ files.  It also seems that someone using 'portable apps' running from a USB stick triggers multiple incidents.  I would like to (actually need to) filter out all these 'non-user itiated' Writes from producing incidents so that I can actually determine if someone attempted a Write attempt or not. 

Now I know, a Write attempt is still occurring so it is working correctly.....But is there a way or an additional setting that I can utilize to determine if the User generated the Write or the System or generally just obtain more detail on the incident.

Thank you

Just a few months ago we enabled the same exact policy at my company. We did determine that it was good to leave it alone because it gave us an idea of who was using a USB device plus we used it as evidence when someone did get blocked we could see exactly what they were copying over. This did help in a few occasions where we busted an employee that was leaving the company and let their manager know they were backing their laptop up before their last day.

 

One thing I did do was to create an exclusion in the policy under the detection tab to exclude attachment/File name.

~WRD*.tmp

 

this cut down on a lot of garbage incidents.

 

Good info, I appreciate the exclusion tip for Temp files.

I'd challenge you on your approach here as it relates to DLP in general. Sounds like you're using the system to simply log ANY activity as it relates to writing to a USB drive, and that the DLP agent is doing exactly what you're asking it to do. First challenge to you that IF you already allow the use of USBs within your environment, how do you expect to be able to review any and all transactions that you're logging via the agent? You completely dismiss the "content-awareness" aspect of DLP, which is the core capability of the tool. In other words, allow the write activity, but detect and/or block when the data that's being moved is violating some policy. Second challenge would be this...if you get the idea of what I'm saying above, then why would you even care if the write to the USB is initiated by the user, or some application that's automatically writing to the USB drive? In either case, something is moving data that you don't want to an inherently insecure device. Not trying to be hyper-critical here, so please don't take my response that way. I've worked on several dozen DLP implementations over the years, and the biggest issue I see with customers trying to manage DLP is that they are looking at it as a "logging" tool, rather than the content aware monitoring and prevention system that it is. ~Keith

I thank you for presenting the challenges...honestly. 

You are right,  at this point I am using it as a logging tool.  As most people have figured out (or will) the Endpoint deployment, as opposed to email/web, is more ‘politically’ challenging.  In this stage of Endpoint I would like to determine overall USB/removable storage usage as well as ‘reasons’ for use.  Compiling this type of data before approaching the business with such questions as ‘who needs USB access’ where the answer is always everybody, gives us leverage (I couldn’t think of a better term) and a better understanding of the business environment.  Later on this information may not be useful, but right now it gives us a starting point, a baseline if you will.

I will be moving forward in phases, as opposed to just dropping the hammer, by limiting on a per user basis (regardless of content), type of device, type of content, type of user, etc… 

Hi Just cott,

 

This looks ther is conflict between ur all policies that are implemented.

You need to review all your group polices , Desktop policies and DLP endpoint policies to see the faesibility and compatibilty among them. First check and confirm about policy defination and rules for each policies.

I definitely understand the need to baseline and understand the activity that occurs on USB. In my experience, putting the focus on the "who" and "how", instead of the "what" can set some misguided expectations around what DLP is intended to do, however, and can dilute the effectiveness of your DLP policies. Can I block all users in Group A from writing any file to a USB drive with DLP? Yes, of course. But is it the correct tool to do that with? Maybe not. SEP, for example, might be a better way to control this behavior (device control vs. data control). A phrase a customer of mine once used..."if I drive my car into a river, it will float for 10 minutes, but that doesn't make it a boat". To the point about "expectations" within your organization, the core functionality of DLP is around content awareness and people in your organization who know about DLP need to know that. It's about detecting/preventing Joe Recruiter in HR from copying SSN data to a non-encyrpted device (for instance). If the expectation is set that this system is there for device control, then it tends to get used in only that manner. What you begin to lose, then, is any critical thought/analysis/evaluation of what data is really important for your company to protect. You then begin to control vectors as opposed to data, and then don't really have any compelling story to tell about what you've really protected. A user in the non-blocked group, for instance, can still be copying sensitive data to USB, and you'd barely know about it unless you're combing through every incident you record. A data-centric approach allows you to focus your resources on what the company has defined as sensitive content. I hope this helps. Again, from my experience and what I've seen at other clients, when you start from a "logging" perspective, it tends to be very difficult to eventually stop just logging and start focusing on content. Some manager somewhere is going to get the expectation that you're always going to be able to look up every piece of data that Joe Recruiter has ever written to USB, and this can make your DLP system very difficult to manage over time. Just my opinion. Baseline is good...it's step one in the recommended methodology for implementing DLP. But it should be focused first around the content (the "what"), as opposed to the action (the "how"). Hope that helps. Of course I don't know much more about what you're doing other than what you've posted here so take it all with a grain of salt. I'm just advising based on how I would advise any one of my DLP clients. Regards, ~Keith