Skip to main content
Splunk Lantern

Unauthorized access to Splunk indexes

You might need to know when a user gains rights to search an index that they're not supposed to have when doing the following:

Prerequisites 

In order to execute this procedure in your environment, the following data, services, or apps are required:

Example

Machine data that is stored within a central logging tool can include personal data. In the case of Splunk, it is 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. This awareness lets you maintain compliance or document and report to authorities as required. You want to find where unauthorized access is occurring in your organization.

To optimize the search shown below, you should specify an index and a time range.

  1. Identify all relevant IT assets from a data mapping exercise conducted by the Data Privacy Officer’s team. These are all IT assets that are relevant to the full audit trail of data processing activities. This includes not only data stores and repositories that house sensitive personal data (PD) and personally identifiable information (PII), but also any technologies that are involved in the processing, storage, transmission, receipt, rendering, encrypt/decrypt, relaying, and handling of such data in any capacity. 
  2. Ensure that those assets are configured properly to report logging activity to an appropriate central repository. 
  3. Use your data mapping results to build a lookup that associates systems to their system category. 
  4. Repeat steps 1-3 for users, instead of systems. At a minimum, the lookup must contain the user field mapped to a GDPR (or other compliance) category. 
  5. Run the following search:
|`User_to_Index_Provisioning_From_Data_Governance_App`
|lookup <name of index lookup you created in step 3> index AS accessible_indexes OUTPUT category AS index_category
|search index_category=*
|lookup <name of user lookup you created in step 3> user OUTPUT category AS user_category
|makemv delim="|" index_category 
|makemv delim="|" user_category
|where isnull(user_category) OR user_category != index_category
  1. Rerun this search on every search head in your environment. Only one cluster member from a search head cluster must be used.

Search explanation

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

Splunk Search Explanation

|`User_to_Index_Provisioning_From_Data_Governance_App`

Run a macro to obtain necessary user permissions information.

|lookup <name of index lookup you created in step 3> index AS accessible_indexes OUTPUT category AS index_category

Look up the indexes in the index categorization lookup you created. 

|search index_category=*

Filter for events that have a value in the index category field.

|lookup <name of user lookup you created in step 3> user OUTPUT category AS user_category

Enrich the field with the user's status from the user categorization lookup you created. 

|makemv delim="|" index_category

|makemv delim="|" user_category 

Split the indexes and users into multi-value fields because each can belong to more than one category.

This syntax assumes that the lookup table user the | as a delimiter. Your lookup may use a difference delimiter, such as a comma separated list. 

|where isnull(user_category) OR user_category != index_category

Look for users who don't have a matching category or who aren't authorized for any information from the indexes at all.

Result

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.

When this search fires, the immediate concern is that a brute force attack was successful. See if it came 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.

Additionally, you should monitor the mapped IT assets changes in logging status, adjust for known outages, and prioritize incident response for any failures to report by hosts that are not scheduled for downtime.

GDPR Relevance: 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. 

For context, the following table shows sample output from the User_to_Index_Provisioning_From_Data_Governance_App macro.

username accessible_indexes roles

user1

bro

ess_admin, ess_analyst, ess_user, user

user1

dns

ess_admin, ess_analyst, ess_user, user

user2

history

ess_admin, ess_analyst, ess_user, user

user2

ioc

ess_admin, ess_analyst, ess_user, user

user2

main

ess_admin, ess_analyst, ess_user, user

  • Was this article helpful?