Share Blog Post
For different incidents, organizations often follow the same workflows. The different processes involved in an incident response lifecycle require different frameworks, such as NIST and others, to handle them. We have introduced an enhanced Workflow Management module that provides organizations the flexibility to customize and create multiple Incident Workflows.
In our latest release of CFTR v2.12, we are offering a Form Management feature that allows users to define different processes of incident response, such as NIST, OODA, or any framework. Users can now decide the criteria of the workflow for incidents and also control phases and fields that appear in the CFTR Incident Creation forms. Moreover, CFTR admins can customize these forms.
Benefits that Form Management Offer
With the new Form Management module, admins can
- create multiple Incident Workflows
- create custom phases as per their business requirements
- utilize an extensive list of fields used across all Incident Workflows through the field library
- display fields according to conditional logic based on specific use cases
- reuse existing phases created making sure users don’t have to build the form from scratch
- map set of parameters to an Incident Workflow, enabling it to be automatically used for the incident.
What’s New?
Earlier, there was only one Incident Workflow that employed the NIST framework and the fields and phases of the incident were not customizable. Also, the users had to use the same workflow for all incident types. The Form Management of incidents had limited options to create different incident response flows for different types of incidents. However, in CFTR v2.12, the workflow-based Form Management feature provides the flexibility to create multiple Incident Workflows for various types of incidents or any custom conditions as per the business needs.
All About Incident Workflow
Users can view the incidents under the Form Management section in the Admin Panel and manage their Incident Workflows. The list of already created Incident Workflows are displayed under Published sections.
The Incident Workflows which are not completely configured or published are the draft Incident Workflows and these cannot be used for an incident as this gives the flexibility for the users to continue to update the workflow, while the published Incident Workflows are the ones that can be configured and published, and they can be used for incidents.
Actions Performed in an Incident Workflow
Create an Incident Workflow: Users can click on the Create Incident Workflow button on the Incident Workflows page and enter the name and description of the Incident Workflow in the respective fields. Moreover, they can add phases, add fields from the Field Library for an Incident Workflow. If the required phase is unavailable in the existing list of phases, users can create phases to add to the Incident Workflow. Field Library is a library of various types of fields that are created by CFTR admins across workflows. If the required field is not available in the Field Library, users can create fields to add to the phase.
Update an Incident Workflow: Users can update the Incident Workflows that are saved as Draft or Published. To update an Incident Workflow, users can visit the Form Management page and locate it under the Draft or Published section.
Clone an Incident Workflow: To create a copy of an existing workflow, users can clone a workflow so that they don’t have to create another workflow similar to it from scratch.
Deactivate an Incident Workflow: If users do not want to leverage an Incident Workflow for any incident momentarily, they can deactivate the Incident Workflow.
Delete an Incident Workflow: The Incident Workflows saved under Draft or Published can be deleted. However, an Incident Workflow cannot be deleted if it is in use by an incident, has a workflow mapping, and is marked as the default workflow.
In Incident Workflows, users can use the Field Settings of a field to define its Conditional Logic. Using Conditional Logic, users can:
- define rules to show or hide a field
- define rules to configure a field as read-only
- define the conditions to apply a rule
- choose to apply a rule when all or any of the conditions match
Using the Incident Workflows, users can also:
- create custom phases
- reuse existing phases from the phase library
- create new fields
- reuse fields from the Field Library
- drive the Incident Workflows per business needs
Workflow Mapping
The new CFTR version supports workflow mapping, allowing CFTR Admins to manage as many workflows as they want and map them to any specific condition or a set of parameters. When an incident is created with a set of parameters that are mapped to an Incident Workflow, the mapped Incident Workflow gets automatically applied to the incident. Some of the examples of the parameters are Incident Type, Business Unit, etc. Users can configure the parameters for up to four parameters of their choice.
The Bottom Line
Every security team has a different approach to incident response and they all follow different Incident Workflows when it comes to responding to an incident. With our Form Management feature, security teams have the flexibility to customize and create multiple Incident Workflows to define different processes involved in incident response like NIST, OODA, or any framework of customers’ choice. Moreover, they now have the flexibility to decide the criteria of the workflow for incidents. The inclusion of the Form Management module puts CFTR head and shoulders above the other traditional incident response platforms.
Tags
Posted on: December 24, 2021
Related Guides
More from Cyware
Stay updated on the security threat landscape and technology innovations at Cyware with our threat intelligence briefings and blogs.
The Virtual Cyber Fusion Suite
