Example of a brute force access behavior detected use case?

adukes_splunk — Mon, 09 Sep 2019 21:33:20 GMT

Does anyone have examples of how to use Splunk to check for brute force access behavior?

Re: Example of a brute force access behavior detected use case?

adukes_splunk — Mon, 09 Sep 2019 21:34:39 GMT

The Splunk Product Best Practices team provided this response. Read more about How Crowdsourcing is Shaping the Future of Splunk Best Practices.

In this use case, we'll explore how to use Splunk Enterprise Security to detect excessive number of failed login attempts followed by a successful login which can indicate a successful brute force attack.

Load data

This use case depends on authentication data as defined by the Common Information Model (CIM). For simplicity, this example uses authentication data from from Windows and Unix or Linux, but any data properly normalized for the authentication data model works well. It’s a best practice to use the CIM to normalize data at search time, but before you put in effort to create new knowledge objects, check Splunkbase to see if such a CIM-compatible app or add-on already exists.

Best practice: In searches, 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.

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

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.
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.
Run the following search to verify you are collecting Windows data: earliest=-1day index=* source=win*security tag=authentication user=* src=* | head 10

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

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.
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.
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.
Run the following search to verify you are collecting Unix and Linux data: earliest=-1day index=* sourcetype=linux_secure tag=authentication user=* src=* | 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 authentication data and ready for this use case: earliest=-1day index=* tag=authentication user=* src=* | head 10

Get insights

This scenario uses the Incident Review dashboard in Splunk Enterprise Security and underlying correlation searches. Use the following procedure to discover incidents:

Navigate to the Splunk Enterprise Security web user interface.
Select Incident Review from the top navigation bar.
Select the text box under Correlation Search, begin typing Brute Force Access Behavior Detected, then select the appropriate result from the result set.
Select Submit to display notable events.

Review the Overview of Incident Review in Splunk Enterprise Security in Splunk docs for guidance on how to triage and act on resulting incidents. If no results appear, there may not be any notable notable events. However, you may need to enable correlation searches.

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.

Re: Example of a brute force access behavior detected use case?

sloshburch — Thu, 03 Oct 2019 19:10:06 GMT

Added related video content.

topic Re: Example of a brute force access behavior detected use case? in All Apps and Add-ons

Example of a brute force access behavior detected use case?

Re: Example of a brute force access behavior detected use case?

The Splunk Product Best Practices team provided this response. Read more about How Crowdsourcing is Shaping the Future of Splunk Best Practices.

Load data

Get insights

Re: Example of a brute force access behavior detected use case?