Monitor & Respond - Email Alert & Incident Queue

Role Requirements

Procedure Scope: Administrators

Required Group Membership: Admin.Security

Handbook Reference

Package: Email Security

Domain: Email

Modifies: Quarantine Queue

When to Perform this Operation

Twice a day: Key times such as 8am and 2pm.

Analyst Description and Importance

 The Defender Incident and Alert Queue is used to monitor essential actions and metrics for the organizations email security and health. It provides the centralized place where security events are organized and prioritized for review, empowering analysts to respond and take action on potential security or business impacts. Continuously monitoring the queue not only ensures that email threats are being addressed and managed effectively, but also that the organization is aware of any events that could impact delivery or availability of email.

Security Importance:

 Monitoring and responding to the alert & incident queue ensures any interruptions to email security are resolved, helping to mitigate the security of risk of critical email security functions from being impaired due to a system change or alert that has been overlooked. 

Business Importance:

 Monitoring and responding to the alert & incident queue ensures any interruptions email deliverability are resolved, helping to mitigate the business risk of critical email not being delivered due to a system change or alert that has been overlooked. 

Covered in this Operation

In email alert and incident management, training is essential for developing a solid understanding of what each alert and incident represents, beyond just hitting "resolve." Effective training enables analysts to interpret the significance of alerts, understand how incidents are constructed, and gain insight into the detection technologies behind them.

With this knowledge, analysts can make informed decisions on when to respond, investigate, or simply resolve an alert. This isn’t about overcomplicating the process—it’s about ensuring that actions are taken with the right context, improving efficiency and accuracy without unnecessary steps. Proper training means analysts can manage alerts and incidents effectively, addressing issues with confidence and minimizing missed risks.

Understanding Alert Entries

In Microsoft Defender, understanding alert details is critical for analyzing and responding to email-based threats and functionality impacts. Each alert is composed of multiple sections that convey essential information about the detected issue and its context.

Alert Queue Entry

• Alert Name: The title of the alert that summarizes the nature of the security event, such as “Email Sending Limit Exceeded” or “Email Reported by User as Junk”. This name gives analysts a quick overview of what type of issue has been identified.
• Tags: Custom labels added to alerts for easy categorization, filtering, or prioritization. Common tags might include “High Priority,” “Phishing,” or specific departmental labels. These tags help organize alerts, making it simpler to sort and focus on relevant alerts.
• Severity: The impact level of the alert, such as “Informational”, “Low”, “Medium”, or “High”. This rating helps analysts prioritize their responses based on the potential risk to the organization. Higher severity alerts generally require immediate investigation.
• Investigation State: The current status of the investigation for the alert, such as “Queued”, “No Threats Found”, “Pending Action”, or “Remediated“. This state provides visibility into which alerts have already been addressed or need further attention.
• Status: The current condition of the alert, such as “New”, “In Progress”, or “Resolved”. The status shows the life cycle of the alert, helping analysts identify unresolved alerts that may still pose a threat.
• Category: The type of threat associated with the alert, such as “Threat Management”. The category allows analysts to filter and organize alerts by threat type, making it easier to manage specific email threats more efficiently.
• Detection Source: Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Office 365 (MDO) for email alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Alert State

• Classification: Defines the nature of the threat after analysis, categorizing it as "True Positive", "Informational", or "False Positive". Helps categorize alerts for post-remediation activities.
• Assigned to: Specifies the analyst or team which was/is responsible for taking an action on the alert. Ensures accountability and clear ownership on response actions.

Alert Details 

• Category: Describes the general type of alert, such as “Threat Management” or “Compliance Manager”. Assists in determining the system the alert relates to and was triggered from.
• MITRE ATT&CK Techniques: Lists the specific techniques associated with the alert from the MITRE ATT&CK framework. Provides a standardized way to understand and communicate threat behaviors.
• Detection Source: Identifies which aspect of the Defender stack the alert originated from, such as "Microsoft Defender for Office 365" or “Microsoft Defender for Endpoint”. Indicates the initial detection source.
• Service Source: Specifies the Microsoft 365 service involved, like "Office 365". Adds data similar to detection sources on which service the threat is associated with.
• Detection Technology: Describes the method or technology used to detect the threat, such as "General Filter", “File Detonation", or "IP Reputation". Offers insight into which detector determined malicious behavior.
• Generated On: Provides the date and time when the alert was created by the system. Important for establishing the timeline of events.
• First Activity: Indicates the earliest timestamp of the suspicious activity related to the alert. Helps determine how long the threat has been present and will always precede the “Generated On” field.
• Last Activity: Indicates the latest timestamp of the suspicious activity related to the alert, either as a result of the threat being remediated or the threat becoming inactive. Helps determine the time between detected activity and remediation/inactivity of the threat by measuring delta between “First Activity” and “Last Activity”.

Evidence

• Evidence Entries: Lists specific data points supporting the alert, such as suspicious emails, IP’s, devices, links, or attachments. Serves as the basis for tracking affected types of entities and their remediation status.

Alert Description

• Alert Description: Provides a detailed summary of the alert, explaining the nature of the threat and potential impact. Essential for understanding the context and severity.

Alert Policy

• Policy Name: Specifies the name of the security policy that triggered the alert, such as "Anti-Phishing Protection Policy", if present. Links the alert to specific organizational controls.
• Alert Policy ID: The unique identifier associated with the alert policy. Facilitates tracking and reference to policy documentation.

Incident Details 

• Incident: References the incident number linked to the alert for tracking and correlation purposes. Integrates the alert into broader incident management processes.
• Incident Severity: Indicates the level of risk associated with the incident, such as "High", "Medium", or "Low". Guides the urgency and extent of response actions.
• Active Alerts: Shows the number of active alerts associated with the incident. Provides an overview of the incident's scope.
• Devices: Lists any affected devices, if applicable. Important for identifying compromised endpoints.
• Users: Identifies users impacted by the threat. Necessary for user-specific remediation and communication.
• Mailboxes: Specifies the mailboxes that were targeted or affected. Key for addressing email-based threats.
• Apps: Lists any applications involved in the incident, if applicable. Helps in assessing the vulnerability of software and services.

Impacted Assets

• Devices (May Appear): Details the specific device entries as they relate to a single alert, with these individual entries that can be found per-alert feeding the overall impact reflected in an incident.
• Users (May Appear): Details the specific user entries as they relate to a single alert, with these individual entries that can be found per-alert feeding the overall impact reflected in an incident.
• Mailboxes (May Appear): Details the specific mailbox entries as they relate to a single alert, with these individual entries that can be found per-alert feeding the overall impact reflected in an incident.
• Apps (May Appear): Details the specific app entries as they relate to a single alert, with these individual entries that can be found per-alert feeding the overall impact reflected in an incident.
• Cloud Resources (May Appear): Details the specific cloud resource entries as they relate to a single alert, with these individual entries that can be found per-alert feeding the overall impact reflected in an incident.

Comments and History

• Comments Section: Allows analysts to add notes and document actions taken or observations about the alert. Facilitates communication among team members and maintains a record of investigative steps.
• History Log: Displays a timeline of actions related to the alert, such as changes in status and assignments to different analysts. Automation events are also tracked here, like linking the alert to a specific incident.

Understanding Incident Entries

In Microsoft Defender, understanding how alerts inform incidents is critical for analyzing and responding to threats and functionality impacts. Each incident is composed of multiple alerts, with a critical understanding being that an incident will never exist without an alert but instead acts as a vehicle to provide context for one or more alerts.

Attack Story section:

• Alerts: Lists all alerts that are part of the incident, providing a consolidated view of related security events and showing how individual alerts contribute to the overall incident.
• Incident Graph: A visual representation of the relationships between entities involved in the incident, such as users, devices, files, and network connections. Displays the attack's progression and identifies patterns or correlations among different components.

Alerts section:

• Alert Name: The title of the alert that summarizes the nature of the security event, such as "Email Sending Limit Exceeded" or "Phishing Attempt Detected." Provides a quick overview of the identified issue.
• Tags: Custom labels added to alerts for easy categorization, filtering, or prioritization. Common tags might include “High Priority,” “Phishing,” or specific departmental labels. These tags help organize alerts, making it simpler to sort and focus on relevant alerts.
• Severity: The impact level of the alert, such as “Informational”, “Low”, “Medium”, or “High”. This rating helps analysts prioritize their responses based on the potential risk to the organization. Higher severity alerts generally require immediate investigation.
• Investigation State: The current status of the investigation for the alert, such as “Queued”, “No Threats Found”, “Pending Action”, or “Remediated“. This state provides visibility into which alerts have already been addressed or need further attention.
• Status: The current condition of the alert, such as “New”, “In Progress”, or “Resolved”. The status shows the life cycle of the alert, helping analysts identify unresolved alerts that may still pose a threat.
• Category: The type of threat associated with the alert, such as “Threat Management”. The category allows analysts to filter and organize alerts by threat type, making it easier to manage specific email threats more efficiently.
• Detection Source: Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Office 365 (MDO) for email alerts and Microsoft Defender for Endpoint for endpoint alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Assets section:

• Devices: Details specific devices involved in the incident, including endpoints that may have been compromised or used in the attack. Provides information crucial for isolating affected devices and preventing further spread.
• Users: Information about users associated with the incident, such as those who received phishing emails or whose accounts may have been compromised. Identifies impacted users for targeted remediation efforts.
• Mailboxes: Details of mailboxes involved in the incident, important for email threats where specific mailboxes have been targeted or affected. Assesses the extent of the threat within the organization's email infrastructure.
• Apps: Information about applications involved in the incident, which may include cloud apps or on-premises software that have been exploited or are at risk. Helps in securing application environments and data.
• Cloud Resources: Details about cloud resources related to the incident, such as Azure services or other cloud assets that may have been involved. Protects cloud infrastructure and services from ongoing threats.

Investigations section:

• Triggering Alert: The initial alert that prompted the automated investigation, serving as the starting point for analyzing the incident. Highlights the event that first signaled a potential threat.
• ID: The unique identifier assigned to the investigation, used for tracking, and referencing throughout the incident response process.
• Investigation Status: The current state of the automated investigation, such as "Pending Action", "Remediated", or "Failed". Indicates progress and whether further manual intervention is required.
• Service Source: Specifies the Microsoft 365 service involved, like "Office 365". Adds data similar to detection sources on which service the threat is associated with.
• Detection Source: Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Office 365 (MDO) for email alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Evidence and Response section:

• Emails (May Appear): Lists emails that are evidence in the investigation, including malicious messages, phishing attempts, or emails with suspicious attachments or links. Outlines individual emails and if they are in scope for remediation actions, should they be approved.
• Email Clusters (May Appear): Groups of related emails identified as part of the same threat campaign. Outlines the email clusters with their status and if they are in scope for remediation actions, should they be approved.
• IP Addresses (May Appear): IP addresses involved in the incident, either as sources of malicious activity or as targets. Outlines IP addresses with their status and if they are in scope for remediation actions, should they be approved.
• Files (May Appear): Files pertinent to the investigation, such as malware samples, infected documents, or unauthorized downloads. Outlines files with their status and if they are in scope for remediation actions, should they be approved.
• Processes (May Appear): Processes running on devices associated with the incident, which may indicate malware execution or unauthorized activities. Outlines processes with their status and if they are in scope for remediation actions, should they be approved.
• URL’s (May Appear): Web addresses involved in the incident, such as phishing sites, command-and-control servers, or sites hosting malware. Outlines URLs with their status and if they are in scope for remediation actions, should they be approved.

Recommended Actions section:

• Rank: The priority level assigned to each recommended action, guiding which steps to take first based on their potential impact on mitigating the threat.
• Recommended Action: Specific steps suggested to help prevent future threats of this type, such enforcing MFA or enabling other specific security controls.
• Score Impact: The number of points converted to a percentage of total possible points given to an organizations Secure Score for implementing the recommendation.
• Points Achieved: The number of points towards the total possible points given to an organizations Secure Score for implementing the recommendation.
• Status: The current state of the recommended action, such as "Completed” or “To Address”, based on if the Secure Score observes the expected configuration items already in place.

Understanding Email Detection Technologies

As it pertains to alerts and incidents for email, the detection technologies are mirrored in the same way as in the quarantine queue and reflect identically. For Microsoft’s verbatim definitions of these, view the knowledge article here.

Recognizing when to Respond and Resolve

Not all alerts or incidents require a response, but those that do benefit from a swift decision and action to ensure business operations aren’t impacted. These types will be resolved as usual, with the addition of an action taken by the security team.

Recognizing when to Investigate and Resolve

Not all alerts and incidents require investigation, but those that do are often the result of activity that relies heavily on the opinion of a technical decision maker at the organization for it fits into the context of the business. These types will be resolved as usual, with the addition of possible further investigation taken by the technology team.

Recognizing when to Resolve Only

Not all alerts and incidents require investigation or response and can simply be resolved with acknowledgement. These types will be resolved as usual, having understood the impact of them being triggered.

In the context of email alert and incident management, monitoring includes 2 steps: alert monitoring and incident monitoring.

This fact is due to the nature of the Defender alert and incident management system, wherein, alerts are the drivers for incidents. An alert contains the specifics about a point in time threat or activity, and incidents are simply one or more alerts combined together. This means a single alert has a high likelihood of generating an incident, and when an alert is remediated or resolved, the incident mirrors this status. The resulting workflow works best when working through alerts first, and then incidents, allowing the resolution of alerts to automatically solve incidents without further intervention in most cases.

Review the Defender for Email Alert Queue

Reviewing unresolved alerts is first, as it drives resolution in both alerts and incidents.

Review the Defender for Email Incident Queue

Reviewing unresolved incidents is next, as checking no further actions are required after solving for alerts in recommended.

In the context of email alert and incident management, a response action is always warranted.

This fact is due to the nature of the email alert and incident management system, wherein, automation may automatically resolve some alerts and by extension the incidents they are a part of automatically. However, alerts and incidents which are not covered under this automation will be marked as “In Progress” or “New”, and subsequently require acknowledgement and resolution at a minimum, or additional actions in certain cases.

Respond with Alert Resolved

The primary goal of alert queue management is concerned with the acknowledgement and resolution of alerts in the queue. Further investigation and response for specific alerts does not need to be performed to successfully resolve an alert, however, there are cases where those additional actions are warranted. See the “Recognize when to Investigate and Resolve” and “Recognize when to Respond and Resolve” sections for more information on these cases.

Respond with Incident Resolved

The primary goal of incident queue management is concerned with the acknowledgement and resolution of incidents in the queue. Further investigation and response for specific incidents does not need to be performed to successfully resolve an incident, however, there are cases where those additional actions are warranted. See the “Recognize when to Investigate and Resolve” and “Recognize when to Respond and Resolve” sections for more information on these cases.

Need Assistance?