New Data Exfil DLP Alerts for User

Description

When you first seen an alert from a user who hasn't generated DLP alerts for data exfiltration before, learn about that.


Use Case

Insider Threat

Category

Insider Threat

Security Impact

When a user who normally does not generate data exfil DLP alerts suddenly starts, it is more notable than a traditional alert. For crucial rules or high privileged users, investigate these events to determine whether sensitive company intelligence is leaving the organization.

Alert Volume

High (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Exfiltration

MITRE ATT&CK Techniques

Exfiltration

Kill Chain Phases

Actions on Objectives

Data Sources

DLP

   How to Implement

Implementation of this rule is straightforward -- the only requirement is to be able to record which DLP alerts represent data exfiltration. That nomenclature or configuration can vary wildly from one organization to another, so this will require coordination with your DLP team. Beyond that, so long as you have a user field and a signature field defined, the search will work.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

   How To Respond

Because this is a behavioral alert, you should generally not use this in isolation unless the severity of the alert or the priority of the user dictate that it is so crucial it must be looked at in isolation, or your DLP is so carefully tuned that alerts are rare. For everyone else, most alerts should only be considered when in conjunction with other alerts, via a risk aggregation mechanism in Splunk ES or the threat models in Splunk UBA.

   Help

New Data Exfil DLP Alerts for User Help

This example leverages the first time seen search assistant. Our dataset is an anonymized collection of DLP events. For this analysis, we are filtering for data exfiltration alerts.

SPL for New Data Exfil DLP Alerts for User

Demo Data

First we bring in our basic demo dataset. In this case, a fabricated set of DLP events (surprisingly, no one wants to share DLP alerts, so we had to fake the demo data!). We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
Next we calculate the most recent value in our demo dataset
We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset.

Live Data

First we bring in our base dataset of DLP Alerts, tagged via the TAs that are complaint with Splunk's Common Information Model. You can adjust this to the index and sourcetype of your DLP logs as well.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Accelerated Data

Here, tstats is pulling in one command a super-fast count of DLP Alerts per user, per hour, per signature.
To make the query easier to write, we immediately rename the Data Model syntax to a more normal version (DLP_Incidents.user -> user).
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Screenshot of Demo Data