Discovering and Reporting on DLP Alerts Older than 7 Days with Microsoft M365 E3
As we discussed in the sharing blog, your organization relies on sharing and working with information both internally and externally.Some of that data will be business and customer sensitive. Detexian’s CTO Adrian Kitto has some suggestions about how to get visibility of the DLP alerts beyond the Microsoft Purview defaults of 7 days.
In case you missed it last time, please check out:
Part 1: Who / What / Why does the mid-market all have Microsoft M365 E3 licenses
Part 2: How does Microsoft M365 E3 work with the non-Microsoft ecosystem applications?
Part 3: Discovering user consented apps with Microsoft M365 E3
Part 4: Identifying and removing inactive users with Microsoft M365 E3
Part 5: Calculating inferred or effective MFA for non-Microsoft applications
Part 6: Privileged Access Management in non-SCIM apps with Microsoft M365 E3
Part 7: Identifying, Evaluating, and Tracking Open Shares for External Users with Microsoft M365 E3
Introduction
In the modern workplace, securing sensitive data is a top priority for organizations of all sizes.
Microsoft’s M365 is the go-to productivity solution for collaboration and productivity. A significant aspect of data security within M365 is the Data Loss Prevention (DLP) feature which has been badged Microsoft Purview recently. When implemented, configured and monitored, it helps prevent inadvertent sharing of sensitive information. While DLP alerts are invaluable for maintaining data confidentiality in real time, there's often a critical gap when it comes to monitoring alerts older than the default 7 days available to Microsoft M365 E3 customers.
In this blog post, we will delve into the risks of not adequately monitoring DLP alerts, the limitations of M365 E3's default retention, and how to use PowerShell to export DLP alerts for better insights and reporting.
The Risks of Ignoring DLP Alerts
DLP alerts are crucial indicators of potential data breaches, highlighting instances where sensitive information might have been shared inappropriately. Failing to monitor these alerts can lead to several risks:
Undetected Data Breaches: Data breaches can go unnoticed for extended periods if DLP alerts are not actively monitored. Attackers can exploit this window of vulnerability to exfiltrate sensitive data or execute targeted attacks.
Lack of Visibility: Ignoring DLP alerts means losing visibility into potential threats and vulnerabilities. This can hamper proactive measures to prevent data leaks and ensure compliance.
Reputational Damage: If sensitive information ends up in the wrong hands, it can lead to reputational damage, loss of customer trust, and legal repercussions, particularly in industries with stringent compliance requirements.
Logging older DLP (Data Loss Prevention) alerts beyond the default retention period can offer several valuable advantages to an organization's security and compliance efforts. Here are some compelling reasons to consider logging and retaining older DLP alerts:
Forensic Investigations: When a security incident occurs, especially one involving data leakage, having access to historical DLP event logs can be instrumental in conducting thorough forensic investigations. These logs can help uncover the root cause of the incident, the extent of the breach, and the timeline of alerts leading up to it.
Compliance Audits: Many industries have regulatory requirements that mandate data retention for a specific duration. By logging older DLP alerts, organizations can demonstrate compliance with data protection and privacy regulations. These logs serve as evidence of due diligence and proactive efforts to safeguard sensitive information.
Identifying Insider Threats: Insider threats, whether malicious or unintentional, can pose a significant risk to data security. Logging older DLP alerts allows organizations to trace back to potential insider threats or anomalies in user behavior that might have gone unnoticed during real-time monitoring.
Training and Education: Historical DLP alerts can serve as real-world examples for training and educational purposes. Organizations can use past incidents to illustrate potential risks and consequences of data leakage, fostering better understanding and promoting better data handling practices among employees.
Preventing Future Incidents: Learning from past mistakes is a key principle of cybersecurity. By analyzing older DLP alerts, organizations can identify gaps in security measures, areas prone to data leakage, and weaknesses in user behavior. This knowledge can guide the implementation of stronger security controls to prevent future incidents.
Litigation and Legal Proceedings: In the event of legal actions, such as data breach lawsuits or intellectual property disputes, access to historical DLP event logs can be critical for building a strong legal defense or demonstrating compliance with data protection obligations.
Historical Analysis and Trend Identification: Logging older DLP alerts enables organizations to perform historical analysis and identify trends in data leakage incidents. By examining patterns over time, security teams can gain insights into common vulnerabilities, risky behaviors, and specific areas that require enhanced protection.
Security Policy Refinement: Historical DLP event logs can inform the refinement of security policies and incident response plans. Organizations can use insights gained from analyzing past incidents to enhance their security strategies, closing loopholes and adapting to emerging threats.
Limitations of M365 E3 Default Retention Period
Microsoft M365 E3 offers a default retention period of 7 days for DLP alerts. After this period, alerts are automatically purged from the system, making it challenging to conduct comprehensive investigations or historical analysis. To address this limitation and retain DLP alerts beyond 7 days, organizations must resort to exporting the alerts to Security Information and Event Management (SIEM) systems or CSV files if they cannot justify upgrading to the Microsoft M365 E5 license offering which allows alerts to be retained for up to 10 years.
Where to start with DLP?
Implementing a basic DLP policy is a crucial step in data protection. Here's a reasonable framework for a basic DLP policy:
Identify Sensitive Data: Identify and classify sensitive data such as personal information, financial data, proprietary information, and confidential documents.
Define Data Sharing Rules: Create rules that prevent sensitive data from being shared with unauthorized recipients or outside the organization. Microsoft Purview has excellent templates that will allow you to identify sensitive data such as GDPR or HIPAA data and monitor or block it.
Educate Employees: Educate employees about the importance of data security and how to recognize potential data leakage risks. We recommend running a Cyber Awareness and Education campaign or solution for this.
Regular Monitoring: Regularly monitor DLP alerts and investigate potential incidents promptly.
Incident Response: Have a well-defined incident response plan in place to address DLP breaches efficiently.
Once you are capturing the alerts, you can use them to start tuning your policy. For example, one of our customers had a system mailbox that was sending nearly 800 emails per day that would trigger the Australian Financial Data template. It was a minor action to update the rule to exclude this one email address to filter out the noise to identify the actual risky behaviors.
Exporting DLP Alerts with PowerShell
As the default retention is only 7 days I highly recommend exporting the DLP alert log 1-2 times per week to develop a library of historical alerts. These are important for the reasons documented above.
Here’s a simple PowerShell command to export all DLP alerts for the last 7 days to a CSV file:
# Connect to Security & Compliance Center
Connect-IPPSSession -UserPrincipalName <update your admin UPN>
# Get DLP alerts for the last 7 days
$startDate = (Get-Date).AddDays(-7)
$endDate = Get-Date
$dlpAlerts = Get-DLPAlert -StartDate $startDate -EndDate $endDate
# Export DLP alerts to CSV
$dlpAlerts | Export-Csv -Path "DLPAlerts.csv" -NoTypeInformation
Remember!! to test the script in a non-production environment and thoroughly review before running it in production.
Once you have these saved over time you can tune and monitor for reduction and / or use it to identify incidents or potential bad actors in your organization.
Conclusion
Maintaining robust data security is an ongoing process that requires vigilance and adaptability. Ignoring DLP alerts exposes organizations to data breaches, reputation damage, and legal consequences. While M365 E3's default retention period of 7 days presents a limitation, PowerShell provides a workaround to export DLP alerts for extended analysis and reporting.
By adhering to a reasonable basic DLP policy, organizations can proactively protect sensitive data, respond swiftly to incidents, and ensure compliance in the evolving landscape of data security.
Security thought for the week
This last week saw the Blackhat security conference held in Las Vegas. Black Hat was founded in 1997 by Jeff Moss, also known as "Dark Tangent" who also founded DEF CON.
The first Black Hat conference took place in Las Vegas, Nevada, USA. The conference was established as a platform for cybersecurity professionals, researchers, and experts to come together to discuss the latest developments, vulnerabilities, and trends in the field of information security. It is a more corporate style conference where DEF CON is more informal and community led.
Till then, stay secure.
Adrian
