version: "1.0.0" name: sdl-solutions author: Prithvi Moses <prithvi.moses@sentinelone.com> description: "Deploy packaged, repeatable SentinelOne Singularity Data Lake (SDL) solutions into a site from one prompt. Catalog: (1) data source onboarding (raw to OCSF, enrichment, dashboard, MITRE detections, threat response); (2) asset enrichment; (3) UEBA anomaly detection; (4) per-device ingest health; (5) detection exclusions; (6) Risk-Based Alerting; (7) Detection as Code (rules as TOML in Git, synced by CI); (8) alert noise reduction; (9) custom detections with MITRE mapping (watchdog alert carrying ATT&CK, since STAR rules cannot); (10) query slicing (long-window PowerQuery as parallel time slices, merged). Triggers: 'onboard a source', 'deploy UEBA/ingest health', 'add a detection exclusion', 'deploy RBA', 'detection as code', 'reduce alert noise', 'map my custom detection to MITRE', 'custom alerts have no MITRE', 'this query is slow', 'run this over 30 days'. NOT for one-off queries or standalone parser authoring."

SentinelOne SDL Solutions

<!-- CONFIG-FILE-ADDRESSING v1 -->

SDL config files: address by `udoId`, and do not trust a REST listing.

REST listFiles / getFile cannot see udoId-addressed /dashboards/ files, so getFile

returns 404 on a dashboard the console is displaying and the listing under-reports (measured on

one tenant: REST 8, GraphQL 17, console 48 files). **If a listing disagrees with what the UI

shows, the listing is wrong until proven otherwise**, change read path before concluding the

object is missing or the token lacks scope. Use the GraphQL configFiles / configFile surface.

A name-addressed addConfigFile to /dashboards/ creates a duplicate instead of updating;

address dashboards by udoId with expectedVersion. content is HJSON, not JSON. S1-Scope

changes which files exist as far as the caller can tell.

Full detail: `sdl-api/references/config-file-graphql.md`

This skill packages repeatable SDL solutions and deploys them into a specific customer environment from a short set of prompts. It is an orchestration layer: it does not reimplement PowerQuery, parser, SDL API, or Hyperautomation mechanics. Instead it collects the customer parameters, renders the solution's templates, previews the result, deploys through the primitive skills, and validates.

Use this skill when the user wants to deploy or tailor a whole solution. For a single query, parser, dashboard, or workflow, use the matching primitive skill directly.

Solution catalog

More solutions are added under references/<solution>.md plus templates under assets/. See "Adding a new solution" below.

How a deployment runs (always follow this loop)

1. Pick the solution. If the user named it, use it. Otherwise show the catalog and ask which one.
2. Collect parameters with simple prompts. Ask only what the playbook needs, one compact question set, with sensible defaults pre-filled. Never start deploying before parameters are confirmed. Each playbook lists its parameters and defaults.
3. Confirm the environment. Resolve the target site name to a siteId (fuzzy match, console site names can contain spaces). Confirm the console/tenant. Read existing config versions before any overwrite.
4. Render and preview. Fill the templates in assets/ with the parameters and show the user the final config (queries, parser, workflow) and the projected enriched record BEFORE deploying. This is a dry run.
5. Deploy in dependency order through the primitive skills (see each playbook for the exact order). Typical order: build lookup tables, then parser or lookup guidance, then refresh flow.
6. Validate with a real ingest and query, and report what populated. Use metadata.version as the propagation canary for parser changes.
7. Test end to end with run-now, then prompt the user. For any solution with HA flows, trigger each flow immediately with POST /web/api/v2.1/hyper-automate/api/public/workflow-execution/manual/{id}/{version}?accountIds=<acct> (works on scheduled-trigger flows once active), poll GET .../workflow-execution/{exec_id} until state is Completed with error_actions: [] and executed_actions == the action count, and confirm the downstream effect (tables written, dashboard renders, a detection alert present). An import is NOT complete until the flow is published to a Shared Draft: treat ha_import_workflow and publish as ONE atomic step, publish in the SAME step as the import, never as a follow-up. Imported flows land as PRIVATE DRAFTS owned by the API token's user (invisible in the console to the person who asked), so IMMEDIATELY after each ha_import_workflow publish it to a Shared Draft: POST /web/api/v2.1/hyper-automate/api/v1/workflows/{id}/publish?siteIds=<id> (bodyless {}, returns 204; use accountIds=<acct> for account-scoped flows). A published flow stays inactive until its connection is bound and it is activated, so always end a deployment by prompting the user to bind/activate and run this E2E check (offer to run it for them once active).
8. Summarize the deployed artifacts (paths, IDs, site) and hand off the rendered config files.

Prove a detection by its alert, not by a query match. Ingest a positive and a negative case per detection with principals unique to the run, add the run tag to the rule's initial filter, and assert the positive appears and the negative does not. Then deploy and wait for the UAM alert: it lands about 8 minutes after detectedAt, and scheduled rules evaluate on staggered offsets within their interval. Read UAM unfiltered and narrow client-side (a server-side filter the API accepts and ignores reads as zero alerts). A rule created but left as Draft never alerts while the create call still succeeds, so read each rule's status (and statusReason) after deploy and report any that are not Active. In the NZISM deployer this caught one rule missing its key command at query level and 21 of 26 rules left as Draft at alert level, both invisible to a query-only test (reference implementation: tools/nzism_detection_harness.py in the s1-nzism-deployer repo, not shipped with this plugin).

Read-only mode. From 1.5.5, s1-secops-mcp is read-only by default (S1_READ_ONLY unset or true), and step 5 writes through sdl_put_file, sdl_create_dashboard, ha_import_workflow, hec_ingest, powerquery_run with | savelookup, and s1_api_post (rules, publish, run-now). Check the mode at step 3, before you render or deploy anything: read mode.readOnly from the sentinelone://credentials-status resource, or the server's initialize instructions. A half-built deployment is worse than none.

• If a write tool returns "s1-secops-mcp is in read-only mode (S1_READ_ONLY).", stop. Do not retry, and do not route around it with another tool (s1_api_post to a different endpoint, purple-mcp powerquery with | savelookup, a hand-built GraphQL mutation).
• Tell the user which action was refused and how to enable write: Docker launcher s1-secops-mcp-launch.sh install --read-write (Windows -ReadWrite), then restart Claude Desktop; .mcpb extension: turn off "Read-only mode (recommended)"; Node install: "S1_READ_ONLY": "false" in the server's env block. Detail: docs/read-only.md in the source repo (not shipped).
• Offer every rendered artifact (parser, lookup CSV, dashboard JSON, workflow JSON, rule body) as a local file via outputFile or the Write tool so nothing is lost.
• Never enable write on the user's behalf by editing their MCP client config.

Keep prompts simple and few. Prefer defaults the user can accept with one word over long forms.

Dependencies (load as needed)

This skill orchestrates the SentinelOne primitive skills. Load the ones a playbook calls for. Every tenant call goes through the s1-secops-mcp MCP tools, which run on the user's machine and read credentials from environment variables or the OS keychain; the Cowork sandbox cannot reach *.sentinelone.net, so Python scripts that call the tenant are host-only (Claude Code or a terminal). If a tool reports a missing credential, ask the user to run s1-secops-mcp setup.

• powerquery for datasource + savelookup queries, run with powerquery_run. The references/datasource-command.md there is the source of truth for the assets datasource.
• sdl-api (or the s1-secops-mcp tools sdl_put_file, sdl_get_file, hec_ingest) to deploy config files and ingest test data. Config-file writes use the console API token; hec_ingest needs an SDL Log Write Key in S1_HEC_TOKEN instead, and because that key is minted for one account or site it also fixes where test data lands, which no scope argument overrides.
• sdl-log-parser for parser authoring and the computeFields lookup pattern.
• hyperautomation for the scheduled refresh workflow.
• mgmt-console-api (or s1-secops-mcp s1_api_*) for site lookup and scoped workflow import / activate / deactivate.

Conventions

• Naming prefix. Every artifact a deployment creates is prefixed with a customer or solution code so multiple deployments coexist cleanly: tables <prefix>IdentityLookup / <prefix>EndpointLookup, parser <prefix>_enrich, workflow <prefix> Asset Lookups.
• Scope by site. Deploy to the customer's site. Resolve the name to a siteId and pass it on every scoped call. The HA import, activation, and deactivation all require the scope parameter.
• Empty suppression. Inventory empties (for example riskFactors as the string "[]") are converted to null in the savelookup so enrichment never writes an empty field.
• Preview before deploy. Always show rendered config and an example enriched record first.
• Idempotence. Read the current version of any SDL config file before overwriting, and pass it as the expected version. Hyperautomation import always creates a new workflow, so to update one, replace it rather than re-import blindly.
• Dashboards: create by name once, update by udoId. Only /dashboards/ files carry a udoId; everything else (/lookups/, /datatables/, /logParsers/, /automaticLookups) is name-addressed. A name-addressed write to an existing dashboard creates a duplicate instead of updating it, so record the udoId returned by the initial create and address the dashboard by udoId on every later write. Solutions are re-runnable, so a name-addressed re-deploy silently doubles the dashboard on each run.
• Asset mapping is built in. Any parser or detection a solution creates must carry the minimum attributes that let an alert bind its Target Asset, so alerts are not "Unknown Device". The endpoint lookup captures device_agentid (the numeric console agent id); the parser stamps device.uid = device_agentid plus an endpoint class_uid; and scheduled detections set entityMappings on the device identity columns (device_host / device_agentid / device_agentuuid). Binding reconciles device.uid against the live Asset Inventory, so a real enrolled agent id is required (a fabricated id stays Unknown Device). The tested binding matrix and the minimum set live in powerquery/references/detection-rules.md.

Reference files

• references/data-source-onboarding.md - the onboarding playbook: the one-line-prompt UX, the parser-attribute editability rule for locating a source, parser create/update to OCSF plus asset enrichment, the 5-minute propagation wait, the parallel dashboard and MITRE-mapped detection build with asset-context columns, and the Hyperautomation SOC threat-response playbook (alert-triggered, VirusTotal-gated containment) with the single deploy-location question. Read this when onboarding a new data source.
• references/asset-enrichment.md - the asset enrichment playbook: parameters and defaults, the deployment-mode prompt (ingest-time parser vs query-time lookup vs automatic lookup; ingest-time requires the parser deployed in AI SIEM), the savelookup table builders, the parser, the validation steps, the Hyperautomation refresh flow, and the gotchas. Read this when deploying or tailoring asset enrichment.
• references/custom-detection-mitre-mapping.md - the custom-detection MITRE playbook: the rule-spec format, rendering with scripts/render_mitre_watchdog.py (or --from-rule to convert a scheduled STAR rule), the import / publish / activate / run-now order, validation queries, and gotchas (finding_info.attacks is ignored, tactic ids not names, one alert per run, no suppression). Read this when a custom detection needs a queryable MITRE ATT&CK mapping.
• references/query-slicing.md - the query slicing playbook: measured LRQ limits and slicing timings, defaults per window, which aggregates merge (count / sum / min / max) and which do not (estimate_distinct, avg, percentiles, top K), running it with powerquery_run (slices + merge) or the host-only scripts/lrq_sliced.py, validation and gotchas. Read this before writing any multi-day query loop, report collector or baseline builder.
• references/detection-as-code.md - the Detection-as-Code playbook: the one-line-prompt UX, prerequisites (Git repo, CI engine, API-token secret), scaffolding the starter repo, the manual repo controls (branch protection, RBAC, CODEOWNERS), wiring lint-on-PR and sync-on-merge CI for GitHub/GitLab/Azure, the TOML rule format for all three rule types (events, correlation, scheduled), the dry-run-then-deploy flow with idempotent create-or-update, the monitor-and-refine loop, and the confirmed Custom Detection API gotchas. Read this when setting up detection as code or automating detection-rule sync from Git.

Templates

assets/ holds the parameterized templates a playbook renders. Tokens use {{NAME}}:

• assets/savelookup_identity.pq - identity lookup table builder
• assets/savelookup_endpoint.pq - endpoint lookup table builder
• assets/parser.template.json - the enrichment parser
• assets/refresh_workflow.template.json - the Hyperautomation refresh workflow
• assets/onboarding_detection.template.json - STAR scheduled PowerQuery detection-rule envelope (onboarding)
• assets/threat_response_workflow.template.json - Hyperautomation SOC threat-response playbook (alert trigger to VirusTotal enrich to VT-gated containment: IOC block + endpoint quarantine, then note + notify) for an onboarded source's detections
• assets/onboarding_dashboard.template.json - starter tabbed dashboard skeleton for an onboarded source
• assets/exclusion_list_assets.csv.template - asset exclusion list (IP / CIDR, keyed cidr =:cidr <ip field>)
• assets/exclusion_list_custom.csv.template - custom-value exclusion list (domain / user / value, keyed value =:anycase <field>)
• assets/exclusion_detection_single_event.template.json - STAR single-event rule (queryType: events) with the exclusion as an inline hardcoded AND NOT (<field> in:anycase (...)) negative list in data.s1ql (no lookup, no dashboard; double backslashes in the JSON so the engine receives one)
• assets/exclusion_detection_correlation.template.json - STAR correlation rule (queryType: correlation, queryLang: 2.0, s1ql empty) with the exclusion as an inline hardcoded AND NOT (<field> in:anycase (...)) negative list appended to each sub-query in data.correlationParams (no lookup, no dashboard; same backslash doubling; tenant-validated 2026-07-01)
• assets/exclusion_detection.template.json - STAR scheduled PowerQuery rule wrapping a base detection with the lookup anti-join (chain multiple lists with distinct excl_* join vars)
• assets/exclusion_dashboard.template.json - exclusion-effectiveness dashboard (excluded vs kept, over time, by list / reason / value, plus a post-exclusion threat tab)
• assets/exclusion_refresh_workflow.template.json - optional nightly rebuild of a source-of-truth (savelookup) exclusion list
• assets/rba_contributors.json - RBA risk model: contributor definitions (noisy observations to score, each with base score + MITRE tag + risk-object/threat-object fields)
• assets/rba_risk_factors.csv.template - RBA per-object risk-factor multipliers (the Risk Factor Editor), built from the Asset Inventory plus hand-edited overrides
• assets/rba_collector.workflow.template.json - RBA scheduled HA collector: sync SDL PowerQuery to MAP_TABLE to JQ NDJSON to publish into the risk index (deploy as Shared Draft, prompt to bind 'SentinelOne SDL', then activate)
• assets/rba_incident_cumulative_score.template.json - RBA STAR scheduled incident rule: 24h cumulative risk score per object >= threshold (render per user / host)
• assets/rba_incident_multitactic.template.json - RBA STAR scheduled incident rule: 7d distinct MITRE tactics per object >= threshold (render per user / host)
• assets/rba_dashboard.template.json - RBA dashboard (risk leaderboard, score over time, MITRE / contributor / threat-object breakdowns, contributing-events timeline)
• assets/rba_risk_register.savelookup.pq - OPTIONAL persisted decayed risk register (daily savelookup; complements, does not replace, the windowed incident rules; tokens {{PREFIX}}, {{DECAY}})
• assets/rba_console/ - OPTIONAL local demo console: a zero-dependency Python proxy (server.py) + a 4-tab HTML UI (index.html) for live demos (talk track, deployed artefacts, live leaderboard, read/write risk-factor editor). Reads S1_CONSOLE_URL / S1_CONSOLE_API_TOKEN from the environment or the OS keychain on the presenter's laptop; render {{ACCOUNT_NAME}}/{{ACCOUNT_ID}}/{{PREFIX}}/{{RULE_*_ID}} tokens. See assets/rba_console/README.md
• assets/mitre_watchdog.workflow.template.json - custom detection with MITRE mapping: scheduled HA watchdog (LRQ launch, poll, summarise, POST one S1 Security Alert with attacks[] on the inline indicator). Render it with scripts/render_mitre_watchdog.py, never by hand: the PowerQuery is escaped twice. Tokens {{PREFIX}}, {{RULE_NAME}}, {{RULE_DESCRIPTION}}, {{PRODUCT_NAME}}, {{PQ_QUERY}}, {{LOOKBACK_HOURS}}, {{INTERVAL_MINUTES}}, {{SEVERITY_ID}}, {{MITRE_ATTACKS_JSON}}, {{HEC_URL}}, {{ACCOUNT_ID}}, {{SITE_ID}}, {{SDL_INTEGRATION_ID}}
• assets/mitre_rule_specs/ - example rule specs for the MITRE solution: encoded_powershell.json, windows_bruteforce.json, e2e_probe.json (synthetic end-to-end test)
• assets/ha_watchdog.workflow.template.json - the generic HA watchdog (no MITRE); see powerquery/references/detection-rules.md
• assets/detection-as-code-starter/ - the whole Detection-as-Code repo scaffold (rendered into the user's Git repo, not a single tokenized file): scripts/dac_sync.py (zero-dependency TOML-to-API validate + convert + idempotent create-or-update engine), scripts/dac_lint.py (local lint / pre-commit), rule.schema.json (editor validation), detections/{endpoint,identity,cloud}/*.toml (working examples of the single-event, correlation, and scheduled rule types), .github/workflows/{lint,sync}.yml + .github/CODEOWNERS, and ci/gitlab/.gitlab-ci.yml + ci/azure/azure-pipelines.yml. Render the [scope] site and CODEOWNERS handles per customer. See references/detection-as-code.md.

Common tokens: {{PREFIX}}, {{IDENTITY_TABLE}}, {{ENDPOINT_TABLE}}, {{PARSER_NAME}}, {{DATASOURCE_NAME}}, {{VENDOR}}, {{HOSTNAME_FIELD}}, {{USERNAME_FIELD}}, {{USERNAME_KEY}} (samAccountName or principalName), {{SCHEDULE_HOUR}}, {{SITE_ID}}, {{CONSOLE_HOST}}, {{ENDPOINT_CLASS_UID}} (OCSF class for the parser's class_uid; default 1007, must be an endpoint class 1xxx for events-rule asset auto-binding). Onboarding tokens: {{DETECTION_NAME}}, {{DETECTION_DESCRIPTION}}, {{MITRE_TACTIC}}, {{MITRE_TECHNIQUE}}, {{SEVERITY}}, {{PQ_BODY_ENDING_WITH_COLUMNS_PROJECTION}}, {{RENOTIFY_MINUTES}}, {{ENTITY_COL_1}}, {{ENTITY_COL_2}}, {{ENTITY_COL_3}} (entityMappings is capped at 3), {{SCOPE_KEY}} (accountIds/siteIds; MUST be accountIds for any detection rule whose PQ body reads a lookup table or datatable, because lookups/datatables are account-level objects and site-scoped creation of lookup-reading rules is invalid), {{SCOPE_ID}}, {{IP_SRC_FIELD}}, {{IP_DST_FIELD}}, {{PORT_FIELD}}, {{ACTION_FIELD}}, {{USER_FIELD}}, {{SOURCE_LABEL}}, {{ACCOUNT_ID}}, {{NOTIFY_WEBHOOK_URL}}, {{IOC_TTL_HOURS_NEG}}. The VirusTotal step uses the packaged VirusTotal integration action, so the API key lives in a Hyperautomation VirusTotal connection, never in the workflow JSON.

Adding a new solution

1. Write references/<solution>.md as a self-contained playbook: parameters with defaults, render steps, deploy order through the primitives, validation, gotchas.
2. Add the rendered templates to assets/.
3. Add a row to the Solution catalog table above and name the new solution in this skill's frontmatter description so it triggers.
4. Keep each solution self-contained so the router can branch cleanly.