DLP interaction/integration with McAfee FRP Device Control

[Keith H]

We've noticed isolated instances of DLP (14.5 console/14.5MP1 agent) trigerring endpoint incidents based on defined policies even though McAfee FRP Device Control prevented the write to a removable storage device (RSD).  McAfee FRP Device Control was implemented to block attempts to write to a RSD without an approved exception.  DLP System Owners and the group responsible for reviewing DLP incidents expect DLP should never generate an incident for an attempt to write to a RSD if/when McAfee FRP blocks the write.  I've been able to recreate instances where McAfee blocked the write to RSD, but DLP generates an incident and instances where McAfee blocks the write to RSD, but DLP does not generate an incident. 

I'm seeking information on the two applications/agents and how they talk to/integrate with one another.  In other words, under what circumstances does the McAfee event/task (RSD block) take priority over DLP (incident detection) and vice versa?  Thanks in advance for your help!          

[DLP Solutions]

Keith,

Overall, BOTH of these applications are utilizing the Windows OS level API's and intercepting them. So they are using Drivers that manage the RSD and also hook into the OS drive API's. So DLP is watching that API and seeing what is being done and I think that McAfee is doing the same.

So I am not sure if I can say which has precedence.

I do want to know what policies do you have that allow for a person to write or not write to an RSD? When does McAfee allow the write and then DLP will see it?

 

Ronak

 

[Keith H]

Hello Ronak,

 

Thank you for responding.  By default, writing to RSDs is blocked by McAfee FRP DC. ONLY users with an approved exception on file can write to RSD.  Those with an approved exception are managed via an AD group for the duration of the exception. When the exception expires, they are removed from the group and the McAfee default RSD block is restored.  

The system owner would like DLP policies to detect ONLY when a user with an approved exception has written specific IP content to RSD.  Ideally, all users without an approved exception attempting to write to RSD should be blocked by McAfee.  DLP SHOULD NOT see the write attempt by the user and SHOULD NOT generate an incident.  We are not using DLP to block attempts to write to DLP.   Thanks again for your help!         

[Keith H]

Correction... We are not using DLP to block attempts to write to RSD.   Thanks again!   

[Keith H]

Hello Ronak,

Thank you for responding.  By default, writing to RSDs is blocked by McAfee FRP DC. ONLY users with an approved exception on file can write to RSD.  Those with an approved exception are managed via an AD group for the duration of the exception. When the exception expires, they are removed from the group and the McAfee default RSD block is restored.  

The system owner would like DLP policies to detect ONLY when a user with an approved exception has written specific IP content to RSD.  Ideally, all users without an approved exception attempting to write to RSD should be blocked by McAfee and DLP SHOULD NOT see the write attempt by the user and SHOULD NOT generate an incident.  We are not using DLP to block attempts to write to DLP.   Thanks again for your help!         

[DLP Solutions]

Keith,

The issue plain and simple is that there is no way to control this. Both applications are intercepting the OS drivers to access and then write to the RSD.

So McAfee watches the same API that DLP does on a user trying to access the RSD. If you can closly watch the McAfee Agent and DLP agent you may see the file actually look like it was written to the RSD but it is intercepted and then undone on the RSD.

This is one of those issues with cross compatability that will exist.

Maybe ask McAfee if they have a fix for it, for they are the first line of defence that is making the decesion.

Ronak

[Keith H]

Thank you, Ronak!