Skip to main content
Splunk Lantern

Unauthorized access to systems

You might need to verify that employees, vendors, or suppliers only access to systems they are authorized to view or use when doing the following:

Prerequisites 

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

Example

Lots of different employees, vendors, and suppliers access your systems. You want to ensure that they are authorized to view the data present on any systems they log into. You also want to maintain a complete audit trail about the authorized access of employees/vendors/suppliers to systems and applications that process personal data.

To optimize the search shown below, you should specify an index and a time range. In addition, this sample search uses Microsoft Windows security. You can replace this source with any other authentication data used in your organization. 

  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. At a minimum, the lookup must contain the host field mapped to a GDPR (or other compliance) 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 category.
  5. Run the following search:
source="*WinEventLog:Security" user=* dest=* action=success 
| bucket _time span=1d 
| stats count BY user, dest 
| lookup <name of system lookup you created in step 3> host AS dest OUTPUT category AS dest_category 
| search dest_category=* 
| lookup <name of user lookup you created in step 3> OUTPUT category AS user_category |makemv delim="|" dest_category 
| makemv delim="|" user_category 
| where isnull(user_category) OR user_category != dest_category

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

source="*WinEventLog:Security"

Search Windows security authentication data. 

Note: In this example, we specify the WinEventLog but your environment may only need the tag=authentication, or you may need to add other sources. 

user=* dest=* 

Search all users and destinations.

action=success 

Search only for successful connections.

| bucket _time span=1d 

Group events based on time, effectively flattening the actual time value to the same hour.

| stats count BY user, dest 

Summarize the number of logins by user or destination.

| lookup <name of system lookup you created in step 3> host AS dest OUTPUT category AS dest_category 

Look up the host in the system categorization lookup you created. 

| search dest_category=* 

Filter for events that have a value in the destination 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="|" dest_category 

| makemv delim="|" user_category

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

| where isnull(user_category) OR user_category != dest_category

Look for users who don't have a matching category or who aren't authorized to access any information from the destination systems. 

Result

This search will fire when someone is not in the documented list. The most common scenario is that the documented list is just old. Look for indications that someone should be added to the documentation or removed, but validate with your data protection officer (DPO) or their team before doing so. You can think about automating the update of the authorized user list and pull it from the source where your 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.

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

  • Was this article helpful?