GOV-04: Automate Threat Response with SOAR

Overview

GOV-04 is a Level 3 (Maximum Security) control. It requires that high-risk identity detections in Microsoft Entra ID Protection trigger automated playbooks that contain threats in seconds, not hours.

Manual incident response introduces unacceptable dwell time at this security tier. A compromised account that sits active while an analyst is paged, investigates, and escalates gives an attacker a window measured in hours. Automated Security Orchestration, Automation, and Response (SOAR) closes that window by acting the moment a high-risk detection fires.

The two core automated responses required by this control are:

• High-risk user detected: account is disabled and all active sessions are revoked automatically, then the Security Operations Center (SOC) is alerted for review.
• High-risk sign-in detected: sign-in is blocked and the user is required to change their password, then the SOC is alerted.

Microsoft Sentinel is the recommended SOAR platform for Microsoft 365 environments. Equivalent platforms (Splunk SOAR, Palo Alto XSOAR, and others) are acceptable if they can consume Entra ID Protection signals and execute Microsoft Graph API actions.

TrueConfig role: TrueConfig detects whether automated playbooks are configured and active, and advises on gaps. The actual playbook automation is built and maintained by your security team in Sentinel or your chosen SOAR platform. This control is manual-only from a TrueConfig perspective; there is no one-click fix.

Why it matters: Manual incident response takes hours. Automated playbooks respond to threats in seconds. Level 3 organizations minimize attacker dwell time by automatically containing compromised accounts.

Prerequisites

Required Roles

• Security Administrator or Global Administrator to configure Entra ID Protection and Sentinel connectors
• Microsoft Sentinel Contributor to deploy and manage playbooks (Logic Apps)
• Security Operations team or SOC with escalation workflows and on-call coverage

Required Licenses

• Microsoft Entra ID P2: required for Entra ID Protection risk detections (high-risk user and high-risk sign-in signals that trigger the playbooks)
• Microsoft Sentinel: consumption-based (pay-per-GB ingested) or via Microsoft 365 E5 Security bundle; a workspace in Azure Log Analytics is required
• Microsoft Defender for Cloud Apps (optional but recommended): enriches signals with app-level behavioral context

Time Estimate

Step-by-Step Instructions

Step 1: Deploy Microsoft Sentinel

If Sentinel is not yet deployed in your Azure subscription:

1. In the Azure portal, search for Microsoft Sentinel.
2. Click + Create and select or create a Log Analytics workspace.
   • Place the workspace in the same Azure region as your Microsoft 365 tenant for lowest latency.
   • Retention default is 90 days; increase to 180 or 365 days for compliance.
3. Click Add Microsoft Sentinel to attach it to the workspace.
4. Complete the onboarding wizard.

If Sentinel already exists in your environment, note the workspace name and resource group before proceeding.

Step 2: Connect the Microsoft Entra ID Data Connector

1. In Microsoft Sentinel, go to Content management > Content hub.
2. Search for Microsoft Entra ID and install the solution.
3. Navigate to Configuration > Data connectors > Microsoft Entra ID.
4. Click Open connector page and enable all relevant log types:
   • Sign-in logs
   • Audit logs
   • Identity Protection risk events (required for this control)
   • Provisioning logs
5. Confirm the connector shows Connected status and data is flowing into the AADRiskyUsers and AADUserRiskEvents tables.

Step 3: Enable Sentinel UEBA

User and Entity Behavior Analytics (UEBA) enriches risk signals with behavioral baselines, reducing false positives in your playbooks.

1. In Microsoft Sentinel, go to Configuration > Settings > UEBA.
2. Enable UEBA and select Azure Active Directory as the data source.
3. Allow 24-48 hours for initial behavioral baselines to build.

Step 4: Create the High-Risk User Playbook

This playbook fires when Entra ID Protection marks a user as high-risk. It disables the account, revokes all active sessions, and alerts the SOC.

1. In Microsoft Sentinel, go to Configuration > Automation > Playbooks.

2. Click + Create > Playbook with incident trigger.

3. Name it Respond-HighRiskUser.

4. In the Logic App designer, add the following steps in order:

   Step 4a: Parse the incident entities

   • Use the Microsoft Sentinel connector action: Entities - Get Accounts.

   Step 4b: Disable the user account

   • Use the Microsoft Entra ID (Azure AD) connector action: Update user.
   • Set accountEnabled to false.

   Step 4c: Revoke all sign-in sessions

   • Use the HTTP action to call the Microsoft Graph API:
     • Method: POST
     • URI: https://graph.microsoft.com/v1.0/users/{userId}/revokeSignInSessions
     • Authentication: Managed Identity (assign the Logic App's managed identity the User.ReadWrite.All and Directory.Read.All Graph API application permissions).

   Step 4d: Alert the SOC

   • Use the Microsoft Teams or Outlook connector to post a message to your SOC channel or inbox, including the user's UPN, risk level, detection time, and a link to the Sentinel incident.

5. Save and enable the playbook.

6. Wire the playbook to an automation rule:

   • Go to Configuration > Automation > Automation rules.
   • Click + Create > name it Auto-Respond-HighRiskUser.
   • Condition: Incident provider = Microsoft Sentinel; Analytic rule name contains your high-risk user detection rule (or use the built-in Entra ID Protection analytics rule that creates incidents from AADRiskyUsers).
   • Action: Run playbook > select Respond-HighRiskUser.

Step 5: Create the High-Risk Sign-In Playbook

This playbook fires when a sign-in is classified as high-risk. It blocks the session and flags the account for a forced password change.

1. Create a new playbook named Respond-HighRiskSignIn (same process as Step 4).

2. Steps:

   Step 5a: Parse entities (same as Step 4a)

   Step 5b: Revoke sign-in sessions

   • Graph API call: POST https://graph.microsoft.com/v1.0/users/{userId}/revokeSignInSessions

   Step 5c: Require password change at next sign-in

   • Update user via Graph: set passwordProfile.forceChangePasswordNextSignIn = true.

   Step 5d: Alert the SOC with sign-in details (IP, location, risk reasons, timestamp).

3. Wire to an automation rule triggered by high-risk sign-in incidents from the Entra ID data connector.

Step 6: Configure SOC Escalation for Manual Review

Automated playbooks act immediately, but a human must review every automated action to confirm correctness, investigate root cause, and close the incident.

1. In your SOC ticketing system (ServiceNow, Jira Service Management, or equivalent), create an incoming webhook or connector that Microsoft Sentinel can call.
2. Extend each playbook's alert step (Steps 4d and 5d) to create a ticket in the SOC queue with:
   • Automated actions taken (disabled, sessions revoked)
   • Risk reasons from Entra ID Protection
   • Recommended next steps (investigate sign-in logs, check for mailbox forwarding rules, reset MFA)
3. Define an SLA for SOC review: recommended maximum 30 minutes for a high-risk user incident during business hours, with an on-call escalation path outside business hours.
4. Add a Sentinel automation rule action to close the incident automatically only after the SOC analyst marks the ticket resolved and confirms no further exposure.

Step 7: Test the End-to-End Flow

Before relying on these playbooks in production, simulate a risk event:

1. Use a test user account (non-privileged, no access to sensitive data).
2. Trigger a risk event via the Microsoft Graph API:

   POST https://graph.microsoft.com/beta/identityProtection/riskyUsers/{userId}/confirmCompromised
   

3. Confirm:
   • Sentinel incident created within 5 minutes.
   • Playbook executed: account disabled, sessions revoked.
   • SOC alert or ticket created.
4. Re-enable the test account and dismiss the risk via Entra ID Protection.

Verification Checklist

• Microsoft Sentinel workspace is deployed and connected to the Entra ID data connector
• AADRiskyUsers and AADUserRiskEvents tables are receiving data
• UEBA is enabled and baseline has had at least 48 hours to build
• Respond-HighRiskUser playbook is active and wired to an automation rule
• Respond-HighRiskSignIn playbook is active and wired to an automation rule
• Both playbooks have the correct Graph API permissions via managed identity
• SOC escalation channel or ticket queue is receiving alerts from playbooks
• End-to-end test with a simulated risk event completed successfully
• SOC on-call escalation path is documented and tested
• TrueConfig GOV-04 check shows compliant status

Troubleshooting

Issue: Playbook Does Not Fire on High-Risk Detection

Cause: Automation rule condition does not match the analytics rule name, or the Entra ID data connector is not streaming risk events.

Solution:

1. Confirm the AADRiskyUsers table has recent rows: run AADRiskyUsers | take 10 in Sentinel Log Analytics.
2. Verify the analytics rule creating incidents from risk events is enabled: go to Analytics > find rules named "Create incidents based on Microsoft Entra ID Protection alerts".
3. Check the automation rule condition matches those analytics rule names exactly.
4. Review the playbook run history in the Logic App for errors.

Issue: Graph API Call Returns 403 Forbidden

Cause: The Logic App's managed identity does not have the required Graph API application permissions.

Solution:

1. In Azure Active Directory, go to App registrations > find the managed identity associated with the Logic App.
2. Add application permissions: User.ReadWrite.All and Directory.Read.All.
3. Grant admin consent.
4. Re-run the playbook.

Issue: Legitimate User Account Was Auto-Disabled

Cause: False positive risk detection (VPN, travel, new device).

Solution:

1. Re-enable the account immediately in Entra admin center: Identity > Users > select user > Account status = Enabled.
2. Revoke any additional sessions the attacker may have reused.
3. In Entra ID Protection, dismiss the risk for the user after confirming the detection was a false positive.
4. Tune the analytics rule or add a named location exclusion in Conditional Access to reduce recurrence.

Issue: SOC Is Not Receiving Alerts

Cause: Teams/Outlook connector authentication expired, or webhook URL changed.

Solution:

1. Open the Logic App in the Azure portal and check the run history for the alert step.
2. Re-authenticate the Teams or Outlook connector.
3. Test the playbook manually using the Run trigger option.

Best Practices

1. Test regularly: run the end-to-end simulation quarterly. Playbook connectors expire and permissions drift.

2. Tune before scaling: start with report-only mode for the automation rule, review 2-4 weeks of incidents, confirm low false-positive rate, then switch to active response.

3. Exclude break-glass accounts from auto-disable: add emergency access accounts to a named exclusion list checked by the playbook before disabling. A false-positive disable of a break-glass account during an actual incident is catastrophic.

4. Document every automated action: Sentinel incident timelines and Logic App run histories constitute audit evidence. Ensure Log Analytics retention matches your compliance requirements.

5. Align with your IR policy: automated containment replaces the initial containment step of manual IR, not the investigation, eradication, or recovery steps. SOC analysts must still close each incident with a documented root cause.

Related Controls

• GOV-03: Access reviews for privileged role lifecycle
• PA-04: Require PIM for All Privileged Roles (limit blast radius when an account is compromised)
• LOG-03: Security alerts configuration (underlying signal quality for SOAR playbooks)

Revision History