The automation aspect of SOAR platforms acts as a force multiplier for the SOC teams. Automation is achieved with the help of playbooks. Analysts can design playbooks to implement their use-cases and automate repetitive tasks, allowing the SOC team to focus on high-value activities and investigations.

Playbooks in SIRP allow the automation of security processes across external systems. SIRP provides a user-friendly, drag-and-drop-based canvas to design your playbooks.

Playbooks can be accessed by selecting Playbooks from the Main Menu.

There are three main options in the playbook module:

You can also view, edit, and delete playbooks by clicking on the respective icons provided in the Actions column.

Users can also create playbooks by configuring rules, conditions and activities, phases and tasks, and apps.

In SIRP, you have the option to import and export playbooks as per your requirements. This option helps you maintain a backup of your playbooks and re-import when required.

To create your own playbook, click on the Create Playbook button provided at the top of the page.

You can also view, edit, and delete playbooks by clicking on the respective icons provided in the Actions tab. Each playbook can be enabled or disabled based on its usage requirements.

Playbook Logs help users view the entire lifecycle of playbooks. You can access the logs by selecting Playbooks from Main Menu and then clicking Playbook Logs from the top.

This output shows the details of the playbook such as container name, type, status, and execution time.

By clicking on the view button under the Actions column, you will be able to view each action and its status.

For example, in this playbook, the actions in green denote that they were executed successfully, while the actions in red denote execution failure.

This allows an analyst to gain complete visibility into the status of each action.

After clicking the actions on the green, you will be able to view the results of the command.

This output shows the results of the get_hash_info action.

Use Case Family is intended to help security teams quickly evaluate the stack of playbooks under different categories.

For example, Phishing playbooks will go into the Use Case Family of Phishing.
​
An administrator has the right to Add, Enable or Disable any Use Case Family. However, a user can choose their desired category via the drop-down menu while creating a playbook.

The playbook canvas provides you with an easy-to-use, drag-and-drop interface to design your playbooks. The playbooks are designed by using the available playbook components.

This component signifies the starting point of the playbook. This is available on the canvas and cannot be removed. This is where the playbook begins, i.e. the actions following this component will be the first ones to get executed.

This component is used to execute a certain action. You can drag an action item from the left pane and drop it inside the main canvas. Clicking on the action will open a slide-in form containing the configurational parameters of that action.

In the configuration form, you can select the App followed by an Action belonging to the selected App. Click Save to save the changes.

Action Output Filtering

You can click on the filter icon, placed next to the Actions label in the Action Configuration pane to view the action’s sample output data. Clicking on the icon will display a popup with Action’s sample output.

This is useful in case you wish to use the output of an action and feed it to another Action or Decision. Use the filtering option to pick the desired dataset that you wish to use.

To design your filtering query string, use the following example as a reference:

Sample Output of AlienVault OTX

This output also contains a search bar that can be used to search any parameter.

Data Filtering

The data filtering queries in SIRP’s playbook allow an analyst to run filtering queries on the output results.

Example 1: If you wish to get the value of the “hostname” from the above output, you will select and copy the parameter from the output and click on the Result button:

If the query is correct, the “Filtered Output” section will show you the fetched value(s). In this case, the output value would be “login.rewterz.com, rewterz.com, blog.rewterz.com”.

Example 2: If you wish to fetch all the values of a particular array, for example, general > pulse info > references, use * at the end to traverse and get all the values of the array.

Example 3: If you wish to fetch the values or datasets of an index of an array (instead of recursively fetching all the values), replace * with an (index) number. For example, instead of recursively fetching all the values of all the indexes of the pulses array (in Example no. 4 above), if you want to fetch the values of the first index, your query will change to this:

Notice the 0 between pulses/ and /tags instead of *. This will result in getting the values of only the first index of the pulse array rather than all. The query will function like this:

The result would be ALL the tags of the first index of the pulses.

Example 4: Similarly, if you want to fetch just the second value of tags i.e. “brute force”, your query will change to this:

Users can drag the decision component from the left pane to the main canvas. The slide-in form allows you to define AND/OR based conditions on the output values of the actions directly connected and preceding the Decision.

In the configuration form, copy and paste the output filter query (from one of the actions connected to this decision) in the Field. Select a Condition, enter the desired that you want to compare with the output then click Add.

Normally, each action uses the data from the container (incident, alert, investigation, vulnerability, threat intelligence) for execution. But if you want an action to use the output of another action (instead of artifacts in the alert) as its input, then we use the Filter component.

For example, if the output of one action is “IP Address” and you want to feed that IP address as input of the second action that takes the IP address as input and returns its location. Then you will use the Filter component in between the two actions to pass the output of the first action as input for the second action.

When you click on the Filter icon, you get a slide-in configuration form containing just one field. Use the same output filtering query as you use in the Decision to fetch the desired value from the last action.

Connectors are elements that connect two playbook components together.

Every component in the playbook has four joining points that appear when you mouse over on the component. As soon as you click on any of the four joining points and drag your mouse, this connector will appear, allowing you to connect one action with another action

Click on the Playbook Settings button at the top right corner of the canvas to configure playbook settings. When you click on the Playbook Settings form, a slide-in form appears that allows you to configure the following properties:

A Rule can be added in the playbook to make it automatically executable when certain conditions are satisfied. In the rules editor pane, the user is required to input Rule Name, Container, Name, Source, Category, Subcategory, Disposition, Sub disposition, Location, Severity, and Status. Any of the parameters will define how and when the playbook should be executed automatically without any intervention from the user.

The playbook marketplace contains out-of-the-box playbooks in SIRP. These playbooks are designed by SOAR Engineers who have gathered years of experience in building use cases and playbooks in various organizations.

Some playbooks in the marketplace are:

Users can easily view the playbook details by clicking the eye button. Playbook details contain information about the use case, it's dependencies, required integrations, actions, and type of inputs.

Playbook Details also shows the playbook canvas.

Users can import these playbooks in their own SIRP instance by clicking import button.