Playbooks
My Playbooks are the Playbooks that are created/imported/modified by Orchestrate users. Playbook store is a collection of pre-built orchestration workflows for simplified security investigation and response. Analysts can use the out-of-the-box Playbooks to perform the most common orchestration tasks and reduce a security operation center’s mean time to respond to security threats.
Playbooks are the building blocks of SOAR, as they automate a multitude of manual and repetitive tasks. Playbooks help to build orchestration workflows across the multiple security and non-security third-party solutions used in your deployment. This helps to improve the overall security posture of your environment.
Primarily, the Playbooks are categorized into Cyware Playbooks and My Playbooks. Cyware Playbooks, are a set of out-of-box Playbooks that are available for you to use instantly. For example, Ransomware Investigation Playbook. Whereas, under My Playbooks, the playbooks that you have created or cloned will be displayed as a list.
You can build Playbooks using a combination of the different nodes, and each of these nodes is defined for a specific task. The types are:
Start Node: The node represents the start of the workflow. Whenever a Playbook execution is triggered, the event's data is stored in the Start Node.
Action Node: The node is used to perform specific actions. The three types of nodes that can be configured for actions are App action, Custom action, and Playbook action nodes.
Condition Node: The node performs a condition decision and also be used to branch out a workflow in Playbook based on a set of conditional expressions.
Input Node: The node is added whenever manual input from users is required before proceeding to the next node in a Playbook.
Memory Node: The node stores data from the Playbook workflow and uses it as input for other nodes of the same playbook, or a different playbook.
Anyone with basic computer skills and an understanding of the environment's security automation and orchestration requirements can build Playbooks. There are no design skills required to build one, as Cyware's simple and user-friendly canvas, with drag and drop facility makes it easy to create Playbooks. However, Cyware can also assist you to build Playbooks. Kindly contact customer support to avail the assistance.
No special design skills are required for one to build a Playbook. Cyware's simple and intuitive design with a simple drag-and-drop feature for adding nodes makes it easy for you to create a Playbook.
You can build playbooks using either of these two ways:
Create a new Playbook from the UI using the Playbook canvas.
Create a custom Playbook using Python, and you will need knowledge of Python for this.
You can only follow/bookmark the Playbooks which are available under My Playbooks.
Yes. You can map multiple labels for a Playbook.
Yes. You can map multiple tags for a Playbook. While creating the Playbooks you can add the tags from the Select Tags option under the Overview section. Note that, only the tags that are already added will be displayed here for selection.
Yes. If you wish to specify multiple values either as Input or Output parameters, you can specify them using the loop option { } available and enable the option Iterate over each item. This ensures that the Playbook executes each of the values specified.
Yes. We can import a Playbook in JSON format.
While defining the Playbook workflow for a specific use case (for example, to block IPs), if there is an existing Playbook that is already defined for a similar use case (for example, to get IP details and to take actions on the IP), you can reuse the latter Playbook as a sub-Playbook.
You can view the Cyware Playbooks based on the workflows they automate using our advanced filter options. To customize the Playbook listings, select the Category under Filters. This way, you can sort and view the Playbooks based on the criteria you specify. The categorizations that we support are:
Security Hygiene
Intel Enrichment
Incident Response
Incident Reporting
Incident Onboarding
Incident Notification
Incident Enrichment
Asset Management
You can integrate third-party software using one of the following three ways:
Orchestrate Open APIs: You can use the Open API module to generate a required number of API credentials and access the application's features using the API.
Apps: You can use install apps to integrate, orchestrate, and respond using different security tools you may have in your organization. You can find the apps under the Appstore library, and also can choose to clone an app to further customize them, to meet your unique requirements.
Webhooks: You can push data from other applications into Orchestrate, using the Webhooks settings by creating and managing the Webhook configurations and tokens.
Creating custom Playbooks is a great way to create customized orchestration for your security environment. As you create them, keep a few best practices in mind:
Limit each node to a single logical step: Even if a single node can handle all the data that is processed, it is advisable to split it across multiple nodes. This way, others accessing the Playbook can easily understand the actions or the use case the Playbook serves. In addition, this ensures consistent implementation of nodes and application nodes.
Provide node descriptions: Give a title and description to all nodes, depending on the context of the node’s usage.
Include docstrings to provide descriptions: The docstring should include descriptions of each parameter, as well as the expected field type. Alternatively, use type hinting, for example use the :str in def func(foo: str) to indicate an expected type of string.
Use comments for unintuitive code: In addition to docstrings, the custom code can be very complex or difficult to read. Therefore, provide inline comments to explain what is accomplished.
Use filtered lists instead of condition nodes: Use filtered lists of parameters to subsequent nodes, instead of using conditional nodes, as they complicate the control flow of Playbooks. For example, assume a use case to fetch a list of CFTR incidents, and check to see if there are any open incidents, and further close the opened incidents. You can accomplish this by introducing a condition node that determines if any open incidents are present. However, it is easier to create a custom node to filter out all closed incidents, returning a list of IDs of incidents to close. This way, the list can be passed to the Close CFTR Incident node whether it is empty or not. When passing the empty list to a node with the checked Loop option, it executes zero times.
Save customized results from the output data of a node: Instead of retrieving all the fields (entire dump) from the output data of the node, filter the output to fetch only a specific set of fields. To filter the output to specify specific fields, you must make use of dynamic path expressions.
No, you cannot clone Playbooks that are in inactive status. To clone Playbooks, you must first change the status to Active. You can mark the status by navigating to the Playbook Overview, and toggle the status of Playbook to Active.
A Playbook workflow can be defined using agent-enabled apps and instances. Once these Playbooks are executed, their execution details will be logged under Cyware Agent Tasks. You can navigate to Main Menu > Cyware Agent Tasks to view the Playbook execution details.
The Action node and the Playbook node can be executed concurrently in a Playbook by enabling Run Asynchronously in the node configuration. As a result, the other nodes of a Playbook are unaffected by how a single node is executed. When a Playbook executes, the node that is set to run asynchronously will not block the execution of the nodes that follow it.
Run Asynchronously runs a playbook node independent of the playbook workflow. Run Asynchronously is available for a playbook action node (sub-playbook) and Cyware agent-enabled app action node. For example, consider a playbook that extracts threat indicators from an email, enriches the threat indicators, and creates an incident in CFTR. The enrichment part can be configured in a sub-playbook that runs asynchronously.
Note
You cannot utilize the output of a playbook node that will run asynchronously as an input to another node of the Playbook workflow.
The purpose of the action retry count in the app action nodes is to specify the number of times an action should be automatically re-executed on failure. Analysts can configure the action retry count when temporary node failures are expected, and a retry is likely to succeed, allowing the overall flow to continue and avoid manual intervention. You can configure the action retry count in the range of 1 to 15.
You can bookmark or follow a playbook to receive email notifications on playbook updates and playbook run failures. To bookmark a playbook, go to Manage Playbooks > My Playbooks and click the bookmark icon 
next to the Playbook ID.