SentinelOne collector

[ 1 Configuration requirements ] [ 2 Overview ] [ 3 Devo collector features ] [ 4 Data source ] [ 5 Vendor setup ] [ 6 Minimum configuration required for basic pulling ] [ 7 Accepted authentication methods ] [ 8 Run the collector ] [ 9 Change log ]

Configuration requirements

Configuration	Details

Configuration	Details
API Token	You will need to generate a SentinelOne API Token.

More information

Refer to the Vendor setup section to know more about these configurations.

Overview

SentinelOne 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

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

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

In order to configure the SentinelOne collector, you need to generate a SentinelOne API token. Follow these steps to do it:

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

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

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).

Change log

Release	Released on	Release type	Details	Recommendations

Release	Released on	Release type	Details	Recommendations
`v1.5.0`	Jan 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`	Aug 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`	Oct 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`	Jun 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`