Splunk SOAR

Filter/Decision block from within an Input playbook

JackTheRipper
Loves-to-Learn

Hey, consider a scenario where you want to create a reusable input playbook that takes advantage 

of the condition blocks such as Filter&Decision. 

For example, an input playbook that receives an ip_hostname, then queries AD over LDAP to check whether the ip_hostname is in a specific OU. that would be easily achievable using Filter/Decision normally, but since its in an input playbook, I haven't seen any output parameters that u can then use as in a main playbook to find out whether the condition was true or false. 

Thanks in advance

Labels (2)
0 Karma

phanTom
SplunkTrust
SplunkTrust

Again, there are many ways to do things in SOAR and we're just trying to give you ideas. 

Sometimes the work needed to build re-usable playbooks, if it's just 1 action and 1 filter/decision, isn't worth not adding it into the main playbook each time as it takes just as much time to input the inputs to the action/decision than an input playbook. 

It depends really on what you are wanting to do with the True/False items?

If true ones are sent to another action then yes, just use the input playbook to work out True and then output a list of them for use later. If you want to get more complicated you can as playbooks allow that. 


JackTheRipper
Loves-to-Learn

the filter/decision blocks doesnt have an output variable that tells you which route it took natively that you can use as a result... 

0 Karma

SOARt_of_Lost
Path Finder

I understand now. If the only thing you need to do is evaluate whether the user exists or not, and there are no actions you need to take down either branch, I'd say a simple custom code block is the way to go. Filter and decision blocks are more useful for deciding a path for the playbook to continue down.

Something along the lines of

if user exists:
    output_variable = True
else:
    output_variable = False

 

0 Karma

JackTheRipper
Loves-to-Learn

custom code block? we are talking about an app action it may vary and a custom code block is not suitable here without further interactions -_- also what if there are 10 different paths, filter/decision simply should result in what path was derived from the condition... just like in ansible

0 Karma

phanTom
SplunkTrust
SplunkTrust

Why not have the input playbook act as a filter and anything that matches your requirement come as an one output and if you want, the others under another output? Then you can work out which was True and which was False?

OR tag/update the artifact that contains the value with something to indicate the result of the check?

There are many ways to do things in SOAR just depends how janky you want to get!

JackTheRipper
Loves-to-Learn

I didnt quite understand what you mean, you are saying for example the input will return the OU of the domain computer and then in automation playbooks I filter it based on the value? if yes, that kinda defeats the purpose of input playbooks?

0 Karma

jenniandthebets
Explorer

I think what you may be looking for is something like the following:

  1. Action block that queries AD for the OU the object is in. 
    1. The object (ip_hostname in your example) is configured as the input at the start of the playbook
  2. Decision Block checking if the OU matches your condition
    • My org had some trouble with these initially, you should configure these like below (rather than the opposite direction,  which is what we were trying initially)

 

if <artifact_datapath> == <the OU you're trying to match>​

3. Each path on your decision block then has a custom code block. You'll need to configure an output variable for the custom block themselves and set it to either True/False 

4. The output of your entire playbook will be set to the variable you configured in step 3.

 

JackTheRipper
Loves-to-Learn

what you said doesnt make sense, in the end I can only choose one variable to return so all of the custom blocks must share the same variable, change it on -the-fly depends on the passed result. sure you can use a custom function e.g passthrough for that but that seems so unnecessary for such a simple task,  thanks anyways I understand the only solutions arent quite built-in 

0 Karma

SOARt_of_Lost
Path Finder

I'm not entirely clear what the problem is here since you decide what the outputs are when building an input playbook. Working off your example, I would say it's better to have the input playbook determine whether the user exists, output that result, then make any decisions in the parent playbook.

0 Karma
Get Updates on the Splunk Community!

Splunk Classroom Chronicles: Training Tales and Testimonials

Welcome to the "Splunk Classroom Chronicles" series, created to help curious, career-minded learners get ...

Access Tokens Page - New & Improved

Splunk Observability Cloud recently launched an improved design for the access tokens page for better ...

Stay Connected: Your Guide to November Tech Talks, Office Hours, and Webinars!

&#x1f342; Fall into November with a fresh lineup of Community Office Hours, Tech Talks, and Webinars we’ve ...