How to Build an Incident Triage Workflow Across Multiple Microsoft 365 Tenants

Creating a comprehensive and well-defined incident triage workflow is essential for IT administrators, especially those managing a large number of devices. This allows IT staff to detect and contain incidents, such as security breaches, much more quickly and efficiently, and prevent personnel from experiencing alert fatigue.

Having an incident triage workflow also supports incident SLAs and ensures your organization is compliant with regulatory requirements. It will also improve reporting consistency for quarterly business reviews and legal compliance.

For a visual breakdown of this topic How to Build an Incident Triage Workflow Across Multiple Microsoft 365 Tenants.

A step-by-step guide to creating an incident triage framework

Before proceeding with this process, make sure that you have the following prerequisites:

• A system with Microsoft 365 tenants with Microsoft Defender for Office 365 and/or Microsoft 365 Defender
• Windows PowerShell 7 or higher
• Tenant-specific account application registration or a central service account
• An RMM platform to manage your devices

Additional and/or optional requirements:

• It would be useful to have Logic Apps or an SIEM to help automate the escalation of high-severity incidents.
• You can also use Microsoft 365 Lighthouse for a free, unified view of security alerts across all delegated tenants, or Microsoft Sentinel for advanced cross-tenant SOAR (Security Orchestration, Automation, and Response) Microsoft Sentinel is moving to the Microsoft Defender portal and won’t be supported in the Azure portal after March 31, 2027, so plan to manage it there.

Step 1: Define a cross-tenant triage framework

The first thing you have to do is standardize the core triage phases for all your tenants when an incident occurs. Here’s a sample triage guide:

Create a JSON template or CSV schema to log these incidents. The specific details of the template will depend on your organization’s policies and expectations.

Step 2: Use Microsoft Graph API to pull alerts from each tenant

Prerequisite: Microsoft Graph should already be installed and configured for your Microsoft 365 accounts. It should have delegated or app-level API permissions.

1. Open the Start Menu and search for PowerShell 7.
2. Right-click PowerShell 7 > Run as administrator.
3. Type this script and press Enter:

Connect-MgGraph -Scopes “SecurityEvents.Read.All”

$alerts = Get-MgSecurityAlertV2 -All | Where-Object { $_.Status -ne “resolved” }

To filter by severity and product:

$highAADAlerts = $alerts | Where-Object { 

$_.Severity -eq “high” -and $_.ProductName -eq “Azure Active Directory Identity Protection”

$highAADAlerts | Select-Object Id, Severity, Status, ProductName, Title, CreatedDateTime}

This will pull up all relevant alerts from Defender for your tenants, if any.

4. Run these queries on a scheduled loop for all your tenants and export the results to a .CSV or .JSON file so you can track the data easily. You can do these tasks using your preferred endpoint management tool.

Step 3: Tag devices or users via Registry or PowerShell for local triage

When an incident occurs on a specific endpoint, administrators can create Registry keys and values to record incident data for that device or user profile. This information will be saved locally. To do that, follow these steps:

1. Open the Start Menu and search for Windows PowerShell.
2. Right-click Windows PowerShell > Run as administrator.
3. Deploy a script that will create the necessary Registry values to track incident data on a device.

Here’s a sample PowerShell script you can use:

New-Item -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Force

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “LastAlert” -Value “PhishingAttempt”

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “Tag” -Value “UnderInvestigation”

The name and value of the registry keys (“LastAlert,” “PhishingAttempt,” “Tag,” and “UnderInvestigation”) are dependent on the incident that you’re trying to record. Change it according to your needs.

4. To check these Registry keys and values, open Command Prompt as an administrator.
5. Type this command and press Enter:

reg query HKLM\SOFTWARE\Org\IncidentTriage

Replace the path with the path of the value you want to check.

Note: You can use an RMM tool to scan your managed devices, generate a report on tag values, and track each endpoint’s state.

While Registry keys are useful for local RMM tracking, you should also apply Defender for Endpoint tags via the API. This ensures that the “Under Investigation” status is visible to anyone viewing the Microsoft Defender Security Center.

# Example: Tagging a device in Defender for Endpoint via API

$DeviceID = “your-device-id”

$Tag = “UnderInvestigation”

Invoke-RestMethod -Uri “https://api.security.microsoft.com/api/machines/$DeviceID/tags” -Method Post -Body @{Value=$Tag;Action=”Add”}

Step 4: Automate response with PowerShell and Defender for Endpoint

If there’s an incident involving a compromised user account, you can disable that account and invalidate all their user sessions. You can use Windows PowerShell to deploy specific responses for that incident. Here are a few sample actions they can take when an incident occurs:

Prerequisite: Microsoft Graph should already be installed and configured for your Microsoft 365 accounts. It should have delegated or app-level API permissions.

1. Open the Start Menu and search for Windows PowerShell.
2. Right-click Windows PowerShell > Run as administrator.
3. To disable the compromised accounts:

Update-MgUser -UserId $user.Id -AccountEnabled $false

To invalidate sessions of the compromised account:

Revoke-MgUserSignInSession -UserId $user.Id

To require a user to change their password:

$PasswordProfile = @{

ForceChangePasswordNextSignIn = $true

}

Update-MgUser -UserId $user.Id -PasswordProfile$PasswordProfile

To tag a device as quarantined using a Registry tag:

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “IsolationState” -Value “Quarantined”

Please note this must be done manually on the compromised endpoint. You can’t do it remotely because the computer should be isolated from your organization’s network.

Note: Administrators can use an endpoint management tool to apply Firewall rules or disable network interfaces.

Instead of manually visiting a computer to unplug it, use the Defender API to isolate the device. This cuts all network connections except for its link to Microsoft 365, preventing lateral movement.

# Isolate a device remotely

Invoke-MgIsolateSecurityMachine -MachineId $MachineId -Comment “Isolating due to high-severity alert.”

Troubleshooting/Things to look out for

Additional considerations when building an incident response framework across multiple Microsoft 365 tenants

• Use certificate-based application registrations with short expiration dates to prevent security breaches.
• Store incident and triage logs based on tenant IDs or display names for historical audits.
• Consider integrating Logic Apps or Power Automate to help you escalate high-severity incidents.
• Consider third-party security tools via an API when possible to add more layers of protection and prevent security breaches.

How NinjaOne services can help with your cyber-incident triage workflow

NinjaOne can support cross-tenant incident triaging by:

• Running PowerShell scripts across specific device tags or client scopes to address the incidents
• Logging and creating reports using incident metadata
• Providing user-friendly dashboards and script audit logs across tenants to make creating business summaries and reviews easier

Strengthen security by building a comprehensive incident triage process

IT administrators can contain incidents faster when they have an automated and consistent triage workflow. The workflow also standardizes incident documentation, which supports audit and regulatory reporting.

Related topics:

• What Is Incident Response?
• What is Cloud Incident Response?
• Enhancing Efficiency Through IT Workflow Automation
• Building an Incident Response Checklist for MSP Technicians
• MSPs: 6 Keys to Surviving a Ransomware Outbreak Across Your Client Base