Using Sentinel Playbooks to Block Risky Sessions (AC.L2-3.1.12)

A Microsoft Sentinel playbook block risky remote sessions workflow can detect high-risk Entra ID sign-ins, create a Sentinel incident, revoke the affected user’s refresh tokens and browser sessions through Microsoft Graph, and retain incident evidence for review. This supports NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice AC.L2-3.1.12 by automating a controlled response while preserving human approval for account-disablement decisions and other high-impact actions.

For an RFP response, describe this as an Azure-native control chain: Entra ID forwards sign-in telemetry to Log Analytics, Microsoft Sentinel identifies a defined risky-session condition, an automation rule invokes a Logic Apps playbook, and the playbook executes a narrowly scoped Microsoft Graph action. The proposal should also state the important limitation: revoking sign-in sessions invalidates refresh tokens and browser session cookies, but an already-issued access token may remain usable until it expires unless other enforcement mechanisms, such as Conditional Access or Continuous Access Evaluation, apply.

What can be automated versus what requires a control owner?

AC.L2-3.1.12 requires the organization to permit, identify, control, and monitor remote access sessions. Azure automation is well suited to the repeatable detection, containment, logging, and notification portions of that requirement. It should not silently make every business-risk decision on behalf of an authorized control owner.

For proposal language, avoid claiming that automated token revocation “terminates all access immediately.” A defensible statement is that the organization automatically revokes renewable sign-in sessions for qualifying risk events, alerts responsible personnel, and uses Conditional Access and manual escalation procedures for conditions requiring stronger or faster containment.

How does a Microsoft Sentinel playbook block risky remote sessions?

The implementation below uses a Sentinel scheduled analytics rule to detect Entra ID risk signals and a Logic Apps Consumption playbook with a system-assigned managed identity. The playbook receives the Sentinel incident, extracts the Entra ID user identifier, calls Microsoft Graph, and records its result in the incident. This approach avoids storing a Graph client secret in the workflow.

1. Define the Sentinel detection logic

The following Kusto Query Language query identifies risky interactive sign-ins. It intentionally focuses on users rather than service principals because the session-revocation action is a user action. The organization should route Entra sign-in logs to the Sentinel workspace before enabling this rule.

SigninLogs
| where TimeGenerated > ago(10m)
| where RiskLevelDuringSignIn in ("high", "medium")
    or RiskState in ("atRisk", "confirmedCompromised")
| where UserType == "Member"
| where isnotempty(UserId)
| project TimeGenerated, UserPrincipalName, UserId, AppDisplayName,
          IPAddress, Location, RiskLevelDuringSignIn, RiskState,
          ConditionalAccessStatus, CorrelationId
| extend AccountCustomEntity = UserPrincipalName
| extend AadUserIdCustomEntity = UserId

A production implementation normally uses High severity for automatic revocation and sends medium-risk events to an analyst queue. That distinction is important in a proposal: containment thresholds are approved risk decisions, not merely technical defaults.

2. Deploy the playbook and assign only the required Graph permission

The Bash example creates a Logic Apps workflow from a reviewed JSON definition, enables a system-assigned identity, and assigns the Microsoft Graph application permission required to revoke user sessions. Run it from a controlled deployment identity with authority to create Logic Apps resources and grant Microsoft Graph app roles. The deployment identity should be separated from day-to-day Sentinel analyst accounts.

#!/usr/bin/env bash
set -euo pipefail

RG="rg-cui-sentinel-prod"
LOCATION="eastus2"
PLAYBOOK="la-sentinel-revoke-risky-session"
WORKFLOW_FILE="revoke-risky-session.workflow.json"

az logic workflow create \
  --resource-group "$RG" \
  --location "$LOCATION" \
  --name "$PLAYBOOK" \
  --definition @"$WORKFLOW_FILE" \
  --state Enabled

az logic workflow identity assign \
  --resource-group "$RG" \
  --name "$PLAYBOOK"

MI_OBJECT_ID=$(az logic workflow show \
  --resource-group "$RG" \
  --name "$PLAYBOOK" \
  --query "identity.principalId" -o tsv)

GRAPH_SP_OBJECT_ID=$(az ad sp list \
  --filter "appId eq '00000003-0000-0000-c000-000000000000'" \
  --query "[0].id" -o tsv)

REVOKE_ROLE_ID=$(az ad sp show --id "$GRAPH_SP_OBJECT_ID" \
  --query "appRoles[?value=='User.RevokeSessions.All' && contains(allowedMemberTypes, 'Application')].id | [0]" \
  -o tsv)

az rest --method POST \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals/$MI_OBJECT_ID/appRoleAssignments" \
  --headers "Content-Type=application/json" \
  --body "{\"principalId\":\"$MI_OBJECT_ID\",\"resourceId\":\"$GRAPH_SP_OBJECT_ID\",\"appRoleId\":\"$REVOKE_ROLE_ID\"}"

The Graph permission assignment should be documented in the system security plan and reviewed as privileged application access. If the organization elects to disable users automatically, that is a separate, more powerful permission and should be governed by a distinct approval decision, test plan, and rollback process.

3. Configure the Graph action in the Logic Apps playbook

In the workflow definition, use the Microsoft Sentinel incident trigger and an HTTP action authenticated with the workflow’s managed identity. The core containment call is shown below. The expression assumes the workflow has extracted an Entra ID object ID into a variable named UserObjectId from the incident entities.

{
  "type": "Http",
  "inputs": {
    "method": "POST",
    "uri": "@concat('https://graph.microsoft.com/v1.0/users/', variables('UserObjectId'), '/revokeSignInSessions')",
    "authentication": {
      "type": "ManagedServiceIdentity",
      "audience": "https://graph.microsoft.com"
    },
    "headers": {
      "Content-Type": "application/json"
    }
  },
  "runAfter": {}
}

Follow the HTTP action with a Sentinel incident comment containing the user principal name, incident number, Graph response status, timestamp, and playbook run ID. This turns the automation record into usable assessment evidence rather than an opaque background task.

How should the automation enter CI/CD or scheduled operations?

For a federal proposal, position the workflow as infrastructure and detection content managed through source control. Store the KQL query, Logic Apps workflow JSON, deployment script, parameter files, and approval records in a restricted repository. Use separate parameter values for development, staging, and production workspaces; do not promote production connection settings or incident-routing addresses by copying them manually.

A practical GitHub Actions pattern runs validation on every pull request and performs production deployment only after an environment approval. The deployment identity should use Azure workload identity federation rather than a long-lived client secret.

name: deploy-sentinel-session-response

on:
  push:
    branches: [main]
    paths:
      - "sentinel/**"
      - "playbooks/**"

jobs:
  deploy-production:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: $
          tenant-id: $
          subscription-id: $
      - name: Deploy session response playbook
        run: bash playbooks/deploy-revoke-risky-session.sh

Use a scheduled job for assurance, not for primary containment. A daily Azure Automation runbook or GitHub Actions schedule can verify that the analytics rule remains enabled, the playbook is enabled, diagnostic settings are still forwarding logs, and the managed identity still holds only the intended Graph role.

Which monitoring and alerting hooks prove the control is operating?

A Sentinel playbook to block risky remote sessions should produce separate operational evidence for detection, response, and failure. Configure the playbook to update the originating incident, create a ServiceNow security incident for high-risk events, and notify the security operations channel when containment succeeds or fails. Enable diagnostic settings for Logic Apps workflow runtime events and send them to the same Log Analytics workspace.

• Detection hook: Sentinel incident created from the risky-sign-in analytics rule, including user, IP address, application, location, and risk state.
• Containment hook: Logic Apps run status and Microsoft Graph HTTP status code recorded in an incident comment.
• Escalation hook: ServiceNow ticket assignment to the incident-response queue when session revocation succeeds, fails, or cannot identify a user object ID.
• Compliance hook: Monthly report showing incident count, percentage with successful playbook execution, failed execution reasons, and analyst closure time.

These artifacts demonstrate the “monitor” and “control” portions of AC.L2-3.1.12. They also help evaluators distinguish an implemented control from a policy statement that relies on unverified manual action.

What happens when the playbook cannot safely block a session?

Failure handling must be explicit because an unavailable connector, malformed entity, or revoked permission can otherwise leave a risky remote session unaddressed. Configure the workflow’s failure branch to add a high-priority incident comment, assign the incident to the on-call queue, and create an escalation ticket. Do not mark the incident closed automatically merely because the playbook ran.

• If UserObjectId is missing, do not call Graph by user principal name without validation; assign the incident for analyst verification.
• If Graph returns 403, treat it as a privileged-permission configuration failure and alert the platform owner; do not repeatedly retry indefinitely.
• If Graph returns 429 or a transient 5xx, retry with bounded exponential backoff and retain each attempt in workflow history.
• If revocation succeeds but the user is privileged or CUI exposure is suspected, require analyst escalation for Conditional Access enforcement, account disablement approval, and scope review.
• If the Sentinel rule generates excessive volume, disable only the automation rule after approval; preserve logging and continue creating incidents for investigation.

For the RFP response, include the workflow diagram, KQL rule, managed-identity permission record, test results, and sample incident timeline as objective evidence that remote sessions containing or accessing CUI are monitored and controlled.

Next step: Include this playbook design as a contract-line implementation artifact and map its evidence outputs directly to the AC.L2-3.1.12 assessment objectives in the proposal compliance matrix.