User Logged into In-Scope System They Should Not Have

Description

Follow your GDPR requirement and action your data mapping exercise by tracking employee/vendor/supplier access to systems, to ensure that they are authorized to view the data present on any systems they log into.


Use Case

Insider Threat, Compliance

Category

GDPR, IAM Analytics, Lateral Movement, Operations

Security Impact

GDPR gives the right to individuals that they can ask an organization where their data is stored (Article 15) - through data mapping reinforced by controls to detect violation, an organization can identify which vendors/processors accessed the data and might store it and in which other services the data is processed regularly. If you're processing on behalf of a controller data - this search can prove that only authorized individuals have accessed it (Article 28).

Alert Volume

High (?)

SPL Difficulty

Basic

Journey

Stage 4

MITRE ATT&CK Tactics

Credential Access
Privilege Escalation
Collection

MITRE ATT&CK Techniques

Valid Accounts
Data from Information Repositories
Account Manipulation

MITRE Threat Groups

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

Kill Chain Phases

Actions on Objectives

Data Sources

Windows Security
Authentication

   GDPR Relevance

Problem:

Under the GDPR, organizations are required to maintain a complete audit trail about the authorized access of employees/vendors/suppliers to systems and applications that process personal data.

Impact:

Per GDPR Article 15, individuals have the right to ask an organization where their data is stored. In order to fulfill such a request, an organization will need to identify which vendors and processors have accessed the personal data in question, and also identify and report on which other services the personal data in question is processed regularly. When processing personal data on behalf of a controller - there will also be a requirement to prove that only authorized individuals have accessed the data in question (Article 28). If there is an audit trail that shows unauthorized access, then this will need to be documented and reported to the data privacy authorities.

   How to Implement

First, use the results of the data mapping exercise from your data privacy officer to build a lookup that associates systems to the GDPR category. Then do the same for users. Use your data mapping results to build a lookup that associates systems to their GDPR category, and the same for users. At that point, as long as you have the data onboarded with common information model compliance, everything should go smoothly!

   Known False Positives

This will fire when someone is not in the documented list, so the most common scenario is that the documented list is just old. You can think about automating the update of the authorized user list and pull it from the source where you DPO holds the definitive record of authorized users. Another option is to generalize and enrich the information to departments who are allowed access by enriching the username with the department names.

   How To Respond

The most likely scenario when this alert fires is that the documentation is simply out of date. Look for indications that someone should be added to the documentation or removed, but validate with your data protection officer or their team before doing so.

   Help

User Logged into In-Scope System They Should Not Have Help

This example leverages the Simple Search assistant. Our example dataset is a collection of anonymized Windows Authentication logs, during which someone logs into a new system. Our live search looks for Windows Authentication activity across any index in the standard sourcetype.

SPL for User Logged into In-Scope System They Should Not Have

Demo Data

First we bring in our basic demo dataset. This dataset includes interactive logins from Windows Security 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 look up the host in the GDPR categorization lookup. Because we only care about GDPR hosts for this example, we filter for only the hosts that are in scope for GDPR.
Next we look up the user in the GDPR categorization lookup.
Because a user or host can belong to many different categories, we use mvexpand to split them into a multi-value field.
Finally we look for users who don't have a matching GDPR category, or who aren't authorized for any GDPR information at all.

Live Data

First we bring in our basic dataset. This dataset includes logins from Windows Security logs.
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same hour.
Now we summarize the number of logins by user, or destination.
Next we look up the host in the GDPR categorization lookup. Because we only care about GDPR hosts for this example, we filter for only the hosts that are in scope for GDPR.
Next we look up the user in the GDPR categorization lookup.
Because a user or host can belong to many different categories, we use mvexpand to split them into a multi-value field.
Finally we look for users who don't have a matching GDPR category, or who aren't authorized for any GDPR information at all.

Screenshot of Demo Data