DLP incidents generated by Network Prevent for Email or Network Prevent for Web do not show information in the attributes area as expected, where Endpoint events do.
Incident attribute information is set after data from the incident is used by one or more lookup plugins (often LDAP lookups) to query their data source. Information such as the sender or user information is queried against the data source, and when a match is found, DLP attempts to pull information from that record to populate attributes.
Since this is a string match, the information that DLP passes to the lookup plugin must match what's in the source.
In cases where the sender shows up as "WINNT://<domain>/<username>" or "NTLM://<domain><username>", since these exact string values don't usually show up in an typical LDAP record, the query fails and no attribute information is populated.
To resolve this issue, we need to do a lookup that will map the "bad" data to a field that is in LDAP using the CSV lookup. If you are already leveraging a CSV lookup, you can simply add this to your existing CSV file.
CSV files should be pipe delimited, and look like this:
Note: Variable2 is the name for the custom attribute being created, and in this example, the name "Variable2" will show up amongst the list of custom attributes in incidents. Because of this, you may wish to name this something unique. However, for readability, we will use "Variable2" in this document.
Email is the data that comes into the incident for the sender...in this example, network incidents show "winnt:\\ABC\JUser" as the user.
Variable2 is data from LDAP that we want to match up...in this example, this field is the user's sAMAccountName in LDAP.
Save the CSV file on the file structure of Enforce. The location doesn't matter, as long as the protect user (the account that's actually performing Enforce actions) can access it.
Now that the CSV file is set up, Enforce must be configured to look for the data it's pulling.
1.) In Enforce, go to System -> Incident Data -> Attributes.
2.) Click the Custom Attributes tab.
3.) Click Add.
4.) Type the name of the variable that's being populating from LDAP. In this example, since the LDAP information is being stored in Variable2" in the CSV, enter Variable2 here.
5.) *Optional* Click the pull-down for Attribute Group and change where the variable shows up. This changes where the custom attribute appears on the right side of an incident, and doesn't affect functionality at all.
6.) Click Save.
Next, set up the two plugins.
1.) In Enforce, go to System -> Incident Data -> Lookup Plugins.
2.) Click New Plugin, then select CSV.
3.) Enter a name for the plugin. It is recommended that you use something descriptive, like "CSV lookup".
4.) *Optional*: Enter a description for what this plugin does.
5.) Enter the path to the CSV file that was created earlier. Note: you must use forward slashes for the path, as shown in the example directly below this field in Enforce.
6.) Set the Delimiter to Pipe [|].
7.) Leave File Encoding to UTF-8.
8.) Enter the following in the Attribute Mapping, substituting as needed:
attr.sender-email = Email
attr.Variable2 = Variable2
keys = Email
9.) Click Save.
Now, turn the CSV plugin on and move it up in the list of plugins.
1.) Click Modify Plugin Chain
2.) Click the pull-down next to the CSV plugin you just created and set it to one *higher* than LDAP. For example, if you have 4 plugins (counting your newly created CSV plugin) and LDAP is currently #2 in the list, change the CSV plugin to #1. The position of the CSV lookup doesn't matter provided that it's *higher* than the LDAP plugin.
3.) Check the box for Dedicated Actions - > On for the CSV plugin.
4.) Click Save. Remain on this page, we will need it below.
Finally, we must configure the LDAP query to look for this data as well. Click the link to your LDAP query.
Once there, you'll see several queries, such as this:
attr.First\ Name=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$) (mail=$sender-email$)):givenName
An LDAP query breaks down like this:
attr.First\ Name -> This is the custom attribute that will be filled out in an incident
(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$) (mail=$sender-email$) -> This is the string that is used to check LDAP. In this example, Enforce takes the endpoint-user-name, file-owner, and sender-email data from an incident and try to match them up with the data from sAMAccountName in LDAP.
:givenName -> This is the data we pull from LDAP for this query. If the LDAP query finds a record in AD that matches, Enforce takes whatever it finds in givenName field in that LDAP record and populates the custom attribute "First Name" in the incident.
Because this is a string match, the query fails. However, with the CSV lookup being done prior to the LDAP lookup, we're able to map that "bad" data with an entry in LDAP and store it in a variable. This is accomplished by adding the variable to the search string and tell it where to look in LDAP:
attr.First\ Name=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$) (mail=$sender-email$) (sAMAccountName=$Variable2$)):givenName
With this query, we still won't be able to find anything for endpoint-user-name, file-owner or sender-email that matches up, but since the data from Variable2 DOES match up with an entry in sAMAccountName, this query is able to return the data needed for the First Name custom attribute.
To get LDAP queries to succeed, you need to add "(sAMAccountName=$Variable2$)" (no quotes) to the search string for *each* lookup you want to be sure succeeds. Each of these queries are run in the order they're listed, so if endpoint-user-name matches something in sAMAccountName, the LDAP query will stop looking. As it's assumed that LDAP queries are, for the most part, working without issue in the environment, we highly recommend putting our CSV lookup string at the end of the existing lookups.
Once you've updated the LDAP lookup plugin to look for your custom attribute from CSV, click Save.