Microsoft 365 Alert Policies

Microsoft 365 alert policies are predefined or custom rules that automatically generate alerts when specific activities occur in the Microsoft 365 environment. They are part of the Microsoft 365 Defender suite and are managed in the Microsoft 365 Defender portal (security.microsoft.com). Alert policies help security teams detect potential threats, compliance violations, or operational issues by monitoring user and admin actions across Exchange Online, SharePoint Online, OneDrive for Business, Azure AD, Microsoft Teams, and other workloads.

Before alert policies, organizations relied on manual review of audit logs or third-party SIEM tools to detect suspicious activity. This was inefficient and often missed critical events. Alert policies automate detection by applying predefined logic to the Unified Audit Log (UAL). They reduce mean time to detect (MTTD) and enable automated responses like blocking a user or initiating an investigation.

Alert policies operate through a three-stage pipeline: (1) Activity Triggering, (2) Aggregation and Threshold Evaluation, (3) Alert Generation and Notification.

Stage 1: Activity Triggering

Every user or admin action in Microsoft 365 generates an audit record in the UAL. For example, when a user signs in from a new IP address, an "User logged in" event is recorded with properties like UserId, IP address, Location, ClientApp, and Timestamp. Alert policies subscribe to specific event types. When an event matches the policy's conditions (e.g., event type is "MailItemsAccessed" and the operation is "MailboxLogin"), the policy engine evaluates the event.

Stage 2: Aggregation and Threshold Evaluation

Many alert policies use aggregation to reduce noise. Instead of firing an alert for every single event, the policy collects events that match a pattern over a time window. For instance, the policy "A user has sent more than 100 emails in 5 minutes" aggregates all "Send" events for a specific user within a 5-minute sliding window. If the count exceeds the threshold (100), an alert is triggered. The default aggregation window is 5 minutes for most policies, but this can be configured for custom policies.

Stage 3: Alert Generation and Notification

When the threshold is met, the alert policy generates an alert in the Microsoft 365 Defender portal. The alert includes:

Additionally, the policy can send email notifications to a security distribution group or specific admins. The email is sent within 5 minutes of alert generation, but there may be a delay if the alert volume is high.

- Policy Types: - Predefined policies: Microsoft provides about 30+ default alert policies covering common scenarios like malware detection, impossible travel, risky sign-ins, and data exfiltration. These cannot be deleted but can be deactivated or modified (except for some critical ones). - Custom policies: Admins can create custom alert policies for specific needs, such as monitoring a sensitive SharePoint site or tracking deletion of large numbers of files.

- Default Alert Policies: - "Suspicious email sending patterns" – triggers when a user sends > 100 emails in 5 minutes. - "Malware campaign detected after delivery" – triggers when a malware campaign bypasses initial filters. - "Impossible travel" – triggers when a user signs in from two locations that are geographically distant within a time window shorter than the travel time. - "Risky sign-in" – triggers when Azure AD Identity Protection detects a risky sign-in. - "eDiscovery search started or exported" – triggers when an admin starts or exports an eDiscovery search.

Alert policies are managed in the Microsoft 365 Defender portal under Email & collaboration > Policies & rules > Alert policy. To view existing policies:

Navigate to https://security.microsoft.com/alertpolicies

To create a custom alert policy: 1. Go to Alert policy > + New alert policy. 2. Name: e.g., "SharePoint mass download detection" 3. Description: Describe the purpose. 4. Severity: Choose High. 5. Category: Data loss prevention. 6. Choose a condition: e.g., Activity is "FileDownloaded" and IP address is not in the trusted IP range. 7. Set threshold: > 20 downloads in 5 minutes. 8. Notifications: Send email to security@contoso.com. 9. Review and create.

To verify alerts, check the Incidents & alerts > Alerts page. You can also use PowerShell to manage alert policies:

# Connect to Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# Get all alert policies
Get-AlertPolicy | Format-Table Name, Enabled, Severity

# Create a new alert policy (example)
New-AlertPolicy -Name "Custom Policy" -Severity High -Category DataLossPrevention -Threshold 100 -TimeWindow 10

Alert policies integrate deeply with: - Unified Audit Log: All events are recorded here. Alert policies query this log in near-real-time. - Microsoft 365 Defender: Alerts appear in the unified incidents queue, correlating with other signals like endpoint detection and response (EDR) alerts. - Azure AD Identity Protection: Risky sign-in alerts from Identity Protection can trigger alert policies. - Microsoft Purview Compliance: Data loss prevention (DLP) policies can generate alerts that are surfaced through alert policies. - Automated Investigation and Response (AIR): Some alert policies can trigger automated playbooks that investigate and remediate threats without manual intervention.

A large financial services company with 10,000 employees uses SharePoint Online to store sensitive client documents. They need to detect when an employee downloads an unusually large number of files in a short period, which could indicate data exfiltration. They create a custom alert policy named "Mass Download Detection" with the following configuration:

In production, this policy generates about 5-10 alerts per week. Most are false positives from users on VPN (VPN IPs are not always in the trusted range). They add the VPN IP range to the exclusion list, reducing false positives to 1-2 per week. Performance is not an issue because the policy engine scales automatically. However, during a merger, thousands of files were legitimately migrated, causing a spike. They temporarily disabled the policy. Misconfiguration could occur if the threshold is set too low (e.g., 10 files), causing alert fatigue, or too high (e.g., 500 files), missing real exfiltration.

A global consulting firm with offices in New York, London, and Tokyo uses the predefined "Impossible travel" alert policy. This policy detects when a user signs in from two geographically distant locations within a time window that makes travel impossible. For example, a sign-in from New York at 9:00 AM and from London at 9:30 AM would trigger an alert because the travel time is at least 7 hours. The policy uses Azure AD Identity Protection data and the user's typical sign-in patterns. In production, the policy generates about 20 alerts per month. Many are false positives due to VPNs or mobile devices that route through different data centers. The security team uses the alert to investigate and often finds that the user was using a VPN or had a mobile device with location spoofing. They tune the policy by excluding trusted IP ranges and known VPN exit points. A common misconfiguration is not updating the trusted IP list regularly, leading to excessive false positives.

A healthcare organization subject to HIPAA must monitor all admin actions in Exchange Online and SharePoint. They use the predefined "eDiscovery search started or exported" alert policy to track when an admin runs an eDiscovery search or exports results. This policy triggers an alert for each occurrence (no aggregation) with severity Medium. The security team receives email notifications and reviews the search queries to ensure they are legitimate. In production, this generates about 10 alerts per day from the compliance team's routine searches. To reduce noise, they create a custom policy that excludes the compliance team's service account. They also set up a Power Automate flow to automatically log the alert to a SIEM system. Misconfiguration could occur if the policy is disabled accidentally, leading to undetected unauthorized eDiscovery activities.