Golden-path demo — SSH brute-force, end to end

Source of truth: docs/demo-script.md (synced at build time — edit the original, not this copy). A click-by-click walkthrough of the suite’s closed loop: logs land in VectorFlow → a detection fires in Sigmatic → the alert escalates to a Warden case → a runbook runs to an approval gate → an approver approves → the case is closed with a disposition. It is the human companion to scripts/seed-demo.sh and e2e/golden-path.spec.ts.

Terminology used below is pinned in ../CONTEXT.md: Alert (Sigmatic detection output), Escalation (alert → case edge), Case (Warden’s response record), Runbook (Warden automation), Disposition (case close-reason), Severity (5-level security scale).

0. Prerequisites

• A suite with all three products, installed with veltro install (or make init && make up from a checkout), and the first admin signed in once. An install with fewer products doesn’t get this walkthrough: veltro demo seed seeds that install’s own datasets instead (sample-pipeline for VectorFlow, log-clearing for Sigmatic, case-walkthrough for Warden). See “Single-product installs” at the end.

• The admin’s login. The seed signs in as that admin and does everything below with its session, so it has to be a suite admin. Identity’s personal access tokens only reach the MCP tools, not the APIs the seed uses, so it takes the email and password:

  export VF_ADMIN_EMAIL=admin@example.com VF_ADMIN_PASSWORD=...
  veltro demo seed   # from a checkout: PYTHONPATH=cli python3 -m veltro_cli demo seed

  That’s all a fresh install needs. The seed sets up the rest itself:

  • Two demo logins, an analyst and an approver. It creates demo-analyst@example.test and demo-approver@example.test through identity’s invite flow, sets random passwords, and gives them their product roles. The logins are saved in .seed-demo-identities.env (mode 0600) in the install directory, and later runs reuse them. To use your own, export SEED_ANALYST_EMAIL, SEED_ANALYST_PASSWORD, SEED_APPROVER_EMAIL and SEED_APPROVER_PASSWORD. If one of those users already exists with a different password, the seed stops and says so.
  • A team called Demo, when VectorFlow has none. VectorFlow needs a team to hold the golden-path-demo environment.
  • The VectorFlow agent. When no environment has an enrolled agent, the seed starts the compose vf-agent (the same thing veltro agent enroll does), mints an enrollment token and waits for it to enrol.

  If anything it needs is missing and it can’t set it up, it stops at that step with one FAIL line that says what to do.

  veltro demo seed runs scripts/seed-demo.sh with COMPOSE_PROFILES set to the profiles veltro up starts. Run the script by hand and it stops unless COMPOSE_PROFILES is set in the environment or in .env.

  The seed is idempotent, so re-run it freely. It prints a SEED SUMMARY with the demo logins, the Sigmatic rule id, the runbook, and the Warden case key it created.

Runbook note. The scenario is SSH brute-force, but the approval-gated shipped runbook is suspicious-login-triage.yml (bruteforce-response.yml exists but ships without an approval step). The seed tags the detection authentication,login so that runbook triggers; with AbuseIPDB unconfigured its clean-IP branch parks on the approval gate deterministically.

1. VectorFlow — logs are shipping to detection

1. Open PUBLIC_BASE_URL/ → the Veltro launcher. Confirm each module shows separately measured readiness, dependency health, and running/pinned/latest version state. Any unavailable probe must remain visibly Unknown. In the seeded demo, the six stable required readiness facts — agent enrolled → pipeline deployed → Data Source configured → detection rule deployed → Warden intake configured → runbook enabled — are all complete.
2. Click VectorFlow. Open the seeded pipeline “SSH Auth Demo”: a demo auth-log source wired to a Sigmatic sink. This is the log path into detection.

2. Sigmatic — the detection fires

1. From the launcher (or the AppSwitcher) open Sigmatic.
2. Rules → the deployed rule “SSH Brute Force - Failed Login Threshold” (5 failed logins from one source.ip in 10 minutes). Status: Deployed.
3. Alerts → a new alert from the replayed batch (source 203.0.113.66), rendered with a medium Severity badge. Open it — the alert detail shows the matched log fields and, once Warden has the case, an Escalation link to the Warden case (seam 8: Sigmatic → Warden case link).

3. Warden — the case, the runbook, the approval

Sign in (or switch) as the analyst.

1. Cases → the escalated case (e.g. WARDEN-<n>) created from the Sigmatic alert. Open it: the Alerts tab lists the linked Sigmatic alert (seam 3). The Runs tab shows the triage runbook run, paused at an approval gate (seam 4).

Now switch to the approver.

2. Approvals inbox → one pending item (“Add a Sigmatic exception for known-good login source…”). Click Approve (seam 5). The run resumes and, a moment later, shows completed in the case’s Runs tab (seam 6).

4. Close the loop — the disposition ritual

Back as the analyst, on the case:

1. Move the case forward: New → Investigating → Resolved (only legal next states are offered — the A2 guarded transitions).
2. Click Close. The close dialog requires a Disposition — choose Resolved and add a note. Confirm (seam 7).
3. The case is now Closed with disposition Resolved, recorded on the timeline. The loop is closed: log → detection → escalation → response → approval → resolution.

5. Automated equivalent

The same walk, asserted:

export SEED_ANALYST_EMAIL SEED_ANALYST_PASSWORD SEED_APPROVER_EMAIL SEED_APPROVER_PASSWORD
npx playwright test e2e/golden-path.spec.ts

The spec authenticates both users over the suite credentials plane, walks all three zones, and hard-asserts each load-bearing seam (alert severity, escalated case + linked alert, approval gate, approve, run completion, disposition close).

Single-product installs

veltro demo list shows only the datasets whose products are all installed, and veltro demo seed with no --dataset seeds all of them when brute-force isn’t one. Each uses the same VF_ADMIN_EMAIL and VF_ADMIN_PASSWORD login and records its ids in .demo-datasets.json.

• VectorFlow only, sample-pipeline. The seed makes sure VectorFlow has a team, then picks the environment that has an enrolled agent. When none does, it creates the demo environment, starts the bundled vf-agent, writes an enrollment token where the agent reads it, and waits for it to enrol. It then deploys “Veltro sample pipeline” (Vector’s demo_logs source into a console sink) and waits until the agent reports it running with events out. Open Pipelines to see its throughput, and docker logs veltro-vf-agent to see the JSON lines it prints. Set SEED_VF_ENVIRONMENT_ID when more than one environment has an agent.
• Sigmatic only, log-clearing. The seed creates the Veltro demo: log-clearing push data source, deploys “Demo - Windows Security audit log cleared” and posts the events to it. Open Alerts for the alert.
• Warden only, case-walkthrough. The seed saves and enables the veltro-demo-case-walkthrough runbook, opens “Demo - Suspicious sign-in reported by a user” and runs the runbook on it. The case shows three triage tasks and a note, and its run shows as succeeded.

veltro demo reset undoes each one: it deletes the sample pipeline (the environment and agent stay), undeploys the Sigmatic rule and disables its data source, and closes the Warden case and disables the runbook. It prints what it keeps.