Welcome the third part of our series on how to build an automated incident response playbook for phishing threats inside of Smart SOAR. In this part, we will be transferring our rough wireframes into the playbook editor to create a more realistic understanding of how the workflow will look and what we may need to make it operational.
In the first two parts of this series, we covered the important phases that inform good playbook development. You can catch up on those by following the links below:
Building the Event Playbook
Once the wireframing is complete and the logic has been agreed upon by the relevant people, the next step is to build the workflow inside of your playbook editor. In Smart SOAR, we use the event playbook engine to build and execute the triage stage. To learn more about Smart SOAR’s two-tiered automation, read this article.
When an alert is ingested into Smart SOAR, it is first stored as an event. Then, if it needs to be investigated further, it can be escalated into an incident. This lets users build triage, correlation, and verification workflows into the event level, while incident response and analysis can be kept for the incident level.
The triage stage of our phishing workflow looks like the following:
When a phishing event is ingested it kicks off the playbook. The first stage is the DMARC check, where two conditional tasks are used to select the correct risk score to apply to the event, if any. Then the workflow proceeds to SPF and DKIM verification, which follows a similar process:
Finally, the risk score is collected and compared against our benchmarks. The correct severity can then be assigned to the event and it is either escalated into an incident or dismissed as a false positive.
Building the Incident Playbook
To build the incident playbook, we will leverage Smart SOAR’s utility commands. Utility commands are actions or workflows that can be reused in different playbooks without needing to be rebuilt. For example, here we have built the Recipient Email Enrichment workflow as a utility command, and used it as a block in the phishing incident playbook (denoted by the chain-link to the right of the command). If needed, this utility command could be used in a different playbook, reducing the time needed to build and maintain various playbooks.
Recipient Email Enrichment Utility Command
Utility Command Used In Parent Playbook
We can follow a similar process for the other enrichment workflows and end up with the following design:
As each task is stacked on top of one another, they will execute in parallel rather than sequentially, ultimately saving time through the entire playbook.
We can do the same with Containment and Recovery and end up with the complete workflow:
Next Steps
In part four of this series, we will run test data through the workflow and ensure the commands are triggering as needed. Then, we will publish the playbook and make it live on the site to see how it works with production data.
