Shuffle Hands-on Labs¶

Choose the route that fits your available time and computing resources. Use the Interactive Lab to build and run a simple Wazuh alert-delivery workflow in this page, or use the Full Lab to build and validate a more advanced workflow in virtual machines.

Hands-on proof of concept

Build it. Test it. Recover it.

Start with a safe lab, build an observable suspicious-login workflow, require approval before containment, and prove that success, failure, and rollback are all recorded.

⏱ 4–6 hours◆ Beginner to intermediate✓ Evidence required

Start building

Self-hosted · Several hours

Shuffle Full Lab

Installation required

Keep response actions reversible

Use only a disposable training identity, the reserved address 203.0.113.66, and a lab-only blocklist. Require approval before containment and never use production credentials.

Objective¶

Install Shuffle, send a synthetic suspicious-login alert, enrich and record the event, require approval before a reversible block, and prove that invalid input, connector failure, duplicate delivery, and rollback are handled safely.

Minimum lab¶

Component	Minimum requirement	Purpose
Shuffle	One supported Linux VM with Docker Compose	Workflow editor, execution engine, and run history
Alert source	Supplied synthetic JSON or an isolated Wazuh instance	Sends a controlled suspicious-login event
Integrations	Mock HTTP endpoints or dedicated training accounts	Identity lookup, case record, notification, and temporary block
Test data	`lab-admin` and `203.0.113.66`	Reserved values that cannot target a real public system

Use mock endpoints for the guided baseline. Add Wazuh, TheHive, VirusTotal, or another product only after the baseline succeeds.

Starter alert¶

Save this as suspicious-login.json or send the same fields from your isolated alert source:

{
  "event_id": "CDK-SHUFFLE-001",
  "event_type": "suspicious_login",
  "user": "lab-admin",
  "source_ip": "203.0.113.66",
  "failed_attempts": 6,
  "successful_login": true,
  "confidence": 92,
  "environment": "training"
}

01

Activity 1: Build a safe automation lab¶

Install Shuffle using the online or offline journey.
Record the repository revision, image tags, container health, network boundaries, credentials, permissions, and clean snapshot.
Create a workflow named Suspicious Login Response and add a Webhook trigger.
Create mock or lab-only endpoints for identity enrichment, case creation, notification, temporary blocking, and unblocking.
Test every integration with a harmless read-only request before enabling a write action.
Run the unblock action independently and verify that it removes only the exact test entry.

Expected result Shuffle and every required integration are healthy, least-privilege access is recorded, and the response can be safely reversed.

02

Activity 2: Create and test the playbook¶

Build this visible node path:

1 Webhook→2 Validate→3 Enrich→4 Case lookup→5 Decide→6 Approve→7 Block & record

Map event_id, user, source_ip, confidence, and environment from the webhook body. Reject the event when any required field is missing.
Read the identity and address context from training data.
Search for an existing case using event_id as the idempotency key.
Create a case only when no matching case exists.
Close a low-confidence event with an explanation. Send a high-confidence event to the approval branch.
After approval, add only 203.0.113.66 to the lab blocklist with a ten-minute expiry.
Record the approver, action result, expiry, verification lookup, and rollback command in the case.
Run the starter alert and approve the temporary response.

Expected result The workflow pauses before containment, executes only after approval, records a time-bounded block, and preserves a complete audit trail.

03

Activity 3: Test failure and recovery¶

Run and record this test matrix:

Test	Change	Safe expected result
Positive	Use the complete starter alert with confidence `92`	Approval is requested; one temporary block and one case record are created
Invalid input	Remove `source_ip`	Workflow stops before enrichment or response and records the validation error
Low confidence	Set confidence to `12`	Enrichment is recorded, but containment is not requested
Connector failure	Disable the case endpoint after approval	The completed block is not repeated; an owner is notified and the record step can be resumed
Duplicate delivery	Send `CDK-SHUFFLE-001` again	The existing case is updated; no duplicate case or block is created
Rollback	Run the exact-entry unblock action	The address is absent from the blocklist and the recovery time is recorded

Export the workflow and retain the execution history for all six tests. Do not claim success from a green workflow alone—verify the case, blocklist, expiry, notification, and rollback result in their destination systems.

Expected result The workflow remains observable and safe under success, invalid input, low confidence, partial failure, duplicate delivery, and rollback.

Full Lab evidence checklist¶

This checklist applies to the VM-based Full Lab. If you completed the Interactive Lab, retain its downloaded evidence summary instead.

Build record, versions, network boundaries, credentials, permissions, and recovery point.
Workflow map with validation, enrichment, idempotency, decision, approval, action, and recording.
Approved positive run and verified temporary response result.
Invalid-input and low-confidence runs with no disruptive action.
Connector failure and duplicate-delivery evidence without repeated impact.
Rollback verification, exported workflow, and saved run histories.

0 of 6 recorded Mark each item after saving the evidence.

Clean up¶

Stop the webhook, revoke temporary credentials, remove the lab-only blocklist entry, delete disposable cases if appropriate, and revert the training systems to their clean recovery points. Retain the exported workflow, test matrix, execution histories, and conclusion as your lab record.