0.5 The Blast Radius Assessment

Every containment action breaks something

Confidence measures the probability that an alert is real. Blast radius measures the cost of acting on it. Both are necessary because they answer different questions, and a correct answer to one does not compensate for a wrong answer to the other.

A session revocation on a standard user during normal working hours forces a re-authentication that takes 30 seconds. The same revocation on a service account running an automated data pipeline breaks every downstream process that depends on that authentication token until an administrator manually re-authenticates the service. A device isolation on a desktop workstation removes one user from the network until IT releases it. The same isolation on a shared server hosting a line-of-business application takes the entire department offline.

Blast radius is not a property of the containment action alone. It is a property of the action applied to a specific entity at a specific time. Disabling a standard user account is moderate blast radius. Disabling the CEO's account during a board meeting is extreme. Disabling a break-glass emergency access account could lock every administrator out of the tenant. One action, applied to different entities, produces entirely different consequences.

The four blast radius categories

Blast radius assessment classifies the affected entity into one of four categories based on the business impact of a false containment action. Each category determines how the playbook handles the incident.

Category 1: Standard users. Employees with normal M365 access, no administrative privileges, and no executive classification. A false containment action (session revocation, account disablement) disrupts one person's workflow for minutes to hours. The help desk resolves it through a standard ticket. Business impact is limited to individual productivity. These entities can be processed through fully automated containment when the confidence threshold passes.

Category 2: Privileged accounts. Accounts with administrative roles in Entra ID, Exchange Online, SharePoint, Defender, or Sentinel. A false containment action on a Global Administrator can prevent security operations from responding to other incidents. A false action on an Exchange Administrator can block emergency email communication. These entities require an elevated confidence threshold (typically 5-10% higher than the standard threshold) and should route through semi-automated approval for any action beyond session revocation.

Category 3: VIP and executive accounts. C-suite, board members, and other executives whose disruption has external visibility. A false action during a customer meeting, investor call, or media interview creates reputational damage. These entities should always route through approval for any containment action, regardless of confidence score. The approval request includes additional context: the user's current calendar state (in a meeting or free), the action's reversibility, and the estimated time to restore access.

Category 4: Service and critical infrastructure accounts. Service principals, managed identities, shared mailboxes processing automated workflows, break-glass emergency access accounts, and accounts linked to critical business processes. A false containment action on these entities can cascade across systems in ways that are difficult to predict and slow to reverse. These entities should be excluded from all automated containment and escalated to a human operator with explicit awareness that the entity is classified as critical infrastructure.

Implementing the assessment in playbooks

In a playbook, the blast radius assessment runs after the confidence check and before the containment action. It evaluates the affected entity's properties against three data sources: a VIP watchlist, an administrative role check, and a service account registry.

// Determine blast radius category for an entity
// Run against entity UPN from the incident
let targetUPN = "j.morrison@northgateeng.com";
let vipList = _GetWatchlist('VIPUsers')
    | where UserPrincipalName == targetUPN;
let adminRoles = IdentityInfo
    | where AccountUPN == targetUPN
    | where AssignedRoles has_any (
        "Global Administrator",
        "Exchange Administrator",
        "Security Administrator",
        "Privileged Role Administrator"
    );
let svcAccounts = _GetWatchlist('ServiceAccounts')
    | where AccountUPN == targetUPN;
let breakGlass = _GetWatchlist('BreakGlassAccounts')
    | where AccountUPN == targetUPN;
// Classify: Cat 4 > Cat 3 > Cat 2 > Cat 1 (highest wins)
print Category = case(
    toscalar(svcAccounts | count) > 0
        or toscalar(breakGlass | count) > 0, "Cat4_HumanOnly",
    toscalar(vipList | count) > 0, "Cat3_ApprovalRequired",
    toscalar(adminRoles | count) > 0, "Cat2_ElevatedThreshold",
    "Cat1_Standard"
)

In a Logic App, this classification runs as a series of HTTP actions against the Microsoft Graph and Sentinel watchlist APIs. The playbook checks the VIP watchlist first (a Sentinel watchlist lookup), then queries directoryRoles for admin role assignments, then checks the service account watchlist. The highest matching category determines the containment path.

Your watchlists are critical infrastructure for the automation program. Build the VIP watchlist with executive accounts, board member accounts, and any user whose disruption has external business impact. Build the service account watchlist with managed identities, service principals, shared mailboxes that run automated workflows, and break-glass accounts. Both watchlists must be maintained as part of the onboarding and offboarding process. A new executive who is not on the VIP list receives the same automated treatment as a standard user, which is exactly the wrong outcome.

The combined decision gate

Confidence and blast radius form a two-part gate. A containment action executes automatically only when both checks pass. If either fails, the incident routes to a human.

For a Category 1 (standard) user: the confidence score must exceed the action-specific threshold (95% for session revocation, 97% for account disable). If confidence passes, the playbook executes the containment action immediately.

For a Category 2 (privileged) user: the confidence threshold increases by 5%. Session revocation requires 98% instead of 95%. Account disablement is restricted to semi-automated mode only, routed through approval regardless of confidence.

For a Category 3 (VIP) user: all containment routes through approval. The approval request includes the enrichment summary, the confidence score, the user's current calendar state (pulled from Graph API), and the estimated disruption impact. An analyst reviews and approves before any action executes.

For a Category 4 (critical infrastructure) entity: no automated containment of any kind. The incident is escalated to a senior analyst or SOC manager with an explicit flag that the entity is classified as critical infrastructure. The human decides the appropriate response, which may include out-of-band verification with the entity owner before taking any action.

Time-sensitivity and context

Blast radius is not static within a single incident. The same VIP account has different blast radius at different times. Disabling the CFO's account at 2 AM on a Saturday has minimal operational impact: she is not working, her team is not waiting on her, and IT can re-enable the account before Monday. Disabling the same account at 10 AM on a Tuesday during earnings season has significant impact.

Calendar-aware blast radius assessment uses the Microsoft Graph Calendar API to check the entity's current meeting status. If the VIP is currently in a meeting (especially a meeting with external attendees), the blast radius classification escalates. Session revocation for a VIP in a meeting becomes an approval-required action even if the confidence score would normally justify automatic execution for that action type.

This does not mean you never contain a VIP during a meeting. It means the automation pauses, presents the context to the analyst (confidence score, enrichment summary, meeting details), and lets a human weigh the trade-off. If the compromise is genuine and the attacker is actively exfiltrating data, 30 seconds of analyst review is a small price for avoiding an unnecessary executive disruption. If the compromise is real and the damage is escalating, the analyst approves immediately. The gate adds seconds, not minutes, and prevents the reputational incidents that kill automation programs.

Maintaining the assessment over time

Blast radius classification is not a one-time setup. The assessment degrades as the organization changes. Executives join and leave. Service accounts are created for new integrations. Administrative roles are assigned for project work and never revoked. A watchlist that was accurate six months ago may have significant gaps today.

Build a quarterly review cycle into the automation governance framework (SA0.9 covers this in detail). Each quarter, reconcile the VIP watchlist against the current executive roster and board membership. Reconcile the service account watchlist against active service principals in Entra ID (a Graph API query against /servicePrincipals returns the full inventory). Reconcile the admin role check against current directory role assignments. Any gap between the watchlists and reality is a gap in the blast radius assessment, which means automated containment is operating on incomplete data.

Automated drift detection helps. A scheduled analytics rule that compares the VIP watchlist against a daily export of users with executive-level job titles, or that compares the service account watchlist against active service principals, can generate a low-severity alert when discrepancies appear. Treat these alerts as hygiene tasks, not security incidents, but do not defer them. An unregistered VIP is one false positive away from an automated disruption.

The most common drift patterns are predictable. New executive hires that bypass the VIP onboarding process because HR does not notify the SOC. Service accounts created by IT for new SaaS integrations without updating the registry. Temporary administrative role assignments for project work that become permanent because nobody revokes them. Each pattern has a specific detection: new users with executive-level job titles not in the VIP watchlist, new service principals in Entra ID not in the service account watchlist, directory role assignments older than 30 days that were flagged as temporary. Building these detections into your automation hygiene ruleset ensures the blast radius assessment stays accurate as the organization evolves.

You should also document the classification criteria explicitly. A written policy that defines who qualifies for Category 3 (VIP) prevents debates during incident response. "All users with the job title VP or above, all board members, and all users on the executive assistant delegation list" is clear. "Important people" is not. The policy goes into the automation governance framework alongside the confidence thresholds and the watchlist maintenance schedule.