Microsoft Incident Response Plan Template

Standard Operating Procedure: Microsoft Incident Response Plan Template Execution

Document ID: SOP-TR-MSFT-IRP-042
Effective Date: October 24, 2023
Version: 3.1.0
Review Cadence: Semi-Annual
Author: Julian Vance, Chief Architect, Template Registry

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional requirements for deploying, customizing, and executing the Microsoft Incident Response Plan (IRP) template within enterprise hybrid and cloud environments. The objective is to standardize containment, eradication, and recovery workflows across Microsoft 365 (M365), Azure, and on-premises infrastructure, minimizing mean-time-to-detection (MTTD) and mean-time-to-remediation (MTTR) while preserving digital forensics integrity.

---

2. Scope & Prerequisites

Scope

Applies to all systems, applications, data repositories, and cloud tenants managed or subscribed to by the organization utilizing Microsoft security tooling.

Prerequisites & Tools

• Global Administrator / Security Administrator access to the target Microsoft Entra ID (formerly Azure AD) tenant.
• Microsoft Sentinel workspace deployment with appropriate Data Connectors active.
• Microsoft Defender XDR portal access (Defender for Endpoint, Defender for Office 365, Defender for Cloud).
• PowerShell 7.x with Microsoft.Graph, AzureAD, and Az modules installed.
• Secure Workstation (SAW) or hardware-token-authenticated administrative terminal.

---

3. Roles & Responsibilities (RACI Matrix)

(Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed)

---

4. Step-by-Step Procedure

Phase 1: Triage, Identification, and Scoping

• 1.1 Acknowledge incoming Microsoft Sentinel or Defender XDR high/critical severity alerts within 15 minutes of generation.
• 1.2 Instantiate the incident channel within the secure communication platform and assign the Incident Commander (IC) and Lead Security Engineer (LSE).
• 1.3 Export initial telemetry snapshots from Microsoft Defender XDR utilizing advanced hunting queries to establish baseline impact.
• 1.4 Classify the incident scope (e.g., Business Email Compromise, Ransomware, Lateral Movement, Data Exfiltration) using the Microsoft taxonomy.

Phase 2: Containment (Isolation & Revocation)

• 2.1 Identity Containment: Revoke refresh tokens and sessions for compromised user accounts via Microsoft Graph PowerShell:

  Revoke-MgUserSignInSession -UserId "user@domain.com"
  

• 2.2 Disable user sign-in capabilities in Microsoft Entra ID and enforce multi-factor authentication (MFA) re-registration.
• 2.3 Endpoint Containment: Isolate compromised endpoints via Microsoft Defender for Endpoint portal (Device Actions -> Isolate device -> Restrict app execution).
• 2.4 Network Containment: Update Azure Network Security Groups (NSGs) or Azure Firewall rules to sever unauthorized egress traffic from affected subnets.

Phase 3: Eradication & Threat Removal

• 3.1 Identify persistence mechanisms (e.g., malicious OAuth applications, hidden inbox rules, scheduled tasks, or rogue service principals).
• 3.2 Remove illicit OAuth enterprise applications via Azure CLI or Microsoft Graph:

  Remove-MgServicePrincipal -ServicePrincipalId "<Object-Id>"
  

• 3.3 Purge malicious emails across mailboxes using Exchange Online PowerShell compliance search and purge commands:

  New-ComplianceSearchAction -SearchName "MalwarePurge" -Purge -PurgeType SoftDelete
  

• 3.4 Patch underlying vulnerabilities exploited during the attack vector, cross-referencing Microsoft CVE advisories.

Phase 4: Recovery & System Validation

• 4.1 Re-enable isolated endpoints following verification of clean system state by Defender for Endpoint scans.
• 4.2 Reset credentials for compromised service accounts, administrative identities, and rotate associated API keys / secrets.
• 4.3 Validate business application integrity, verifying that database replication and storage accounts have not suffered silent corruption.
• 4.4 Transition systems from containment mode back to standard operational monitoring over a mandatory 24-hour observation window.

Phase 5: Post-Incident Review & Documentation

• 5.1 Consolidate all Microsoft Defender incident timelines, audit logs, and memory dumps into the secure evidence repository.
• 5.2 Schedule and execute a Blameless Post-Mortem with engineering and operational stakeholders within 5 business days of incident closure.
• 5.3 Update Microsoft Sentinel detection rules, custom Kusto Query Language (KQL) detections, and suppress false positives based on lessons learned.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Immutable Logging: Ensure Azure Activity Logs and Microsoft 365 Unified Audit Logs are forwarded to an immutable, write-once-read-many (WORM) storage container prior to initiating remediation.
• Automated Playbooks: Integrate Azure Logic Apps with Microsoft Sentinel to automate Phase 2 containment actions for known-good indicators of compromise (IoCs).

Common Pitfalls

• Premature Eradication: Deleting persistence mechanisms before collecting forensic artifacts, which obscures the root cause analysis.
• Ignoring OAuth Tokens: Failing to check and revoke malicious OAuth app consents, allowing persistent access even after complete credential resets.

Metric Thresholds

• MTTD (Mean Time to Detect): $\le 15 \text{ minutes}$ for critical alerts.
• MTTR (Mean Time to Respond/Contain): $\le 30 \text{ minutes}$ from alert triage to automated/manual isolation.

---

6. Frequently Asked Questions (FAQ)

Q1: What should be done if an attacker modifies global administrator roles within Microsoft Entra ID?
A: Immediately invoke the emergency Break-Glass account procedures. Log into the tenant using the cloud-only, non-federated global administrator emergency account, terminate all active sessions for the compromised administrator, and audit the Azure Active Directory audit logs for illicit role assignments.

Q2: How do we preserve evidence in Microsoft 365 without disrupting ongoing business operations?
A: Utilize the built-in Microsoft Purview eDiscovery (Standard/Premium) tools to place legal holds on affected mailboxes and SharePoint sites. For endpoints, collect live response packages via Microsoft Defender for Endpoint without executing a hard shutdown whenever possible.

Q3: Can containment steps be fully automated via the Microsoft template?
A: Yes, through Microsoft Sentinel Automation Rules coupled with Logic Apps. However, automated isolation must be restricted to high-confidence fidelity alerts (e.g., confirmed ransomware execution) to prevent operational denial of service.