Hi all,
I am using Splunk SOAR Community Edition and have a general question on how to correctly trigger a playbook.
I am thinking of a scenario where an external alert from a SIEM like qRadar or Elastic should trigger a playbook. For example, a bruteforce alert should trigger a bruteforce playbook, a portscan alert should trigger a portscan playbook, and so on. Unfortunately, it is only possible to assign the same labels to all incoming SIEM alerts. Based on these labels a playbook is then executed.
Is there any way to assign the labels based on the type (e.g. a field of the alarm) of the incoming alarm or to solve the difference between alarms in another way?
As a workaround, I was thinking of a "general" playbook that distributes incoming alerts to specific playbooks. But is that really the best way to solve the problem?
I'm looking forward to some ideas or hints. Thank you very much in advance.
kind regards
simon
@saiiman when you setup the integration between SIEM and SOAR you use an automation account. These accounts can be attached to labels. Therefore if you create an automation account for each "use case" and assign a specific label, when the SIEM or other source sends an event with that automation account, the label stipulated will be attached to the container.
Your "landing playbook" idea is also valid! You can either just send it to the relevant playbook or even "flip the label" once you understand where it's meant to go and by flipping the label it will cause the active automation against that label initiate too!
I would use the landing approach for use cases where there are similarities; I.E. If the use cases need enrichment then maybe do that first for all events, then flip the label or direct to a sub-playbook based on <some_data>.
Hope this helps, if so please mark as the Solution.
Happy SOARing
@saiiman when you setup the integration between SIEM and SOAR you use an automation account. These accounts can be attached to labels. Therefore if you create an automation account for each "use case" and assign a specific label, when the SIEM or other source sends an event with that automation account, the label stipulated will be attached to the container.
Your "landing playbook" idea is also valid! You can either just send it to the relevant playbook or even "flip the label" once you understand where it's meant to go and by flipping the label it will cause the active automation against that label initiate too!
I would use the landing approach for use cases where there are similarities; I.E. If the use cases need enrichment then maybe do that first for all events, then flip the label or direct to a sub-playbook based on <some_data>.
Hope this helps, if so please mark as the Solution.
Happy SOARing
Hi,
your suggestion to flip the label fits for me. I think this is the most elegant solution to manage different types of alarms from one source.
Thank you for your help.