FortiSOAR Knowledge Base
FortiSOAR: Security Orchestration and Response software provides innovative case management, automation, and orchestration. It pulls together all of an organization's tools, helps unify operations, and reduce alert fatigue, context switching, and the mean time to respond to incidents.
Andy_G
Staff
Staff
Article Id 195283
Description

In order to provide feedback to the user running a playbook we devised a "running log" of sorts for when we run Intelligence Enrichment playbooka against an alert. Although any results found are attached and related to the source alert, this log helps see at a glance what Intel sources were run in addition to when and how many results were found. 

When starting the action playbook from the alert you'll need to collect the current value of the "running log" field using a set variables Step. We named ours intelenrichment. And you'll need to grab the source alertID as well. 

  

HTML
input_log = {{vars.request.data.records[0].intelenrichment}}
input_alertID = {{vars.request.data.records[0]['@id']}}


NOTE: if you are using a map playbook to iterate through multiple selected input records it will be "{{vars.loop_resource.intelenrichment}}" where the map playbook collection is "{{vars.request.data.records}}". Same goes for the @id field as well. 


Next build out your playbook and API calls or connectors. At the end of the playbook (we did it at the end of the action playbook) you can put in a step to "Update Resource".


image


As you can see it cut off the syntax for the resource. Here it is:


  

HTML
{ "intelenrichmentment":  "
<p style='color:LightSeaGreen;'> 
<hr>
 === Source: HybridAnalysis ===<br>
 == Time: {{arrow.get().to('UTC').format('YYYY-MM-DD HH:mm:ss ZZ')}} ==<br>
 == Total of {{vars.event_count_total}} Found, Returned Top {{vars.event_count_returned}} Based on Date == <br>
Added by {{vars.playbook_run_by_firstname}} {{vars.playbook_run_by_lastname}} =
=<br>
</p> <p> Found Results and Inserted Into Intel Search Results </p> 
<p> {{vars.input_intelenrichment}} </p>  
" }

  

There are several variables in here that are likely not being mapped, so lets walk through this. 

  • Line 1 we are telling what field we want to update
  • Line 2 we are defining the color scheme of the Text we are placing into the field
  • Line 3 is a horizontal line to separate the log entries from the next entry
  • Line 4 states where the results were run, this can be substituted for a variable set at the beginning to make it more dynamic
  • Line 5 sets the current time this field was updated in a human readable format using arrow
  • Line 6 describes the data retrieved, such as how many results total were found versus how many were returned by the API. These are two variables set after the results are returned. You can use the modifier "length" to count how many values you have in your results, such as {{vars.results.records|length}}.
  • Line 7 shows us who ran the playbook. This info is retrieved via a script (csop crud request) for the currentUser variable, which we'll be able to grab the user's first name, last name, email, phone number etc, and set those to variables. This is something you can do from the beginning of the playbook. Example below:
  • Line 8 shows the user some sort of text, in this case just lets the user know results were found and inserted/related
  • Line 9 is used to place the original value of intelenrichment so the new "log entry" shows at the top of the "running log". You can easily reverse this if you want it to show at the bottom of the log as well by putting this on line 3 instead.

image



Hope this helps for some use cases out there, its a good way to troubleshoot from a user without permissions to the running playbooks logs. If there is no log entry in the rich text field, they know the playbook broke or didn't complete somewhere. It can also make an entry when there are Zero results, so the user knows it did complete, but nothing was found. This is likely the most useful use case given there will be no new relationships or fields edited, meaning the user might thing it failed and run the playbook again.






Fortunately this was incorporated into 4.10 with the addition of Collaborate. This allows the posting of messages for the user, which I believe was introduced in 4.10.1. Its great stuff and effectively replaced my need for this log. But this is a good concept in terms of taking previous data keeping it intact and posting new data, as it can be useful for several other things. 


Contributors