Automated Incident Response

Objective

In this lesson you will configure automated incident response workflows that tie the security cloud, XDR, and firewall controls together. You will create playbooks (orchestration workflows) that run automatically when XDR raises a high-severity alert: the system will create a ticket in the ticketing system, gather contextual data, and push a quarantine action to the firewall. Automating these steps reduces mean-time-to-contain in production networks and limits lateral movement during an active compromise.

Real-world scenario: a detected lateral-movement indicator in XDR should immediately trigger both a service ticket for the SOC and an automated quarantine so the potentially compromised host is isolated while analysts investigate.

Quick Recap

Use the same topology and devices from Lesson 1. This lesson does not add new devices or IP addresses; it focuses on configuration inside the security cloud/XDR plus the existing perimeter firewall from earlier lessons.

Tip: If you completed Lesson 1, you already have the firewall registered in the security cloud and XDR telemetry flowing from endpoints. This lesson links those existing integrations into an automated playbook.

Key Concepts

• Playbooks / Orchestration: Playbooks are ordered workflows that execute response actions (create ticket, collect artifacts, call firewall action). Think of a playbook like a recipe: each step is a task that either gathers information or changes state. In production, playbooks reduce manual steps and human error during an incident.

• Event-driven Triggers: XDR generates alerts; an event rule matches criteria (e.g., severity=High, TTP=credential-theft) and triggers a playbook. At the protocol level this is an internal publish/subscribe: the XDR publishes an alert event; the orchestration engine subscribes and executes the workflow.

• API-driven Enforcement: Quarantine actions against a firewall are executed via API calls (or via the firewall's orchestration connector). In production this requires service accounts and least-privilege API keys so automation can act with a defined scope.

• Ticketing Integration: Creating a ticket is a synchronous API operation: the playbook sends alert details to the ticketing system and receives a ticket number. Use integrations for case-tracking and auditability.

• Idempotence & Safety: Playbooks must be safe to run multiple times (idempotent) and include checks to avoid unnecessary disruption (for example, only quarantine when host is known to be on a protected subnet).

Step-by-step configuration

Step 1: Enable Ticketing Integration with CX

What we are doing: Configure the security cloud to create and modify tickets in the CX ticketing system when a playbook requests it. This is important so that automated responses generate a tracked incident for SOC analysts.

# Enter cloud orchestration configuration context
scc-cli login --org NHPREP --user admin@lab.nhprep.com --password Lab@123

# Configure ticketing connector for CX
scc-cli connector ticketing create --name CX-Ticketing \
  --type cx --api-url https://api.cx.lab.nhprep.com --api-key ZXhhbXBsZWFwaWtleQ==

# Enable ticketing for orchestration engine
scc-cli orchestration settings set --ticketing-connector CX-Ticketing

# Exit
scc-cli logout

What just happened: The first command authenticates to the security cloud orchestration CLI using the organization NHPREP and the provided credentials. The connector creation registers a ticketing integration named CX-Ticketing with the CX API endpoint and API key (kept as a base64 placeholder here); this allows the orchestration engine to create/modify tickets. The orchestration settings command tells the engine which connector to use as the default for ticket creation.

Real-world note: In production, use a secure vault for API keys, restrict the API key to only the ticket actions needed, and rotate keys regularly.

Verify:

scc-cli connector ticketing show --name CX-Ticketing

Connector Name: CX-Ticketing
Type: cx
API URL: https://api.cx.lab.nhprep.com
Status: Connected
Last Test: 2026-03-30T14:22:11Z

Step 2: Create a Firewall Quarantine Action (Orchestration Connector)

What we are doing: Register the firewall orchestration connector so the playbook can request enforcement actions (host quarantine). This step matters because enforcement requires authenticated API access to the firewall.

scc-cli connector firewall create --name Perimeter-FW \
  --type firewall --vendor cisco --host 203.0.113.5 --api-user automation --api-key S3cr3tAPIKey

scc-cli connector firewall test --name Perimeter-FW

What just happened: The connector creation registers a firewall endpoint named Perimeter-FW with host 203.0.113.5 and credentials for API calls. The test command performs a connectivity and authentication test so the orchestration engine knows it can talk to the firewall. The orchestration engine will use this connector to issue quarantine/disconnect commands during playbook execution.

Real-world note: Only give the automation account minimal privileges (for example, a role that can create an access-list and apply it to a specific interface) to reduce blast radius.

Verify:

scc-cli connector firewall show --name Perimeter-FW

Connector Name: Perimeter-FW
Type: firewall
Vendor: cisco
Host: 203.0.113.5
Status: Ready
Last Test: 2026-03-30T14:24:45Z

Step 3: Build the Playbook — Ticket + Context Collection

What we are doing: Create an orchestration playbook that first creates a ticket, then gathers endpoint context (process list, network connections) from XDR. These telemetry-gathering steps give analysts the necessary evidence to triage.

scc-cli playbook create --name Quarantine-and-Ticket \
  --description "Create CX ticket, collect host context, then call firewall quarantine"

# Add step 1: Create ticket
scc-cli playbook step add --playbook Quarantine-and-Ticket --name CreateTicket \
  --action ticket:create --connector CX-Ticketing --params '{"title":"Automated XDR High Alert - {{alert.id}}","priority":"High"}'

# Add step 2: Gather endpoint context
scc-cli playbook step add --playbook Quarantine-and-Ticket --name CollectContext \
  --action xdr:collect --params '{"host_ip":"{{alert.host.ip}}","artifacts":["process_list","network_connections","recent_events"]}'

What just happened: The playbook Quarantine-and-Ticket was created with two steps. The first step instructs the system to create a CX ticket using the CX-Ticketing connector and populates the ticket title with the alert ID. The second step invokes XDR's collection capability to retrieve telemetry for the host IP referenced in the alert (process list, network connections, recent events). These steps are crucial for documentation and evidence capture before enforcement.

Real-world note: Collecting context before enforcement preserves evidence; in some legal contexts, immediate quarantine without artifact collection can hinder forensic analysis.

Verify:

scc-cli playbook show --name Quarantine-and-Ticket

Playbook Name: Quarantine-and-Ticket
Description: Create CX ticket, collect host context, then call firewall quarantine
Steps:
  1) CreateTicket - ticket:create via CX-Ticketing
  2) CollectContext - xdr:collect (process_list, network_connections, recent_events)
Status: Active

Step 4: Add Conditional Firewall Quarantine Step

What we are doing: Add a decision step that only quarantines the host if XDR confirms the alert is High severity and the host is in a protected subnet. This prevents unnecessary disruption and ensures safe enforcement.

# Add decision step
scc-cli playbook step add --playbook Quarantine-and-Ticket --name DecideQuarantine \
  --action decision --params '{"condition":"{{alert.severity}} == \"High\" AND {{host.network}} == \"Protected\"","true_next":"QuarantineHost","false_next":"End"}'

# Add quarantine step
scc-cli playbook step add --playbook Quarantine-and-Ticket --name QuarantineHost \
  --action firewall:quarantine --connector Perimeter-FW --params '{"target_ip":"{{alert.host.ip}}","mode":"isolate","duration_minutes":60}'

# Add end step
scc-cli playbook step add --playbook Quarantine-and-Ticket --name End --action noop

What just happened: The DecideQuarantine step evaluates the alert severity and the host's network membership. If conditions are met, the flow continues to QuarantineHost; otherwise it ends. The QuarantineHost step calls the Perimeter-FW connector to isolate the target IP for 60 minutes. The noop End step provides an explicit end of workflow.

Real-world note: Use clearly defined conditions and whitelist management to avoid quarantining critical infrastructure systems by mistake.

Verify:

scc-cli playbook show --name Quarantine-and-Ticket --full

Playbook Name: Quarantine-and-Ticket
Steps:
  1) CreateTicket - ticket:create via CX-Ticketing
  2) CollectContext - xdr:collect (process_list, network_connections, recent_events)
  3) DecideQuarantine - decision (condition: (alert.severity == "High" AND host.network == "Protected"))
  4) QuarantineHost - firewall:quarantine via Perimeter-FW (target_ip, mode=isolate, duration_minutes=60)
  5) End - noop
Status: Active

Step 5: Configure XDR Alert-to-Playbook Trigger

What we are doing: Create an alert rule in XDR that triggers the playbook when a High severity alert with specific TTPs is generated. This links detection to response automatically.

scc-cli xdr rule create --name High-Lateral-Movement \
  --condition '{"severity":"High","ttp":"LateralMovement"}' \
  --action playbook:execute --playbook Quarantine-and-Ticket

scc-cli xdr rule enable --name High-Lateral-Movement

What just happened: An XDR rule called High-Lateral-Movement was created: when an alert matches severity=High and the TTP equals LateralMovement, the Quarantine-and-Ticket playbook is executed. Enabling the rule activates detection-to-response automation.

Real-world note: Keep detection rules tight and test in a staging environment before enabling in production to reduce false-positive automated enforcement.

Verify:

scc-cli xdr rule show --name High-Lateral-Movement

Rule Name: High-Lateral-Movement
Condition: severity == High AND ttp == LateralMovement
Action: playbook:execute -> Quarantine-and-Ticket
Status: Enabled
Last Fired: None

Step 6: Test the Playbook (Simulate Alert)

What we are doing: Simulate an XDR alert that matches the rule to verify the entire chain: ticket creation, context collection, and firewall quarantine.

# Simulate alert event
scc-cli xdr alert simulate --id test-alert-001 --severity High --ttp LateralMovement --host-ip 10.10.10.15 --host-network Protected

# Check playbook execution history
scc-cli playbook execution show --playbook Quarantine-and-Ticket --last 1

What just happened: The XDR simulate command publishes an alert that matches the rule and should immediately start the playbook. The execution show command returns the run details so you can confirm each step's status (success/failure), ticket number, and firewall action response.

Real-world note: Always test automation in an isolated lab before enabling it against production endpoints; use non-prod host IPs and short quarantine durations for tests.

Verify:

scc-cli playbook execution show --playbook Quarantine-and-Ticket --last 1

Execution ID: exec-20260330-0001
Started: 2026-03-30T14:40:12Z
Status: Completed
Steps:
  1) CreateTicket - Completed - Ticket ID: CX-2026-4578
  2) CollectContext - Completed - Artifacts: /artifacts/exec-20260330-0001/context.json
  3) DecideQuarantine - Completed - Decision: True
  4) QuarantineHost - Completed - Firewall Response: Applied access-list QUARANTINE_10.10.10.15 to interface GigabitEthernet0/1
  5) End - Completed

Verification Checklist

• Check 1: Ticket created — verify with ticketing connector show or ticketing system UI that CX-2026-4578 exists and contains the alert details.

  • How to verify: scc-cli connector ticketing ticket show --connector CX-Ticketing --ticket-id CX-2026-4578 (expected: ticket details and status Open)

• Check 2: Context artifacts stored — verify that artifact path exists and contains process list and network connections.

  • How to verify: scc-cli artifacts fetch --path /artifacts/exec-20260330-0001/context.json (expected: JSON containing process_list and network_connections arrays)

• Check 3: Firewall quarantine applied — verify firewall shows an access list or host object blocking the target IP.

  • How to verify: On the firewall, confirm the applied quarantine object (expected: access-list QUARANTINE_10.10.10.15 permit host 10.10.10.15 any and interface has service-policy input QUARANTINE_10.10.10.15)

Common Mistakes

Symptom	Cause	Fix
Playbook fails at ticket creation	Ticketing connector misconfigured or API key invalid	Re-run connector test and update API key; verify connector status Status: Connected
Playbook proceeds to quarantine all hosts	Decision condition too broad or missing network check	Tighten decision condition to include host.network == "Protected" and add allowlist for critical hosts
Firewall quarantine step fails with authentication error	Perimeter-FW connector credentials incorrect or lacking permissions	Update connector with correct API user and key; grant only required enforcement privileges
No playbook execution on simulated alert	XDR rule not enabled or condition mismatched	Verify rule is Enabled and condition uses correct severity and TTP values (severity == High AND ttp == LateralMovement)

Key Takeaways

• Playbooks automate repetitive SOC tasks (ticket creation, evidence collection, enforcement) and drastically reduce time-to-contain in production incidents.
• Always collect context/artifacts before enforcement to preserve forensic evidence and support incident response.
• Use conditional logic in playbooks to prevent unnecessary disruption — only quarantine when clearly required.
• Test playbooks thoroughly in lab/staging, use least-privilege connectors, and maintain auditable logs for every automated action.

Important: Automation is powerful but not infallible. Combine automated enforcement with human review workflows (e.g., automatic ticket assignment to SOC analyst) to balance speed and accuracy.