This topic covers how to connect SentinelOne Singularity Endpoint to Expel Workbench.
Note
We support alert status syncing from Workbench to SentinelOne Singularity Endpoint. If enabled, when an ingested SentinelOne threat creates an Expel Alert, 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 for more information about status syncing.
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
Managepermissions to Expel in SentinelOne and also enable status syncing in your Workbench security device (instructions are in this guide).
Prerequisites
- You must have admin access in Workbench to set up this integration.
- For the Expel SOC to fully triage and perform deeper investigations of SentinelOne alerts, the SentinelOne Deep Visibility module is required.
Quick Links
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 in 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.
- Log in to your SentinelOne console and navigate to Settings > Users.
- Select the Roles tab in the side menu.
- Locate the Viewer role in the list and select the checkbox.
- Select Actions > Duplicate Role.
- Name the role "Viewer - Expel".
- In addition to the defaults, add these permissions:
- Endpoints: Remote Shell, Initiate Scan, File Fetch, and Fetch Logs.
- Endpoint Threats: Fetch Threat File.
- Select Save.
- In the side menu, select Console Users.
- Select Actions > Add New User.
- 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
Viewpermission. If you wish to enable status syncing, you must also select theManagepermission.
- 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 Token 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.
- Navigate to Settings > Users.
- Select the Service Users tab in the side menu.
- Select Actions > Create New Service User.
- 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.
- Select Next.
- On the Scope of Access screen:
- Access Level - select Account.
- Select the account to grant access, and assign it the IR Team role.
- Select Create User.
- Copy and save the API token in a safe place for use in a later step. You will only be shown this value once.
- 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.
- Log in to Workbench.
- In the side menu, navigate to Organization Settings > Security Devices.
- Select Add Security Device.
- In the search box, type “SentinelOne” and then select the SentinelOne Singularity Endpoint integration.
- 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.
-
Enable status syncing? - if you have chosen to grant
Managepermissions in Step 1, select Yes to enable the status syncing.
- Select Save.
- On the console access screen, select Set up later. Expel will set up console access using the newly created console user.
- Select Save.
- 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. You can then scroll to the Connection section to see if your device is fully connected.
- 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.
- 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.
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. 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.
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.
Limitations
1. Syncing only applies to SentinelOne threats that generate an Expel Alert.
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.
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* | N/A | N/A |
| Incident* | N/A | N/A |
*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.
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* |
|
Closed (Activity Blocked) Closed (Attack Failed) Closed (True Positive) |
True Positive |
|
Closed (Benign) Closed (False Positive) Closed (Testing) Closed (Suppressed) Closed (Suppressed - New Device) Closed (Suppressed - Threshold Exceeded) |
False Positive |
|
Closed (IT Misconfiguration) Closed (Possible Policy Violation) Closed (PUP/PUA) Closed (Other) |
Suspicious |
*Undefined is the typical, default status for a threat that has not been triaged and thus does not map to an Expel “Closed” state.
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.
Supported Events
| Event | Triggers Status Sync? | Triggers Comment? |
| Expel Alert Created | ✅ | ✅ |
| Expel Alert Closed | ✅ | ✅ |
| Expel Alert Reopened | ✅ | ✅ |
| Investigation Created | ✅ | ✅ |
| Investigation Closed | ✅ | ✅ |
| Investigation Promoted | ✅ | |
| Investigation Reopened | ✅ | |
| Incident Created | ✅ | ✅ |
| Incident Closed | ✅ | ✅ |
| Incident Promoted | ✅ | |
| Incident Reopened | ✅ | |
| Investigative Actions | ||
| Comment Created | ✅ | |
| Expel Alert Assigned | ✅ | |
| Investigation Assigned | ✅ | |
| Investigation Alert Added | ✅ | |
| Incident Assigned | ✅ | |
| Incident Downgraded | ✅ | |
| Investigative Action Analysis Assigned | ✅ | |
| Investigative Action Manual Action | ✅ | |
| Investigative Action Assigned | ✅ | |
| Notify Action Assigned | ✅ | |
| Verify Action Assigned | ✅ | |
| Verify Action Approved | ✅ | |
| Verify Action Denied | ✅ | |
| Incident Finding Created | ✅ | |
| Incident Finding Updated | ✅ | |
| Incident Finding Completed | ✅ | |
| Remediation Action Automated | ✅ | |
| Remediation Action Assigned | ✅ | |
| Remediation Action Completed | ✅ | |
| Remediation Action Automated Failed | ✅ | |