Detection Logic Catalog

Trigger logic

1. Inspect directory audit events and match sensitive governance keywords.
2. Resolve a primary workload entity through correlation (application/service principal).
3. Suppress events where the initiator is "Microsoft Online Services" AND the target is a Microsoft first-party SPN (app_owner_organization_id = f8cdef31-…). This is Microsoft refreshing its own apps and is not a tenant-actionable signal.
4. Suppress events where the target SPN is the tenant's own connector principal (sp.app_id = connectors.client_id). This is the platform calling Microsoft Graph as itself.
5. Alert only when at least one risk amplifier is present: high-risk permissions, linked open posture findings, or ownerless identity. Microsoft first-party SPNs and connector-principal SPNs are never treated as ownerless.
6. Create or update grouped incident story for that workload identity.

Scoring and severity

• - Base model: detection_severity_weight=18, permission_criticality_weight=20 (if high risk), owner_missing_weight=10 (if ownerless), plus source finding severity.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "directory_audit",
  "keywords": [
    "consent",
    "permission grant",
    "credential",
    "certificate",
    "secret",
    "owner",
    "service principal",
    "application"
  ],
  "threshold": 1,
  "suppress_microsoft_self_update": true,
  "suppress_platform_connector_principal": true
}

Evidence emitted

• - directory_audit_event id/source_log_id/activity_display_name/activity_date_time
• - linked entity refs (application/service_principal)
• - linked finding refs from posture context

Trigger logic

1. Start from sensitive audit candidates.
2. Require high-risk permissions and creation/bootstrap keyword match.
3. Require the entity to be recent (created within 14 days of event time).
4. Escalate score with additional new identity bootstrap weight.

Scoring and severity

• - Directory-audit base scoring + new_workload_identity_weight=15.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "directory_audit",
  "keywords": [
    "add service principal",
    "add application",
    "add app role assignment",
    "add delegated permission grant"
  ],
  "entity_age_days": 14,
  "requires_high_risk_permissions": true,
  "threshold": 1
}

Evidence emitted

• - single triggering directory audit event reference
• - linked workload entity and optional linked findings

Trigger logic

1. Start from sensitive audit candidates.
2. Require entity to be both high-risk privileged and ownerless.
3. Require credential/governance keyword match.
4. Escalate score with ownerless privileged change weight.

Scoring and severity

• - Directory-audit base scoring + ownerless_privileged_change_weight=18.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "directory_audit",
  "keywords": [
    "add password credential",
    "add key credential",
    "certificates and secrets",
    "update application",
    "credential",
    "secret",
    "certificate"
  ],
  "requires_high_risk_permissions": true,
  "requires_ownerless": true,
  "threshold": 1
}

Evidence emitted

• - single triggering directory audit event reference
• - ownerless=true/high_risk_permissions=true metadata
• - linked workload entity and posture findings

Trigger logic

1. Group consent/grant keyword events per entity (application or service principal).
2. Slide a 30-minute window and require at least 3 events.
3. Require at least one risk amplifier across the window: high-risk permissions or ownerless.
4. Use the whole qualifying window as evidence.

Scoring and severity

• - Directory-audit base scoring + consent_burst_weight=min(20, event_count*4).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "directory_audit",
  "keywords": [
    "consent",
    "oauth2permissiongrant",
    "permission grant",
    "grant admin consent"
  ],
  "threshold": 3,
  "window_minutes": 30
}

Evidence emitted

• - all qualifying directory audit events in the burst window
• - first and latest event ids
• - distinct linked posture findings across the burst window

Trigger logic

1. Group failed sign-ins by identity and app context.
2. Use 30-minute sliding window and require at least 5 failures.
3. Source_id is stable per (identity, app), so subsequent bursts update the same alert in place rather than being dropped because the latest event id differs. Once an alert moves out of NEW (SOC has triaged), the rule stops mutating it.
4. Re-notify on growth: when the failure count grows by +5 since the previous notification, fire a fresh notification so on-call sees the burst continued.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=15, activity_recency_weight=15) with repeated_event_weight=min(20, max(10, count*2)).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "failure",
  "threshold": 5,
  "window_minutes": 30,
  "renotify_delta": 5,
  "stable_source_id_per_identity_app": true
}

Evidence emitted

• - all failed sign-in events in the qualifying window
• - status_error_code is preserved per event
• - app and IP context on latest event
• - notified_at_count records the count at the most recent notification for re-notify gating

Trigger logic

1. Group service principal sign-in events by app_id.
2. Filter to status_error_code == 7000222 (AADSTS7000222 — expired client secret).
3. Emit a MEDIUM operational incident when >= 50 such failures land in a 24-hour window for the same app.
4. Source_id includes a daily bucket so a single alert tracks the day; tomorrow gets a fresh alert if the integration is still broken.

Scoring and severity

• - Operational scoring: base_operational_weight=40 + failure_volume_weight=min(30, failure_count // 50).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status_error_code": "7000222",
  "threshold": 50,
  "window_hours": 24,
  "renotify_delta": 50
}

Evidence emitted

• - app_id and display name
• - failure count over the 24-hour window
• - latest sign-in event id and timestamp
• - linked SPN inventory id when known

Trigger logic

1. Pair each successful INTERACTIVE sign-in with successful NON-INTERACTIVE sign-ins for the same identity within the next 30 minutes.
2. Extract a device fingerprint from each event (deviceDetail.deviceId preferred; falls back to operatingSystem + browser only when neither side has a deviceId).
3. Fire when the two events have differing fingerprints — meaning the post-MFA session is being exercised from a device that did not complete the interactive challenge.
4. Skip when fingerprint data is missing on either side — no signal is better than a noisy guess.
5. One alert per interactive sign-in event so further replays from the captured token do not produce duplicates.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=30) + location_change_weight=12 + aitm_distinct_device_weight=10.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "interactive_status": "success",
  "non_interactive_status": "success",
  "window_minutes": 30,
  "require_distinct_device_fingerprint": true
}

Evidence emitted

• - interactive_sign_in_event_id and non_interactive_sign_in_event_id
• - interactive and non-interactive device fingerprints (deviceId / OS / browser)
• - both IPs and location summaries
• - time delta in minutes between the two events

Trigger logic

1. Require successful sign-in.
2. Require Microsoft risk signal: risk_level medium/high, risk_state atRisk/confirmedCompromised, or non-trivial risk_detail.
3. Emit one detection per risky successful sign-in event.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=18) + id_protection_risk_weight (high/atRisk/confirmedCompromised => 20, medium => 14, specific risk_detail => 10).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "success",
  "risk_level": [
    "medium",
    "high"
  ],
  "risk_state": [
    "atRisk",
    "confirmedCompromised"
  ],
  "threshold": 1,
  "window_minutes": 60
}

Evidence emitted

• - risky sign-in event id/source_log_id/time/ip/location
• - risk_level/risk_state/risk_detail fields
• - linked entities and posture findings context

Trigger logic

1. Start from successful sign-ins.
2. Look back 30 minutes for same identity + same app key failures.
3. Require failure count >= configured threshold (default 5).
4. Require latest failure to be within 10 minutes before success.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=20) with repeated_event_weight=min(25, max(12, failures*2)).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "success_after_failure",
  "threshold": 5,
  "window_minutes": 30,
  "success_after_minutes": 10
}

Evidence emitted

• - all qualifying failure events plus the successful event
• - minutes_since_latest_failure
• - app and IP context

Trigger logic

1. Start from successful interactive sign-ins with normalized location.
2. Look back 60 minutes for prior successful interactive sign-in for same identity.
3. Require different normalized location and different IP.
4. Use prior/current sign-in pair as evidence.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=18) + location_change_weight=15.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "success",
  "requires_interactive": true,
  "window_minutes": 60,
  "distinct_location": true,
  "distinct_ip": true,
  "threshold": 1
}

Evidence emitted

• - prior and current successful interactive sign-in event refs
• - time_delta_minutes
• - prior/current location and IP context

Trigger logic

1. Group successful non-interactive sign-ins by identity and app key.
2. Use 20-minute sliding window and require at least 3 events.
3. Require at least 2 distinct IPs and at least 2 distinct normalized locations.
4. Use entire qualifying replay-like window as evidence.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=22) + repeated_event_weight=min(20, max(12, count*3)) + location_change_weight=18 + session_replay_indicator_weight=10.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "success",
  "is_interactive": false,
  "threshold": 3,
  "window_minutes": 20,
  "distinct_ip_min": 2,
  "distinct_location_min": 2
}

Evidence emitted

• - all non-interactive events in qualifying replay window
• - distinct IP and distinct normalized location lists
• - time_window_minutes and app context

Trigger logic

1. Start from successful non-interactive sign-ins.
2. Look back 24 hours for prior successful events for same identity.
3. Skip if there is a recent matching non-interactive event (same location/IP/client app) baseline.
4. Otherwise require a prior interactive success within 60 minutes from a different location/IP.
5. Use interactive->non-interactive pair as evidence.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=20) + location_change_weight=18.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "success",
  "is_interactive": false,
  "window_minutes": 60,
  "baseline_minutes": 1440,
  "threshold": 1
}

Evidence emitted

• - prior interactive success and current non-interactive success refs
• - delta minutes and location comparison
• - client_app_used context

Trigger logic

1. Group failed sign-ins by public source IP address.
2. Use a 20-minute sliding window and require at least 6 failures targeting at least 4 distinct identities.
3. Emit one grouped detection keyed to source IP and event window.
4. Create/update a single incident story for the source IP spray pattern.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=16, activity_recency_weight=15) + repeated_event_weight + multi_identity_failure_burst_weight=12.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "failure",
  "threshold": 6,
  "window_minutes": 20,
  "distinct_identity_min": 4,
  "group_by": "ip_address"
}

Evidence emitted

• - all failed sign-in events in the qualifying IP window
• - public source IP, distinct identity count, and distinct app count
• - first/latest sign-in event ids for grouped story anchoring

Trigger logic

1. Group successful sign-ins by public source IP address.
2. Use a 30-minute sliding window and require at least 5 successes across at least 4 identities.
3. Require either datacenter/proxy risk indicators or a strong non-interactive fan-out pattern.
4. Emit one grouped detection keyed to source IP and event window.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=18, activity_recency_weight=15) + repeated_event_weight + location_change_weight + datacenter_indicator_weight.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "success",
  "threshold": 5,
  "window_minutes": 30,
  "distinct_identity_min": 4,
  "requires_datacenter_signal_or_non_interactive_burst": true,
  "group_by": "ip_address"
}

Evidence emitted

• - all successful sign-in events in the qualifying IP window
• - datacenter/proxy signal counts and non-interactive counts
• - distinct identities/apps/locations with first/latest event anchors

Trigger logic

1. Inspect Office 365 Management Exchange events for inbox-rule operations.
2. Require suspicious rule actions (forward/redirect/delete/hide behaviors).
3. Emit detection when action profile indicates likely mailbox persistence or notification suppression.

Scoring and severity

• - Fixed high-severity mailbox abuse score model for suspicious rule operation + action combinations.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "o365_management",
  "workload": "exchange",
  "requires_inbox_rule_operation": true,
  "requires_suspicious_rule_actions": true
}

Evidence emitted

• - o365_management source log id and operation/workload metadata
• - matched inbox rule operation markers and suspicious action markers
• - mailbox actor context where present

Trigger logic

1. Start from suspicious Exchange inbox-rule manipulation.
2. Require keyword overlap with generic account/security notification terms.
3. Emit detection when filter terms suggest suppression of security notices.

Scoring and severity

• - Fixed high-severity rule for likely suppression of user/account security notifications.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "o365_management",
  "workload": "exchange",
  "requires_filter_terms": [
    "account",
    "security",
    "alert",
    "notification"
  ],
  "minimum_filter_term_matches": 3
}

Evidence emitted

• - same evidence base as inbox-rule detector plus matched keyword list
• - mailbox actor and operation context

Trigger logic

1. Start from suspicious Exchange inbox-rule manipulation.
2. Require finance/BEC keyword suppression terms (invoice/wire/payment/etc).
3. Escalate as critical due to likely business email compromise monetization path.

Scoring and severity

• - Critical mailbox-abuse scoring path for finance/BEC suppression indicators.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "o365_management",
  "workload": "exchange",
  "requires_filter_terms": [
    "finance",
    "invoice",
    "wire",
    "payment",
    "vendor"
  ],
  "minimum_filter_term_matches": 2
}

Evidence emitted

• - matched finance/BEC keyword set
• - suspicious inbox-rule action profile and actor context
• - source log references for forensic triage

Trigger logic

1. Start from suspicious Exchange inbox-rule manipulation.
2. Require external-account security notification keyword overlap observed in Exchange inbox-rule terms (for example Google/Gmail notifications seen in mailbox content).
3. Emit detection for likely cross-platform credential-theft suppression behavior using O365 inbox-rule telemetry.

Scoring and severity

• - High-severity mailbox-abuse scoring for cross-platform security-notification suppression.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "o365_management",
  "workload": "exchange",
  "requires_filter_terms": [
    "google",
    "gmail",
    "security alert",
    "verification code"
  ],
  "minimum_filter_term_matches": 2
}

Evidence emitted

• - matched external security-notification keyword markers
• - rule action markers and mailbox actor metadata
• - source log references for incident story

Trigger logic

1. Correlate risky sign-in detection with authentication-method change event on same identity.
2. Require subsequent suspicious inbox-rule detection for same mailbox context.
3. Trigger when full chain occurs within 24 hours.

Scoring and severity

• - Critical chain score based on multi-stage compromise progression across identity + mailbox telemetry.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "risky_signin_success",
    "authentication_method_change",
    "mailbox_rule_manipulation"
  ],
  "window_hours": 24,
  "scope": "same_identity"
}

Evidence emitted

• - risky sign-in alert id
• - directory audit MFA-change event id
• - inbox-rule detection alert id

Trigger logic

1. Start from credential theft spray alert keyed to source IP.
2. Require successful sign-in detections from same source IP shortly after spray.
3. Require successful multi-identity access from same source IP within 120 minutes.

Scoring and severity

• - Critical chain score prioritizing spray-to-compromise progression plus observed lateral movement.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "credential_theft_detection",
    "successful_signin_after_failures_or_risky_success",
    "multi_identity_same_ip_access"
  ],
  "window_minutes": 120,
  "scope": "source_ip"
}

Evidence emitted

• - spray alert id and matched successful sign-in alert ids
• - shared source IP
• - latest successful sign-in event demonstrating multi-identity access

Trigger logic

1. Aggregate non-interactive token replay alerts by shared source IP.
2. Require replay detections spanning at least two identities.
3. Trigger chain when shared infrastructure is reused across identities within 24 hours.

Scoring and severity

• - High-severity chain score emphasizing cross-identity session compromise pattern.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "non_interactive_token_replay",
    "shared_source_ip",
    "multiple_identities"
  ],
  "window_hours": 24,
  "group_by": "source_ip"
}

Evidence emitted

• - token replay alert ids tied to shared source IP
• - distinct identity count and identity refs
• - shared source infrastructure marker

Trigger logic

1. Start from successful sign-ins and look back for prior failures on the same identity and app context.
2. Require at least 2 preceding MFA-denied failures within a 30-minute window.
3. Require the latest denied challenge to be close to the later success (default 15 minutes).
4. Emit one detection keyed to the successful sign-in event.

Scoring and severity

• - Sign-in base scoring (base_detection_weight=21) + repeated_event_weight + mfa_challenge_bypass_weight=8.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "signin",
  "status": "mfa_denied_then_success",
  "threshold": 2,
  "window_minutes": 30,
  "success_after_minutes": 15
}

Evidence emitted

• - preceding MFA-denied sign-in event refs plus successful sign-in event ref
• - mfa_denied_count and minutes_since_latest_mfa_denied
• - app and IP context on the successful sign-in

Trigger logic

1. Start from risky successful sign-in detections for an identity.
2. Require a correlated authentication-method change event for the same identity within 24 hours.
3. Emit an alert even when no mailbox-rule manipulation is seen yet.
4. Use this as an early warning stage before deeper persistence indicators appear.

Scoring and severity

• - High-severity chain scoring (sequence_steps_weight + time_proximity_weight + auth_control_change_weight).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "risky_signin_success",
    "authentication_method_change"
  ],
  "window_hours": 24,
  "scope": "same_identity"
}

Evidence emitted

• - risky sign-in alert id
• - directory audit authentication-method change event id
• - identity markers and 24-hour chain window context

Trigger logic

1. Start from risky successful sign-in detections for an identity.
2. Require a correlated password reset/change directory-audit event for the same identity within 24 hours.
3. Emit an alert even when no mailbox or MFA-manipulation signal is present.
4. Use this as a persistence/credential-manipulation warning stage after suspicious access.

Scoring and severity

• - High-severity chain scoring (sequence_steps_weight + time_proximity_weight + credential_manipulation_weight).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "risky_signin_success",
    "password_reset"
  ],
  "window_hours": 24,
  "scope": "same_identity"
}

Evidence emitted

• - risky sign-in alert id
• - directory audit password reset event id
• - identity markers and 24-hour chain window context

Trigger logic

1. Start from risky successful sign-in detections for an identity.
2. Require a correlated OAuth consent/permission-grant directory-audit event for the same identity within 24 hours.
3. Flag likely rogue-app staging tied to suspicious authenticated sessions.
4. Escalate early before wider mailbox/data-access abuse appears.

Scoring and severity

• - High-severity chain scoring (sequence_steps_weight + time_proximity_weight + oauth_consent_weight).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "risky_signin_success",
    "oauth_consent_or_permission_grant"
  ],
  "window_hours": 24,
  "scope": "same_identity"
}

Evidence emitted

• - risky sign-in alert id
• - directory audit consent/permission-grant event id
• - consent activity metadata and identity markers

Trigger logic

1. Start from risky successful sign-in detections for an identity.
2. Require a correlated authentication-method change event indicating weaker MFA posture within 24 hours.
3. Prioritize method removals/default changes or weak-method indicators.
4. Escalate as active persistence/MFA-bypass risk until intent is verified.

Scoring and severity

• - Critical chain scoring (sequence_steps_weight + time_proximity_weight + mfa_assurance_reduction_weight).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "risky_signin_success",
    "mfa_method_weakened"
  ],
  "window_hours": 24,
  "scope": "same_identity"
}

Evidence emitted

• - risky sign-in alert id
• - directory audit MFA-weakened event id
• - identity markers and chain window context

Trigger logic

1. Start from risky successful sign-in detections for an identity.
2. Require a correlated privileged role assignment event by the same actor within 24 hours.
3. Treat this as likely privilege-escalation behavior until disproven.
4. Escalate incident early to reduce blast radius.

Scoring and severity

• - Critical chain scoring (sequence_steps_weight + time_proximity_weight + privilege_escalation_weight).
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "sequence": [
    "risky_signin_success",
    "privileged_role_assignment"
  ],
  "window_hours": 24,
  "scope": "same_identity"
}

Evidence emitted

• - risky sign-in alert id
• - directory audit privileged role assignment event id
• - identity actor markers and chain window context

Trigger logic

1. Evaluate older workload identities (service principals) for newly observed recent sign-in activity.
2. Require concurrent sensitive governance change context from directory audit in the same period.
3. Prioritize identities with high-risk permissions, owner gaps, or linked open findings. Microsoft first-party SPNs and connector-principal SPNs are excluded from the ownerless signal.
4. Bucket the activation timestamp into 6-hour windows so multiple sign-ins from the same dormant SPN within a window collapse into one alert (regression guard for incident #19 with 163 alerts).
5. Emit incident-scoped alert keyed to service principal and the 6-hour bucket.

Scoring and severity

• - High-severity scoring from workload risk context + dormant-age/reactivation/governance-change weights.
• - Severity is score-driven (critical >= 55, high >= 40, medium >= 25, else low). Sign-in and directory-audit rules add context weights for permissions, findings, and behavior.

Rule conditions

{
  "event_source": "workload_identity_activity",
  "min_age_days": 90,
  "recent_signin_window_hours": 24,
  "requires_sensitive_change_context": true,
  "activation_bucket_hours": 6
}

Evidence emitted

• - service principal id and last sign-in timestamp
• - linked sensitive directory-audit change event
• - workload age/risk context and linked findings