Data Loss Prevention

The title is a bit weird, so I'll explain--

I am using Lookup Plugins in the following manner to support incident analysis: 

1. Data Insight lookup plugin, for inferred ownership data,

2. the python plugin called "script-lookup.py," for mapping the DI data ownership name to its counterpart in AD, 

3. and the LDAP plugin. 

For endpoint DLP and network prevent (email), the LDAP plugin works as expected, and successfully pulls data from AD.  No issues there, which to me validates a correctly configured LDAP plugin.

However, things get weird when doing Discover scans.  The plugins pull NO data; not even the LDAP plugin.  In turning up the logging for the Tomcat logs (log named as "localhost.[year-month-day]") by modifying the "ManagerLogging.properties" such that I can get more verbose logging for the plugin framework (changed from INFO to FINER), I am able to see that in these cases, "null" is being pulled for all attributes.  So I figured maybe I've incorrectly defined my custom attributes and perhaps didn't map them correctly.  In exhausting my review of syntax, case sensitivity, and mapping, I cannot find an issue. 

In working something else related to auto-quarantining sensitive files for discover scanning, I made a chance discovery.  If I do anything to cause the auto-quarantining to fail upon a Discover incident ( this KB here outlines an easy issue to replicate for this purpose -- https://support.symantec.com/en_US/article.TECH224684.html), such that I get a "Protect Remediation Error", all of my lookup plugins work!!!  As soon as I fix the issue causing the "Protect Remediation Error," sensitive data will get found and quarantined, but the Lookup plugins begin to pull "null" values again.

This behavior continues to stump me, and even trying "FINEST" to get a more detailed plugin look from the Tomcat logs, I have yet to find a root cause.  Any suggestions or ideas are much appreciated!

Thank you.

hello,

 It looks like when quarantine is working, your python script is not able to find an AD account so LDAP plugin is not able to get attribute value in active directory. It may be due to data insight plugin which is not able to return ownership data when remediation works (may be because DLP send quarantine directory as location of the file so DI is not able to get information about the file.)

I just guess it happens like that as i have no system to check it.

In log file, you may have list of parameters sent by DLP to plugins, so you may be able to see if it is correct or not (it should be discover-location parameter).

Unfortunately if i am right, it looks like a bug. You could just avoid null values by adding few steps in your python script.

 Regards.

Thank you for writing back.  I was beginning to think along those same lines, so I've been tinkering with the logging settings to see if I can get some revelation on exactly what parameters are being submitted as part of the Data Insight Lookup process.  I'll poke around and post what I find, if anything.  It would be great if I can verify whether or not the quarantine location is being submitted for reference to Data Insight, as that would certainly be a problem... 

Figured it out... The issue wasn't quite nearly as nefarious as I had begun to worry about.  Given naming convention habits over here, there are actually a few ways to reference the filer, whether by a few different names, or directly by IP.  The location reference (name) of the filer, supplied to the DLP discover target configuration, was actually different from the host name supplied to Data Insight when configuring it as a filer.  Seems you must use the identical host name for the filer recognized by Data Insight when setting up your Discover scans, or Data Insight will not recognize it when doing the lookup, thus, the null values.