---
title: "SentinelOne collector"
canonical: "https://docs.devo.com/space/latest/94657302/SentinelOne%20collector"
format: markdown
---
> Macro (toc)
## Configuration requirements
| **Configuration** | **Details** |
| --- | --- |
| **API Token** | You will need to generate a SentinelOne API Token. |
> ℹ️ **More information**
> ℹ️
> ℹ️ Refer to the [Vendor setup ](#Vendor-setup)section to know more about these configurations.
## Overview
[SentinelOne](http://www.sentinelone.com) delivers autonomous endpoint protection through a single agent that prevents, detects, responds to, and hunts attacks. SentinelOne Singularity platform is a data lake that fuses together the data, access, control, and integration plans of its Endpoint Protection (EPP), Endpoint Detection and Response (EDR), IoT security, and Cloud Workload Protection (CWPP) into a centralized platform.
The Devo | SentinelOne integration collects data from various sources available through the SentinelOne API and ingests it into Devo, where it is made available for enterprise teams to query, analyze, and visualize for different use cases.
## Devo collector features
| **Feature** | **Details** |
| --- | --- |
| Allow parallel downloading (`multipod`) | `Not allowed` |
| Running environments | `Collector Server`
`On Premise` |
| Populated Devo events | `Standard`
`Lookups` |
## Data source
| **Data Source** | **Description** | **aAPI endpoint** | **Collector service name** | **Devo tables** | **Available from release** |
| --- | --- | --- | --- | --- | --- |
| Threat Detections | Detailed telemetry from any threat detected on a device with the SentinelOne agent installed in the organization. This data is additionally mapped to Devo's `edr.all.threats` union table for further analysis and integration with the Devo SecOps application. | `/web/api/v2.1/threats` | `threat_events` | `edr.sentinelone.agent.threats` | `v1.0.0` |
| Management Console Activities | Detailed events captured by the interactions with the SentinelOne management console | `/web/api/v2.1/activities` | `management_activity_events` | `edr.sentinelone.management.activities` | `v1.0.0` |
| Management Console Activity Types | A lookup table which maps numeric activity types to their written description to add usability to the data | `/web/api/v2.1/activities/types` | `activity_types` | Lookup table: `SentinelOne_Management_Console_Activity_Types` | `v1.0.0` |
| Agent Telemetry | System information and telemetry from devices with the SentinelOne agent installed | `/web/api/v2.1/agents` | `agent_telemetry` | `edr.sentinelone.agent.agents` | `v1.0.0` |
## Vendor setup
> Macro (anchor)
In order to configure the SentinelOne collector, you need to generate a SentinelOne API token. Follow these steps to do it:
> Macro (rw-ui-steps-macro)
>
> > Macro (rw-step)
>
> Log in to **SentinelOne** as the user you want to authorize API request. This user should have permissions to view threat, agent and management console activity data.
>
> 
>
> > Macro (rw-step)
>
> Go to the **Help** menu in the upper right corner and select **API Doc**.
>
> 
>
> > Macro (rw-step)
>
> Navigate to Users → Generate API Token.
>
> 
>
> > Macro (rw-step)
>
> Select **Run on console**.
>
> 
>
> > Macro (rw-step)
>
> Select **Run API query** and copu the value of the **token key** displayed in the **Response** section.
>
> 
## Minimum configuration required for basic pulling
Although this collector supports advanced configuration, the fields required to download data with basic configuration are defined below.
> ℹ️ This minimum configuration refers exclusively to those specific parameters of this integration. There are more required parameters related to the generic behavior of the collector. Check the detail of the parameterization for more information.
| **Setting** | **Details** |
| --- | --- |
| `url_value` | Use this param to define the URL used by the collector to pull data. Replace `XXXXXXXXX` with your SentinelOne `host name`. |
| `api_token_value` | Set up here your access token created in the SentinelOne console. |
> ℹ️ See the **Accepted authentication methods** section to verify what settings are required based on the desired authentication method.
## Accepted authentication methods
The following are the accepted authentication methods for this collector.
| **Authentication Method** | **URL** | **API Token** |
| --- | --- | --- |
| API Token | [required] | [required] |
## Run the collector
Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).
> Macro (rw-ui-tabs-macro)
>
> > Macro (rw-tab)
>
> We use a piece of software called Collector Server to host and manage all our available collectors.
>
> To enable the collector for a customer:
>
> 1. In the **Collector Server** **GUI**, access the **domain** in which you want this instance to be created
> 2. Click **Add Collector** and find **SentinelOne Threats- Integrations Factory**.
> 3. In the **Version** field, select the latest value.
> 4. In the **Collector Name** field, set the value you prefer (this name must be unique inside the same Collector Server domain).
> 5. In the sending method select **Direct Send. Direct Send** configuration is optional for collectors that create `Table` events, but mandatory for those that create `Lookups`.
> 6. In the **Parameters** section, establish the **Collector Parameters** as follows below:
>
> ### Editing the JSON configuration
>
> ```
> {
> "global_overrides": {
> "debug": False
> },
> "inputs": {
> "data_puller": {
> "id": "",
> "enabled": ,
> "requests_per_second": ,
> "sentinelone_url": ,
> "credentials": {
> "api_token": ""
> },
> "services": {
> "threat_events": {
> "request_period_in_seconds": ,
> "filters": ,
> "start_time_override":
> },
> "management_activity_events": {
> "request_period_in_seconds": ,
> "filters": ,
> "start_time_override":
> },
> "agent_telemetry": {
> "request_period_in_seconds": ,
> "filters": ,
> "start_time_override":
> },
> "activity_types": {
> "request_period_in_seconds":
> }
> }
> }
> }
> }
> ```
>
> > ℹ️ All defined service entities will be executed by the collector. If you do not want to run any of them, just remove the entity from the `services` object.
>
> Please replace the placeholders with real world values following the description table below:
>
> | | | | | |
> | --- | --- | --- | --- | --- |
> | **Parameter** | **Data Type** | **Type** | **Value Range / Format** | **Details** |
> | `short_unique_id` | `int` | `Mandatory` | Minimum length: 1
> Maximum length: 5 | Use this param to give an unique id to this input service.
> ⚠️ This parameter is used to build the persistence address, do not use the same value for multiple collectors. It could cause a collision. |
> | `input_status` | `bool` | `Mandatory` | `false` / `true` | If the value is `true`, the input definition will be executed. If the value is `false`, the service will be ignored. |
> | `requests_per_second_value` | `int` | `Optional` | Minimum value: 1 | Customize the maximum number of API requests per second. If not used, the default setting will be used: `60` requests/sec.
> 📝 This parameter should be removed if it is not used. |
> | `url_value` | `str` | `Mandatory` | The URL must comply with the following format:
`https://XXXXXXXXX.sentinelone.net` | Use this param to define the URL used by the collector to pull data. Replace `XXXXXXXXX` with your SentinelOne `host name`. |
> | `api_token_value` | `str` | `Mandatory` | Minimum length: 1 | Set up here your access token created in the SentinelOne console. |
> | `request_period_in_seconds_value` | `int` | `Optional` | Minimum length: 1 | Period in seconds used between each data pulling, this value will overwrite the default value (300 seconds)
> 📝 This parameter should be removed if it is not used. |
> | `start_time_override_value` | `str` | `Optional` | UTC with format: `YYYY-mm-ddTHH:MM:SS.sssZ` | This configuration allows you to set a custom date as the beginning of the period to download. This allows downloading historical data (1 month back for example) before downloading new events.
If this settings is not set, the default value is the current time.
> 📝 This parameter should be removed if it is not used. |
> | `custom_filters_value` | `json` | `Optional` | | This configuration allows you to set a custom filter for the retrieved data.
> 📝 This parameter should be removed if it is not used.
**How to filter by **`site_id`**:**
Specific SentinelOne site. This can be useful for MSSPs or customers with large SentinelOne deployments that use multiple Sites on the same SentineOne instance and they want to send data for specific SentinelOne accounts to specific Devo domains.
```
> "filters": {
> "site_id": [
> "siteId 1",
> "siteId 2"
> ]
> }
> ```
> 📝 Define an array of `siteId` definitions with 1 ore more elements.
**How to filter by **`account_id`**:**
Specific SentinelOne account. This can be useful for MSSPs or customers with large SentinelOne deployments that use multiple Sites on the same SentineOne instance and they want to send data for specific SentinelOne accounts to specific Devo domains.
```
> "filters": {
> "account_id": [
> "accountId 1",
> "accountId 2"
> ]
> }
> ```
> 📝 Define an array of `account_id` definitions with 1 ore more elements.
**How to filter by **`site_id`** and **`account_id`**:**
```
> "filters": {
> "site_id": [
> "siteId 1",
> "siteId 2"
> ],
> "account_id": [
> "accountId 1",
> "accountId 2"
> ]
> }
> ```
> 📝 Define an array of `site_id` and `account_id` definitions with 1 ore more elements. |
>
> 
>
>
> > Macro (rw-tab)
>
> ### Structure
>
> The following directory structure should be created for use when running the SentinelOne collector:
>
> ```
>
> └── devo-collectors/
> └── /
> ├── certs/
> │ ├── chain.crt
> │ ├── .key
> │ └── .crt
> ├── state/
> └── config/
> └── config-.yaml
> ```
>
> > ⚠️ Replace `` with the proper value.
>
> ### Devo credentials
>
> In Devo, go to **Administration → Credentials → X.509 Certificates**, download the **Certificate**, **Private key** and **Chain CA** and save them in `/certs/`. Learn more about security credentials in Devo [here](#).
>
> 
>
> > ⚠️ Replace `` with the proper value.
>
> ### Editing the .yaml file
>
> ```
> globals:
> debug: False
> id:
> name:
> persistence:
> type: filesystem
> config:
> directory_name: state
> outputs:
> devo_1:
> type: devo_platform
> config:
> address:
> port: 443
> type: SSL
> chain:
> cert:
> key:
> inputs:
> data_puller:
> id:
> enabled:
> sentinelone_url: https://.sentinelone.net
> credentials:
> api_token:
> services:
> threat_events:
> request_period_in_seconds:
> filters:
> start_time_override:
> management_activity_events:
> request_period_in_seconds:
> filters:
> start_time_override:
> agent_telemetry:
> request_period_in_seconds:
> filters:
> start_time_override:
> activity_types:
> request_period_in_seconds:
> ```
>
> Replace the following placeholders with your required values:
>
> | **Parameter** | **Data type** | **Type** | **Value range** | **Details** |
> | --- | --- | --- | --- | --- |
> | `collector_id` | `int` | `Mandatory` | Minimum length: 1
> Maximum length: 5 | Use this param to give an unique id to this collector. |
> | `collector_name` | `str` | `Mandatory` | Minimum length: 1
> Maximum length: 10 | Use this param to give a valid name to this collector. |
> | `devo_address` | `str` | `Mandatory` | `collector-us.devo.io`
> `collector-eu.devo.io` | Use this param to identify the Devo Cloud where the events will be sent. |
> | `chain_filename` | `str` | `Mandatory` | Minimum length: 4
> Maximum length: 20 | Use this param to identify the chain.cert file downloaded from your Devo domain. Usually this file's name is: `chain.crt` |
> | `cert_filename` | `str` | `Mandatory` | Minimum length: 4
> Maximum length: 20 | Use this param to identify the `file.cert` downloaded from your Devo domain. |
> | `key_filename` | `str` | `Mandatory` | Minimum length: 4
> Maximum length: 20 | Use this param to identify the `file.key` downloaded from your Devo domain. |
> | `input_id` | `int` | `Mandatory` | Minimum length: 1
> Maximum length: 5 | Use this param to give an unique id to this input service.
> ⚠️ This parameter is used to build the persistence address, do not use the same value for multiple collectors. It could cause a collision. |
> | `input_status` | `bool` | `Mandatory` | `false` / `true` | If the value is true, the input definition will be executed. If the value is false, the service will be ignored. |
> | `customer_hostname` | `int` | `Mandatory` | Minimum length: 1 | The host name of the customer to access SentinelOne |
> | `api_token_value` | `str` | `Mandatory` | Minimum length: 1 | Set up here your access token created in the SentinelOne console. |
> | `request_period_in_seconds` | `int` | `Optional` | Minimum length: 1 | Period in seconds used between each data pulling, this value will overwrite the default value (300 seconds)
> ℹ️ This parameter can be removed or commented. |
> | `start_time_override` | `str` | `Optional` | UTC with format: `YYYY-mm-ddTHH:MM:SS.sssZ` | This configuration allows you to set a custom date as the beginning of the period to download. This allows downloading historical data (1 month back for example) before downloading new events.
If this setting is not set, the default value is the current time.
> ℹ️ This parameter can be removed or commented. |
> | `filters` | `json` | `Optional` | | This configuration allows you to set a custom filter for the retrieved data.
> ℹ️ This parameter can be removed if it is not used.
**How to filter by **`site_id`**:**
Specific SentinelOne site. This can be useful for MSSPs or customers with large SentinelOne deployments that use multiple Sites on the same SentineOne instance and they want to send data for specific SentinelOne accounts to specific Devo domains.
```
> filters:
> site_id:
> - siteId 1
> - siteId 2
> ```
> ℹ️ Define an array of `siteId` definitions with 1 ore more elements.
**How to filter by **`account_id`**:**
Specific SentinelOne account. This can be useful for MSSPs or customers with large SentinelOne deployments that use multiple Sites on the same SentineOne instance and they want to send data for specific SentinelOne accounts to specific Devo domains.
```
> filters
> account_id
> - accountId 1
> - accountId 2
> ```
> ℹ️ Define an array of `account_id` definitions with 1 ore more elements.
**How to filter by **`site_id`** and **`account_id`**:**
```
> filters
> site_id
> - siteId 1
> - siteId 2
> account_id
> - accountId 1
> - accountId 2
> ```
> ℹ️ Define an array of `site_id` and `account_id` definitions with 1 ore more elements. |
>
> ### Download the Docker image
>
> The collector should be deployed as a Docker container. Download the Docker image of the collector as a .tgz file by clicking the link in the following table:
>
> | **Collector Docker image** | **SHA-256 hash** |
> | --- | --- |
> | [collector-sentinelone_if-docker-image-1.5.0.tgz](https://drive.google.com/file/d/1lmA8xmJmaernOyyRuFSjUnyvQJQvuvGu/view?usp=drive_link) | `649234e7a38abf7049728388dcf428530c9499ea1e09cd78d8872fadebfa108e` |
>
> Use the following command to add the Docker image to the system:
>
> ```
> gunzip -c -.tgz | docker load
> ```
>
> > ⚠️ Once the Docker image is imported, it will show the real name of the Docker image (including version info). Replace `` with the required value.
>
> The Docker image can be deployed on the following services:
>
> #### Docker
>
> Execute the following command on the root directory `/devo-collectors//`
>
> ```
> docker run
> --name collector-
> --volume $PWD/certs:/devo-collector/certs
> --volume $PWD/config:/devo-collector/config
> --volume $PWD/state:/devo-collector/state
> --env CONFIG_FILE=config.yaml
> --rm
> --interactive
> --tty
> :
> ```
>
> > ⚠️ Replace ``, `` and `` with the required values.
>
> #### Docker Compose
>
> The following Docker Compose file can be used to execute the Docker container. It must be created in the `/devo-collectors//` directory.
>
> ```
> version: '3'
> services:
> collector-:
> image: :${IMAGE_VERSION:-latest}
> container_name: collector-
> volumes:
> - ./certs:/devo-collector/certs
> - ./config:/devo-collector/config
> - ./credentials:/devo-collector/credentials
> - ./state:/devo-collector/state
> environment:
> - CONFIG_FILE=${CONFIG_FILE:-config.yaml}
> ```
>
> To run the container using docker-compose, execute the following command from the `/devo-collectors//` directory:
>
> ```
> IMAGE_VERSION= docker-compose up -d
> ```
>
> > ⚠️ Replace ``, `` and `` with the required values.
## Change log
| **Release** | **Released on** | **Release type** | **Details** | **Recommendations** |
| --- | --- | --- | --- | --- |
| `v1.5.0` | 1/23/2024 | [IMPROVEMENT] | ### Improvements
- Updated DCSDK from 1.9.1 to 1.10.2:
- Fixed error in pyproject.toml related to project scripts endpoint
- Updated PythonSDK to version 5.0.7
- Introduced pyproject.toml
- Added requirements.dev.txt
- Added input metrics
- Modified ouutput metrics
- Updated DevoSDKA to version 5.1.6
- Standardized exception messages for traceability
- Added more detail in queue statistics
- Upgrade internal dependencies | `Recommended version` |
| `v1.4.0` | 8/16/2023 | [IMPROVEMENT] | **Updated DCSDK from 1.4.3 to 1.9.1:**
- Store lookup instances into DevoSender to avoid creation of new instances for the same lookup
- Ensure service_config is a dict into templates
- Ensure special characters are properly sent to the platform
- Changed log level to some messages from info to debug
- Changed some wrong log messages
- Upgraded some internal dependencies
- Changed queue passed to setup instance constructor
- New "templates" functionality
- Functionality for detecting some system signals for starting the controlled stopping
- Input objects sends again the internal messages to devo.collectors.out table
- Upgraded DevoSDK to version 3.6.4 to fix a bug related to a connection loss with Devo
- Refactored source code structure
- Changed way of executing the controlled stopping
- Minimized probabilities of suffering a DevoSDK bug related to "sender" to be null
- Ability to validate collector setup and exit without pulling any data
- Ability to store in the persistence the messages that couldn't be sent after the collector stopped
- Ability to send messages from the persistence when the collector starts and before the puller begins working
- Ensure special characters are properly sent to the platform
- Added a lock to enhance sender object
- Added new class attrs to the setstate and getstate queue methods
- Fix sending attribute value to the setstate and getstate queue methods
- Added log traces when queues are full and have to wait
- Added log traces of queues time waiting every minute in debug mode
- Added method to calculate queue size in bytes
- Block incoming events in queues when there are no space left
- Send telemetry events to Devo platform
- Upgraded internal Python dependency Redis to v4.5.4
- Upgraded internal Python dependency DevoSDK to v5.1.3
- Fixed obfuscation not working when messages are sent from templates
- New method to figure out if a puller thread is stopping
- Upgraded internal Python dependency DevoSDK to v5.0.6
- Improved logging on messages/bytes sent to Devo platform
- Fixed wrong bytes size calculation for queues
- New functionality to count bytes sent to Devo Platform (shown in console log)
- Upgraded internal Python dependency DevoSDK to v5.0.4
- Fixed bug in persistence management process, related to persistence reset
- Aligned source code typing to be aligned with Python 3.9.x
- Inject environment property from user config
- Obfuscation service can be now configured from user config and module definition
- Obfuscation service can now obfuscate items inside arrays
- Ensure special characters are properly sent to the platform
- Changed log level to some messages from info to debug
- Changed some wrong log messages
- Upgraded some internal dependencies
- Changed queue passed to setup instance constructor | `-` |
| `v1.3.0` | 10/26/2022 | [IMPROVEMENT] | **Improvements:**
- Updated `Devo Collector SDK` from version `1.3.0` to `1.4.3b` including the following changes:
- Added log traces for knowing the execution environment status (debug mode)
- Fixes in the current puller template version
- The Docker container exits with the proper error code
- New controlled stopping condition when any input thread fatally fails
- Improved log trace details when runtime exceptions happen
- Refactored source code structure
- New "templates" functionality
- Functionality for detecting some system signals for starting the controlled stopping
- Input objects sends again the internal messages to `devo.collectors.out` table | `Recommended version` |
| `v1.2.1` | 6/9/2022 | [IMPROVEMENT] | **Improvements:**
The underlying collector framework has been upgraded from v1.1.4 to v1.3.0 that includes the following resilience improvements for input services:
- When an exception is raised by the Collector Setup, the collector retries after 5 seconds. For consecutive exceptions, the waiting time is multiplied by 5 until hits 1800 seconds, which is the maximum waiting time allowed. No maximum retries are applied.
- When an exception is raised by the Collector pull method, the collector retries after 5 seconds. For consecutive exceptions, the waiting time is multiplied by 5 until hits 1800 seconds, which is the maximum waiting time allowed. No maximum retries are applied.
- When an exception is raised by the Collector pre-pull method, the collector retries after 30 seconds. No maximum retries are applied.
SDK changes from version v1.2.0
- Bug fixed related to lookup sending (not all collectors are really using the lookup sending)
- New functionality for starting a controlled collector restarting when the re-connection is not possible
- New validations have been included to avoid (human) configuration errors in the Lookups Factory Service.
- New improved re-connection behavior
- Updated internal libraries for removing some security vulnerabilities
- Added some console log traces about memory usage and sending stats | `Update` |