Published: 13th Feb, 2021
Author: Denis Kattithara
I have been working on DLP for over a decade, and the technology landscape keeps changing constantly. Unfortunately, these changes have a severe impact on the business strategy and incident management functions. As an example, I have seen customers using Symantec and migrating to Forcepoint/Microsoft. Moreover, few customers also leverage multiple DLP technologies, which is a nightmare for incident management (ie. multiple consoles).
The idea behind a layered service architecture is to consolidate DLP incident management & reporting functionality in a centralized interface. This means that you could have incident feeds from various technologies available for review and remediation in a single platform. Moreover, this creates a layer between incident management vs technology, ensuring that you could migrate from one technology to another with negligible impact on incident management teams. It is possible to achieve this through a custom developed connector (where required), that performs the following functions:
a) Fetch DLP incidents from the source technology solution
b) Ingest incidents into a Service Desk / Case Management solution, that will be leveraged for centralized incident management. Most of these solutions have inbuilt workflow management, as well as reporting capabilities.
Note: You may consider benefiting from existing solutions like the Symantec DLP 15.8 ServiceNow / Splunk Phantom integration etc, as well as custom plugins developed by various service providers
There are several aspects that must be considered while designing a centralized incident management solution:
Access Management - This is likely to differ to a significant extent across various organizations, as incident management teams may be structured and staffed differently. Moreover, the adoption of a Fan-in vs Fan-out incident management approach plays an important role here. Below are some pointers that may be helpful in determining access requirements and categorizing the same into unique roles:
- Who needs access to DLP incidents, and what are their job descriptions?
- What level of access is required?
- System parameters (eg. incident attributes) that may be leveraged to provision access
Workflows - There are various workflows leveraged within DLP, ranging from access driven incident escalation to more complicated automations built for operational tasks. Building these workflows into a single centralized platform is a big win, as it reduces a lot of complexities over the longer term. At a high level, we should factor various automated vs manually triggered workflows that must be implemented.
Presentation of incidents - The success of a DLP program is heavily reliant on qualitative incident management. It is imperative that the incident management interface must be really simple and straight forward from the perspective of an analyst, thus maximizing the ROI of this solution. Below are few pointers to consider:
- Look and feel of an incident
- Anchor attributes available within the source incident solution (Active directory account, SMTP address etc)
- Attributes required within an incident (Job title, department, manager, ++ etc)
- Data available within an incident (File, content snapshot, ++ etc)
DLP Reporting - In most cases you should be able to generate reports from your newly integrated Service Desk / Case Management solution. However, you may also consider integration with an appropriate SIEM solution in order to build and leverage enhanced reporting capabilities.
