Splunk's Adaptive Response Framework

Before I start this post, I want to give a quick shout out to Splunk. I recently just got back from my first .conf and I have to say, overall it was one of the best conferences I've ever been to.

Seeing all of the great talks made me want to do a better job of documenting some of the item's I've worked on over the past few months, especially with regards to the Adaptive Response framework within Splunk Enterprise Security.

Overview of Adaptive Response
For those of you who are not very familiar with it, I highly recommend reading the Splunk Dev page on it found here, but at a high level, it's a way to streamline your notable events and add some automation to the mix.

I know, I know, but Phantom does all of that and 100x more. I 100% agree with you and would love to use Phantom but due to various reasons, we do not have that right now so we're trying to utilize as many features as possible within Splunk without paying anymore $$.

Unfortunately due to the Phantom acquisition, there doesn't seem to be much of a focus on Adaptive Response and it was one of the few things I was disappointed about at the conference. Thus, why I'm creating this post now!

How to Create Your First AR
To start out, we'll go through the high level steps to create an Adaptive Response rule. The full details can be found in Splunk's documentation.

1.  Install the Add-on Builder from Splunkbase.

• I've read quite a few things about not installing this on a production ES search head due to performance reasons but overall we haven't had that big of an issue with it. From time-to-time it will take a significant time to save the app but overall we found that it's easier to run through test cases directly on it due to our environment. If you have a few dev/test environment, I would do it there.

2.  Now that the Add-on builder is installed, depending on the permissions you may need to log in as Admin and ensure whoever is creating these responses has the appropriate permissions. You can then access it from the App drop down menu on the top left.

3.  Once you are in the app, select "new Add-on" and give it whatever name you want. The naming scheme will vary greatly depending on the organization but just make sure you keep a similar naming scheme across the board that is very clear for the analyst to know what action is being performed.

4.  After you create the app, it will then take you another screen where you can start digging into what you want the app to truly do. For our use case, we are only interested in Adaptive Response so we're going to only use the "Create Alert Actions" field. Then select "New Alert Action".

5.  The first screen, Properties, is fairly self explanatory. The main thing you want here is to yet again abide by a naming convention and make sure you select the "Support as an ad-hoc action" button. For ours, we also gave each Adaptive Response (AR) a generic source type so we can search for it later if needed.

6.  The next page is where we finally get into doing some actual work and not just clicking through everything. This is where you define various variables that will either be hard coded, pulled from the notable events fields, or have a free form/drop down option for the analyst to pick.

In the screenshot below, you can see I have multiple variables that I'm pulling out from the notable as well as three fields that allow the analyst to pick who it's assigned to, what the sub-classification is, and the default description. 

7.  The final page is where half of you will be really excited that you can write some Python and the other half will probably cry. This is where all of the variables you defined in the previous screen come together and you tie it into whatever automated action you want to occur. 

Before we move on, I will start out by saying I am not a programmer. There are probably plenty of items in the code that will make you real programmers cringe, but the code works. I welcome any recommendations and will always try to make things better as I can.

Now that the disclaimer is over, let's move on. Here is a fairly modified version of the code we're using to auto create ServiceNow tickets based off of Splunk malware notable events.

I removed about 60 lines that we use for tying into CMDBs and routing tickets depending on geographic location, host name, etc. But to make things simpler, I removed the majority of it and focused on how to create the SN ticket with variables and update the notable.  

Adding AR to Correlation Rules

Now that you have AR setup, tested, and ready to roll, let's add it to the correlation rule. This process is pretty easy so we'll blow through it in a few steps.

1. Enterprise Security --> Configuration --> Content --> Content Management
2. Select the correlation rule you want AR to be tied to. 
3. At the bottom of the screen, select the Notable event that you have already setup and simply click on "Insert Adaptive Response Action" to the "Next Steps" field.

Bringing it All Together

Now when an analyst opens a notable event they'll see your AR rule ready to roll.

The screenshot below is from a notable event that popped in the Incident Review page. Once you click on the Host-AV next steps, it will bring up the previous screenshot that will pull the variables and allow you to edit whatever you want to.

After that finishes, it will update the history with the SN ticket URL as well as close out the notable event.

Closing Notes

This is just one of many examples of what we've been doing with AR. While there is a decent learning curve and some gotchas along the way, I think it's a highly under utilized tool that allows you to streamline your workflows.

Assuming this is useful for others, I can add some of the more complicated ones we've done that don't require any analyst interaction at all and just runs ARs once notables are hit.

Please let me know if you have any questions/comments.