TEAM: Huntress Managed Security Information and Event Management (SIEM)
PRODUCT: API Log Source
ENVIRONMENT: SentinelOne
SUMMARY: Configuration Guide for Sentinel One Activity Ingestion
Vendor Information
| Vendor | SentinelOne |
|---|---|
| Collection Method | API |
| Query Syntax: | event.provider == "Syslog-SentinelOne" |
| Billable Sources Calculation | 1 Endpoint Source Per Endpoint with an S1 Agent |
| Additional Information | Configuration is restricted to the Huntress Account level. Organizations will be mapped to enforce data segregation. |
Source Configuration
Create a Role for the Service User
- In the SentinelOne management console, go to
Settings, selectUSERS, and then selectRoles. - Select the built-in
Viewerrole, then chooseDuplicate Rolein the Actions drop down menu

- Provide a name for the new user role (e.g. Huntress SIEM Integration) then select
NEXT. - Navigate to the following sections and add the noted permissions:
Console Integrations(View, Edit,Create)Notification Settings(View, Edit,Create)
Create Service User
- In the SentinelOne management console, go to
Settings, selectUSERS, and then selectService Users. - Create a new
Service Userby specifying a name and an expiration date, then clickNext. - On the Scope of Access screen, you will want to select Account in the Access Level box (allows you to use a single token to map all SentinelOne Sites within Huntress). Make sure the new Role is selected in the drop-down box next to your site name before proceeding.
- Click
Create Userto obtain the API token. - Securely copy the API token for the service user, then choose
Close.
The API token you generate is time-limited. To generate a new token (and invalidate the old one), you may need to copy the Service User. Please refer to the SentinelOne documentation for more information on how to perform these steps.
Create Huntress Integration
- Navigate to Huntress SIEM -> Source Management -> SentinelOne
Select the green +Add button to create a new SentinelOne configuration.
Enter the details of the configuration as needed, including the API key obtained in the first two steps. Save the configuration. The Default Organization will be where logs that aren't endpoint or site-specific will be stored.
After saving, you'll be directed to the Configure page where you will need to map the organizations between SentinelOne and Huntress. For each SentinelOne Site, select a Huntress equivalent organization from the dropdown. Any data received from unmapped organizations will be discarded.
The License Count column will determine the number of data sources billed per mapped organization.
Any data received from SentinelOne for a Site that is not mapped will be discarded.
Once the organizations have been mapped, the SentinelOne configuration page will show the mapped log sources.
Common Errors:
"Unable to create SentinelOne data source: Syslog already setup"
When adding a new SentinelOne connection into Huntress SIEM if you get the above error this means there's already a syslog integration already setup inside SentinelOne. You'll need to remove that existing syslog integration in SentinelOne before you'll be able to connect Huntress SIEM.
"Unable to create SentinelOne data source: Insufficient permissions"
This error inside the Huntress dashboard indicates the SentinelOne Service User or Role created for the Huntress SIEM integration doesn't have sufficient permissions for the integration to be initiated. Carefully review all the permissions created in the first two sections of this guide. You should also verify the new Service User you created is assigned to the new Role you created, this is typically done at the "Scope of Access" window but can also be seen/edited in the Service User menu.
Using Third Party EDR and AV Log Sources
Huntress has developed several third-party EDR and AV SIEM integrations in order to provide visibility in the Huntress platform into those third party activities and findings. We have developed several detections that surface third party detections to the Huntress SOC, and leverage that data for investigations. While this increases the visibility of the Huntress SOC into customers environments with alternative EDR/AV solutions, there are certain limitations that partners should be aware of.
Limitations
- These are one-way integrations that ingest high level alert and solution audit activity from the third party solutions. Raw telemetry is not included as that accounts for a significant amount of data that would rapidly overwhelm account data pools. Most EDR solutions store endpoint telemetry within the solution for a limited amount of time to meet compliance requirements, as generally storing raw endpoint telemetry is not suitable for SIEM ingestion.
- Huntress has no ability to leverage response actions of third party agents. If the Huntress agent is not installed in parallel, the Huntress SOC investigation capability will be limited to what other SIEM sources are available for that endpoint. For example firewall and cloud log sources.
- Huntress does not have the ability to manage third party agents or platforms, or update the state of third party detections within that solution console.
Benefits
- In scenarios where you have an organization or subset of endpoints with only the third party agent installed, the Huntress SOC will have very limited insight into that endpoint. However the detection alerts from that third party agent do provide a minimum amount of visibility into that particular endpoint.
- In scenarios where you have an organization or subset of endpoints with both the Huntress and the third party agent installed, for example with SIEM or EDR customers, the SOC can take remediation actions through the Huntress agent when the third party agent indicates an investigation is warranted.
Third party EDR integrations are provided to ensure Huntress can service and protect partners to the best possible ability given a diversity of contracted services and agents.