Detecting anomalous customer record lookups with statistical baselines

Prerequisites

• Splunk platform version 9.x+ or higher
• Splunk Machine Learning Toolkit
• Python for Scientific Computing

Data required

• Financial data for consumer financial applications
• Authentication data for consumer financial applications

Solution

To detect anomalous customer record lookups, we'll follow this process:

1. Create a statistical baseline of normal user activity to account for natural fluctuations.
2. Create a search that compares current user activity against the baseline to detect abnormalities.
3. Perform a drill-down investigation that focuses on suspicious login patterns (like failed-then-successful logins) for high-risk users to confirm potential account compromise.
4. Pivot to IP geolocation to identify the attack's origin, solidifying evidence of a compromised account.

index=<your index> sourcetype=core:app:audit action=customer_lookup earliest=-18d@d latest=-7d@d
| eval hod=strftime(_time, "%H"), dow=strftime(_time, "%a")
| bin _time span=1h
| stats count as hourly_lookups BY user hod dow _time
| stats avg(hourly_lookups) AS user_mu stdev(hourly_lookups) AS user_sigma count AS data_points BY user hod dow
| where data_points >= 2
| eval user_sigma = if(user_sigma==0 OR isnull(user_sigma), 1, user_sigma)
| fields user hod dow user_mu user_sigma data_points
| outputlookup user_lookup_baselines.csv

index=<your index> sourcetype=core:app:audit action=customer_lookup earliest=-7d@d
| fields _time user
| eval hod=strftime(_time, "%H"), dow=strftime(_time, "%a")
| bin _time span=1h
| stats count AS current_lookups BY user _time hod dow
| lookup user_lookup_baselines.csv user hod dow OUTPUT user_mu user_sigma
| where isnotnull(user_mu)
| eval user_sigma = if(user_sigma==0, 1, user_sigma)
| eval z_score = round( (current_lookups - user_mu) / user_sigma, 2)
| where z_score >= 3
| stats
sum(z_score) AS risk_score
count AS anomaly_count
avg(z_score) AS avg_z_score
max(z_score) AS max_z_score
BY user
| eval avg_z_score = round(avg_z_score, 1)
| sort - risk_score
| head 25

Step 3: Perform a drill-down investigation

We'll start by investigating Alice’s login activity, focusing on instances where a successful login follows a failed attempt within a short time frame. We can use the following SPL query to do this:

index=<your index> sourcetype=iam:auth user="USER-0075" earliest=-4d@d latest=-2d@d
| where auth_result="failure" OR auth_result="success"
| eval event_time_epoch = _time
| transaction user src_ip \
startswith="auth_result=failure" \
endswith="auth_result=success" \
maxpause=5m \
mvlist=true
| where eventcount > 1
| eval time_interval_secs = round(duration)
| eval combined_events = mvzip(event_time_epoch, auth_result)
| mvexpand combined_events
| eval temp_fields = split(combined_events, ",")
| eval event_time_epoch = mvindex(temp_fields, 0)
| eval auth_result = mvindex(temp_fields, 1)
| eval event_time = strftime(event_time_epoch, "%Y-%m-%d %H:%M:%S")
| table event_time user src_ip auth_result time_interval_secs

Search explanation

The table below provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.

Step 4: Pivot to IP geolocation

Let’s investigate the associated IPs with USER-0075 by using the built-in SPL command iplocationto examine where in the world these logins are coming from:

index=<your index> sourcetype=iam:auth src_ip="120.80.80.120" earliest=-4d@d latest=-2d@d
| iplocation src_ip
| table _time user src_ip auth_result City Country Region

Search explanation

The table below provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.

Next steps

This use case provides a powerful foundation for insider threat detection. To further enhance this capability, consider the following:

• Integrate with risk-based alerting (RBA): Instead of alerting directly, you can have this detection contribute to a user's risk score in Splunk Enterprise Security. This allows you to correlate this behavior with other suspicious activities (such as data loss prevention alerts, or unusual VPN access) to generate higher-fidelity alerts.
• Automate response: Use Splunk SOAR to automate response actions when a high-confidence alert triggers. This could include creating a ticket in a case management system, notifying the user's manager, or temporarily restricting access pending investigation.
• Tune thresholds: The z_score >= 3 threshold is a good starting point. Monitor the alerts and adjust this value based on your organization's risk tolerance and the fidelity of the alerts to find the right balance.

Additionally, these resources might help you understand and implement this guidance:

• Use Case: Monitoring mandatory time away (MTA) with the Splunk platform
• Use Case: Using risk scores to improve decision-making
• Use Case: Monitoring for account takeover with the Splunk App for Behavioral Analytics
• Use Case: Monitoring for account abuse with the Splunk App for Behavioral Analytics
• Use Case: Using Amazon SageMaker to predict risk scores
• Splunk Blog: User and Entity Behavior Analytics (UEBA) For Enterprise Security

To learn more about how to detect anomalous customer record access, contact your Splunk sales representative today. You can contact your account team through the Contact Us page.