Finding DLP Incidents That Have Not Been Responded to in Time

As an incident responder, you know that reacting slowly to incidents can result in worse breach outcomes.  This is why many Incident Response teams commit to Service Level Agreements, or less formal Service Level Objectives, in order to track their response rate and ensure the correct prioritization of work.  In turn, being able to track incident response activity helps customers assess the long-term success of their program and identify areas for improvement.

Symantec DLP, by Broadcom Software, offers multiple ways to help customers automate incident remediation.  This helps incident responders triage incidents, perform additional remediation, and confirm resolution, all in order to satisfy the operational parameters dictated by the organization's risk appetite.  For example, Symantec DLP helps customers perform automated remediation with end-user and escalated notifications, real-time blocking and prevention, and quarantining information on-premises or on the cloud.

In order to help customers better meet their SLA/SLO goals, Symantec continuously innovates and introduces new features that help streamline incident remediation processes.  One such example is the use of the Symantec DLP RESTful API to help customers identify incidents that have breached an established SLA/SLO. The code is available here. Before we look at the detail, you should be aware that the RESTful API allows customers to improve the management of their DLP system in many other ways (you can find links to other articles at the end).

How to use the RESTful API to report on ‘aged’ incidents

The first step is to identify incidents that breach your established SLA/SLO. To do this, you will need to create an Incident Status that will indicate an incident has not been triaged as per the SLA/SLO. For the example in this article, we have created the SLA Breach status.

Once the Incident Status is created, find the identifier that Symantec DLP Enforce assigned to that status. Review that value under System >  Incident Data > Attributes and hover over the Incident Status. In the example below, the value is 161.

We are using the Incident’s creation date and the system status New to filter incidents that breached the SLA/SLO. In the example, you can modify the criteria to fit your organization’s needs. You can define the number of hours stipulated in your SLA/SLO to triage New incidents. In the segment of code from the example below, High Severity incidents have a 4-hour SLA/SLO, Medium Severity ones have an extended 8-hour SLA/SLO, and so on.

dlpEnforceSeverityHighHours= 4

dlpEnforceSeverityMediumHours= 8

dlpEnforceSeverityLowHours= 12

dlpEnforceSeverityInfoHours= 16

As you build out your code we recommend that you test it.  A useful tip is to limit the number of incidents returned by the API, for example, you can use the code below to limit the report to 2 pages in length.

dlpEnforceIncidentPageSize = 2

Lastly, you can simply schedule this utility to run according to your needs, you can adapt the code and run it from an AWS Lambda Function, your own ITMS, SOAR (using, for instance, the Splunk Phantom Timer app - registration required), or any other platform that your SOC uses. The API will move the Incidents to a special SLA Breach queue for prioritized triaging.

Prerequisites

• DLPIncidentSLABreach.py is written in Python 3.8
• Symantec DLP 15.8 MP1
• A Symantec DLP user with API privileges
• Python 3.8
  • Modules: json, requests, logging, datetime, timedelta

NOTE: The code is:  a) an example and b) provided as-is:  we do not know your computing environment so you need to assess the script’s function and performance before implementing it.

What else can the RESTfulAPI do?

The RESTful API provides a powerful capability to our customers, and we believe helps them take their DLP programs to a higher level, whatever their level of Information Security maturity.  Our customers are the source of inspiration for the example we provide above, and REST assured, we will continue to develop the applications of this technology to help meet our customers’ needs.  If you see different applications that would help you, please let your Broadcom account team or technology partner know.

For a more general understanding of the RESTful API, please read this technical guide.

For a different application of how the RESTful API can help, read our blog post listed below.