SC-200: Automation Rule Fires but Playbook Fails Mid-Incident

Automation Rule Fires but Playbook Fails Mid-Incident

Fabrikam's SOC uses Microsoft Sentinel with a playbook triggered by an automation rule when a 'Suspicious process' incident is created. The playbook calls the Microsoft Graph Security API to isolate the device, then posts to a Teams channel, then assigns the incident. During a live ransomware incident, the automation rule ran, but the playbook failed at the isolation step with an authorization error. The device was not isolated for 47 minutes until an analyst acted manually. Investigation shows the playbook's managed identity has the 'Security Reader' role, not 'Security Administrator'. The automation rule itself has 'Microsoft Sentinel Automation Contributor' on the resource group. The playbook was last edited 5 days ago by a contractor who changed the connection reference. There are 30 other playbooks in the same resource group sharing similar connection references.

1. Explain why the playbook failed and identify the precise permission gap. Then state what must change and what must NOT change.

Read the worked answer

Two separate permission planes are involved, and the failure is on the playbook's plane, not the automation rule's.

The automation rule has Microsoft Sentinel Automation Contributor on the resource group. That role lets the rule invoke playbooks; it does not grant the playbook's identity any rights against Defender/Graph.
The playbook's managed identity has Security Reader. Isolation via the Graph Security API (/security/cases/.../deviceCommands or the equivalent isolate action) requires a write-capable role - Security Administrator or a custom role with the isolate action. Read-only cannot isolate, hence the authorization error.

What must change: grant the playbook's managed identity Security Administrator (least privilege: scope to the specific action if a custom role is feasible), and re-test the isolation step in a non-production incident.

What must NOT change: do not widen the automation rule's role, and do not switch the playbook to run under a human account's credentials - that breaks auditability and creates a standing privileged credential. Also do not touch the 30 other playbooks until you confirm whether the contractor's connection-reference edit changed their identity binding too.

2. The contractor's edit five days ago is the suspected trigger. Describe how you would determine blast radius across the 30 other playbooks and what immediate mitigation you would apply during an active incident.

Read the worked answer

During the active incident (first 30 minutes):

Manually isolate the affected device and contain the incident; do not wait for playbook repair.
Disable the automation rule that invokes the broken playbook so it does not silently fail on subsequent incidents, and post a note in the incident timeline.
Snapshot the current playbook definition (JSON export) before any further edits.

Blast-radius analysis:

Run a Resource Graph query listing all playbooks in the resource group and their identity blocks; flag any whose managed identity or connection reference changed in the last 7 days using the activity log (Microsoft.Logic/workflows/write).
For each flagged playbook, compare the current connection reference to the prior version via the Logic Apps run history and the deployment history.
Test each flagged playbook's critical action against a canary incident in a test workspace.

Mitigation: revert the connection reference to the known-good binding, re-grant the correct role to the managed identity, and add a CI check (or a scheduled query) that alerts when a playbook's identity or connection reference changes. Document the 47-minute gap as a control failure and add a manual isolation runbook as a fallback.