Getting Started with Workspaces
This section provides a guided walkthrough of the steps required to set up and use workspaces in Orchestrate.
The following illustration shows the workflow of using workspaces in Orchestrate.
Admin Configurations for Workspaces
An administrator must perform the following steps to enable and create workspaces.
To get started with workspaces, the first step is to enable Workspaces as a feature and then create your first workspace. Data from playbooks, apps, and other key resources will be migrated to this workspace. For more information on enabling workspaces, see Configure General Settings.
You can create additional workspaces such as Dev and Production. Use these workspaces to plan the organization of playbooks, apps, and other resources into specific workspaces based on your requirement. You must specify the user groups that can use this workspace. You can create a maximum of 10 workspaces. For more information on creating workspaces, see Manage Workspaces.
You can mark a workspace as restricted if an approval process is required to publish playbooks to that workspace. For example, you can mark the Production workspace as restricted since it may store critical resources.
You can also keep a workspace unrestricted if it is not intended to store critical resources. For example, you can store playbooks that are in draft status in a Development workspace.
You must specify the approver user groups for restricted workspaces. Any playbook that is being published to a restricted workspace must be approved. For example, you can add senior analysts and security officers as part of the approver user groups.
Publish Playbook to a Workspace
An analyst must perform the following steps to publish playbooks to a workspace.
You can select a playbook to publish to a destination workspace based on the security process defined in your organization. For example, you can create a Threat Hunting playbook in the Development workspace and publish it to the Production workspace for execution as the playbook stores sensitive data.
The publishing process varies depending on whether a workspace is restricted or unrestricted (approval-free).
Restricted Workspace: To publish playbooks to a restricted workspace, analysts must raise a publish request, and an approver must review the playbook details and approve the publish request. For more information on publishing playbooks to a restricted workspace, see Publish Playbooks to a Restricted Workspace.
Unrestricted Workspace: Analysts can review the playbook details and publish a playbook without approval to a workspace that is approval-free. For more information on publishing a playbook to an unrestricted workspace, see Publish Playbook to Unrestricted Workspace.
Best Practices to Work with Workspaces
Administrators and analysts must consider the following best practices before working with workspaces:
Best Practices for Administrators:
Administrators must review the assigned permissions of a user group before adding a user group as an allowed user group to a workspace. This is essential as the users from these groups can apply the configured permissions of the user group to work with playbooks, apps, and other resources in the workspace.
Administrators should create only a required number of workspaces for effective management of workspaces.
Administrators must mark a workspace with critical or confidential resources as restricted to ensure that playbooks are published to the workspace through an approval process. For example, you can mark the Production workspace as restricted.
Best Practices for Analysts:
If you are publishing a playbook for the first time to a destination workspace, then it is recommended to include the associated sub-playbooks for publishing.
If you are re-publishing a playbook to the destination workspace and you have made changes to only the master playbook, then it is recommended to exclude the associated sub-playbooks for publishing.
If a playbook and its associated sub-playbooks already exist in the destination workspace, you must review the playbook details thoroughly before taking action on playbooks such as creating a new copy of the playbook, replacing the playbook in the destination workspace, or skipping publishing and using the existing playbook in the destination workspace.
Key Pointers that Analysts Must Know
The following are the key pointers that analysts must know before working with workspaces:
When a playbook is published from a source workspace to a destination workspace, a source reference ID of the playbook is stored in the destination workspace. If an analyst republishes the same playbook from the source to the destination workspace, then the destination workspace validates the source reference ID of the playbook and prompts the user to either create a new copy of the playbook, replace the playbook of the same reference ID, or skip publishing (for sub-playbooks) to the destination workspace.
When a playbook is published across multiple workspaces, then the source reference ID of the playbook is maintained only in the consecutive workspace. For example, if you publish a playbook from a Development workspace to a Testing workspace, then the source reference ID of the playbook from the Development workspace is maintained only in the Testing workspace. The source reference ID of the playbooks is changed if it is published to other workspaces from the Testing workspace.
When a playbook that contains sub-playbooks is published to the destination workspace, then all the nested sub-playbooks are also published to the destination workspace.
A playbook in which the master playbook and the sub-playbook runs in a cycle is called a cyclic playbook. It is not recommended to create and publish a cyclic playbook to a workspace.