Geographically Improbable Access Detected against Category

Description

To ensure you have a GDPR-mandated audit trail with individual accounts for each person, detect when the same account is logged into twice in a short period of time but from locations very far away, to a GDPR-tagged system.


Use Case

Compliance

Category

GDPR

Security Impact

Detecting and proving that your organizations environment does not use shared user accounts for accessing and processing personal data is industry best practice and should be considered as a effective security control which is required by Article 32 and will help you to prove compliance for data privacy audits from authorities (Article 58) or counteract any compensation claims (Article 82).

Alert Volume

Low (?)

SPL Difficulty

Advanced

Journey

Stage 4

MITRE ATT&CK Tactics

Initial Access

MITRE ATT&CK Techniques

Valid Accounts

MITRE Threat Groups

APT18
APT28
APT3
APT32
APT33
APT39
APT41
Carbanak
Dragonfly 2.0
FIN10
FIN4
FIN5
FIN6
FIN8
Leviathan
Night Dragon
OilRig
PittyTiger
Soft Cell
Stolen Pencil
Suckfly
TEMP.Veles
Threat Group-1314
Threat Group-3390
menuPass

Data Sources

Authentication
AWS
Audit Trail

   GDPR Relevance

Problem:

When monitoring user activity, a key indicator to look for is anomalous authentication attempts (see method above, “Brute Force Access Behavior Detected”). These can point to evidence of stolen or exploited credentials. Concurrent authentication attempts from multiple IP addresses can indicate unauthorized sharing of credentials, or even stolen credentials; and improbable travel anomalies, such as logging in from two geographically distant locations at the same time, which can be an indicator of exploited or misused credentials.

Impact:

Detecting and proving that individuals within the organization are not sharing user accounts for accessing and processing personal data is an industry best practice and can be considered an effective security control, as required by Article 32. Demonstrating that credentials are not being misused or exploited will help to prove compliance for data privacy audits from authorities (Article 58) or counteract any compensation claims (Article 82). This is applicable to processing personal data from the controller, and needs to also be addressed if contractors or sub-processors from third countries or international organizations access and transfer personal data (Article 15).

Resolution Path:

Ensure you have a GDPR-mandated audit trail with individual user accounts for each processor accessing personal data. Detect when the same account is logged into twice in a short period of time but from multiple locations far away from each other, to a GDPR-tagged system.

   How to Implement

First, use your data mapping results to build a lookup that associates systems to their GDPR category. Then you just need a log source that provide external IP addresses. If you are using SFDC data, as we are in the live example, it will work easily. Otherwise, any data source that is compliant with the Splunk Common Information Model (so that it contains a src_ip field) should work pretty automatically.

   Known False Positives

There are two big buckets for false positives. One is where the geoip is unreliable -- particularly outside of major economic areas (e.g., US, larger countries in Western Europe), the free MaxMind GeoIP that ships with Splunk Enterprise tends to be less accurate, causing some customers to add the paid version in their Splunk installations. The other big categories is where IPs are centralized, such as someone in the US using a Korean VPN service, or using a networking service that originates nation-wide traffic from the same set of IPs (for example, years ago all traffic from a major US cellular carrier originated from the same IP space that was geolocated to Ohio).

   How To Respond

When this fires, you should reach out to the user involved to see if they're aware of why their account was used in two places. You should also see what actions were taken, particularly if one of the locations was unusual. If the user is not aware of the reason, it's important to also ask if the user is aware of sharing their credentials with anyone else. You can also see what other activities occurred from the same remote IP addresses.

   Help

Geographically Improbable Access Detected against Category Help

This example leverages the Simple Search assistant. Our example dataset is a collection of anonymized Salesforce.com logs, during which someone logs in from opposite ends of the earth. Our live search looks for the same activity across the standard index and sourcetype of SFDC data. For this use case, you can use any kind of data source, including VPN logs and others.

SPL for Geographically Improbable Access Detected against Category

Demo Data

First we bring in our basic demo dataset. In this case, AWS CloudTrail logs. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Next we pull the last src_ip for the same user using streamstats (sorted based on the user).
Next we look up the AccountId in the GDPR categorization lookup. Because we only care about GDPR Accounts for this example, we filter for only the hosts that are in scope for GDPR. (You could also categorize based on any other field in AWS.)
Here we filter for logins that are GDPR in scope, and in a short enough time range that it would be difficult to travel to distant parts of the globe.
Here we resolve the Last src_ip to a physical location, and stick that in a field so that we can conveniently use it.
Now we resolve the *current* src_ip
Now we calculate the distance using an approximation for the curvature of the earth. Easy, right? I do not understand it, I copy-pasted from https://answers.splunk.com/answers/317935/calculating-distances-between-points-with-geoip-us.html#answer-568451
Here we pull the date of the event, to make this easier to run over longer time windows.
Finally we use stats to collect all of the values into one line, per user, per day, and per set of locations. We're using some specific AWS data fields here -- if you're using a log source like VPN, then you might choose other fields.

Live Data

First we bring in our basic dataset. In this case, AWS CloudTrail logs.
Next we pull the last src_ip for the same user using streamstats (sorted based on the user).
Next we look up the AccountId in the GDPR categorization lookup. Because we only care about GDPR Accounts for this example, we filter for only the hosts that are in scope for GDPR. (You could also categorize based on any other field in AWS.)
Here we filter for logins that are GDPR in scope, and in a short enough time range that it would be difficult to travel to distant parts of the globe.
Here we resolve the Last src_ip to a physical location, and stick that in a field so that we can conveniently use it.
Now we resolve the *current* src_ip
Now we calculate the distance using an approximation for the curvature of the earth. Easy, right? I do not understand it, I copy-pasted from https://answers.splunk.com/answers/317935/calculating-distances-between-points-with-geoip-us.html#answer-568451
Here we pull the date of the event, to make this easier to run over longer time windows.
Finally we use stats to collect all of the values into one line, per user, per day, and per set of locations. We're using some specific AWS data fields here -- if you're using a log source like VPN, then you might choose other fields.

Screenshot of Demo Data