search cancel

Incident Workflow and Configuring DIM Remediation Actions

book

Article ID: 172062

calendar_today

Updated On:

Products

Information Centric Analytics Data Loss Prevention Core Package

Issue/Introduction

Enhance or mimic your DLP workflow using ICA's Data in Motion Remediation Actions

Resolution

What is a Remediation Action?

Remediation Actions are buttons that are found on the Data In Motion (DIM) toolbar. ICA has three default Actions already defined (Escalate, Resolve, and Dismiss).

An Action can be created and configured to meet the need of the organization and to assist with the defined remediation workflow for DIM Incidents. An Action can be configured to set the Status, assign a selected Reason or Resolution, or assign an incident to a queue. An Action can also be configured to simply add a Comment to an incident. The Actions can be created and configured to work with existing DLP remediation workflow and processes.

 

How do you create a Remediation Action?

To create a Remediation Action:

     1. Go to the Admin navigation menu item and select settings

     2. Click on Data In Motion Settings tab at the top of the Settings page

     3. Click on the Remediation Action Types tab

     4. Click on the Remediation Action button. This will open a configuration window.

     5. Begin configuring the Remediation Action button:

Example Remediation Action Prompt

Below is a list of the fields and definition for each that are available when configuring a Remediation Action button.

a. Main and Window Configuration sections: These sections determine how the Remediation Action prompt is displayed

   1) Allow Multiple Selection: Allows users to select more than one item in the Remediation Action prompt

   2) Title: Name displayed at the top of the Remediation Action Prompt.

   3) Button Text: Name displayed on the button

   4) Instructions: Text that is displayed at the top of the Remediation Action Prompt.

   5) Glossary: A list of terms. For example, the glossary could list Reason/Resolution Codes and when each should be used.

To add an item to the Glossary:

     A. Click on the Glossary button to open the glossary configuration window

     B. Add a title for the glossary

     C. Click Add Entry to add items to the Remediation Action's glossary table

 

b. Toolbar Configuration section

   1) Button Text: Name displayed on the button

   2) Button Width: Display width of the button

   3) Icon: Allows customize icons show with the button

   4) Is Button Enabled: Enables the button. If this option is not checked, the button will still be visible to users, but will not function. Disabling buttons allows the Administrator to create the buttons to see how they will be displayed on the toolbar without having to worry about users clicking on them when they are not fully configured. In the image below, the Dismiss button has been disabled.

   5) Is Button Displayed: Either shows or hides the button from users. Setting the display value allows the Administrator to hide buttons that are configured, but not ready for use or to hide buttons that are not currently needed.

 

c. Actions Configuration section: This section allows the Administrator to configure what remediation actions fields are available to the user. These actions can range from setting the Status of an incident to simply adding a comment.

If updating of Symantec DLP is enabled (confirm with the ICA Administrator), this section also identifies what Source System Field ICA will be updating within Symantec DLP

Update Status

1)  (optional) Update Status: If checked, this allows the button to set the Status of an incident.  The Status value is not visible to the user.

2)  (optional) Update Source System: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies whether or not ICA will update the Status of the actioned incident(s) in Symantec DLP as well.

Update Assigned To

3)  (optional) Update Assigned To: Allows the user to specify a Queue that is assigned to the incident

  1. All: Shows all available DIM Queues that have been defined within ICA
  2. Fixed List: Shows only specific DIM Queues that have been defined within ICA
  3. Static Value: Specifies one DIM Queue to be used
    1.  (optional) Visible:  This setting is only available if the Static Value option is selected.  This determines whether or not the Queue value is shown to the user.

4)  (optional) Source System Field: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies the Custom Attribute of the actioned incident(s) within Symantec DLP that will be updated with the specified value

5)   (optional) Required: Whether or not a value for Assigned To is required

Update Reason

6) (optional) Update Reason: Allows the user to specify and assign Reason codes to actioned incident(s)

  1. All: Shows all available Reason Codes that have been defined within ICA
  2. Fixed List: Shows only specific Reason Codes that have been defined within ICA
  3. Static Value: Specifies the Reason Code to be used
    1.  (optional) Visible:  This setting is only available if the Static Value option is selected.  This determines whether or not the Reason Code value is shown to the user.

7) (optional) Source System Field: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies the Custom Attribute of the actioned incident(s) within Symantec DLP that will be updated with the specified value

8) (optional) Required: Whether or not a value for Reason Code is required

Update Resolution

9)  (optional) Update Reason: Allows the user to specify and assign Resolution codes to actioned incident(s)

  1. All: Shows all available Resolution Codes that have been defined within ICA
  2. Fixed List: Shows only specific Resolution Codes that have been defined within ICA
  3. Static Value: Specifies the Resolution Code to be used
    1.  (optional) Visible:  This setting is only available if the Static Value option is selected.  This determines whether or not the Resolution Code value is shown to the user.

10) (optional) Source System Field: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies the Custom Attribute of the actioned incident(s) within Symantec DLP that will be updated with the specified value

11) (optional) Required: Whether or not a value for Resolution Code is required

Update Comment

12) (optional) Update Comment: Allows the user to specify a comment

13) (optional) Source System Field: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies the Custom Attribute of the actioned incident(s) within Symantec DLP that will be updated with the specified value

14) Add Note in Source System: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), the comment will be added to the Notes field of the incident(s) within Symantec DLP

15) (optional) Required: Whether or not a value for a Comment is required

Update Case Number

16) (optional) Update Case Number: Allows the user to specify a value (ticket number, case number, etc.) from an external system (i.e. an Event Management System, HR system, SOC ticket system, etc.).

17) (optional) Source System Field: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies the Custom Attribute of the actioned incident(s) within Symantec DLP that will be updated with the specified value

18) (optional) Required: Whether or not a value for Case Number is required

Update Last Actioned By

19) (required) Update Case Number: Sets Last Actioned By field within ICA to the user account of the user actioning the incident(s)

20) (optional) Source System Field: If ICA is configured to update Symantec DLP (confirm with the ICA Administrator), specifies the Custom Attribute of the actioned incident(s) within Symantec DLP that will be updated with the specified value

 

d. Notifications Configuration section: This section allows the Administrator to assign a notification template that will be used when email messages are sent out. The email messages are used to notify users or a group of users when an item needs action (remediation, review, etc.) or an action has been taken.

1) (optional) Use Custom Notification Rules: Enables custom notification rules and (if enabled) overrides the Assigned To Queue notifications.

2) Template: Sets Notification the template to be used

3) Override Template Distribution List: overrides defaults defined with the selected Notification Template

4) From: Overrides the sender email specified on the Notification Template

5) To: Overrides the recipient email(s) specified on the Notification Template

6) CC: Overrides the CC recipient email(s) specified on the Notification Template

7) BCC Overrides the BCC recipient email(s) specified on the Notification Template

 

Putting context around Remediation Actions and how to implement them

Example DLP Incident Lifecycle and Workflow

Above is a swim lane diagram that shows an example workflow and lifecycle of an incident from when it was identified by Symantec DLP (New) and when no further action was needed for the incident and it was considered closed or resolved.

Each swim lane represents a different group that is or could be involved throughout the process.  Each of these groups represent a different Queue (Assigned To selection from a Remediation Action).  Each Queue has its own process to review and eventually close or resolve an incident.  As part of this process, each Queue can have its own Remediation Actions that are customized and represent their internal processes. 

Analysts Queue

This queue is the initial queue that is assigned to an incident once it comes into ICA.  They will review the incident and decided whether or not the incident needs to be escalated to the Investigation queue or if the incident can be resolved.  If the incident needs to be escalated, the user will use a remediation action to escalate the incident to the Investigation queue by using the Escalate to Review remediation action.  If the incident can be resolved, then the user will use one of two remediation actions (Dismiss or Resolve) and the incident lifecycle will be complete.

Example Remediation Actions and configuration based on example workflow

  • Dismiss Actions:
    • Sets the status of the incident to Dismissed
    • Provides a set list of Resolution Codes that can be used
      • Example: False Positive, Policy Tuning
    • Provides a set list of Reason Codes that can be used
      • Example: Log files, Data does not match policy, other
    • Allows the user to add a comment to provide more details as to why the incident is being dismissed and any potentially useful information
  • Resolve Actions:
    • Sets the status of the incident to Resolved
    • Provides a set list of Resolution Codes that can be used
      • Example: Personal Use, Business Use, Other
    • Provides a set list of Reason Codes that can be used
      • Example: Employee Personal Information, Unsecure Website, Business Improvement
    • Allows the user to add a comment to provide more details as to why the incident is being resolved/closed and any potentially useful information
  • Escalate to Review Actions:
    • Sets the status of the incident to Investigation
    • Sets the Queue to Investigation (queue value is not visible to user)
    • Provides a set list of Reason Codes that can be used to provide a simple code / text to help identify why the incident is being escalated
    • Allows the user to add a comment to provide more details as to why the incident is being escalated and any potentially useful information for the Investigation queue.

Investigation Queue

This queue is the first level of escalation for an incident.  Only the Analyst queue can assign incidents to this queue.  The users assigned to this queue will review the incident and decided whether or not the incident needs to be escalated to the Escalation Queue (could be HR, SOC, Legal, etc.) or if some other action has been taken to resolve the incident.  If the incident needs to be escalated, the user will use a remediation action to escalate the incident to the Escalation queue.  If some other action has been taken to resolve the incident, then the user will only have the Resolve remediation action available in order to complete the incident lifecycle process.

 

 

Example Remediation Actions based on example workflow

  • Resolve Actions:
    • Sets the status of the incident to Resolved
    • Provides a set list of Resolution Codes that can be used
      • Example: Personal Use, Business Use, Other
    • Provides a set list of Reason Codes that can be used
      • Example: Family member’s Information, Encrypted Devices was used, Communication channel was encrypted
  • Allows the user to add a comment to provide more details as to why the incident is being resolved/closed and any potentially useful information
  • Escalate to Review Actions:
    • Sets the status of the incident to Escalated
    • Sets the Queue to Escalation (queue value is not visible to user)
    • Provides a set list of Reason Codes that can be used to provide a simple code / text to help identify why the incident is being escalated
    • Allows the user to add a comment to provide more details as to why the incident is being escalated and any potentially useful information for the Investigation queue.

Escalation Queue

This queue is the last level of escalation for an incident.  Only the Investigation queue can assign incidents to this queue.  The users assigned to this queue will review the incident and decides if further action is needed or if some other action has been taken and the incident can be resolved.  Notice that this queue only has one remediation action.  The Resolve remediation action allows the user to close the incident and specify an additional actions that that may need to be taken such as escalating to another area outside of the ICA/DIM workflow.  This remediation action is used to complete the incident lifecycle process.

Example Remediation Actions based on example workflow

  • Resolve Actions:
    • Sets the status of the incident to Closed
    • Provides a set list of Resolution Codes that can be used
      • Example: Privacy Event, Unapproved Business Use, Legal
    • Provides a set list of Reason Codes that can be used
      • Example: No further action needed, Escalated Investigation, Legal, Other
  • Case Number: Reference to external systems and related case number
  • Allows the user to add a comment to provide more details as to why the incident is being resolved/closed and any potentially useful information

 

Example questions to ask when creating Remediation Actions:

  1. What is the current workflow within DLP / lifecycle of an incident within DLP?
    1. How does an incident go from being created within DLP to being closed/resolved?
  2. Do all incidents get set to a closed or resolved state?
  3. Are other internal teams involved in the lifecycle of a DLP incident?
    1. If so, what are their workflow processes?
    2. How are then notified that there is an incident needing their review?
  4. Are special action, escalation, investigation, or closure codes being used in the current DLP or other workflows?

Attachments

Powered by Wolken Software