> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cantina.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# SentinelOne

> Forward Singularity Endpoint threat detections from SentinelOne into Clarion as alerts.

This guide explains how to connect SentinelOne to Clarion. Once configured, every threat SentinelOne raises on your chosen site becomes a Clarion alert that agents can triage, investigate, and link to incidents.

> **Note:** **Estimated time:** 10-15 minutes. You will need **Site Admin** (or higher) access in SentinelOne, plus access to the Clarion workspace where you want to connect SentinelOne.

## What you'll configure

Connecting SentinelOne takes three things:

| What                             | Purpose                                                                                                                                                                                                      |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Clarion webhook URL + secret** | SentinelOne posts threats to this URL. The secret, sent as the `x-webhook-secret` header, authenticates them. Both are generated when you click **Connect**.                                                 |
| **SentinelOne API token**        | A Service User token with the **SOC role** that lets Clarion enrich each alert with the full threat details and run response actions (mitigate, isolate, set verdict/status). Without it, alerts are sparse. |
| **Console URL**                  | Your tenant URL, used for the "View in SentinelOne console" deep link on alerts.                                                                                                                             |

## Prerequisites

* A SentinelOne console with at least one Linux, macOS, or Windows agent enrolled
* An admin role on the SentinelOne account or site you want to forward
* Access to the Clarion workspace where you want to configure the integration

## Step 1 - Connect SentinelOne in Clarion

1. Open Clarion and go to **Integrations** → **SentinelOne**.
2. Click **Connect**. Clarion generates the webhook URL and a webhook secret for this workspace.
3. **Copy the webhook URL and secret immediately.** The secret is shown only once; if you lose it you'll have to disconnect and reconnect to generate a new one.

Keep these on your clipboard or paste them into a password manager - you'll need them in steps 3 and 4.

## Step 2 - Create a SentinelOne Service User (SOC role)

You can use a personal API token (tied to your user) for testing, but for the actual integration we recommend a dedicated **Service User** so the token survives if the original creator's account changes.

1. In the SentinelOne console: **Policies and settings → User management → Service Users**.
2. Click **+ New Service User**.
3. Fill in:
   * **Name:** `clarion-integration`
   * **Description:** `Used by Clarion to enrich and action threats.`
   * **Scope:** prefer **Site** (the specific site you're forwarding from) over Account - least privilege.
   * **Role:** **SOC**. This grants both read and edit access on Threats, so Clarion can enrich alerts *and* run response actions (mitigate, isolate, set verdict/status). A custom role with equivalent Threats read/edit access also works. A read-only role (e.g. Viewer) only enriches alerts and cannot action threats.
   * **Expiration:** set to 1 year; rotate annually.
4. Save → the console shows the **API Token** once. Copy it immediately.

## Step 3 - Paste console URL and API token into Clarion

Back on Clarion's SentinelOne configure page, fill in **Console details**:

* **Console URL** - your tenant URL, e.g. `https://your-tenant.sentinelone.net`. No trailing slash.
* **Site ID / Account ID** - optional; populated automatically once the first real threat lands but you can pre-fill them if you have them.
* **API token** - paste the token from step 2.

Click **Save**. The page will show `API token (stored — leave blank to keep)` next to the field on subsequent visits, confirming the token is set.

## Step 4 - Configure the SentinelOne side

SentinelOne sends webhooks via the **Singularity Webhook** marketplace app. The built-in Notifications channels (SMTP, Syslog) don't support arbitrary headers, so the marketplace app is required for auth to work.

### 4a. Install Singularity Webhook

1. SentinelOne console → **Marketplace**.
2. Search for **Singularity Webhook**.
3. **Install** (or **Add Configuration** if already installed). Scope to the site you want to forward from.

### 4b. Configure Threat Response Action 1

In the configuration screen:

* Toggle **Make Response Actions available as Manual Response Actions from Threats** to **on** (so you can also fire the webhook manually from a threat in the SentinelOne console).
* Under **Advanced**, leave **Auto-Disable on Unauthorized Error** on.
* Expand **Threat Response Action 1**:
  * **Name:** `Clarion`
  * **Description:** `Forward threats to Clarion`
  * **Automation Trigger Options:** `All Threats`
  * **URL:** paste the **Clarion webhook URL** from step 1.
  * **Action:** `POST`
  * **Webhook Request Body:** switch to **Custom** (the presets ship without custom headers, so they can't authenticate).

### 4c. Custom Body

The webhook body only needs the threat ID - Clarion fills in the rest. Paste this as **Define custom message body**:

```json theme={null}
{ "threatId": "${activity.threatInfo.threatId}" }
```

> **Note:** Use the `${activity.…}` placeholder syntax (braces, not `$(…)` parentheses). `${activity.threatInfo.threatId}` and `${activity.id}` both resolve to the threat ID and work equally well.

### 4d. Headers

Set **Headers** to:

```json theme={null}
{"Content-Type": "application/json", "x-webhook-secret": "${Var1}"}
```

Then scroll down to the **Secret variables** section:

* **Var1 - Secret variable description:** `Clarion webhook secret`
* **Var1 - Secret variable value:** paste the **Clarion webhook secret** from step 1.

Click **Install**.

### 4e. Test the connection

In the Threat Response Action 1 view, click **Test Connection**. SentinelOne should report `Status 200` (or `201`) - and you should see a corresponding `webhook accepted: alert created` log line in your Clarion environment.

> **Note:** SentinelOne's "Test Connection" sends the template with `${activity.…}` placeholders unsubstituted (because there's no threat in scope during the test). A test alert *will* be created in Clarion with literal-string placeholder values in the payload - that's expected. A real threat detection produces the resolved payload.

## Step 5 - Verify with EICAR

The cleanest end-to-end test is the [EICAR test file](https://www.eicar.org/download-anti-malware-testfile/). On any enrolled endpoint:

```bash theme={null}
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > /tmp/eicar.com
```

Within \~1 minute SentinelOne mitigates the file, posts the thin webhook to Clarion, and Clarion calls back to fetch the full threat. You should see an alert titled `[SentinelOne] eicar.com — <hostname>` in **Triage → Alerts**, with full description (file path, SHA256, mitigation status, endpoint IP, site name, deep link back to the console).

## How severity is mapped

SentinelOne's payload doesn't include a `severity` field - only `confidenceLevel: "malicious" | "suspicious" | …`. Clarion maps it like this:

| SentinelOne `confidenceLevel` | Clarion severity |
| ----------------------------- | ---------------- |
| `malicious`                   | high             |
| `suspicious`                  | medium           |
| anything else                 | medium (default) |

If a custom template ever sends a `severity` field with `Critical`/`High`/`Medium`/`Low`/`Informational`, Clarion uses that directly and ignores the confidence fallback.

## Troubleshooting

### `webhook rejected: missing authentication header` in Clarion logs

The `x-webhook-secret` header isn't reaching Clarion. Most common causes:

* You switched the Singularity Webhook body mode from **Custom** to a preset; presets drop custom headers.
* The `Var1` value field is blank, while the headers JSON references `${Var1}`.
* The headers JSON has a syntax error and SentinelOne is silently sending no headers.

### `webhook rejected: invalid authentication token`

The `x-webhook-secret` value doesn't match what's stored on the Clarion integration. You probably rotated the secret in Clarion (disconnect + reconnect) and forgot to update Var1 in SentinelOne, or vice versa. Reconnect in Clarion and re-paste the new secret into Var1.

### Alerts are created but with empty fields

The API token is missing, expired, or scoped to the wrong account/site, so Clarion can't pull the threat details. Regenerate the token in SentinelOne and re-paste it into Clarion's **API token** field.

### `${activity.…}` placeholders showing as literal text in the alert payload

You're most likely seeing a Test Connection alert, where placeholders don't substitute by design - see step 4e. If a real detection also shows the literal `${activity.threatInfo.threatId}` string, re-paste the minimal template exactly as shown in step 4c (braces, not `$(…)` parentheses).

### `Authentication issue occurred while running automated_response_actions. (1) Invalid json value for Body field`

SentinelOne validates the Custom Body as JSON at save time, before any substitution. A bare `${activity}` or `$(activity)` is not valid JSON. Only string-position placeholders (`"threatId": "${activity.threatInfo.threatId}"`) work.

## Why the API token matters

With the minimal body above, the webhook only carries the threat ID - Clarion needs the API token to turn that into a complete alert (threat name, classification, host, file, mitigation status, console link). The same token also lets Clarion run response actions back in SentinelOne (mitigate, isolate, set verdict/status), which is why we recommend the **SOC role** rather than a read-only one. Without a token, alerts will be sparse, so we strongly recommend configuring one.