General Documents

In CFTR, an incident response process is handled using forms with the default workflow that the Admins set up. Once identified, an incident goes through the logging process to include incident information such as description, business unit, location, the date and time of inference, etc.

The old approach to form management has limited flexibility wherein, the analysts are not allowed to add custom phases in a workflow or add fields of their choice. Logging the sources of information using forms is inspired using a traditional framework named NIST.

This use case describes how an organization can use customized forms to automate the management of the incident response process flexibly to save time and effort.

Along with Incident Workflows and Mapping techniques, Admins can also build conditional workflow logic with custom rules, set custom templates for incident exports to change the incident form dynamically, and ensure critical tasks and assignments move smoothly through the process. Admins can design forms to display or hide fields based on the responses to the fields setup, simplifying the analyst experience.

Let us consider a scenario with a large organization, wherein incidents are observed on a case-by-case basis frequently and saved for analysis. Sources of the incident gathered from 3rd party integrations, UI, or REST API needs a workflow.

CFTR Admins are allowed to create one or more incident response flow that meets their organizational requirements or abide by a set of parameters. When the analyst begins to analyze an incident, the respective workflows configured are automatically applied using parent parameters.

By configuring an Incident workflow under Form Management in CFTR, analysts will have the flexibility to create multiple incident workflows to define different processes involved in incident response like NIST, OODA, or any framework of their choice.

What is an Incident Workflow?

The incident information that ingests into your application requires an Incident Workflow to analyze your data with defined phases and incident fields. Configuring an Incident Workflow enables you to monitor and manage the responses for an incident.

How does mapping parent parameters work?

After creating a workflow, Admins can choose a maximum of 4 parent parameters or a minimum of 1 parameter for the workflow to apply to an incident automatically. Parent parameters consist of important indicators such as Incident Type, Source, Business Unit, Location, or any custom parameter.

Let's consider a case where you select an Incident Type(s) as parent parameters to a workflow named ABC. When an analyst logs in an incident and fills all the parent parameters i.e. the Incident Types listed, the workflow phases mapped along with these indicators get automatically applied for investigation under the Response tab.

What is it convenient for?

The 2.12 CFTR version supports workflow mapping, allowing CFTR Admins to manage and map as many workflows they want, to any specific condition or a set of parameters.

By establishing an unrestricted workflow, organizations can achieve maintainability, and availability of key fields to a unique set of data that is relevant to that specific incident type.

You can customize almost every aspect of the workflow, including, but not limited to:

Additionally, the Incident Workflow helps you categorize and integrate the incident information in the following components:

In most instances, you can create a new or a different workflow by analyzing the incoming incidents to accommodate the investigation effort. This facilitates your analysts to focus on the uncommon incidents that require further investigation.

The Incident workflow can be configured irrespective of the service and the deployment scenario planned for an organization.

To set up an Incident Workflow in CFTR, follow these stages.

The following workflow diagram illustrates the process of form management to create and manage an Incident Workflow. You can add new phases, fields and map them to tailor a specific investigation.

Before you begin creating an Incident Workflow, plan the following:

Select the type of incident flow: Linear or Non-Linear

The phases under Incident Workflow consist of Detection Analysis, Containment, Investigation and Eradication, Recovery, and Closure which is inspired from the NIST framework. You can add a new phase that you want to include apart from the phases available.

Select the existing fields available or create new fields to match your Incident Workflow here. Some fields that assist with the incident investigation include Title, Investigation summary, Assigned group, Incident Date, Motives, Source Port, Description and so on which are added to the layout.

Conditional logic is a set of statements, when satisfied, run pre-determined activities. A condition is a statement that checks a field for a value using an operator, such as equal to. Conditions are used to determine when to invoke the rule.

Let's take an example where a rule is executed only when the controlling field Incident Log Source Identified contains a controlling field value Other. In this case, the form retains the Incident Log Source Identified field if the condition contains an exact match. If it is not an exact match, the form removes the field created from the condition setup.

Classification determines the type of incident framework that is created for the incidents ingested from a source. Mapping helps you match the parent parameters that you wish to associate with an ingested incident. Some of the parent parameters available are Incident Type, Business Unit, etc.

Admins can create a template and customize the fields they want to perform export or merge operations after the Incident Response process. To add a template to the existing workflow configured it must be published. Admins can create one or more templates for a workflow and set any one of them as default. Templates are created automatically whenever a workflow is created to reduce the user’s efforts.

It is necessary to create or customize the layout to ensure that you display the most relevant data for analysts at all stages of the incident response process. The Incident Workflow that you planned has options to create, update, delete, clone, and deactivate. Review and customize the layout, fields, phases or change the desired parent parameters under mapping.

Investigate an incident with the workflow containing the respective fields and phases. You can customize them from the workflow devised when needed.

As a result of an established Incident Workflow, an incident automatically goes through the following stages:

For more information, see Configure Forms.

To read through the most commonly asked questions, see the Incident Workflows FAQs.