Understanding Phantom ROI Summary Metrics

Image of Phantom ROI Widget

Splunk Phantom has a useful widget on the dashboard called Automation ROI Summary. With it, we get a summary of automation gains made with Phantom, including the total resolved events, mean dwell time, mean time to resolve, and some metrics around “return on investment” or ROI. These ROI metrics can be a bit mysterious in how Phantom calculates them, so in this blog post, I’ll go over just that and how to tweak them to fit your environment.

Continue reading “Understanding Phantom ROI Summary Metrics”

Splunk Phantom Tips: ES Notable Playbook Validation

When using Splunk Phantom to process notable events from Splunk ES, a best practice is to validate that the playbook the analyst is running is the right one for that notable event and they are running it on the correct artifact. Here are two tips for doing just that:


Decision Block

At the beginning of your playbook, put a decision block that matches on the relevant field in the notable event. For example, if your playbook is for notables with the search_name “My Search Name”, your decision block condition would be artifact:*.cef.search_name == My Search Name. Off of the condition point would be the rest of your playbook, and you can also add an else condition to send feedback to the analyst such as a comment or a prompt displaying the an error such as “Playbook canceled – Search name does not match”.


Filter Block

You can use a filter block to make sure the analyst is running the playbook only on the notable artifact. The condition in the filter block would look similar to the decision block condition, or could be as simple as checking that the search_name field isn’t blank. The difference with the decision block is that now you use the filtered list of artifacts all throughout your playbook. For example, if you’re building a description for a ticket, instead of using the normal artifact:*.cef.whatever you would select the filtered artifact list and it would look something like filtered-data:filter_x:condition_1:artifact:*.cef.whatever. This avoids the issue where if there is more than one artifact, you get a list of values for the artifact fields such that artifact:*.cef.search_name would be output as something like “My Search Name, None, None”.


Implementing either or both of these tips in your playbooks will dramatically reduce playbooks being run on the wrong notable events or artifacts. I’d love to hear any tips you’ve discovered or thoughts you have on this use case so feel free to leave a comment or hit me up in the Splunk Phantom community slack (@rplas).

Splunk Phantom Tips: How to Get the Username of the User Who Ran a Playbook in That Playbook

This is an issue I ran into recently. I wanted to assign a task to the user who ran a playbook, but that was easier said than done. The first step is to get the effective_user_id of the playbook. We can do this by creating a custom code block, so that we can pass around the user id later in the playbook. The custom code block doesn’t need any input parameters and should have an output parameter of effective_user_id.

Code-wise, you really only need two lines. First, we make a call to phantom.get_playbook_info() (docs). This returns “a list containing a single dictionary” that looks something like this:

[{
    'parent_playbook_run_id': '0',
    'name': 'test_plabook',
    'run_id': '37',
    'scope_artifacts': [],
    'scope': 'new',
    'id': '562',
    'repo_name': 'local',
    'effective_user_id':5
}]Code language: JavaScript (javascript)

The item we’re interested in is effective_user_id so our second line of code is grabbing that and assigning it to the output variable we named in the custom code config. The finished product looks like this:

################################################################################
## Custom Code Start
################################################################################

info = phantom.get_playbook_info()
    
custom_function_1__effective_user_id = info[0]['effective_user_id']

################################################################################
## Custom Code End
################################################################################Code language: Python (python)

Now, we have the used id of the user who ran the playbook. This will work for things like setting the owner of a container, which can take the user id, but there are other actions, like assigning a task, that take a username as a parameter. Getting the username from a user id is a bit of a process, but it’s not too complicated. It takes three steps:

  • Format the REST API endpoint
  • Call the REST API endpoint
  • Modify the Task block to use the data from the REST API

First, we use a format block to create the REST API endpoint we’ll be calling. The template will be /ph_user/{0} and the value we’ll use to fill the template is our effective_user_id value that we get from the custom code block. It’ll end up looking like this:

Next we’ll feed this into an HTTP get data action block. This will require that you’ve created an HTTP asset that is pointed at your phantom instance. The config for this block will just be the location which is what we’ve created in our format block.

Now that we’ve done that, we can modify the task block (or whatever other block you’re using) to get the username from the HTTP block. This will require some custom code, but nothing too fancy.

Again, we’ll need only two lines of code to get the username. One to get the username data from the HTTP action results and another to parse it out of the returned list. It’ll end up looking something like this:

results_data_1 = phantom.collect2(container=container, datapath=['get_data_2:action_result.data.*.parsed_response_body.username'], action_results=results)

username = [item[0] for item in results_data_1][0]

.
.
.

phantom.task(user=username, message=message, respond_in_mins=30, name="task_1")Code language: Python (python)

Be aware that your function names (get_data2, format_1, custom_function_1, etc.) may be different than what I have based on where this is happening in your playbook.

You now have a task that is assigned to the user that ran the playbook. This can be useful for getting feedback from an analyst during the playbook run or handling an action that can’t be automated for whatever reason.

Using WordPress Transients for Speed and Profit

In this post, I’ll be going over what transients are, how to use them, and why you should use them.

What are Transients?

Transients are a way to cache information in WordPress.  They are very similar to WordPress Options with one key difference: Transients include a lifespan.  We’ll get into what that means in the next section.

Continue reading “Using WordPress Transients for Speed and Profit”