SentinelOne Response Integration via API

Purpose

This guide explains how to configure the SentinelOne response integration in Logsign so that analysts can trigger endpoint containment and eradication actions directly from an Incident or Alarm, without switching to the SentinelOne Management Console. Once configured, you can terminate a malicious process, quarantine or kill a detected threat, suspend a threat, or isolate an agent from the network, all from within Logsign.

This is a separate feature from the SentinelOne log collection poller. The poller pulls Threats, Device Control, and Deep Visibility events from SentinelOne into Logsign on a schedule. This integration does the opposite: it sends action requests out to SentinelOne on demand, typically from a playbook or a manual action attached to an Incident or Alarm. If you already configured the poller for log collection, you still need to configure this integration separately under Responses, since they use different configuration screens in Logsign even though both talk to the same SentinelOne console.

Prerequisites

You need a SentinelOne Management Console with API access and an API token generated for a Service User with permission to mitigate threats and act on agents. You also need your console's management URL (referred to below as the API domain), and Logsign 6.3.17 or later, matching the minimum version used by other Responses-module integrations; this specific minimum was not independently verified against Logsign release notes for this integration.

Use least privilege, not the Admin role. SentinelOne's built-in roles are Viewer, C-Level, IT, SOC, IR Team, and Admin, plus fully Custom roles on Singularity Complete and higher plans. Viewer is read-only and will not work here, since this integration performs write actions (threat mitigation and agent network isolation), not just data collection. Based on SentinelOne's public documentation and blog material on role-based access control, the built-in IR Team role is intended for incident response actions of this kind and is a reasonable choice if Custom roles are not available on your plan. If your plan includes Custom roles, build one scoped to threat mitigation and agent action permissions only, rather than granting Admin. The exact names of the granular Custom Role permissions for threat mitigation and agent actions are not published in SentinelOne's public documentation and were not independently verified against a live console; if you use a Custom role, review the permission list on the Custom Role creation screen in your own console (Settings > Users > Roles) before assigning it.

Step 1: Generate a least-privilege API token in SentinelOne

Log in to your SentinelOne Management Console and go to Settings, then select the Users tab, then Service Users. Service Users are API-only accounts, not tied to a person's console login, which makes them easier to trace and revoke independently of any individual's credentials.

• Click Actions, then Create New Service User.
• Enter a Name and Description that identify this token as belonging to the Logsign response integration, and set an Expiration Date. SentinelOne API tokens are time-limited; plan to rotate the token before it expires, since an expired token will stop every method below from working until it is replaced.
• Click Next, then choose the Scope (Global, Account, or Site) that matches which part of your SentinelOne environment Logsign should be able to act on, and select the Account(s) or Site(s) accordingly.
• For the Role, select IR Team, or a Custom role scoped to threat mitigation and agent actions if your plan supports Custom roles. Do not select Admin.
• Click Create User. In the confirmation window, click Copy API Token to copy the token to your clipboard, or Download API Token to save a copy. SentinelOne shows this token only once; if you close the window without copying it, you will need to create a new Service User (or rotate the existing one) to get a new token.

While you are in the console, note your API domain. This is the hostname shown in your browser's address bar when you are logged into the SentinelOne console, for example usea1-partners.sentinelone.net. You will need this in Step 2.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for SentinelOne, click Configure, then +Device to add a new configuration. Fill in the following fields:

Click Create to save. Once saved, this configuration becomes available as a Device inside Logsign's Incident and Alarm response actions, where you pick one of the methods below and supply its parameters (typically a threat ID or agent ID pulled from the alarm itself).

Available Methods

All five methods below take a single ID parameter and issue one POST request to SentinelOne per call. Each parameter field supports Logsign's mention-input format, meaning you can reference a value from the triggering alarm or incident instead of typing it manually. None of the methods currently support acting on more than one threat or agent per call, even though SentinelOne's own API supports batch operations on multiple IDs at once.

Terminate (terminate)

Kills the malicious process associated with the threat and removes the underlying malicious file from the endpoint. This is classified in Logsign as an Eradication action.

Returns a result object with success (boolean), message (text from SentinelOne describing the outcome), and threatId (echoes the ID you supplied).

Quarantine (quarantine)

Moves the detected threat into SentinelOne's quarantine, isolating the malicious file without necessarily terminating an already-running process. Classified as a Containment action.

Returns success, message, and threatId, same shape as Terminate.

Kill Threat (kill_threat)

Kills the active malicious process tied to the threat without the broader file removal that Terminate performs. Classified as an Eradication action.

Returns success, message, and threatId.

Suspend Threat (suspend_threat)

Suspends the threat's activity on the endpoint. Classified as a Containment action.

Returns success, message, and threatId.

Network Quarantine (network_quarantine)

Intended to isolate a SentinelOne agent from the network while leaving the SentinelOne agent itself able to communicate with the Management Console, so the endpoint can still be investigated and remediated remotely. Classified as a Containment action. Unlike the four methods above, this one acts on an agent, not a threat.

Returns a result object with success, message, and agentId instead of threatId.

Notes and Limits

• This integration is a Response (Action) integration for on-demand threat and agent actions during Incident/Alarm handling. It does not collect or ingest SentinelOne data as a log source; that is handled by the separate SentinelOne API poller, which has its own configuration screen under Settings > Data Collection > API.
• The built-in connection test (the check Logsign runs when you save or test the device) does not make any HTTP call to SentinelOne in the current implementation; based on a review of the integration's source code, it returns immediately without contacting your console. A test that appears to succeed does not confirm that the Host or Api Token are actually correct. Verify a new configuration by running one of the five methods above against a real threat or agent ID and checking the result, rather than relying on the test alone.
• Each method call acts on exactly one threat ID or agent ID. If you need to act on multiple threats or agents from a single alarm, you currently need to invoke the method once per ID.
• The Insecure Skip Verify option defaults to on. Review and disable it after configuration unless you specifically need it for a TLS-inspecting proxy in front of your SentinelOne console.
• The Host field only accepts your bare API domain. Do not include https://, a port, or any path, since Logsign constructs the full request URL from this value automatically. See Step 2 and the Troubleshooting table below.
• Based on a review of the integration's source code, action calls may currently return an unexpected or internal-looking error even when the Host and Api Token are both correct and the threat or agent ID is valid. This was not confirmed with a live test against a SentinelOne tenant, so it should not be assumed to affect every environment, but if you see this behavior consistently across different threat and agent IDs, it is worth opening a ticket with Logsign support and referencing this note rather than continuing to re-check your own configuration.

Troubleshooting