User Has Access to In-Scope Splunk Indexes They Should Not

Description

Alerts the first time a user gains rights to search an index that they're not supposed to according to the output of a GDPR data source and GDPR user mapping exercise.


Use Case

Insider Threat, Compliance

Category

GDPR, IAM Analytics, Operations

Alert Volume

Low (?)

SPL Difficulty

Basic

Journey

Stage 4

Kill Chain Phases

Actions on Objectives

Data Sources

Any Splunk Logs

   GDPR Relevance

Impact

Per Article 6, data can only be accessed and used for the legitimate reason it needed to be collected and lawfully processed. This lawful processing requires meeting specific criteria, such as the data subject has consented to processing, or processing is necessary for the performance of a contract with the data subject, or for compliance and legal obligations, or for protecting the vital interests of individuals, or for public interest reasons or the legitimate interests by the controller or a third party. Machine data that is stored within a central logging tool can include personal data -- in the case of Splunk, as stored within indexes or as the result of functions performed within Splunk such as enrichment or correlations across data sources. Therefore it is critical to be aware of when a user has access to in-scope Splunk indexes when they should not, to maintain compliance and / or to document and report to authorities as required.

   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 a GDPR category. Then do the same for users. Then the search should work smoothly. Importantly though, this information is held on the search head, so if you have multiple search heads in your environment you will need to run this search on every one of them (only one cluster member from a search head cluster must be used).

   Known False Positives

The only known scenario where this search could generate false positives is if you have a single source (for example, a web app) that centralizes the authentication for many people. In that scenario, you might need to adjust thresholds for that source, or exclude it and build a separate similar search just using the logs from that host.

   How To Respond

When this search fires, the immediate concern is that the brute force attack was successful. See if it is coming from a host that typically logs in with that account to make sure it is not just coincidental, and then reset the password for any compromised accounts and look for any other places where that username was used.

   Help

User Has Access to In-Scope Splunk Indexes They Should Not Help

This example leverages the Simple Search assistant. Our example dataset is the output of very long and complicated macro (see the live search).

SPL for User Has Access to In-Scope Splunk Indexes They Should Not

Demo Data

First we bring in our basic dataset. This is the output of an exceedingly complicated macro that pulls from Splunk's authorization information. 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 enrich the index field with the GDPR category.
Because this is a GDPR search, we search for just the GDPR in scope indexes.
Next we enrich the user field with the User's GDPR status.
Because a user or index 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 dataset. This is the output of an exceedingly complicated macro that pulls from Splunk's authorization information, which was grabbed for Data Governance.
Next we enrich the index field with the GDPR category.
Because this is a GDPR search, we search for just the GDPR in scope indexes.
Next we enrich the user field with the User's GDPR status.
Because a user or index 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