Monitor & Respond - Device Alert & Incident Queue

Role Requirements

Procedure Scope: Administrators

Required Group Membership: Admin.SecurityOperator

Handbook Reference

Package: Device Security

Domain: Alert & Incident Queue

Modifies: Device Alert Queue, Device Incident Queue 

When to Perform this Operation

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

Analyst Description and Importance

The Defender Device Incident and Alert Queue is used to monitor essential actions and metrics for the organization's device security and health. It serves as a centralized hub where security events related to devices are organized and prioritized for review, enabling analysts to assess and respond to potential security or operational risks. Continuously monitoring the queue ensures that device threats are identified and addressed effectively, while also providing visibility into events that could impact system integrity, compliance, or availability.

Security Importance:

 Monitoring and responding to the alert & incident queue ensures that any potential threats or misconfiguration to device security are resolved, helping to mitigate the security risk of critical device security functions being compromised due to overlooked alerts or system changes.

Business Importance:

 Monitoring and responding to the alert & incident queue ensures that any potential disruptions caused by device security events are minimized, helping to mitigate the business risk of critical device functions being compromised due to overlooked alerts or system changes.

Covered in this Operation

In device 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 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 device-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 “[Name of Malware] high-severity malware was detected” or “[Name of Software] credential theft tool”. This name gives analysts a quick overview of what type of threat has been identified.
• Tags:  Custom labels are added to alerts for easy categorization, filtering, or prioritization. Common tags might include “High Priority,” “Ransomware,” 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 “Suspicious Activity”. The category allows analysts to filter and organize alerts by threat type, making it easier to manage specific device threats more efficiently.
• Detection Source:  Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Endpoint (Antivirus) for device 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 next steps.

Alert Details

• Alert ID: Lists the unique ID associated with the generated alert. Assists in uniquely identifying an alert.
• Category: Describes the general type of alert, such as “Suspicious Activity” or “Malware”. Assists in determining the stage or general classification of a potential threat.
• 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 Endpoint" or “Microsoft Defender XDR”. Indicates the initial detection source.
• Service Source: Specifies the Microsoft 365 service involved, like "Defender for Endpoint". Adds data similar to detection sources on which service the threat is associated with.
• Detection Status: Insight into how a threat was identified and handled, such as “Detected”, “Blocked”, or “Prevented”. These statuses help security teams understand the nature of threats and the effectiveness of their security measures, guiding appropriate responses to maintain organizational security.
• Detection Technology: Describes the method or technology used to detect the threat, such as "Client", or "Heuristic". 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 devices, files, or applications. Serves as the basis for tracking affected types of entities and their 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.

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 affected 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.

Linked By

• Same Device (May Appear): Alerts are associated with the same device.
• Same File (May Appear): Alerts are associated with the same file.
• Same URL (May Appear): Alerts are associated with the same URL.

Automated Investigation (May Appear)

• Investigation ID (May Appear): Identifies the suspected threat or tool being investigated.
• Investigation Status (May Appear): Describes the current state of the automated investigation.
• Start Time (May Appear): Timestamp of when the automated investigation began.
• End Time (May Appear): Timestamp of when the automated investigation ended.
• Duration (May Appear): Time taken for the investigation to complete.

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

• 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

• Alert Name: The title of the alert that summarizes the nature of the security event, such as "[Malware Name] heigh-severity malware was detected" or "[Name of software] post-exploitation tool." 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,” Ransomware,” 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 “Suspicious Activity”. The category allows analysts to filter and organize alerts by threat type, making it easier to manage specific device threats more efficiently.
• Detection Source: Identifies the Microsoft Defender component that generated the alert, typically listed as Defender for Endpoint (Antivirus) for device alerts and Microsoft Defender for Office 365 for email alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Assets

• 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 the threat.
• Mailboxes: Details of mailboxes involved in the incident, important for email threats where specific mailboxes have been targeted or affected. Identifies impacted mailboxes for the threat.
• 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. Identifies impacted apps for the threat.
• Cloud Resources: Details about cloud resources related to the incident, such as Azure services or other cloud assets that may have been involved. Identifies impacted apps for the threat.

Investigations

• 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. Helps to uniquely identify the activities related to the investigation.
• Investigation Status: The current state of the automated investigation, such as "No Threats Found. Indicates progress and whether further manual intervention is required.
• Service Source: Specifies the Microsoft 365 service involved, like "Microsoft Defender for Endpoint". 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 Endpoint (Antivirus) for device alerts. This field helps analysts understand where the alert originated, guiding them to the right tools and resources for investigation.

Evidence and Response

• 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.

Summary

• Alerts and Categories: Provides information on the number of unresolved alerts tied to this incident, MITRE ATT&CK framework tactics identified in the alerts, and general classification tags associated with the alerts.
• Scope: Provides the number and type of affected assets tied to the incident.
• Alerts: Provides all associated alerts that are tied to the incident.
• Evidence: Provides the number and type of malicious/suspicious files, processes, IP addresses, URLs, etc.

Understanding Device Detection Technologies

As it pertains to alerts and incidents for devices, the detection technologies are derived from Microsoft Defender Antivirus or Microsoft Defender Advanced Threat Protection.

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.

If you encounter an alert/incident name that is not currently listed in the table above, a good baseline to follow for severity would be:

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 device 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. 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 Device Security Alert Queue

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

Review the Defender Device Security Incident Queue

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

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

This fact is due to the nature of the device 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 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” section 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” section for more information on these cases.

Need Assistance?