Quick Start
This page is the shortest supported path to a first DSP result.For the first run, use local execution and the normal profile. You do not need webshell mode or XDR API credentials to verify that DSP itself is working.
1. Check prerequisites
You need a Linux operator host with:- Python 3.11 or newer
gitandcurl- network reachability to the authorized target network
- an approved CIDR and test window
2. Install DSP
Run the bootstrap installer:$HOME/xdr-poc-script by default, clones or updates DSP, creates .venv, installs the package, and opens the operator menu. Existing configuration and run artifacts under ~/.dsp/ are preserved.
If the menu is not open, launch it with:
3. Configure the first run
Choose 2 — Configure environment and set only these values for the simplest test:
Leave webshell settings alone for the first run. They are only needed when traffic must originate from a remote host inside the customer environment.
4. Run
Choose 3 — Run scenario. For direct CLI use, activate the DSP virtual environment first:5. Review the result
The fastest check is 4 — Show latest report in the menu. Each run is also stored under:
Additional artifacts such as
events.db, events.jsonl, and validation.json are useful for deeper verification and troubleshooting.
What counts as success?
A successful DSP run means the activity-generation and evidence pipeline worked. It does not guarantee that the XDR/NDR product generated an alert. For the customer POC, verify the same time window, source/destination hosts, and scenario type in the XDR/NDR console, then record the matching alert or case identifiers in the evidence templates.Next steps
POC workflow
Turn a DSP run into a repeatable customer validation process.
Scenario coverage
See which activity types the current profile can generate.
Webshell mode
Use an authorized internal host as the execution origin when needed.
Reports & evidence
Understand the run artifacts and evidence chain.