Phishing

How to Build a Phishing Playbook, Part 2

Phishing Alert text button on keyboard

95%. That’s the percentage of respondents to MSSP Alert’s Top 250 MSSPs Survey that said they mitigated phishing incidents for their customers in 2023. The ubiquity of phishing attempts — and in most cases, their relative simplicity — make them low-hanging fruit for automated response playbooks.

In this two-part series, we are showing you how to build a phishing playbook that can save you a ton of time and keep your team focused on more complex incidents. In part one, we took a playbook from the preparation phase through the wireframing of the workflow. Now, it’s time to put those plans into action and turn the wireframes into a complete playbook that we can test and deploy to production.

The specific example will follow the form of a SOAR playbook, but many of the principles will apply to different automation platforms. The playbook uses integrations with tools including Office 365, Microsoft Entra ID, and Check Point NGFW, but those specific tools can be replaced with others in their categories.

Building the Playbook

Let’s pick up our playbook from where we left it in part one. We had wireframed a phishing workflow across four stages: triage, enrichment, containment, and recovery. 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 the triage stage, we will build the authentication checks to assess the incoming email, such as DMARC, SPF, and DKIM verification — as described in detail in part one. Based on the results of these checks, the playbook will generate a risk score and compare that to a predetermined benchmark to determine the severity of the incident. Revisit part one for a complete example of how this benchmark might be calculated.

In the enrichment stage, we will create the tasks that gather information on the key artifacts of the incident, such as the email recipient, email sender, the IP address of the sender, the file hash of the attachment, and the domain of the sender. For example, the email recipient enrichment task would query Entra ID for user information and activity logs, and CrowdStrike for device information.

As you can see, this task is not a single action, but a short workflow. Ideally, this should be built as a reusable block that can be dropped into other playbooks as if it was an action. In our Smart SOAR platform, these are called nested playbooks. If your platform doesn’t support this, the playbook still works the same way, it will just be more complicated visually and not as easily repurposed.

Following the enrichment stage, we will build in a manual task, which is a decision point for the user to decide, based on triage and enrichment, whether the playbook should dismiss the incident or continue to containment.

In the containment stage, we will build out the tasks that interrupt the phishing attack. These will include orchestrating one-off actions, such as blocking the sender’s URL or domain in Check Point, as well as more nested playbooks, such as workflows for user containment in the case of a successful phishing attempt.

In the recovery stage, we will take our wireframed processes for restoring assets to their usual functions and turn them into tasks and nested playbooks. These will accomplish recovery tasks like recovering affected devices.

Testing the Playbook

Now that we have built the playbook, we need to test that it functions properly. Are all the connections to other tools working? Is the logic of the workflow set up correctly? Does each task return the expected results when we run test data through it?

We can use sample email alerts to run tests. By setting up a mailbox account to which you can forward different email formats, you can make sure that the playbook can handle edge cases. In our example, we will use Postman to push custom alerts into the playbook.

Your platform may have a separate interface for testing playbooks, or it may be built into the playbook editor, as in the case of our Smar SOAR platform. To test the triage stage of the playbook, we will feed it the sample data and specify the parameters to test the triage tasks. For example, the DMARC authentication check can be configured to search for [authentication_parameter]=pass and return True if found. After running the test data, we can see that the check returned True and we can proceed to the SPF and DKIM tasks. Once all the authentication checks are complete, we will review the severity calculation at the end of the triage stage to make sure that it is correctly following our benchmarks.

In the later stages of the playbook, many of the tasks contain multiple steps. Earlier, we described how these should be built as reusable blocks — what we call nested playbooks — that can be deployed across playbooks, instead of being remade from scratch. If your platform has this capability, each nested playbook will appear as a regular task in the parent playbook. We will push test data through these tasks, which will trigger all the underlying commands, enabling us to verify that the inputs and outputs are correct.

Deploying the Playbook

Once each command has been configured to intake and output the correct values, the playbook can be published and made available for use by analysts and investigators. Now, when a potential phishing email is detected, the system can assign the Phishing Response playbook and execute automated triage, enrichment, containment, and recovery, saving your team valuable time on each incident. Playbooks like these, for frequent and time-consuming incidents, can unlock scalability for MSSPs, enabling teams to do more for clients without adding headcount.

Revisit part one of this series for how to take your playbook from initial preparation to a complete wireframe.

About D3 Smart SOAR for MSSPs

D3 Security supports MSSPs around the world with our Smart SOAR platform. D3 Security supports full multi-tenancy, so you can keep client sites, data, and playbooks completely segregated. Importantly, we’re vendor-agnostic and independent, so no matter what tools your clients use, our unlimited integrations will meet their needs. D3’s Event Pipeline can automate the alert-handling capacity of dozens of analysts, while reducing alert volume by 90% or more. Watch our case study video with Trifork Security to see how a successful MSSP uses Smart SOAR.

Guest blog courtesy of D3 Security. Read more D3 Security guest blogs and news hereRegularly contributed guest blogs are part of MSSP Alert’s sponsorship program.