Blog 5 - Cortex XSOAR pt. 6
Recap of Last Week
Last week, we talked about how data is stored in context and how it can be manipulated through filters and transformers.
Today we’ll talk about inputs and outputs for playbooks.
Playbook Inputs
Just like how a function (or method in Java) can have parameters with values which act as input for the function, playbooks can also take input. You can even think about sub-playbooks as black boxes. All you need to do is pass in the correct parameters.
Inputs for a playbook
When setting inputs for playbooks, you can make them optional or mandatory. If you don’t pass in a value for an optional input, no error will occur. However, if you require an input to be mandatory and don’t pass a value in, the playbook will run into an error and stop. You can also give inputs a default value, which will be overriden if you pass in a different value to the playbook. You can also set a description to each input parameter. It’s always good practice to add a short description so that anyone looking at the playbook can easily figure out the purpose of having that input. Documentation is extremely important! No one will ever be mad at having more information than none.
Playbook Outputs
Again, similar to traditional programming functions, playbooks too can return outputs. Of course, if you’re using a playbook to simply automate some tasks, like activating a user’s AD account a day before their hire date, you won’t necessarily need any outputs to be returned. Think carefully about the data you need for a task. You don’t want to clog up the context data by creating unnecessary objects that won’t be used for another playbook down the road.
Outputs for a playbook
An important thing to note about outputs is that you can set the data type for each of them. This matters because it will limit the type of operations you can do on the output objects. Using the picture above for example, Endpoint.OS has its data type set to string. This means that you won’t be able to use any operators or transformers like Array to String. You can always set the data type to be Unknown, however you should set a specific data type if you know what it will be. This way if you get garbage input for that value later on, like a numerical value when it should be a string, you can validate your input and know that it’s incorrect.
Next Week
I’m still unsure what the next blog post will be about, but this might be the end of my series on Cortex XSOAR. I hope you enjoyed reading about XSOAR and I encourage you to try it out if you can. It’s got a bit of a learning curve, but it is definitely an exciting tool to use!