One of the most powerful capabilities of the Phantom platform is its support for nested playbooks. When defining your process as a Phantom playbook, one of the four main branching choices offered by the Integrated Development Environment (IDE) is another playbook.
Nesting a playbook within a playbook using the Phantom platform’s visual automation IDE.
Similar to the way a function call works in programming languages, the parent playbook jumps to the child playbook and executes the appropriate actions. To illustrate the utility of the nesting capability, let’s examine a process for handling Malware incidents and lay out the logic using a Phantom playbook.
Malware is one of the most common incident types handled by Security Operations (SecOps) teams. If you’re a member of such a team, you likely have a series of processes, or playbooks, to handle the various malware categories you may encounter. It’s also likely that there is a large amount of overlap, or redundancy, between these playbooks.
Using the Phantom platform, when you receive a suspected malware alert you can begin a generic malware response workflow. After performing investigative actions, such as retrieving the file reputation from a threat intelligence service, you can use that context to determine which of the more specific malware playbooks to branch to in order to execute the unique responses for that particular malware type.
Simplified diagram showing the ability to branch from a parent playbook into a child playbook.
This is a very simple use case for nested playbooks, but hopefully it illustrates how powerful nesting playbooks can be. Through nesting, you can build elaborate response workflows that minimize the amount of redundancy needed. That way, when your process changes you have fewer places to change in your Phantom playbooks.