SentinelOne API Feed Integration

Have you tried the current integration just for verification that the S1 API works? Do you have the verify SSL checked on both the integration and connector?

We're planning to implement the same SentinelOne ingestion, very interested to know the details surrounding this ingestion.

Dear @PhaniY @stefancoook1 ,

I'm wondering, are you speaking about SentinelOne event ingestion into Chronicle SIEM ?
Or are you speaking about using Chronicle SOAR integration and/or connector for SentinelOne ?

We are only using the Chronicle SOAR integration for SentinelOne and it is working fine with a SaaS version of SentinelOne Management Console and with "Verify SSL" option checked.

Louis 

I'm having the same issue, did you resolve? How?

Thank you

As I run a MSSP, I have one Shared Instance of the Integration, and each client has a connector that uses the SentinelOne Site ID as an alias in their Environments setup and in the connector to link the clients alerts in their respective environments. 

On the Shared S1 Integration, you need the URL of you management URL and the API token (I recommend setting up a service user and a 1-2 year token), you need to check the box by Verify SSL.

The service user in S1 console can be created here:

Once this is setup hit test and it should come back with a green check. 

Then on the connector side, I have one for each client. I use the SiteID section, you may not need this. Same URL and API Token as the Integration. You will need to assign the correct or Default environment, save and test, It should come back on the right hand side with an ok at the bottom and if there are any alerts they will show on the left hand section.  

In each client's environment, I use the alias field to link the SentinelOne SIteID to the Environment. I also have a custom connector for this as well with a few lines of extra code.

We have one master shared playbook that handles all clients. We only deviate if the client needs something different. In the custom trigger we use [alert.environment] != <environment> in those cases. We are different as we add custom IOCs via API at the account level to S1, so our playbook has to account for 'user-blocklist'. We also use Blocks for the action part of the playbook. 

Our playbook looks like this: The MDK name comes from Demolition Man. 

I hope this helps

Hello @PhaniY @Roberto_Del 

You have to enter the API key in the correct format

 “Authorization: ApiToken <Your Token>”