Purpose of This Lesson

Microsoft Sentinel incidents provide a central investigation record for related alerts, entities, evidence, analyst decisions, and response actions. This lesson focuses on the permissions required to manage incidents and the manual workflow for investigating, assigning, documenting, classifying, and closing an incident in the Microsoft Defender portal.

The SC-200 exam commonly tests whether an analyst can:

• Select the correct Microsoft Sentinel role.
• Interpret an incident graph and its entities.
• distinguish incident severity from analyst classification.
• Assign ownership and update incident status.
• Document whether activity is malicious, benign, or incorrectly detected.
• Choose an appropriate response for suspicious identity activity.

Key Concepts

Microsoft Sentinel Incident Permissions

Microsoft Sentinel uses Azure role-based access control, or Azure RBAC. Roles can be assigned through Access control (IAM) at scopes such as the Sentinel workspace, resource group, or subscription.

The main role for analysts who must update and manage incidents is Microsoft Sentinel Responder. It permits an analyst to investigate incidents and perform incident-management operations such as changing status and assignment.

Use the narrowest practical scope:

1. Open the relevant Log Analytics workspace or its resource group in the Azure portal.
2. Select Access control (IAM).
3. Add a role assignment.
4. Select Microsoft Sentinel Responder.
5. Assign the appropriate user or security group.

Assigning the role at resource-group scope affects applicable resources throughout that resource group. Workspace scope is preferable when access should be limited to one Sentinel workspace.

> Important: Microsoft Entra Global Administrator and Azure resource permissions are separate authorization systems. A Global Administrator does not automatically receive access to every Azure resource. Azure RBAC must still be assigned, unless privileged access has been explicitly elevated and granted.

Incident Versus Alert

An alert is a detection generated by an analytics rule or connected Microsoft security product. An incident is the investigation container that can correlate one or more alerts and their associated entities.

An incident may include:

• Alerts and detection details
• User accounts
• IP addresses
• Devices or hosts
• Files and processes
• Mailboxes, messages, or URLs
• Cloud resources
• Activity timelines
• Investigation notes and ownership
• Response actions and final classification

Do not treat an incident and an alert as interchangeable. The incident is the case-management object used by the SOC.

Incident Graph and Attack Story

The incident graph visually represents the entities associated with an incident and their relationships. For a suspicious sign-in, it might connect an Entra ID user account to an IP address. A more complex incident could also include devices, processes, files, mail messages, or cloud resources.

The graph helps an analyst answer questions such as:

• Which account was targeted?
• Which IP address initiated the activity?
• Was the user connected to a managed endpoint?
• Did the incident involve a suspicious process or file?
• Are multiple alerts linked through a common entity?

The graph is only as useful as the data and entity information supplied by the alert sources. Connecting a data source does not guarantee that every event will appear as a graph entity. Analytics rules and integrated detections must expose or map the relevant entity fields.

Suspicious Sign-Ins from Anonymous IP Addresses

A sign-in from an anonymous IP address may be associated with:

• Tor exit nodes
• Consumer or corporate VPN services
• Anonymous proxy services
• Compromised infrastructure
• Account takeover attempts
• Password spraying
• Impossible or unusual travel patterns

An anonymous IP alert does not prove compromise. It provides a risk signal that must be evaluated with identity, device, location, and authentication evidence.

Useful validation questions include:

• Does the user recognize the sign-in?
• Was the user authorized to use a VPN or Tor?
• Was multifactor authentication completed?
• Was the authentication method changed recently?
• Did the sign-in obtain access to sensitive applications?
• Are there other risky sign-ins for the same account?
• Is the source IP associated with other users or incidents?
• Is the device known, compliant, and managed?

Threat Analytics Context

Microsoft Defender XDR may associate an incident with a relevant threat analytics report. These reports provide Microsoft threat intelligence and explain common attacker techniques, affected technologies, indicators, and recommended mitigations.

Threat analytics can help establish context, but it does not replace validation of tenant-specific evidence. A report describing anonymous infrastructure or cloud identity abuse does not prove that the individual incident is malicious.

Incident Details and Ownership

Incident metadata commonly includes:

• Incident ID
• Creation time
• First and last activity times
• Severity
• Current status
• Assigned analyst or owner
• Related alerts
• Products or detection sources
• Tags

Assignment and status are essential for preventing duplicate work. An unassigned incident should be claimed or routed according to the SOC’s triage process.

Assets, Evidence, and Timeline

The Assets or entities view identifies objects involved in the incident, such as a user or device. Whether a device appears depends on available telemetry and entity association. Defender for Endpoint integration often provides richer device evidence, but a device does not appear merely because some logs were collected through Azure Monitor Agent.

The Evidence and response area can provide expanded information about entities and artifacts, including IP address details. The timeline organizes incident activity chronologically, helping analysts determine sequence and scope.

For an identity incident, review:

1. The account and its risk state.
2. Source IP address, geolocation, and reputation.
3. Authentication result and MFA details.
4. Applications and resources accessed.
5. Related alerts before and after the sign-in.
6. Associated devices and endpoint telemetry.
7. Any changes to credentials, authentication methods, roles, or inbox rules.

Microsoft Security Operations Context

Manual Investigation Workflow

A defensible incident workflow is:

1. Claim or assign the incident. Establish an owner before making changes.
2. Review severity and alert sources. Understand why the incident was generated.
3. Inspect the attack story. Identify users, IP addresses, devices, files, and other entities.
4. Review the timeline. Determine what happened before, during, and after the detection.
5. Enrich the evidence. Use entity pages, threat intelligence, Entra sign-in data, and endpoint telemetry.
6. Determine scope. Search for the same indicators across other users and systems.
7. Contain when necessary. Disable or restrict accounts, revoke sessions, isolate devices, or block indicators according to procedure.
8. Remediate the cause. Reset credentials, remove persistence, delete malicious content, or correct policy gaps.
9. Document the investigation. Record evidence, decisions, actions, and remaining risks.
10. Classify and close the incident. Apply the correct disposition only after investigation and required response actions are complete.

Managing an Incident

The incident-management pane allows an analyst to update case-management fields. Labels and available status values can vary as the Microsoft Defender portal evolves, but the underlying workflow remains consistent.

Incident Name

The generated name can be changed to make the incident easier to identify. Use a concise naming convention that preserves the core detection context.

Severity

Severity represents expected impact or urgency. Analysts may adjust it when evidence shows that the original priority is inappropriate.

Examples:

• Increase severity when a privileged account is affected.
• Increase severity when successful access to sensitive resources is confirmed.
• Decrease severity when compensating controls substantially reduce risk.
• Avoid lowering severity merely to improve queue metrics.

Changing incident severity does not erase the severity or logic of the underlying source alert.

Tags

Tags support filtering, reporting, routing, and recurring operational workflows. Useful standardized tags might identify:

• Identity compromise
• Phishing investigation
• Privileged account
• Training or simulation
• Known authorized VPN
• Escalated to identity team

Tags should be governed and reusable. Detailed actions such as the exact time of a password reset generally belong in comments or investigation notes rather than in an improvised tag.

Assignment

Assign the incident to the analyst or team responsible for investigation. Ownership should be updated during escalation or shift handoff.

Status

Use status to represent the current stage of work:

• Active or new: Investigation has not been completed.
• In progress: An analyst is actively investigating or responding.
• Resolved or closed: Investigation and required response are complete.

Do not close an incident simply because the alert appears understandable. Confirm the scope, record the outcome, and complete required containment or remediation first.

Classification

Classification records the investigation’s final disposition. Depending on the portal workflow, classifications may include categories such as:

• True positive: A real security event or policy violation occurred.
• Benign positive: The activity occurred and matched the detection logic, but it was authorized or otherwise nonmalicious.
• False positive: The detection incorrectly identified normal activity as suspicious, often because the rule logic or data quality needs improvement.
• Undetermined: Available evidence is insufficient for a reliable conclusion.

For example, an authorized Tor test that correctly triggered an anonymous-IP rule is often better understood as a benign positive or expected test activity rather than a detection failure. Use the classifications available in the tenant and follow the organization’s disposition standard.

Exam-Relevant Takeaways

• Use Microsoft Sentinel Responder when an analyst must update and manage Sentinel incidents.
• Azure RBAC role assignments can be scoped to a workspace, resource group, or subscription.
• Apply least privilege; do not grant Owner merely to let an analyst manage incidents.
• An incident correlates alerts, entities, evidence, ownership, status, and investigation decisions.
• The incident graph displays relationships among entities such as accounts, IP addresses, devices, files, and processes.
• An anonymous IP address is a risk indicator, not conclusive proof of compromise.
• Threat analytics adds intelligence context but does not replace tenant-specific investigation.
• Assignment, status, tags, comments, and classification support SOC case management.
• Do not close an incident until investigation, response, and documentation are complete.
• A successful password reset may be only one response action; active sessions and authentication methods may also require review.

Tool / Feature Decision Guide

Requirement	Appropriate feature or action	Key consideration
Allow an analyst to update Sentinel incidents	Microsoft Sentinel Responder	Assign at the narrowest practical Azure RBAC scope
Allow read-only review of Sentinel data and incidents	Microsoft Sentinel Reader	Does not provide the same incident-management capability as Responder
Understand relationships among users, IPs, and devices	Incident graph or attack story	Depends on entity data and mappings supplied by detections
Establish the order of events	Incident timeline	Compare first activity, alert creation, and later response actions
Research an IP address or account	Entity page and evidence details	Correlate reputation data with tenant-specific behavior
Understand a known campaign or technique	Threat analytics report	Contextual intelligence is not incident confirmation
Establish clear case ownership	Incident assignment	Update during escalation and shift handoff
Support filtering and operational routing	Standardized incident tags	Avoid inconsistent, one-off tags
Record detailed investigative work	Comments or investigation notes	Include evidence, timestamps, actions, and rationale
Record the final outcome	Incident classification and closure	Classify only after sufficient investigation
Execute repeatable response steps	Automation rule or playbook	Use approvals and safeguards for disruptive actions

Common Exam Traps

Granting Excessive Permissions

Do not select Owner or Contributor when the requirement is only to manage incidents. Microsoft Sentinel Responder is the purpose-built least-privilege role.

Confusing Global Administrator with Azure Resource Access

Microsoft Entra directory roles and Azure resource roles are distinct. Global Administrator does not inherently provide operational control of a Sentinel workspace.

Treating Every Anonymous IP Alert as Compromise

Tor and VPN services can be used legitimately. Validate authentication, user intent, device state, resource access, and related activity before classifying the incident.

Calling Expected Test Activity a Detection Failure

If a detection correctly identifies activity that was intentionally generated during an approved test, the rule may be working as designed. Depending on organizational terminology, classify it as benign or expected test activity rather than automatically calling it a false positive.

Assuming All Collected Logs Produce Graph Entities

Log ingestion alone does not guarantee that an entity appears in the incident graph. The alert or analytics rule must provide the relevant entity data and mappings.

Closing Before Remediation

Confirm that containment and remediation are complete. For a compromised account, resetting the password alone may not invalidate existing tokens, remove malicious authentication methods, or address persistence.

Overtrusting the Generated Severity

Severity is an initial prioritization signal. Business impact, privilege level, sensitive-resource access, and corroborating evidence may justify changing it.

Real-World SOC Analyst Notes

• Preserve evidence first. Capture sign-in details, IP information, timestamps, token activity, and related alerts before disruptive remediation changes the environment.
• Document user validation carefully. Record who confirmed the activity, how identity was verified, and whether the behavior was authorized.
• Coordinate identity response. Password resets, session revocation, account disablement, authentication-method changes, and Conditional Access actions may require coordination with the identity team.
• Use caution with automation. Automatically disabling accounts based solely on an anonymous-IP alert can cause tenant-wide operational disruption and attacker-triggered denial of service.
• Standardize classification. Inconsistent use of true positive, benign positive, and false positive damages reporting and makes detection tuning difficult.
• Review recurring benign detections. Repeated alerts from an approved VPN may justify rule tuning, an allowlist, or a watchlist, but exceptions should be narrowly scoped and change-controlled.
• Maintain an audit trail. Notes should include findings, response actions, timestamps, approvals, escalation details, and the reason for closure.
• Consider retention. Incident records and supporting logs may have different retention periods. Preserve required evidence according to legal, compliance, and internal policy.

Quick Reference Summary

• Primary incident-management role: Microsoft Sentinel Responder
• Permission system: Azure RBAC through Access control (IAM)
• Primary investigation location: Incidents under Investigation and response in the Microsoft Defender portal
• Graph purpose: Visualize entity relationships
• Timeline purpose: Establish event sequence
• Threat analytics purpose: Add Microsoft threat-intelligence context
• Assignment purpose: Establish case ownership
• Tags purpose: Support filtering, routing, and reporting
• Classification purpose: Record the final disposition
• Closure requirement: Investigation, response, and documentation must be complete

Flashcards

Q: Which built-in Azure role is intended for analysts who need to manage Microsoft Sentinel incidents?
A: Microsoft Sentinel Responder.

Q: Where are Microsoft Sentinel role assignments configured?
A: Through Azure RBAC under Access control (IAM) at an appropriate scope, such as the workspace or resource group.

Q: Does Microsoft Entra Global Administrator automatically grant access to all Sentinel workspaces?
A: No. Microsoft Entra directory roles and Azure resource permissions are separate.

Q: What is the difference between an alert and an incident?
A: An alert is an individual detection; an incident is a case-management container that can correlate alerts, entities, evidence, and response work.

Q: What does the incident graph show?
A: Entities associated with an incident and the relationships among them.

Q: Does an anonymous IP alert prove that an account was compromised?
A: No. It is a risk signal requiring investigation and contextual validation.

Q: What is the purpose of incident assignment?
A: To establish clear ownership and prevent duplicate or missed investigation work.

Q: When should incident severity be changed?
A: When evidence and business impact show that the generated priority does not reflect the actual risk.

Q: What is a true positive?
A: An incident in which genuine malicious or prohibited activity occurred.

Q: Why might approved Tor or VPN testing be considered benign activity rather than a false positive?
A: Because the detection may have correctly identified the behavior even though the behavior was authorized and nonmalicious.

Q: Does collecting device logs through Azure Monitor Agent guarantee that a device appears in the incident graph?
A: No. The detection must expose or map the device entity for the graph.

Q: What should happen before an incident is closed?
A: Complete investigation, containment, remediation, documentation, and final classification as required.

Practice Questions

Question 1

A SOC analyst must investigate Microsoft Sentinel incidents, assign them to team members, update their status, and close them. The analyst should not be able to administer the Azure subscription. Which role should you assign?

A. Global Reader
B. Microsoft Sentinel Reader
C. Microsoft Sentinel Responder
D. Owner

Correct answer: C. Microsoft Sentinel Responder

Explanation: Microsoft Sentinel Responder is designed for incident investigation and management. Reader is insufficient for updates, while Owner grants excessive permissions.

Question 2

Microsoft Sentinel generates an incident after an employee signs in through a Tor exit node. The employee confirms that the activity was part of an approved security test, and no other suspicious activity is found. What is the best response?

A. Treat the account as compromised because Tor is always malicious.
B. Close the incident without notes because no attack occurred.
C. Document the validation and classify it according to the organization’s benign or authorized-test category.
D. Disable the analytics rule permanently.

Correct answer: C. Document the validation and classify it according to the organization’s benign or authorized-test category.

Explanation: Anonymous infrastructure is suspicious but not automatically malicious. The detection may have worked correctly, so the analyst should preserve the investigative record and apply the organization’s appropriate benign disposition.

Question 3

An analyst can open a Sentinel incident but cannot change its assignment or status. What is the most likely solution?

A. Assign Microsoft Sentinel Responder at the appropriate Azure RBAC scope.
B. Assign Security Reader in Microsoft Entra ID.
C. Add the analyst to a Conditional Access policy.
D. Install Azure Monitor Agent on the analyst’s device.

Correct answer: A. Assign Microsoft Sentinel Responder at the appropriate Azure RBAC scope.

Explanation: Updating Sentinel incidents requires the appropriate Sentinel permissions. Conditional Access and Azure Monitor Agent do not grant case-management rights.

Question 4

A high-severity incident involves a privileged Entra ID account. The user has reset the password, but the analyst has not reviewed active sessions or authentication methods. What should the analyst do next?

A. Close the incident because the password has been reset.
B. Lower the severity to informational.
C. Continue the investigation, review persistence mechanisms, revoke sessions if required, and document the response.
D. Delete the incident to prevent duplicate alerts.

Correct answer: C. Continue the investigation, review persistence mechanisms, revoke sessions if required, and document the response.

Explanation: A password reset may not invalidate active tokens or remove attacker-added authentication methods. Closure is appropriate only after scope, containment, remediation, and documentation are complete.