About UEBA
UEBA stands for User and Entity Behavior Analytics. It is a type of methodology used to detect anomalous behavior patterns in a network's users and entities.
The basic premise behind UEBA is that threats are often initiated by insiders who have legitimate access to the network. These threats can take many forms, such as stolen credentials, phishing attacks, or malicious insiders. By analyzing the behavior of users and entities on a network, UEBA can identify unusual or suspicious behavior patterns that may indicate a potential threat.
UEBA technology typically collects data from a variety of sources, including user activity logs, network traffic, and data access logs. This data is then analyzed to identify patterns and anomalies. Some common types of behavior that UEBA systems may look for include:
- Multiple login attempts with different credentials
- Accessing sensitive data outside of normal business hours
- Unusual data transfer patterns
- Changes to access permissions or other system configurations
By analyzing user and entity behavior patterns, UEBA can help organizations identify and respond to potential threats before they result in a data breach or other security incident.
About Time Series detectors
Time series detectors are used to detect anomalies and potential threats in network traffic or other types of data over time. These detectors are based on the idea that abnormal behavior can be identified by analyzing patterns in time series data.
Time series data can include network traffic, system logs, user behavior, and other data streams that are collected over time. Time series detectors analyze these data streams to identify patterns and trends, and then compare them to established baselines or expected behaviors. When the detector identifies a deviation from the expected pattern, it alerts security personnel to investigate the potential threat.
Hunters Time Series detectors
Detection logic
Hunters provides a growing list of time series detectors based on UEBA. For the purpose of this article, we’ll discuss the SaaS Application Brute Force Attempt detector as an example.
The SaaS Application Brute Force Attempt detector is designed to establish a baseline for regular login attempts behavior using three time-sensitive checks:
- Skipping check - the Skipping check compares current behavior with past behavior in a corresponding time period (e.g., the same weekday and hour in the previous 8 weeks). Once an anomaly is identified, a lead is produced to notify that the system found an unexpected number of failed logins, compared to the expected calculated number based on past behavior.
Note that this is calculated based on time windows, which can vary between 1 hour to 1 day, depending on the detection thesis. - Continuous check - the Continuous check performs the same comparison, but its baseline is the recent past. For example, current behavior compared to behavior in the past 10 hours, hour-by-hour.
- Time slicing - the time slice configuration in our time series detector is used for baselining, not for determining the detection interval. This means that the system uses these slices (e.g., 1h, 4h, 8h) to establish normal behavior patterns, and if an anomaly is detected within any given time slice, an alert will be generated based on that deviation (even if the window wasn't close).
The system generates a lead whenever one of the detectors identifies a discrepancy between the expected behavior and the current behavior. Each detector is configured with a specific standard deviation threshold, and once this threshold is exceeded, a lead is created.
Available data
The following data items are presented in a time series lead:
- Number of samples - the number of samples used to establish the baseline behavior. For instance, for an anomalous behavior that was registered on Monday 9PM, we’ve sampled this same time slot in the past 8 weeks (the sample number) and compared the expected baseline behavior with the current behavior to establish an anomaly is occurring.
- Expected value - the calculated value we were expecting to see, based on previous behavior. For instance, examining past behavior, we were expecting to see 0 failed login attempts, but currently seeing 1624.
- Detected anomalous value - the anomalous value that has triggered the lead creation. For instance, we’ve now registered 1642 failed login attempts, while the expected number, based on the calculated baseline, is 0.