> For the complete documentation index, see [llms.txt](https://docs.expel.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.expel.io/connect-your-technology/q-z-integrations/sentinelone/sentinelone-singularity-endpoint-setup-for-workbench.md).

# SentinelOne Singularity Endpoint Setup for Workbench

{% hint style="info" %}
We support alert status syncing from Workbench to SentinelOne Singularity Endpoint. If enabled, when an ingested SentinelOne threat creates an [Expel Alert](/workbench-reference/alerts/how-expel-alerts-work.md), its status (e.g. open, investigating, closed) is reflected back into SentinelOne as the SOC conducts its work. Comments are also included for every state change, or for any action taken by the SOC (e.g. a Verify Action is sent). See the [Reference](#reference) for more information about status syncing.
{% endhint %}

## Scope and Limitations

When choosing to set up this integration, remember the following:

* We only ingest S1 threats, not alerts.
* To enable status syncing, you must grant `Manage` permissions to Expel in SentinelOne and also enable status syncing in your Workbench security device (instructions are in this guide).

## Prerequisites

1. You must have admin access in Workbench to set up this integration.
2. For the Expel SOC to fully triage and perform deeper investigations of SentinelOne alerts, the SentinelOne Deep Visibility module is required.

## Step 1: Create a New Role and Console User for Expel

This step creates a user account for Expel that keeps the Expel activity separate from other activity on the SentinelOne console. Having access to the interface of your technology allows Expel to dig deeper during incident investigations. Our device health team uses this access to investigate potential health issues with your tech. For more information, see [Why Expel Asks for Console Access](/connect-your-technology/about-integrations/why-expel-asks-for-console-access.md).

1. Log in to your SentinelOne console and navigate to **Settings > Users**.
2. Select the **Roles** tab in the side menu.
3. Locate the **Viewer** role in the list and select the checkbox.
4. Select **Actions > Duplicate Role**.<br>

   <div align="left"><figure><img src="/files/oMvVQ4c9eN6Zm7hHR2XW" alt="Select Duplicate Role from the Actions dropdown." width="164"><figcaption></figcaption></figure></div>
5. Name the role "Viewer - Expel".
6. In addition to the defaults, add these permissions:
   * **Endpoints**: Remote Shell, Initiate Scan, File Fetch, and Fetch Logs.
   * **Endpoint Threats**: Fetch Threat File.
7. Select **Save**.
8. In the side menu, select **Console Users**.
9. Select **Actions > Add New User**.<br>

   <div align="left"><figure><img src="/files/sgOSt1TMdSy9t1WsENrt" alt="Select Add New User from the Actions dropdown." width="375"><figcaption></figcaption></figure></div>
10. Configure the new user as follows:
    * **Full Name** - enter "Expel SOC".
    * **Email Address** - enter "soc+\<Your\_Organization\_Name>@expel.io".
      * For example, if your organization were Acme Corp, the format would be "<soc+acme_corp@expel.io>".
    * **Access Level** - select **Account** and select the account for access.
    * **Role** - enter a role name and then select the `View` permission. If you wish to enable [status syncing](#about-status-syncing), you must also select the `Manage` permission.

<figure><img src="/files/nVMVIegj0Tm9JG6Jxq3f" alt="Image showing how to search for and select the role permissions using checkboxes." height="411" width="624"><figcaption></figcaption></figure>

11. Select **Create User**. This triggers an email invitation allowing the Expel SOC to create an account and complete console access configuration in Workbench on your behalf.

## Step 2: Create a Service User and API Key for Expel

Next, you will create a service user, assign it a role, and use it to generate an API token to integrate with Workbench.

1. Navigate to **Settings > Users**.
2. Select the **Service Users** tab in the side menu.
3. Select **Actions > Create New Service User**.<br>

   <div align="left"><figure><img src="/files/CwcjC8TafYJgS9hyQ4Vp" alt="Select Create New Service User from the Actions dropdown." width="375"><figcaption></figcaption></figure></div>
4. Configure  the new user as follows:
   * **Name** - enter "Expel API".
   * **Description** - enter "API Service user for Expel integration".
   * **Expiration date** - select an expiration period that suits your organization.
5. Select **Next**.
6. On the Scope of Access screen:
   * **Access Level** - select **Account**.
   * Select the account to grant access, and assign it the **IR Team** role.<br>

     <div align="left"><figure><img src="/files/f9l66kubmDK7GttzHPRU" alt="" width="188"><figcaption></figcaption></figure></div>
7. Select **Create User.**
8. **Copy and save the API token** in a safe place for use in a later step. You will only be shown this value once.
9. Select **Close**.

## Step 3: Add SentinelOne Singularity Endpoint as a Security Device in Workbench

Now that you have the necessary credentials configured, you can set up the integration in Workbench.

1. [Log in to Workbench](https://workbench.expel.io/auth/login?orig=%2F).
2. In the side menu, navigate to **Organization Settings > Security Devices**.
3. Select **Add Security Device**.
4. In the search box, type “SentinelOne” and then select the **SentinelOne Singularity Endpoint** integration.<br>

   <div align="left"><figure><img src="/files/cSa2X2WJKHvQNlBFymB9" alt="SentinelOne Singularity Endpoint Add Security Device screen in Workbench." width="326"><figcaption></figcaption></figure></div>
5. Complete the fields as follows:
   * **Name** - enter a name that might help you more easily identify this integration, such as “CompanyName - S1 EDR”.
   * **Location** - enter the location of your integration, for example “cloud" or "on-prem”.
   * **Server address** - enter the server address (URL) of the SentinelOne console. For example: `https://usea1-1001.sentinelone.net`
   * **API key** - enter the API token you generated in [Step 2](#step-2-create-a-service-user-and-api-key-for-expel).
   * **Enable status syncing?** - if you have chosen to grant `Manage` permissions in [Step 1](#step-1-create-a-new-role-and-console-user-for-expel), select **Yes** to enable the status syncing.
6. Select **Save**.
7. On the console access screen, select **Set up later**. Expel will set up console access using the newly created console user.&#x20;
8. Select **Save**.
9. Select **Done**.

Your device should be created successfully within a few seconds. A few reminders:

* After your connection is healthy, it will take some time for your device to begin polling and receiving data.
* To check on the status, select the downward arrow for your device in the first column and choose **View details**.
* Polling will happen first; data will be received after that. **You must refresh the page to see updates.**
* If your device does not begin polling within 15 minutes, and does not begin receiving data within 30 minutes, [contact our support team for help](/support/how-to-reach-us.md).
* To check if alerts are coming through, navigate to **Dashboards > Alert Analysis**. Scroll to the device you want to check, and select the **Expel Alerts** tab to reveal more alert information. It can take 36 to 72 hours for alerts to appear after setup, as we [tune your device](/workbench-reference/alerts/how-expel-alerts-work.md#device-tuning).

## Reference

### About Status Syncing

If you have chosen to grant Manage permissions to Expel during your setup and have also enabled status syncing in the security device, syncing will be enabled upon completion of this guide.&#x20;

Workbench status syncing is available for any SentinelOne customer using the Singularity Endpoint platform. The addition of Wayfinder MDR or other SentinelOne services do not impact API permissions or Workbench status syncing.

{% hint style="info" %}
Syncing is currently one-way and Workbench serves as the source of truth. This means statuses in SentinelOne are updated by Workbench, but Workbench is not informed or updated by status changes made in SentinelOne.&#x20;
{% endhint %}

#### Limitations

**1. Syncing only applies to SentinelOne threats that generate an Expel Alert.**&#x20;

If a SentinelOne alert is ingested but does not meet our detections threshold (i.e. remains a vendor alert), then nothing “happens” in SentinelOne. We acknowledge this creates a possible blind spot into knowing what our SOC is or is not triaging, and are committed to supporting this use case in the future.

**2. Status syncing behaviors are limited to alert status and commenting.**&#x20;

Expel Alert assignment metadata (i.e. assigned to Expel, assigned to your organization) does not map back to SentinelOne threats.

### Object Mappings

| Workbench Object    | Syncing Key          | SentinelOne Object |
| ------------------- | -------------------- | ------------------ |
| Expel Alert         | SentinelOne alert ID | Threat             |
| Investigation\*[^1] | N/A                  | N/A                |
| Incident\*[^1]      | N/A                  | N/A                |

### State Mappings

| Expel Alert State or Action | SentinelOne Status               |
| --------------------------- | -------------------------------- |
| New / Reopened              | Unresolved                       |
| Investigating               | In Progress                      |
| Closed                      | Resolved                         |
| (Closed Reason)             | N/A (to be captured via comment) |

| Expel Alert (Close Reason)                                                                                                                                                                  | SentinelOne Analyst Verdict |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- |
| N/A                                                                                                                                                                                         | Undefined\*[^2]             |
| <p>Closed (Activity Blocked)</p><p>Closed (Attack Failed)<br>Closed (Incident)</p><p>Closed (True Positive)</p>                                                                             | True Positive               |
| <p>Closed (Benign)</p><p>Closed (False Positive)</p><p>Closed (Testing)</p><p>Closed (Suppressed)</p><p>Closed (Suppressed - New Device)</p><p>Closed (Suppressed - Threshold Exceeded)</p> | False Positive              |
| <p>Closed (IT Misconfiguration)</p><p>Closed (Possible Policy Violation)</p><p>Closed (PUP/PUA)</p><p>Closed (Other)</p>                                                                    | Suspicious                  |

### Comments

In addition to state syncing, the close reason and associated analysis is added as a comment to the SentinelOne Singularity Endpoint alert or incident upon closure. &#x20;

### Supported Events

| Event                                  | Triggers Status Sync? | Triggers Comment? |
| -------------------------------------- | --------------------- | ----------------- |
| Expel Alert Created                    | ✅                     | ✅                 |
| Expel Alert Closed                     | ✅                     | ✅                 |
| Expel Alert Reopened                   | ✅                     | ✅                 |
| Investigation Created                  | ✅                     | ✅                 |
| Investigation Closed                   | ✅                     | ✅                 |
| Investigation Promoted                 | <p><br></p>           | ✅                 |
| Investigation Reopened                 | <p><br></p>           | ✅                 |
| Incident Created                       | ✅                     | ✅                 |
| Incident Closed                        | ✅                     | ✅                 |
| Incident Promoted                      | <p><br></p>           | ✅                 |
| Incident Reopened                      | <p><br></p>           | ✅                 |
| Comment Created                        | <p><br></p>           | ✅                 |
| Expel Alert Assigned                   | <p><br></p>           | ✅                 |
| Investigation Assigned                 | <p><br></p>           | ✅                 |
| Investigation Alert Added              | <p><br></p>           | ✅                 |
| Incident Assigned                      | <p><br></p>           | ✅                 |
| Incident Downgraded                    | <p><br></p>           | ✅                 |
| Investigative Action Analysis Assigned | <p><br></p>           | ✅                 |
| Investigative Action Manual Action     | <p><br></p>           | ✅                 |
| Investigative Action Assigned          | <p><br></p>           | ✅                 |
| Notify Action Assigned                 | <p><br></p>           | ✅                 |
| Verify Action Assigned                 | <p><br></p>           | ✅                 |
| Verify Action Approved                 | <p><br></p>           | ✅                 |
| Verify Action Denied                   | <p><br></p>           | ✅                 |
| Incident Finding Created               | <p><br></p>           | ✅                 |
| Incident Finding Updated               | <p><br></p>           | ✅                 |
| Incident Finding Completed             | <p><br></p>           | ✅                 |
| Remediation Action Automated           | <p><br></p>           | ✅                 |
| Remediation Action Assigned            | <p><br></p>           | ✅                 |
| Remediation Action Completed           | <p><br></p>           | ✅                 |
| Remediation Action Automated Failed    | <p><br></p>           | ✅                 |

[^1]: There is no apples-to-apples object def mapping between Workbench and SentinelOne. Workbench Investigation/Incident states instead map to all S1 Threats associated with the Incident/Investigation.

[^2]: Undefined is the typical, default status for a threat that has not been triaged and thus does not map to an Expel “Closed” state.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.expel.io/connect-your-technology/q-z-integrations/sentinelone/sentinelone-singularity-endpoint-setup-for-workbench.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
