Enhance or replicate your Symantec Data Loss Prevention (DLP) workflow using Information Centric Analytics' (ICA) Data in Motion (DIM) Remediation Actions.

Version : 6.x

Component : Symantec DLP Integration Pack

What is a Remediation Action?

Remediation Actions are found on the Data In Motion toolbar in the ICA console. ICA has three pre-defined default actions: Escalate, Resolve, and Dismiss.

Figure 1: Remediation Action buttons on the DIM toolbar

Figure 2: Example of a Remediation Action prompt

Actions can be configured to set an incident 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. Additional actions can be created corresponding to your organization's DIM incident remediation workflow in DLP.

How do you create a Remediation Action?

To create a remediation action, navigate in the ICA console to Admin > Settings > Data In Motion > Remediation Action Types. Once there, click on the Remediation Action button to open the Remediation Action Type configuration window, which is divided into four main sections:

• Window Configuration
• Toolbar Configuration
• Actions
• Notifications

Window Configuration

This section controls how the remediation action prompt is displayed to the user.

Figure 3: Window Configuration options

1. Allow Multiple Selection: Allows users to select more than one item in the remediation action prompt window.
2. Title: Remediation action name displayed at the top of the remediation action prompt window.
3. Button Text: Name displayed on the remediation action button in the remediation action prompt window.
4. Instructions: Text displayed at the top of the remediation action prompt.
5. Glossary: A list of terms relevant to the remediation action. For example, the glossary could list Reason/Resolution Codes and when each should be used.
   1. Title: Glossary title as presented to the user.
   2. Add Entry: Add a glossary entry.
   3. Remove: Remove a glossary entry.

Figure 4: Glossary

Toolbar Configuration

This section controls how the remediation action button is displayed in the toolbar.

Figure 5: Toolbar Configuration options

1. Button Text: Text displayed on the button in the toolbar.
2. Button Width: Display width of the button in the toolbar.
3. Icon: Assign a custom icon from the icon library to the button in the toolbar.
4. Is Button Enabled: Enable or disable the button. If this option is not checked, the button will still be visible to users but will not function. Disabling buttons allows ICA administrators to see how buttons will appear on the toolbar without the risk of users clicking on them before they are fully configured and tested. In the following figure, the Dismiss button has been disabled.

   Figure 6: Example of disabled remediation button

   
5. Is Button Displayed: Display or hide the button from users. Hiding buttons allows an ICA administrator to hide buttons that are configured but not ready for use, or to hide buttons that are not currently needed.

Actions

This section controls the remediation actions fields available to the user. These actions include setting the status of an incident, entering a comment, etc. If writeback to Symantec DLP is enabled, this section will also identify the source system field that will be updated in DLP.

Figure 7: Actions configuration options

1. Update Status: Optional. If checked, this enables the button to set the status of an incident. The status value is not visible to the user.
2. Update Source System: If ICA is configured to update Symantec DLP, this controls whether ICA will update the status of the actioned incident(s) in DLP.
3. Update Assigned To: Optional. Allows the user to assign the incident to a queue.
   1. All: Shows all available DIM queues that have been defined in ICA.
   2. Fixed List: Shows only specific DIM queues that have been defined in ICA.
   3. Static Value: Specifies a DIM queue to be used for all incidents.
      1. Visible: Optional. This setting is only available if the Static Value option is selected. This determines whether the static queue value is displayed to the user.
4. Source System Field: Optional. If ICA is configured to update Symantec DLP, this specifies the custom attribute within DLP that will be updated with the specified value for the actioned incident(s).
5. Required: Optional. Controls whether a value for Assigned To is required.

   Figure 8: Action configuration options (continued)

   
6. Update Reason: Optional. Allows the user to assign reason codes to actioned incident(s).
   1. All: Shows all available reason codes that have been defined in ICA.
   2. Fixed List: Shows only specific reason codes that have been defined in ICA.
   3. Static Value: Specifies the reason code to be used.
      1. Visible: Optional. This setting is only available if the Static Value option is selected.  This controls whether the reason code value is displayed to the user.
7. Source System Field: Optional. If ICA is configured to update Symantec DLP, this specifies the custom attribute within DLP that will be updated with the specified value for the actioned incident(s).
8. Required: Optional. This controls whether a value for reason code is required.
9. Update Resolution: Optional. Allows the user to specify and assign resolution codes to actioned incident(s).
   1. All: Shows all available resolution codes that have been defined in ICA.
   2. Fixed List: Shows only specific resolution codes that have been defined in ICA.
   3. Static Value: Specifies the resolution code to be used.
      1.  Visible: Optional. This setting is only available if the Static Value option is selected.  This controls whether the resolution code value is displayed to the user.
10. Source System Field: Optional. If ICA is configured to update Symantec DLP, this specifies the custom attribute within DLP that will be updated with the specified value for the actioned incident(s).
11. Required: Optional. Controls whether a value for resolution code is required.

    Figure 9: Action configuration options (continued)

    
12. Update Comment: Optional. Allows the user to add a comment to the actioned incident(s).
13. Source System Field: Optional. If ICA is configured to update Symantec DLP, this specifies the custom attribute within DLP that will be updated with the specified value for the actioned incident(s).
14. Add Note in Source System: If ICA is configured to update Symantec DLP, the comment will be added to the Notes field of the incident(s) within DLP.
15. Required: Optional. Controls whether a comment is required.
16. Update Case Number: Optional. Allows the user to specify a value (ticket number, case number, etc.) corresponding to an external system. For example, an Event Management System, HR system, or SOC ticketing system.
17. Source System Field: Optional. If ICA is configured to update Symantec DLP, this specifies the custom attribute within DLP that will be updated with the specified value for the actioned incident(s).
18. Required: Optional. Controls whether a value for Update Case Number is required.
19. Update Last Actioned By: Required. Sets the Last Actioned By field in ICA to the account of the user actioning the incident(s).
20. Source System Field: Optional. If ICA is configured to update Symantec DLP, this specifies the custom attribute within DLP that will be updated with the specified value for the actioned incident(s).

Notifications

This section allows the ICA administrator to assign a notification template to e-mail notifications sent to users. E-mail notifications are used to notify users or groups of users when an item requires action (e.g., remediation, review, etc.), or when an action has been taken.

Figure 10: Notifications configuration options

1. Use Custom Notification Rules: Optional. Enables custom notification rules and (if enabled) overrides the Assigned To Queue notifications.
2. Template: Sets the notification template to be used.
3. Override Template Distribution List: overrides defaults defined with the selected notification template.
4. From: Overrides the sender e-mail address specified on the notification template.
5. To: Overrides the recipient e-mail address(es) specified in the notification template.
6. CC: Overrides the CC recipient e-mail address(es) specified in the notification template.
7. BCC: Overrides the BCC recipient e-mail address(es) specified in the notification template.

Putting context around Remediation Actions and how to implement them

The following swim lane diagram shows an example workflow and lifecycle for an incident from when it was first identified by Symantec DLP to the point when no further action is required and the incident can be considered closed or resolved.

Figure 11: Example of a DLP incident lifecycle and workflow

Each swim lane represents a different group that is or could be involved at some point in the investigation and remediation process. Each group represents a different queue (the 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 to represent their internal processes. 

Analysts Queue

This queue is the initial queue to which an incident is assigned once it comes into ICA. The members of this queue will review the incident and decided whether it needs to be escalated to the Investigation queue or if it 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 without further investigation, the user will use one of two remediation actions (Dismiss or Resolve) and the incident lifecycle will be complete.

Based on this example workflow, remediation actions could be configured as follows:

• Dismiss
  • Set the status of the incident to Dismissed
  • Provide a set list of Resolution Codes
    • Examples: False Positive, Policy Tuning
  • Provide a set list of Reason Codes
    • Examples: Log files, Data does not match policy, Other
  • Allow the user to add a comment to explain why the incident is being dismissed and add any other potentially useful information
• Resolve
  • Set the status of the incident to Resolved
  • Provide a set list of Resolution Codes
    • Examples: Personal Use, Business Use, Other
  • Provide a set list of Reason Codes
    • Examples: Employee Personal Information, Insecure Website, Business Improvement
  • Allow the user to add a comment explaining why the incident is being resolved/closed and add any other potentially useful information
• Escalate to Review
  • Set the status of the incident to Investigation
  • Set the queue to Investigation (queue value is not visible to user)
  • Provide 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
  • Allow the user to add a comment explaining why the incident is being escalated and add any other 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 the incident needs to be escalated to the Escalation queue (this could be HR, SOC, Legal, etc.), or determine whether 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.

Based on this example workflow, remediation actions could be configured as follows:

• Resolve
  • Set the status of the incident to Resolved
  • Provide a set list of Resolution Codes
    • Examples: Personal Use, Business Use, Other
  • Provide a set list of Reason Codes
    • Examples: Family member’s Information, Encrypted Devices was used, Communication channel was encrypted
  • Allows the user to add a comment explaining why the incident is being resolved/closed and add any other potentially useful information
• Escalate to Review
  • Set the status of the incident to Escalated
  • Set the queue to Escalation (queue value is not visible to user)
  • Provide 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
  • Allow the user to add a comment explaining why the incident is being escalated and add any other potentially useful information for the Escalation 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 decide whether further action is required or whether 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 any additional actions required such as escalating to another area outside of the ICA/DIM workflow. This remediation action is used to complete the incident lifecycle process.

Based on this example workflow, remediation actions could be configured as follows:

• Resolve
  • Set the status of the incident to Closed
  • Provide a set list of resolution codes
    • Examples: Privacy Event, Unapproved Business Use, Legal
  • Provides a set list of reason codes
    • Examples: No further action needed, Escalated Investigation, Legal, Other
• Case Number: Reference to external systems and related case or ticket number
• Allow the user to add a comment explaining why the incident is being resolved/closed and add any other 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?