Listen to this Post
Introduction:
The integration of native case management into the Microsoft Defender portal represents a significant evolution in Security Operations Center (SOC) workflows. By moving beyond isolated incident handling to structured, case-driven investigations, Microsoft is enabling teams to group related incidents, assign tasks, and maintain context within a unified interface. This new feature, which requires a connected Microsoft Sentinel workspace, leverages Role-Based Access Control (RBAC) to ensure that security analysts can manage complex investigations with greater efficiency and clarity.
Learning Objectives:
- Understand the architecture and prerequisites for implementing native case management in the Microsoft Defender portal.
- Learn how to configure RBAC and custom statuses to align case management with your SOC’s operational model.
- Explore step-by-step guidance for creating, managing, and closing cases, including the critical distinction between closing a case and closing linked incidents.
You Should Know:
1. Core Architecture and Prerequisites for Case Management
Before leveraging case management, it is essential to understand the integration between Microsoft Defender and Microsoft Sentinel. The feature is hosted within the Microsoft Defender portal (security.microsoft.com) but relies on a connected Log Analytics workspace that has Microsoft Sentinel enabled. This bidirectional integration allows security data from Defender’s XDR (Extended Detection and Response) to flow into Sentinel, and case management actions to be reflected across both platforms.
To verify or establish this connection, you can use the following Azure CLI command to check the status of your Sentinel workspace:
az sentinel workspace-manager list --resource-group <YourResourceGroup> --workspace-name <YourWorkspaceName>
For Windows environments utilizing PowerShell with the Az module, you can confirm RBAC assignments required for case access:
Get-AzRoleAssignment -Scope "/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroup>/providers/Microsoft.OperationalInsights/workspaces/<WorkspaceName>"
This setup ensures that analysts have the necessary permissions to create and view cases, leveraging built-in roles like “Microsoft Sentinel Responder” or custom roles tailored to your SOC hierarchy.
- Configuring RBAC and Custom Statuses for Operational Alignment
Effective case management hinges on proper access control and workflow customization. The Microsoft Defender portal supports RBAC, allowing you to define which users can create cases, assign tasks, or change case statuses. This is particularly important for MSSPs (Managed Security Service Providers) who must segment data across tenants while maintaining centralized oversight.
To configure custom statuses, you must navigate to the Microsoft Defender portal’s settings. While there is no direct CLI command for setting custom statuses, the configuration is performed via the portal under Settings > Microsoft Sentinel > Case management. Here, you can define states such as “In Review,” “Awaiting Evidence,” or “Escalated.” For automation, you can use the Microsoft Graph API to programmatically update case statuses. An example Graph API call to update a case status would look like this:
PATCH https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/{caseId}
Content-Type: application/json
{
"status": "inReview"
}
This level of customization allows SOC managers to enforce consistent investigation protocols and generate accurate metrics on case resolution times.
- Step-by-Step: Creating and Managing Cases in the Microsoft Defender Portal
The process of creating a case is designed to aggregate context from multiple incidents. Analysts can select several related incidents from the Microsoft Defender portal’s incident queue and choose “Create new case.” The portal then allows you to add a descriptive name, assign priority, and attach relevant artifacts. A key advantage is that all investigation steps—including automated alerts, user entities, and file indicators—are preserved within the case workspace.
For a more automated approach, you can use PowerShell to create a case via the Microsoft Graph. Ensure you have the appropriate permissions and modules installed:
Connect-MgGraph -Scopes "SecurityCases.ReadWrite.All"
$params = @{
displayName = "Suspicious Lateral Movement - Case 001"
description = "Investigation into multiple failed logins and subsequent network traversal"
status = "active"
}
New-MgSecurityCaseEdiscoveryCase -BodyParameter $params
Once a case is active, you can assign tasks to specific analysts. This is accomplished within the case view under the “Tasks” tab, where you can define subtasks, set due dates, and track progress. The ability to maintain all this context in one place reduces the time spent switching between consoles and ensures that investigation notes are centralized.
4. Investigation Flow: Linking Incidents and Managing Tasks
A fundamental feature of this new case management system is the ability to link existing incidents to a case. In the Microsoft Defender portal, after opening a case, you can select “Add incidents” and choose from the list of unresolved or related incidents. This creates a parent-child relationship where the case serves as the overarching investigation container. Analysts can then view all linked incidents and their associated alerts in a unified timeline.
It is critical to note the operational nuance: closing a case does not automatically close the linked incidents. This design choice prevents accidental closure of incidents that might still require follow-up or remediation. To automate the closure of incidents when a case is resolved, you must implement a logic app or automation rule. Below is an example of an Azure Automation runbook snippet that closes all incidents linked to a specific case:
Pseudo-code for closing linked incidents
$caseId = "12345"
$incidents = Get-SentinelIncident -CaseId $caseId
foreach ($incident in $incidents) {
Update-SentinelIncident -IncidentId $incident.Id -Status "Closed" -Classification "TruePositive"
}
This level of granular control ensures that your SOC can maintain strict closure protocols and avoid gaps in the incident lifecycle.
5. Automation and API Integration for Advanced Workflows
For organizations with high-volume SOC environments, manual case management is not scalable. The new case management feature is fully accessible via the Microsoft Graph API’s security domain, enabling integration with SOAR (Security Orchestration, Automation, and Response) platforms. You can automate the creation of cases based on alert rules, automatically assign tasks based on analyst skill sets, and even enrich cases with threat intelligence data.
A practical automation workflow involves using Azure Logic Apps to monitor for high-severity alerts. When such an alert is detected, the Logic App can create a case, link the associated incidents, and post a notification to a Microsoft Teams channel. The following JSON snippet represents the schema for a Logic App action that creates a case via the Graph API:
{
"inputs": {
"method": "POST",
"uri": "https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases",
"body": {
"displayName": "@{triggerBody()?['alertName']} - Automated Case",
"description": "Case created automatically due to high-severity alert",
"status": "active"
}
}
}
This integration ensures that no critical alert is missed and that case management becomes a seamless extension of your detection infrastructure.
6. Multi-Tenant Management for MSSPs
MSSPs face the unique challenge of managing security operations across multiple clients, each with their own Sentinel workspaces. The new case management feature in the Microsoft Defender portal supports delegated administration via Azure Lighthouse. With Azure Lighthouse, you can project multiple customer tenants into your own portal, allowing you to create and manage cases across all clients without switching contexts.
To deploy Azure Lighthouse for this purpose, you use Azure Resource Manager templates to onboard customers. The core of the deployment involves defining authorizations in an ARM template:
{
"properties": {
"mspOfferName": "MSSP Sentinel Case Management",
"authorizations": [
{
"principalId": "your-mssp-security-group-id",
"roleDefinitionId": "b195f5e6-9f1b-4c6a-8f5a-1e8f2a3b4c5d",
"principalIdDisplayName": "MSSP SOC Analysts"
}
]
}
}
This configuration allows your central SOC team to manage cases, assign tasks, and monitor incident resolution across all clients, significantly reducing administrative overhead.
- Mitigating Operational Risks: Closure Protocols and Audit Logs
One of the most critical aspects of case management is ensuring that the closure process is both thorough and auditable. As noted, the disconnect between case closure and incident closure can lead to “ghost incidents”—incidents that remain open indefinitely. To mitigate this, it is recommended to enforce a mandatory “Closure Review” step in your case workflow. This step can be implemented by creating a custom status that requires a manager’s approval before final closure.
Additionally, all actions performed within case management are logged in the Microsoft 365 Unified Audit Log. To query these logs for compliance or post-mortem analysis, you can use the `Search-UnifiedAuditLog` cmdlet in Exchange Online PowerShell:
Search-UnifiedAuditLog -Operations "CaseCreated", "CaseUpdated", "CaseClosed" -StartDate (Get-Date).AddDays(-7)
This provides a forensic trail of who created or modified cases, ensuring accountability and supporting regulatory compliance requirements such as GDPR or SOC 2.
What Undercode Say:
- Unified Context is a Force Multiplier: By embedding case management directly into the Defender portal and linking it with Sentinel, Microsoft eliminates the need for third-party ticketing systems for initial triage, allowing analysts to focus on investigation rather than data gathering.
- Automation is Essential to Avoid Gaps: The decision to not automatically close incidents when a case is closed prevents accidental data loss but introduces a new operational risk. Organizations must automate the closure process to maintain hygiene and accurate metrics.
This update signals Microsoft’s commitment to unifying its security stack under a single operational lens. For SOC teams, the ability to manage cases with custom statuses and RBAC brings much-needed flexibility to incident response. However, the true value will be realized only when teams integrate this feature with automation—using PowerShell, Graph API, and Logic Apps—to create a fluid response pipeline. The shift from alert-centric to case-centric operations is a fundamental maturity step; those who adopt it effectively will see reduced mean time to resolution (MTTR) and improved collaboration across distributed teams.
Prediction:
The introduction of native case management is a precursor to deeper AI-driven capabilities within the Microsoft Security ecosystem. In the near future, we can expect AI models to automatically suggest case groupings based on MITRE ATT&CK patterns, predict analyst task assignments based on workload, and even draft executive summaries for closed cases. This will transform the SOC analyst’s role from manual case creation to strategic oversight, enabling faster containment and more sophisticated threat hunting. Organizations that embrace these workflows now will be better positioned to leverage the coming wave of generative AI in security operations.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Eduards Grebe%C5%BEs – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
