Skip to main content

SentinelOne Data Connector

Learn how to automatically ingest SentinelOne threats and alerts into Torq to enable Auto Triage and trigger response workflows.

Overview

The SentinelOne Data Connector provides a native, polling-based ingestion mechanism that continuously brings threats and alerts into Torq for use in workflows and Auto Triage.

Key benefits include:

  • Simplified setup: Configure ingestion through a guided UI, no need to build custom polling workflows, manage API logic, or implement deduplication.

  • Continuous event ingestion: Threats and alerts are retrieved automatically at regular intervals, ensuring a steady flow of data into Torq workflows.

  • Flexible routing: Route ingested events to Workflows, Auto Triage, or both, depending on your automation needs.

  • Historical backfill: During setup, configure a lookback window (up to 14 days) to ingest past events and immediately populate workflows or Auto Triage.

  • Granular filtering: Use JSON filters, Account IDs, and Site IDs to precisely scope which events are ingested, supporting MSSP and multi-tenant environments.

  • Built-in reliability: Handle pagination, state tracking, and duplicate detection automatically, ensuring accurate and consistent event processing.

Common scenarios

Automated triage and case creation from SentinelOne detections

The SentinelOne Data Connector enables security teams to automatically route threats and alerts into Torq’s Auto Triage, where events are enriched, analyzed, and converted into investigation cases. These cases consolidate detection data, enrichment results, and context into a single workspace for efficient analysis and response.

Case-driven response and investigation workflows

Once alerts are triaged, Torq workflows can be triggered to support both reactive response and proactive investigation. These workflows enrich events with additional context, correlate data across tools, collect evidence, create tickets, and execute automated containment or remediation actions, supporting both incident response and threat hunting operations.

Prerequisites

Before setting up the SentinelOne data connector, ensure the following requirements are met:

  • SentinelOne subscription:

    • Threats: Available on all paid SentinelOne plans (Core, Control, Complete).

    • Alerts (STAR alerts): Require a Singularity Complete subscription with STAR enabled.

    • Some alert types depend on additional entitlements. If not enabled, the connector may not return expected results.

  • Service user setup: Create a service user in the SentinelOne console prior to configuration.

  • Permissions: Ensure the service user has sufficient permissions to access threats and alerts APIs. Missing permissions may result in incomplete or failed data ingestion.

How to use

Create a SentinelOne service user

Follow these steps to create a service user and obtain an API token:

  1. Navigate to Service Users: Go to Settings > USERS > Service Users.

  2. Create service user: Select Actions > Create New Service User. Then, provide a name, and set an expiration date.

  3. Configure scope and role:

    • Select scope: Account or Site.

    • Assign the Viewer role (minimum required for read-only access to threats and alerts).

    • If selecting Account: Choose the account, then assign the Viewer role.

    • If selecting Site: First select the account, then choose one or more sites.

    • Complete MFA verification: Confirm the action by completing MFA validation.

  4. Copy API token: Copy the API token when displayed. It is shown only once and cannot be retrieved later.

Set up a data connector instance

  1. Open connector setup: Go to Integrations > Triggers > SentinelOne Data Connector > Add Instance.

  2. Configure connection details:

    • Name: Enter a descriptive name for the connector instance

    • Management URL: Enter your SentinelOne management URL

    • API key: Provide your SentinelOne API key

  3. Set backfill (optional): Configure a lookback period (up to 14 days) to ingest historical data. This option is only available during initial setup.

  4. Select routing destination: Choose where ingested events will be sent:

    • Workflows

    • Auto-Triage

  5. Select event types: Choose which events to ingest:

    • Alerts

    • Threats

  6. (Optional) Configure filters:

    • Alert filters (JSON): Upload JSON to filter alert ingestion (see Configure alert filters section below)

    • Threat filters (JSON): Upload JSON to filter threat ingestion (see Configure threat filters section below)

  7. (Optional) Scope ingestion:

    • Accounts: Select specific accounts

    • Sites: Select specific sites

      Leave empty to ingest from all accessible accounts and sites.

  8. Save configuration: Click Add to create the connector. Ingestion starts automatically.

When you edit an existing SentinelOne instance, the past data ingestion period cannot be changed. To change it, delete the instance and create a new one.

You’ve successfully set up the SentinelOne Data Connector in Torq. With the instance configured, Torq will continuously ingest threats and alerts from your SentinelOne environment and automatically trigger workflows and Auto Triage based on those events.

Example: Configure filters

Use filters to control which alerts and threats are ingested, helping you focus on relevant events and reduce noise.

Configure alert filters

Use filters to control which alert events are ingested from SentinelOne’s GET /cloud-detection/alerts endpoint. You can control exactly which alerts are returned by providing a Filters JSON object in the step configuration.

Add filters

  • Define filters: Enter a JSON object where each key is a parameter and each value defines the filter criteria.

  • Use relevant parameters only: Include only the parameters required for your use case; omitted parameters do not affect results.

Example: Fetch high-severity unresolved alerts:

{
  "severity": "High,Critical",
  "incidentStatus": "IN_PROGRESS,UNRESOLVED"
}

Common parameters

Use these parameters for most SOC automation scenarios:

Parameter

Description

Example

severity

Filter by alert severity

"High,Critical"

incidentStatus

Filter by incident status

"IN_PROGRESS,UNRESOLVED"

analystVerdict

Filter by analyst verdict

"TRUE_POSITIVE,FALSE_POSITIVE"

ruleName__contains

Filter by detection rule name (partial match)

"STAR-rule,lateral-movement"

createdAt__lte

Return alerts created before a timestamp (ISO 8601)

"2024-01-16T00:00:00.000000Z"

reportedAt__gte

Return alerts reported after a timestamp (ISO 8601)

"2024-01-15T00:00:00.000000Z"

osType

Filter by operating system

"windows,macos,linux"

sortBy

Field to sort results by

"createdAt"

sortOrder

Sort direction (asc or desc)

"desc"

Format requirements

  • Use comma-separated values.

  • Do not use JSON arrays.

  • Correct format: "value1,value2"

  • Incorrect format: ["value1", "value2"]

Key differences from threat filters

Alert filters differ slightly from threat filters:

  • Use incidentStatus instead of incidentStatuses.

  • Use analystVerdict instead of analystVerdicts.

  • Use osType instead of osTypes.

  • Alerts include severity and rule name fields.

Configure threat filters

You can control which threats are ingested from SentinelOne’s GET /threats endpoint by providing a JSON object in the Filters field. Each parameter narrows the results returned.

Add filters

  • Define filters: Enter a JSON object where each key is a parameter and each value defines the filter criteria.

  • Use relevant parameters only: Include only the parameters required for your use case; omitted parameters do not affect results.

Example: Fetch unresolved malicious threats:

{
  "confidenceLevels": "malicious",
  "incidentStatuses": "unresolved"
}

Common parameters

Use these parameters for most SOC automation scenarios:

Parameter

Description

Example

confidenceLevels

Filter by threat confidence level

"malicious,suspicious"

analystVerdicts

Filter by analyst verdict

"true_positive"

incidentStatuses

Filter by incident status

"unresolved,in_progress"

mitigationStatuses

Filter by mitigation state

"not_mitigated"

createdAt__lte

Return threats created before a timestamp (ISO 8601)

"2024-01-16T00:00:00.000000Z"

computerName__contains

Filter by endpoint name (partial match)

"DESKTOP-,john-laptop"

osTypes

Filter by operating system

"windows,macos,linux"

resolved

Filter by resolution status

false

sortBy

Field to sort results by

"createdAt"

sortOrder

Sort direction (asc or desc)

"desc"

Format requirements

  • Use comma-separated values: Do not use JSON arrays.

  • Correct format: "value1,value2,value3"

  • Incorrect format: ["value1", "value2"]

Related Articles
Elastic Security
SentinelOne
Workflow Template: Create Cases from SentinelOne Events found in Azure Sentinel
Workflow Template: Poll for new SentinelOne Threats and Open a Torq Case
Workflow Template: Microsoft Defender for Endpoint Triage HyperAgent
Did this answer your question?