Skip to content

identity-detection-response.md

Latest commit

 

History

History
75 lines (63 loc) · 4.54 KB

identity-detection-response.md

File metadata and controls

75 lines (63 loc) · 4.54 KB
Raw
name identity-detection-response
description Respond to a Falcon Identity Protection detection in a Falcon Fusion workflow by getting the user's identity context, evaluating a condition (e.g. a recent password change), then auto-resolving the detection or notifying — reducing false-positive noise on identity alerts
source https://www.reddit.com/r/crowdstrike/comments/1oj9rve/cool_workflow_wednesday_password_compromise/
example skills/authoring/examples/identity-response/identity-detection-auto-resolution.yaml
skills
authoring
deployment
execution
capabilities
workflow
identity
response

When to Use

User wants a workflow that triages Identity Protection detections automatically — pulling the involved user's identity context, deciding whether the alert is a likely false positive, and either closing it or leaving it for an analyst. The grounding example auto-resolves "Password Brute Force attack" detections when the user changed their password within 30 minutes of the detection (recent password change → likely legitimate activity). This is corroborated by the Workflow Wednesday "password compromise" post, which builds the same identity-response shape.

This is grounded in the real Content Library playbook skills/authoring/examples/identity-response/identity-detection-auto-resolution.yaml — read it for the exact structure: a Signal trigger → detection-name gate → get identity context → time-window condition → set status → comment.

Pattern

  1. Trigger on the identity detection. The example uses a Signal trigger named Detection > Identity Detection with event: Investigatable/IDP and version_constraint: ~0. This fires the workflow on each Identity Protection detection.
  2. Gate on detection name (optional but recommended). The example's first condition is an FQL expression on Trigger.Category.Investigatable.Product.IDP.DetectName, matching only Password Brute Force attack (Active Directory) and ...(web-based) so the automation scopes to the detections it understands.
  3. Get the user's identity context. Call Get user identity context (version_constraint: ~1), passing the user from the trigger — entity_sid: ${Trigger.Category.Investigatable.Product.IDP.SourceAccountObjectSid} and username: ${Trigger.Category.Investigatable.Product.IDP.SourceAccountName}. Set continue_if_entity_not_found: false so the workflow stops if the user can't be resolved.
  4. Evaluate a condition. The example uses a CEL condition comparing the detection end time to the user's last password change: cs.timestamp.parse(data['Trigger.Category.Investigatable.Product.IDP.EndTime'], 'RFC3339') - cs.timestamp.parse(data['get_user_identity_context_....PasswordChange'], 'RFC3339') < duration('30m'). When true, the detection is treated as a likely false positive.
  5. Act on the verdict.
    • Auto-resolve: call Set detection status with investigatable_id: ${Trigger.Category.Investigatable.InvestigatableID} and status: closed.
    • Annotate: call Add comment to detection with the same investigatable_id, recording why it was resolved (e.g. "user changed password shortly before detection triggered"). Swap the close for a notification action if you want a human to review instead of auto-closing.
  6. Validate, then deploy. Run validate.py, then import and release to the CID.

Key Actions

The id and version_constraint values below are taken directly from the source example YAML.

Action id version_constraint
Get user identity context 19c7e2af0a24f468be7797fe180c8329 ~1
Set detection status beb56cc40d334583671ca91e6e390056 ~0
Add comment to detection 7b77cb5d5ff2651cc51c7c4c610d54d1 ~0

Note: the "Set detection status" action omits version_constraint in the example YAML (the platform defaults it), but the correct explicit value is ~0 per the action catalog via action_search.py --details.

The trigger's Signal event value (Investigatable/IDP) and all ${Trigger.Category.Investigatable...} references are taken from the example; keep them exact, since they bind to the Identity Detection signal's data shape.

When to Route Elsewhere

Keep identity triage in the workflow when each step feeds the next directly (context → condition → status). Build a Foundry function (route to foundry-skills) when the decision logic is complex, reused across many workflows, needs custom result transformation in code, or is paired with a UI or collection.