Example of new users taking privileged actions?

[adukes_splunk]

Does anyone have examples of how to use Splunk to check for new users taking privileged actions?

[adukes_splunk · Accepted solution]

The Splunk Product Best Practices team helped produce this response. Read more about example use cases in the Splunk Platform Use Cases manual.

For more information on this and other examples, download the free Splunk Security Essentials app on Splunkbase.

Most large organizations have strict controls to find users enacting privileged actions. While most users who suddenly start taking privileged actions are legitimate, there can be a risk when a user suddenly exercises privileged rights they have had for a while or uses new rights. Combine these events with other risky behavior to identify users for the Insider or SOC team to analyze.

This use case is from the Splunk Security Essentials app. Check it out for more examples and demo data for this type of use case.

Load data

This use case depends on authentication data from Windows, Unix and Linux, or any data properly tagged as privileged. While only one data source is required to get insights, collecting multiple data sources provides a more comprehensive view of the environment's security.

Best practice: Use the Splunk Add-on for Microsoft Windows to accelerate time to value the necessary Windows filesystem data. For details, see Is it a best practice to use the Splunk Add-on for Microsoft Windows? on Splunk Answers.

1. Enable the [WinEventLog://Security] input in the add-on to collect Windows security data. For details, see our post How do I collect basic Windows OS Event Log data from my Windows systems? on Splunk Answers.
2. Deploy the add-on to the search heads to use the Common Information Model to normalize the data at search time. See Install the Splunk Add-on for Windows in Splunk documents for the procedure.
3. Enable Windows to generate file system monitoring. For instructions, see Monitor file system changes within the Splunk Enterprise Getting Data In Manual.
4. Run the following search to verify you are collecting Windows data: earliest=-1day index=* source=win*security tag=endpoint tag=privileged | head 10

Best practice: Use the Splunk Add-on for Unix and Linux to accelerate time to value with Unix and Linux data.

1. Enable the [monitor:///var/log] input in the add-on to collect the Linux security data. See Enable data and scripted inputs for the Splunk Add-on for Unix and Linux in Splunk docs for the procedure.
2. Give Splunk permission to read the /var/log/secure file to allow Splunk to monitor the Linux secure data. For details, see Which UNIX permissions are best for monitoring files? on Splunk Answers.
3. Deploy the add-on to the search heads to use the Common Information Model to normalize the data at search time. See Install the Splunk Add-on for Unix and Linux in Splunk docs for the procedure.
4. Run the following search to verify you are collecting Unix and Linux data: earliest=-1day index=* sourcetype=linux_secure tag=privileged | head 10

Best practice: Since Splunk normalizes values from multiple source types regardless of source or format, it’s a best practice to make sure your data is CIM-compliant. For more information about CIM and the Splunk Common Information Model (CIM) add-on see the Splunk Common Information Model Add-on Manual. Run the following search to verify you are searching for normalized privileged data and ready for this use case: earliest=-1day index=* tag=endpoint tag=privilege | head 10

For more details about the Common Information Model, watch the following video.

Get insights

This search records when a user who suddenly starts taking privileged actions.

Best practice: In the searches below, replace the asterisk in index= with the name of the index that contains the data. By default, Splunk stores data in the main index. Therefore, index= becomes index=main. Use the OR operator to specify one or multiple indexes to search. For example, index=main OR index=security. See About managing indexes and How indexing works in Splunk docs for details.

Top Users Taking Privileged Actions

index=* tag=privileged
| stats count by user _time 
| stats sum(count) as count by user 
| sort - count

Privileged Actions Over Time

index=* tag=privileged 
| bucket _time span=1d 
| stats count by user _time 
| timechart span=1d sum(count) as count

Known false positives: If an event is incorrectly marked with a tag=privileged, this alert is false. This can be tuned through the eventtypes by adding search terms like NOT EventCode=XXXX to block event IDs (XXXX) that you do not find valuable.

How to respond: Determine if the event is not expected from a user with their existing permissions. If that's the case, review the groups the user is a member of or see if a local account with the same username exists that may be the source of these rights. Evaluate whether the event is allowable or not.

If no results appear, you may need to deploy the add-ons to the search heads to use the knowledge objects necessary for simple searching.

[adukes_splunk]

Added related video.