CCFA-200 Workflows

Workflows Detailed Explanation

1. Workflow Triggers

What Are Falcon Fusion Workflows?

Fusion workflows are automated response sequences triggered by events within Falcon. They allow your organization to:

• Respond faster to threats

• Standardize incident handling

• Reduce manual work for security teams

1. What Is a Workflow Trigger?

A trigger is the event that starts the workflow. When Falcon detects a certain condition, it launches the associated automation.

Common Trigger Types:

Trigger Type	Description
Detection Triggered	A new detection occurs on a host
Detection Reviewed/Unreviewed	A detection is reviewed (or remains unreviewed for X time)
Host Joins a Group	A host enters a specific group
Policy Assigned	A host receives a new policy
Host Tag Updated	A tag is added/removed from a host
IOC Match Occurs	A host matches a known IOC
Sensor Health Change	Sensor status changes (e.g., becomes unhealthy)

2. Trigger Conditions

Each trigger can have conditional logic that refines when the workflow should run. You can filter by:

Condition	Example
Severity Level	Only trigger on detections rated “High” or “Critical”
Detection Source	Only trigger on Custom IOA detections
Policy Name	Trigger when a host joins a group with "Finance Policy"
Host Tags	Trigger only on hosts tagged “VIP” or “Executive”

Conditions help ensure that automation runs only when it’s needed, avoiding noise or overreaction.

3. Example Trigger Scenarios

• Auto-Isolate a Host:

  • Trigger: Detection with Severity = Critical

  • Condition: Host tag = “Production”

  • Action: Contain the host

• Create a Ticket in Jira:

  • Trigger: Detection is unreviewed for 1 hour

  • Condition: Severity ≥ High

  • Action: Auto-create a Jira ticket for investigation

Best Practices for Triggers:

Tip	Why It Helps
Start with broad triggers, then refine	Helps observe patterns before over-automating
Use tag-based filters for precision	Targets actions to critical assets
Log all trigger activity	Enables troubleshooting and tuning later
Avoid overlapping triggers	Prevents redundant actions (e.g., multiple isolations)

2. Workflow Actions

What Are Workflow Actions?

Once a trigger fires (such as a detection, tag change, or policy update), Falcon Fusion can automatically perform one or more actions to:

• Respond to threats

• Escalate alerts

• Log or notify teams

Each action is like a step in a playbook, forming the response path.

1. Common Workflow Actions

Action Type	Description
Contain Host	Isolate the endpoint from the network while keeping Falcon connectivity
Add Host to Group	Move the host into a dynamic/static group to enforce new policies
Send Notification	Alert security teams via:
– Email
– Slack
– Webhook (to SIEM, SOAR, or internal platforms)
Create a Ticket	Open tickets automatically in systems like:
– Jira
– ServiceNow
Tag a Host	Add custom tags (e.g., Under_Investigation)
Send to Fusion Queue	Queue the alert for further action via another automation path
Send API Command	Call external APIs (e.g., initiate IR workflow in another tool)

2. Action Chaining

Multiple actions can be chained together. For example:

1. Detection occurs on a VIP laptop.

2. Falcon sends a Slack alert to IR team.

3. Falcon adds the host to “High Risk” group.

4. A policy in that group triggers host containment.

You can control this flow using Fusion Playbook logic, including conditions, delays, and branching.

3. Action Conditions and Timing

• Some actions are instantaneous (e.g., tag a host).

• Others allow delays (e.g., wait 10 minutes before containing).

• Conditional logic can stop an action if a specific check fails (e.g., if the host already has a “Contained” tag).

4. Real-World Example: Phishing Response Workflow

Step	Trigger/Action
1	Trigger: Detection from Office.exe with Severity = High
2	Action: Send email to security analyst
3	Action: Create Jira ticket
4	Action: Add tag Under_Review to host
5	Action: Delay 15 minutes
6	Conditional Action: If no review tag is removed, then contain the host

Best Practices for Actions

Tip	Why It Matters
Use conditional branching to avoid overreaction	Prevents false containment or alert spam
Include manual steps where needed	Gives analysts a chance to intervene before automation escalates
Document each action in your playbook	Improves visibility and post-incident reviews
Start with alerting-only workflows	Validate logic before deploying aggressive actions

3. Fusion Playbooks

What Is a Fusion Playbook?

A Fusion Playbook is the visual design interface for creating and managing workflows in Falcon Fusion. It allows you to build complex automated responses using:

• Triggers

• Conditions

• Actions

• Delays

• Branches

Fusion Playbooks are highly flexible and require no coding—ideal for security teams, analysts, and response engineers.

1. Interface Overview

Fusion Playbooks use a drag-and-drop editor:

• Each step (trigger, condition, or action) appears as a visual block.

• Arrows show the flow of logic.

• Branches can be used to direct the flow based on evaluation of conditions.

2. Playbook Components

Component	Function
Trigger Node	Starts the workflow based on detection, host, or tag change
Condition Node	Evaluates attributes (e.g., severity, host tag)
Action Node	Performs steps like notifications, containment, ticket creation
Delay Node	Adds a pause (e.g., 10 minutes before proceeding)
Branch Node	Splits workflow into “Yes/No” paths based on conditions

3. Example Playbook Flow

Goal: Auto-Isolate a Host After Critical Detection (Unless Already Investigated)

1. Trigger: Detection with Severity = Critical

2. Condition: Does host tag include Under_Review?

   • Yes → End playbook (no action)

   • No → Continue

3. Action: Send Slack message

4. Delay: Wait 15 minutes

5. Condition: Is detection still unreviewed?

   • Yes → Contain the host

   • No → End playbook

4. Playbook Reusability and Editing

• Playbooks can be saved, duplicated, or edited.

• You can assign different playbooks to different detection types or host groups.

• Versioning helps manage changes over time.

5. Role-Based Access and Visibility

• Not all users can create or modify playbooks.

• Roles must have Fusion Playbook permissions to:

  • Design workflows

  • Enable/disable automation

  • View execution logs

Best Practices:

Tip	Why It Helps
Start with templates or clones	Reduces setup errors
Use short, readable node names	Easier for team handoffs
Always simulate before enabling live	Prevents disruptive actions
Review and clean up unused branches	Keeps playbooks efficient

4. Use Cases

1. Automatically Isolate a Host After a Critical Detection

Scenario:

A device generates a detection marked Critical due to suspicious PowerShell activity.

Workflow Steps:

1. Trigger: Detection with Severity = Critical

2. Condition: Host group = Production

3. Action: Send Slack and email alert to SOC

4. Delay: Wait 10 minutes for analyst review

5. Condition: If still unreviewed

6. Action: Contain host from the network

Outcome:

• Threats are contained automatically if not reviewed promptly.

• SOC gets time to review but fallback containment prevents lateral spread.

2. Escalate Unreviewed Alerts to Jira or ServiceNow

Scenario:

Some alerts are being overlooked during overnight shifts.

Workflow Steps:

1. Trigger: Detection not reviewed within 60 minutes

2. Condition: Detection source = Custom IOA

3. Action: Create Jira/ServiceNow ticket

4. Action: Tag host as Needs_Review

Outcome:

• Detections become actionable tickets.

• Teams can track alert lifecycle more efficiently.

3. Enforce Quarantine Policy Based on Tag Change

Scenario:

An analyst tags a host as Compromised manually.

Workflow Steps:

1. Trigger: Host tag added = Compromised

2. Action: Move host to Quarantine Group

3. Action: Notify team lead via email

4. Action: Disable sensor update for the device (prevent instability during investigation)

Outcome:

• Tagging becomes a trigger for deeper automation.

• Analysts control escalation without needing to manually move hosts or send emails.

4. Monitor Sensor Health and Notify IT

Scenario:

You want to proactively handle failing or outdated sensors.

Workflow Steps:

1. Trigger: Sensor status changes to Unhealthy

2. Condition: Host not in Lab group

3. Action: Send alert to IT admin

4. Action: Add host to Sensor Repair group

Outcome:

• Ensures sensor coverage gaps are quickly addressed.

• Supports compliance by reducing blind spots.

5. Custom Alerting for VIP Devices

Scenario:

Executives’ devices require prioritized monitoring.

Workflow Steps:

1. Trigger: Detection on host with tag = VIP

2. Action: Notify CISO directly via SMS or email

3. Action: Add detection to “High Priority Queue”

4. Action: Contain if severity = Critical

Outcome:

• VIP threats are never missed.

• CISO and IR leads are immediately informed.

Summary of Use Cases:

Use Case	Primary Benefit
Auto-isolation	Prevents spread of malware or ransomware
Alert escalation	Ensures alerts don’t get lost
Quarantine policy	Standardizes response for high-risk hosts
Sensor monitoring	Improves system health and visibility
VIP alerting	Enhances protection for key personnel

5. Testing and Logging

1. Why Test Workflows?

Before enabling a new workflow:

• You want to ensure the logic works as intended.

• You need to prevent false containment, misrouted tickets, or missed alerts.

• Testing helps reduce unintended automation outcomes.

2. Simulating Workflow Execution

CrowdStrike provides a simulation feature within the Fusion Playbook editor.

How to Run a Test:

1. Open your playbook in the Fusion editor.

2. Click “Simulate Workflow” or “Test Playbook”.

3. Choose a sample event or define custom test parameters:

   • Severity: Critical

   • Host Group: Finance

   • Detection Source: Custom IOA

4. Run the test and observe:

   • Which branches are triggered

   • What actions are executed

   • Whether all conditions are met as expected

Simulations do not perform real actions (no host isolation, no emails sent). They show a preview of behavior.

3. Enabling Logging

Falcon automatically logs each workflow execution instance, including:

• Trigger time

• Input data

• Step-by-step status

• Failures or skipped actions

To view logs:

• Go to Fusion → Workflow Logs

• Filter by:

  • Playbook name

  • Time

  • Status (Success, Failure, Skipped)

4. Reviewing Execution Outcomes

Logs show:

• Which conditions passed or failed

• Which actions executed successfully

• API call results (success/failure with error codes)

This helps you:

• Identify logic errors (e.g., conditions that never pass)

• Verify delays and branching logic

• Monitor how often workflows run

5. Tuning Based on Logs

Common issues and fixes:

Issue	Fix
Actions skipped unexpectedly	Adjust condition logic or input data
Workflow runs too often	Add additional filters (e.g., severity, host group)
Emails sent to wrong users	Confirm notification settings
Containment delayed or missed	Review branching and delay placement

6. Versioning and Safe Deployment

• Clone playbooks before major changes.

• Label versions clearly (e.g., “PhishingResponse-v1.3-Test”).

• Roll out to test groups first, then expand to production.

Best Practices Summary:

Practice	Benefit
Simulate all new workflows	Avoid production disruptions
Use logs for audit and debugging	Increases visibility and safety
Regularly review active workflows	Prevents outdated logic from running
Document playbook logic and purpose	Supports handoffs and audits

Workflows (Additional Content)

Safe-by-default workflow design: reduce mean time to respond without increasing blast radius

Why this matters (exam lens)

Workflow questions often hide a safety test: can you automate response without creating a “runaway automation” that floods tickets, spams channels, or triggers disruptive actions broadly? Strong answers show staged automation: notify → create case → enrich → (optionally) gated response.

A workflow build pattern that consistently scores well

Use a four-layer structure:

• Trigger: define exactly what event starts the workflow (detection, health state change, policy change event).

• Scope gates: constrain by environment/host group, severity, and asset criticality.

• Action chain: order actions from low-risk to higher-risk (notify first, then ticket/case, then enrichment).

• Proof + rollback: define how you confirm it ran correctly and how you disable/adjust if it misfires.

Common safe first actions:

• Create a case/ticket with key fields populated (host, severity, timestamp, link/reference).

• Notify a team channel with a short summary and the ticket ID.

• Add enrichment fields (owner group, environment tag, last seen, current policy posture).

Exam traps

• Trap pattern: building a workflow that runs for “all detections” with no gating. Better: severity + host group + environment gates.

• Trap pattern: automating disruptive actions immediately. Better: notify + ticket first, then add stronger steps with explicit approval gating.