Skip to main content

Cyware Fusion and Threat Response

Incident Workflows

Incident workflow defines the life-cycle that security teams should follow for threat response. It provides the needed flexibility to CFTR admins for developing multiple incident response flows as per the incident response workflow requirements of the organizations. Using incident workflow, you can define the phases of the incident response.

There are two types of incident workflows: linear and non-linear.

  • Linear incident workflow: The flow of phases is sequential and users cannot arbitrarily switch between phases.

  • Non-linear incident workflow: The flow of phases is non-sequential and users can arbitrarily switch between phases.

Yes. If the required phase is not available in the existing list of phases, then you can create a new phase on the incident workflow configuration. For more information on how to create phases in incident workflows, see Create Incident Workflow.

Yes. To update the sequence of phases, open an incident workflow in edit mode and drag and drop the phases to reorder the sequence.

Yes. On the incident workflow configuration, you can search and select an existing phase. If the phase is being used in multiple incident workflows, then you can select and reuse the phase from an incident workflow.

When a phase of an incident workflow is updated that is being used in multiple incident workflows, then the change applies to the specific incident workflow only and does not reflect in other incident workflows.

Field library is a set of various types of fields that you can use to configure the phases of an incident workflow. You can view the field library on the incident workflow configuration, when you create or edit an incident workflow.

Yes. If the required field is not available, then you can create a field in the field library on the incident workflow configuration.

Yes. When you create a field for your incident workflow, it is added to the field library and the CFTR admins can use it in other incident workflows.

Yes. You can use any field from the field library in the incident workflows.

A field cannot be manually deleted from the field library. However, when a field is being used in a single incident workflow, then the field will no longer be available in the field library if it is deleted from the incident workflow. A field cannot be deleted from the field library if it is being used in multiple incident workflows.

Yes. You can clone an incident workflow to create a copy of the incident workflow.

The Workflow Mappings displays the list of mappings that are configured for the incident workflows for various sets of parent parameters. When an incident is created with the set of parameters that do not match any workflow mapping, then the default incident workflow is used for the incident.

You can deactivate an incident workflow if you do not want any incident to use it. A deactivated incident workflow cannot be used for incidents even if the workflow mapping of the incident workflow matches the parent parameters of an incident. However, you can reactivate it if you want to use it for incidents.

When an incident workflow is deactivated, its workflow mapping gets deactivated as well and the default incident workflow will be used.

Yes. You can add, update, or delete a phase of a draft incident workflow.

No. You cannot add or delete a phase of a published incident workflow.

The maximum number of fields that you can add to the field library is different for different types of fields. The limits for various field types are:

  • Character Fields (Text Field, Expandable Text Field, Text Area): 102

  • Integer Fields: 31

  • Date Fields: 22

  • Single-select Fields: 37

  • Multi-select Fields: 41

Yes. There can be a maximum of 30 active incident workflows. However, there is no limit to the number of inactive and draft incident workflows.

With workflow mapping, you can control the incident workflow being used for an incident. Workflow Mappings displays the list of mappings that are configured for the incident workflows for various sets of parent parameters. When an incident is created with a set of parameters that match a workflow mapping, the corresponding incident workflow is automatically used for the incident. If a workflow mapping does not match the parameters that are used for an incident, then the default incident workflow is used.

You can add a maximum of four parent parameters for a workflow mapping.

The parent parameters suggestions come from the Preparation tab and only single select fields can be used as parent parameters.

Yes. An incident workflow can be used in multiple workflow mappings if the workflow mappings have different sets of parent parameters.

When a workflow mapping is not created for a set of parent parameters, then the default incident workflow is used for the incident.

When a workflow mapping is being used by incidents and the mapping is removed, then the existing incidents will continue using it, but all new incidents will use the default incident workflow.

Following are some of the scenarios when a published incident workflow is updated:

  • Add a Field: When a field is added to a published incident workflow, then the new field will be reflected in all incidents, whether open or closed, that are using the incident workflow.

  • Edit a Field: When a field is updated (including conditional field updates) in a published incident workflow, then the updated field will be reflected in all incidents, whether open or closed, that are using the incident workflow.

  • Rename a Field: When a field is renamed in a published incident workflow, then the new field name will be reflected in all incidents, whether open or closed, that are using the incident workflow.

  • Delete a Field: When a field is deleted from a published incident workflow, then the field will be deleted from all incidents, whether open or closed, that are using the incident workflow.

  • Add a Phase: Adding a phase to a published incident workflow is not allowed. But you can clone the incident workflow and add the phase before publishing it.

  • Rename a Phase: When a phase is renamed in a published incident workflow, then the new phase name will be reflected in all incidents, whether open or closed, that are using the incident workflow.

  • Delete a Phase: Deleting a phase from a published incident workflow is not allowed.