Why DLP System Without Behavioral Analytics Is Blind to Slices
DLP sees content and transmission channel. It works when a document with a “confidential” stamp goes to personal mail or is copied to USB. But the insider, who worked in the company for three years, knows which files are marked with a vulture - renames the document, copies data to the usual Excel, is carried out through the corporate messenger. The DLP system of protection against insiders in such a scenario is powerless.
User Entity Behavior Analytics solves another problem: not “what is transmitted”, but “who behaves atypically”. The system builds baseline behaviors of the user and each entity - the workstation, service account, VPN connection - and detects deviations. A marketing employee, who got to financial bases for the first time in a year at 2 a.m., an anomaly that UEBA will record even if a particular file does not contain DLP markers.
From the point of view of MITRE ATT&CK, a typical insider chain looks like this: legitimate accounts - Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion) Next Next post: Data from Local System (T1005), Data from Network Shared Drive (T1039), Data from Information Repositories (T1213), Data from Removable Media (T1025) - all collection. Exfiltration - USB (T1052.001) or cloud services (T1567) Competent insider also cleans the traces - Indicator Removal (T1070)
DLP will catch T1052.001 or T1567, but only if the channel and content are described in the policy. Behavioral analytics of users will reveal the deviation from baseline already at the stage T1005/T1039 - when the employee is just beginning the mass collection of data. Days or weeks before exfiltration.
Building a baseline: which sources to connect first
Monitoring of user anomalies works exactly as well as full data on the input. Deploy UEBA without the right sources - how to run a correlation in SIEM without logs. According to the recommendations of Security Boulevard (to which Vetra AI refers), baseline is formed in 60-90 days of observation. This is not a passive expectation: during this period, the system should gain sufficient event for statistically significant profiles of each user and entity.
Minimum set of sources for AD-environment
The first and critical source is the events of Active Directory. Without them, the behavioral model is blind:
• Event ID 4624 (Successful Logon) - time, type of login (interactive, network, interactive remote), the original workstation. Baseline Foundation "when and where the user works"
• Event ID 4625 (Failed Logon) - Brutforce, attempts to select, use of other people's records
• Event ID 4648 (Logon using explicit credentials) - the marker credential misuse: the employee clearly uses his credentials
• Event ID 4672 (Special privileges) - the appointment of privileges, uncharacteristic of the role
• Event ID 4663 (Object access) - accessing files and directories when the objects audit included
The second source is DLP-events. If the DLP is already deployed (Symantec DLP, Forcepoint, InfoWatch Traffic Monitor), its alergs enrich UEBA context. The integration of DLP and SIEM works simply: UEBA sees an acne of access, DLP confirms an attempt to take out confidential content. Individually, each signal is noise; together, a high-priority incident.
The third is VPN and proxy logs. Hybrid work is blurry by baseline, and without data on VPN sessions, UEBA will generate positive false positive for every IP change. According to Exabeyam, hybrid environments are one of the main reasons for blind spots in the detection of insider threats: an employee can unload data into a personal OneDrive without touching the corporate network.
The fourth is cloud events: Microsoft 365 Unified Audit Log, Google Workspace Activity Log. Without this layer, UEBA does not see T1567 (Exfiltration Over Web Service). In my experience, this channel insiders choose more often USB - no need for a physical medium, and in logs it looks like a normal cloud work.
Peer group analysis instead of "average in the hospital"
Default setting UEBA in most products compares the user with the general population. The result is chaos: DBA, which performs 500 SQL queries per day, looks abnormally against the background of the whole company, but absolutely normal among fellow administrators. Peer group analysis solves this problem: the system compares the employee with a group that has a similar role, level of access and a pattern of work.
In the Splunk UBA peer group configured through peer_group_config with binding to AD attributes - department, title, manager. In Microsoft, the Sentinel UEBA peer group is formed automatically from Entra ID (Azure AD) data, but requires manual validation. On one project, I found that HR and the financial department were in one peer group because of similar lateral counts of logins - both groups worked from 9 to 18, used one set of enterprise applications. Baseline was distorted, and the anomalous appeals of financiers to the human resources bases went unnoticed. That's how one error in the group killed the entire detection pipeline.
Practical rule: If UEBA generates more than 50 aerates per day after adjusting peer groups, the groups are crooked.
Correlation rules for detecting abnormal behavior of employees
Setting up UEBA in SIEM is built through the chain: raw events -> normalization -> normalization -> rules -> risk scoring -> alert. Below are specific correlations that give results on real infrastructure.
Abnormal volume of data unloading
Splunk SPL - detecting an abnormal number of files requests behind the sliding window:
Code:
index=wineventlog earliest=-30d EventCode=4663 object_category=file
| bucket _time span=1h
| stats count as file_access_count by user, department, _time
| eventstats avg(file_access_count) as avg_access,
stdev(file_access_count) as stdev_access by user, department
| where file_access_count > (avg_access + 3*stdev_access)
AND _time > relative_time(now(), "-24h")
| table _time, user, department, file_access_count, avg_access
Threshold 3*stdev - starting point. For the peer accounting group, the standard deviation will be one, for developers - another. Without a division of peer group, this rule gives up to 80% false positive in the first week. Addition by department in eventstats Radically reduces noise.
First appeal to an uncharacteristic resource
Microsoft Sentinel (KQL) - Detecting new access patterns that were not in history in 30 days:
Code:
let lookback = 30d;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4663
| summarize AccessCount=count() by TargetAccount, ObjectName
| where AccessCount > 10
| join kind=leftanti (
SecurityEvent
| where TimeGenerated between(ago(lookback)..ago(24h))
and EventID == 4663
| distinct TargetAccount, ObjectName
) on TargetAccount, ObjectName
The correlation is looking for file resources, to which the user began to communicate with high intensity in the last day, although for the previous 30 days did not apply. A characteristic picture of the initial phase of Data from Network Shared Drive (T1039): the employee "bypasses" the balls to which he has access, but has never been used.
Intersection of DLP-aller and behavioral anomaly
The most valuable correlation is the intersection DLP event and UEBA-anomalias:
1. DLP generates an event: attempt to send a file to personal mail (severity: medium)
2. UEBA fixes: the same user has turned to resources that are uncharacteristic of his role in the last 48 hours
3. Correlation rule increases the priority of the incident to critical
In Splunk, this is implemented through risk-based alerting: each event adds points to the risk score of the user. According to Cyberhaven, efficient UEBA systems use a 0-100 scale with a dynamic score update when new events arrive. When the score exceeds the threshold, the notable event is formed. In Secureix, a similar mechanic is called Threat Chain: a sequence of events that individually look legitimate, but together they punch on a contact chain insider.
Monitoring of preferred users
Detection of insider threats from preferred users is a separate detection pipeline. The domain administrator, accessing a domain controller at 3 a.m., can perform scheduled maintenance, and can export NTDS.dit. Standard behavioral analytics is stalling here: baseline privileged accounts are too wide.
The solution is the integration of UEBA with PAM. CyberArk, Indeed PAM or analogue fixes: the privileged access session is open through change request, scheduled from 02:00 to 04:00, the scope of work is GPO update. If UEBA sees the export of the AD base in this window, this is an anomaly, even if baseline formally allows night access. PAM gives a context without which UEBA simply does not distinguish legitimate work from data removal.
In the Splenk UBA, preferred accounts are allocated to a separate watchlist with lowered thresholds: for an ordinary user, a deviation in 3 sigma is considered analgesic, for a privileged one - in 2. Microsoft Sentinel to monitor privileged users runs a bundle of Identity Protection (user risk / inin-in risk) + Sentinel UEBA (Investigation Priority Score), where Identity Protection signals come through the connector and are used in the rules to improve the priority of the incident. In Seccausenix for this there is prebuilt policy "Privileged Account Abuse" with a detection of lateral movement Event ID 4648.
DLP sees content and transmission channel. It works when a document with a “confidential” stamp goes to personal mail or is copied to USB. But the insider, who worked in the company for three years, knows which files are marked with a vulture - renames the document, copies data to the usual Excel, is carried out through the corporate messenger. The DLP system of protection against insiders in such a scenario is powerless.
User Entity Behavior Analytics solves another problem: not “what is transmitted”, but “who behaves atypically”. The system builds baseline behaviors of the user and each entity - the workstation, service account, VPN connection - and detects deviations. A marketing employee, who got to financial bases for the first time in a year at 2 a.m., an anomaly that UEBA will record even if a particular file does not contain DLP markers.
From the point of view of MITRE ATT&CK, a typical insider chain looks like this: legitimate accounts - Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion) Next Next post: Data from Local System (T1005), Data from Network Shared Drive (T1039), Data from Information Repositories (T1213), Data from Removable Media (T1025) - all collection. Exfiltration - USB (T1052.001) or cloud services (T1567) Competent insider also cleans the traces - Indicator Removal (T1070)
DLP will catch T1052.001 or T1567, but only if the channel and content are described in the policy. Behavioral analytics of users will reveal the deviation from baseline already at the stage T1005/T1039 - when the employee is just beginning the mass collection of data. Days or weeks before exfiltration.
Building a baseline: which sources to connect first
Monitoring of user anomalies works exactly as well as full data on the input. Deploy UEBA without the right sources - how to run a correlation in SIEM without logs. According to the recommendations of Security Boulevard (to which Vetra AI refers), baseline is formed in 60-90 days of observation. This is not a passive expectation: during this period, the system should gain sufficient event for statistically significant profiles of each user and entity.
Minimum set of sources for AD-environment
The first and critical source is the events of Active Directory. Without them, the behavioral model is blind:
• Event ID 4624 (Successful Logon) - time, type of login (interactive, network, interactive remote), the original workstation. Baseline Foundation "when and where the user works"
• Event ID 4625 (Failed Logon) - Brutforce, attempts to select, use of other people's records
• Event ID 4648 (Logon using explicit credentials) - the marker credential misuse: the employee clearly uses his credentials
• Event ID 4672 (Special privileges) - the appointment of privileges, uncharacteristic of the role
• Event ID 4663 (Object access) - accessing files and directories when the objects audit included
The second source is DLP-events. If the DLP is already deployed (Symantec DLP, Forcepoint, InfoWatch Traffic Monitor), its alergs enrich UEBA context. The integration of DLP and SIEM works simply: UEBA sees an acne of access, DLP confirms an attempt to take out confidential content. Individually, each signal is noise; together, a high-priority incident.
The third is VPN and proxy logs. Hybrid work is blurry by baseline, and without data on VPN sessions, UEBA will generate positive false positive for every IP change. According to Exabeyam, hybrid environments are one of the main reasons for blind spots in the detection of insider threats: an employee can unload data into a personal OneDrive without touching the corporate network.
The fourth is cloud events: Microsoft 365 Unified Audit Log, Google Workspace Activity Log. Without this layer, UEBA does not see T1567 (Exfiltration Over Web Service). In my experience, this channel insiders choose more often USB - no need for a physical medium, and in logs it looks like a normal cloud work.
Peer group analysis instead of "average in the hospital"
Default setting UEBA in most products compares the user with the general population. The result is chaos: DBA, which performs 500 SQL queries per day, looks abnormally against the background of the whole company, but absolutely normal among fellow administrators. Peer group analysis solves this problem: the system compares the employee with a group that has a similar role, level of access and a pattern of work.
In the Splunk UBA peer group configured through peer_group_config with binding to AD attributes - department, title, manager. In Microsoft, the Sentinel UEBA peer group is formed automatically from Entra ID (Azure AD) data, but requires manual validation. On one project, I found that HR and the financial department were in one peer group because of similar lateral counts of logins - both groups worked from 9 to 18, used one set of enterprise applications. Baseline was distorted, and the anomalous appeals of financiers to the human resources bases went unnoticed. That's how one error in the group killed the entire detection pipeline.
Practical rule: If UEBA generates more than 50 aerates per day after adjusting peer groups, the groups are crooked.
Correlation rules for detecting abnormal behavior of employees
Setting up UEBA in SIEM is built through the chain: raw events -> normalization -> normalization -> rules -> risk scoring -> alert. Below are specific correlations that give results on real infrastructure.
Abnormal volume of data unloading
Splunk SPL - detecting an abnormal number of files requests behind the sliding window:
Code:
index=wineventlog earliest=-30d EventCode=4663 object_category=file
| bucket _time span=1h
| stats count as file_access_count by user, department, _time
| eventstats avg(file_access_count) as avg_access,
stdev(file_access_count) as stdev_access by user, department
| where file_access_count > (avg_access + 3*stdev_access)
AND _time > relative_time(now(), "-24h")
| table _time, user, department, file_access_count, avg_access
Threshold 3*stdev - starting point. For the peer accounting group, the standard deviation will be one, for developers - another. Without a division of peer group, this rule gives up to 80% false positive in the first week. Addition by department in eventstats Radically reduces noise.
First appeal to an uncharacteristic resource
Microsoft Sentinel (KQL) - Detecting new access patterns that were not in history in 30 days:
Code:
let lookback = 30d;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4663
| summarize AccessCount=count() by TargetAccount, ObjectName
| where AccessCount > 10
| join kind=leftanti (
SecurityEvent
| where TimeGenerated between(ago(lookback)..ago(24h))
and EventID == 4663
| distinct TargetAccount, ObjectName
) on TargetAccount, ObjectName
The correlation is looking for file resources, to which the user began to communicate with high intensity in the last day, although for the previous 30 days did not apply. A characteristic picture of the initial phase of Data from Network Shared Drive (T1039): the employee "bypasses" the balls to which he has access, but has never been used.
Intersection of DLP-aller and behavioral anomaly
The most valuable correlation is the intersection DLP event and UEBA-anomalias:
1. DLP generates an event: attempt to send a file to personal mail (severity: medium)
2. UEBA fixes: the same user has turned to resources that are uncharacteristic of his role in the last 48 hours
3. Correlation rule increases the priority of the incident to critical
In Splunk, this is implemented through risk-based alerting: each event adds points to the risk score of the user. According to Cyberhaven, efficient UEBA systems use a 0-100 scale with a dynamic score update when new events arrive. When the score exceeds the threshold, the notable event is formed. In Secureix, a similar mechanic is called Threat Chain: a sequence of events that individually look legitimate, but together they punch on a contact chain insider.
Monitoring of preferred users
Detection of insider threats from preferred users is a separate detection pipeline. The domain administrator, accessing a domain controller at 3 a.m., can perform scheduled maintenance, and can export NTDS.dit. Standard behavioral analytics is stalling here: baseline privileged accounts are too wide.
The solution is the integration of UEBA with PAM. CyberArk, Indeed PAM or analogue fixes: the privileged access session is open through change request, scheduled from 02:00 to 04:00, the scope of work is GPO update. If UEBA sees the export of the AD base in this window, this is an anomaly, even if baseline formally allows night access. PAM gives a context without which UEBA simply does not distinguish legitimate work from data removal.
In the Splenk UBA, preferred accounts are allocated to a separate watchlist with lowered thresholds: for an ordinary user, a deviation in 3 sigma is considered analgesic, for a privileged one - in 2. Microsoft Sentinel to monitor privileged users runs a bundle of Identity Protection (user risk / inin-in risk) + Sentinel UEBA (Investigation Priority Score), where Identity Protection signals come through the connector and are used in the rules to improve the priority of the incident. In Seccausenix for this there is prebuilt policy "Privileged Account Abuse" with a detection of lateral movement Event ID 4648.
