Building a Departmental Peer Group

Description

Build a departmental peer group that can be used by the detections in Splunk Security Essentials.


Use Case

Compliance, Insider Threat

Category

Insider Threat, Compliance

Security Impact

In order to do peer group analysis, you must first build out departmental peer groups. This search will convert a peer group into the format that the searches in this app expect.

Alert Volume

Very Low (?)

SPL Difficulty

Medium

Journey

Stage 4

Data Sources

Windows Security

   How to Implement

There are multiple approaches for pulling Active Directory data:

  • Using the Supporting Add-on for Active Directory (aka SA-ldapsearch) which provides the ldapsearch command -- recommended for on premises installations in organizations with fewer than 50,000 users (app link, docs link).
  • Using data from AD Monitor, which is the Splunk Universal Forwarder's ability to monitor Active Directory for changes -- recommended for large organizations, and for Cloud environments (doc link).
  • Using a Powershell script to query Active Directory for this data (link).

Once the AD data is ingested, running through the search is straightforward you should be good to go.

   Known False Positives

Not Applicable

   How To Respond

No alerts will be generated by this search.

   Help

Building a Departmental Peer Group Help

This example leverages the Simple Search assistant. Our dataset is the output of an LDAP Search, which we are transforming into a departmental peer group that we can use in our other detections.

SPL for Building a Departmental Peer Group

Demo Data

First we bring in our basic demo dataset. In this case, anonymized LDAPSearch Output. 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 filter for just users that have a department defined.
Renaming sAMAccountName makes things easier to type, and also conforms to the Splunk Common Information Model
Now we focus on just our most relevant fields.
Eventstats allows us to distribute values across multiple events, without changing any existing values. In this case, we're taking all of the values for username per department, and adding them together. Every row will have three fields, the department name, the user name, and a multi-value field with each member of that department.
Multi-value fields get tricky when we persist them to disk. I always control the process, by making it a single value, comma-separated list.
Finally, we output this to disk.

Live Data

Okay, this is pretty tricky. Because ldapsearch (at least in my testing) doesn't allow us to look for users who are members of particular groups (which would be so much simpler, much like the VIPs from LDAP example), we have to first pull the list of privileged groups and then look for the information of every user in those groups. We will start by pulling the list of privileged groups. As noted in the How To Implement, there are many different approaches to ingesting this data -- ldapsearch is generally the simplest to get started with.
Renaming sAMAccountName makes things easier to type, and also conforms to the Splunk Common Information Model
Now we focus on just our most relevant fields. ldapsearch will also give us several other fields that we don't care about (such as _raw), and | table will get rid of them while putting the output in the proper display mode.
Eventstats allows us to distribute values across multiple events, without changing any existing values. In this case, we're taking all of the values for username per department, and adding them together. Every row will have three fields, the department name, the user name, and a multi-value field with each member of that department.
Multi-value fields get tricky when we persist them to disk. I always control the process, by making it a single value, comma-separated list.
Finally, we output this to disk.

Screenshot of Demo Data