What Should I Do with These DLP Alerts, Anyway?

Today I am going to address a common tactical and process challenge that comes up when working with clients implementing Data Loss Prevention policies: How are DLP alerts handled? Also, who performs triage, investigation, and resolution?

DLP alerts are unique. They can be an indicator of a number of different issues, and they frequently require involvement form both the information security and data governance teams. 

Purview DLP alerts are included in both the Defender portal and the Purview Compliance portal. Having those alerts in the Defender portal is useful since it allows the security team to see the DLP alerts in context with identity and device activity for the same user or endpoint. However, they are usually investigated and resolved outside of the security team, since access to the sensitive data that triggered the alert may only be authorized to be accessed by the HR, compliance, or privacy teams. Since these alerts can cross several organizational groups, a brand-new process often needs to be developed to address the alerts appropriately.

The response process typically consists of the three steps I have outlined below. Depending on the size of your organization and how many stakeholders need to provide input, it may involve more than the groups I have listed here—but the general structure is the same.

Step One: Triage – Is it a Security Event or An Error?

The first step that should be taken is a review of the alert and related details to determine if there is any indication of a breach or attempted malicious data exfiltration. Criteria such as the number of data items included, types of data, contemporaneous identity or endpoint activity, and user history can all help determine the severity of the event and whether your incident response plan needs to be activated.

Most of the time (hopefully), the alert is not caused by malicious activity, but by an employee making a mistake or not following proper procedure in sharing sensitive data. Provided that is the case, the alert can be reassigned and moved to the investigation step so that the appropriate team can evaluate what happened and take corrective action.

This initial review of the incident is typically performed by the security team, who often have existing processes and SOC staff that are already well-positioned to see an alert and act immediately.

Step Two: Investigation – What Happened, and What Should Be Done About It?

Once the initial triage is complete, the alert should be assigned to someone that has been designated to perform some technical analysis of the event and work with employees or their managers to understand what happened and why. It is important that this role have the ability to see the sensitive data that was accessed to ask:

  • Is it a true positive detection of sensitive data?
  • Why and how was this data shared?
  • Is there a process or tool that is needed to prevent a future DLP event?

Depending on the answers to these questions, the investigator can take actions such as improving the DLP platform’s definition of a sensitive data type, engaging with the sender to understand the business process that led to the event, or define a better way to share this data. There may also be an opportunity to provide some training if that is identified as a gap.

Often GRC (governance, risk, and compliance) or data privacy staff will perform this investigation, as they often have the mix of skills and background to understand and provide guidance both technically and procedurally.

Step Three: Resolution – How Do You Improve Data Protection?

There are a variety of findings and recommendations that may come out of an investigation, depending on the circumstances and root cause. Sometimes the resolution is to simply train or update the automated sensitive data detection in the DLP platform. Other times, it may be something as complex as updating acceptable use polices and then identifying and onboarding a new application or service to address a new business need. Or anything in between.

Investigation findings and recommendations should be escalated to the data governance owner and possibly others to evaluate the result and decide what the next step is. As an example, if passwords need to be shared securely, how is that done? Should a password manager be implemented, or do you simply require the email that contains the password to be encrypted? Depending on the industry, regulations, and PMO workload, that answer can vary quite a bit. Someone with the agency and authority to decide should be part of the resolution process.

Senior GRC, CISO, or data privacy staff are often involved to make this determination and help to implement the changes or new practices required.

General Practices to Make DLP Less Disruptive

  • Avoid notifying DLP violators with automated emails. A common first step that I see clients take with DLP is to have the DLP platform send an automated email that tells them they violated a policy. While this may be helpful at the very beginning of a DLP implementation, those alerts become background noise very quickly and people stop paying attention to them. 
  • A better approach can be to warn people with tool tips in Outlook or Word, and soon after, adding in a requirement that they acknowledge or override a detection. This way, their response is logged and can also help identify false positives or process gaps. (Responses are recorded in the M365 audit log.) Blocking policies or manager-approval workflows are obviously the most effective at curbing inappropriate data use, but they need to be accurate and as non-disruptive possible.
  • Make sure to specifically define the “right” way to do things. Written policies are often focused on what not to do. Including guidance that affirmatively approves the sanctioned methods for sharing data goes a long way toward making the policy easier to understand and follow.
  • Related to the above point—make sure the tools to share sensitive data are in place and actually meet the business needs. A conversation with the different business groups to understand how they use sensitive data and how DLP restrictions will impact them is critical to a successful implementation.
  • Applying default sensitivity labels to specific data locations (such as the HR SharePoint library) can help to quickly protect data that is likely sensitive. DLP policies can then be built to protect that labeled data with a high level of accuracy.
  • Determine if DLP alert thresholds are appropriate. The number of sensitive data elements in each email or file can be used as a criterion for alerting. It may be acceptable to share one or two credit card numbers via email for a one-off situation, but not acceptable to share ten. Allowing a small number of records through is often a way to reduce the noise in a DLP alert flow. Thresholds should be determined based on the risk they present. (Some kinds of data should never be shared.)

We Can Help!

If you have questions about Data Loss Prevention or receiving DLP alerts, contact our team at info@eGroup-us.com or complete the form below.

Have Questions or Need Assistance with Data Loss Prevention?

Contact our team of experts today!