In this lesson we will cover:
– What is the SentinelOne integration?
– How to connect to SentinelOne
– Import customers from SentinelOne
– Import Endpoints (Assets) from SentinelOne
– Syncing alerts
– Outbound Request tab
What is the SentinelOne integration?
The SentinelOne integration allows you to import customers, sites and endpoints (assets) from SentinelOne into Halo. Alerting is also supported, alerts and threats in SentinelOne can create tickets in Halo, alerts/threats can be updated from Halo and when the respective ticket is closed in Halo this will then resolve the alert in SentinelOne.
This integration is multi-tenanted, allowing you to connect multiple SentinelOne instances to a single Halo instance.
How to connect to SentinelOne
First head to configuration > integrations, and enable the SentinelOne integration module. Once enabled click into the integration module and create a new tenant to begin configuring the connection.
Fig 1. Enable integration module
Under the details tab you will need to enter the URL of your SentinelOne instance along with an API Token.
Fig 2. Connection details for SentinelOne
The URL will be the URL you use to access your SentinelOne instance.
There are two ways an API token can be generated in SentinelOne, either from a console user account or a service user account.
If you are generating the token from a console user account the token will expire after 31 days, this means a new token will need to be generated (and updated in Halo) every 30 days. Regenerating the API token every 30 days is recommended for security purposes.
The token can also be generated from a service user account, when generating this way you can choose the lifetime of the token so it does not need to be re-generated as often. To do this you will need to create a new service user in SentinelOne.
Generate API token from console User
Head into your SentinelOne management console > select your user profile in the top right > actions > API Token Operations > select 'Generate API token' copy this token to a clipboard. If you have previously generated a token the button will be titled 'Regenerate API token'. Navigate back to Halo and paste the token into the 'API Token' field.
Fig 3. Generate API token from console user
Note: The user logged in and generating the token must have Admin-level access.
Generate API token from service User
Head into your SentinelOne management console > settings > users > service users > actions > create new service user.
Fig 4. Create new service user in SentinelOne
When creating the service user you can set the expiry date of the user, this will determine when the token generated from this user will expire.
Fig 5. Create new service user in SentinelOne
The service user will need 'Account' scope of access and you will need to assign the user a role that has access to view all your endpoints, agents and accounts as well as create/edit/resolve alerts.
Note: The permissions of the service user will be given to Halo therefore if the service user does not have permission to view certain endpoints Halo will not be able to import these endpoints as assets.
Fig 6. Scope of access for service user
Once you have given the service user the correct access hit 'Create User', a pop-up window will now appear containing the API token for the user. Copy and paste this token into Halo.
Once the details are entered save these, the 'Test Configuration' button can be used to confirm you have connected successfully.
Import/Map Customers from SentinelOne
SentinelOne accounts can be mapped to Halo customers, this allows assets to be assigned to the correct customer/site in Halo when imported. This also allows for alerts/threats to be assigned to the respective customer/site when a ticket is created for the alert/threat in Halo. This also allows for changes to accounts in SentinelOne to be synced to Halo and update the mapped customer. Customer updates/syncing will only occur when sites/customers are imported manually using the 'Import Customers' and 'Import Sites' buttons under the 'Customers' tab.
To create customer mappings head to the 'Customers' tab, here you will see the customer and site mappings table. If you already have customers and sites setup in your Halo instance you will need to map each SenintelOne account to their respective Halo customer and each SentinelOne site to their respective Halo site.
If you do not have your customers/sites setup in Halo you can import them from SentinelOne using the 'Import Customers' and 'Import Sites' buttons, customers must be imported before sites. When a customer/site has been imported they will automatically be added to the mappings table.
Fig 7. Import customers
Import Endpoints (Assets)
Endpoints from SentinelOne can be imported into Halo as assets. Head to the 'Assets' tab to begin configuring the import.
Fig 8. Asset import configuration
Asset matching Field – Here you can set which field is used to match assets in SentinelOne to assets in Halo. The asset unique identifier field should be selected here.
Default Site – Here you will need to set the site Assets will be created under if they cannot be matched to a Halo site.
The site the asset is imported to will be determined on the customer/site mappings configured earlier. The site the endpoint is assigned to in SentinelOne will be checked, if there is a mapping for this site the asset will be created under the mapped Halo site. If no mapping exists the asset will be created under the chosen default site.
Don't update the asset site for existing or matched assets – When this setting is enabled assets will be imported to a site in line with the site mappings, but after the initial import their site will not change. This allows you to change the endpoint site in SentinelOne without this changing the site of the asset in Halo.
Asset Fields
Mappings can be configured to ensure data from SentinelOne fields are imported into a chosen Halo field. Create a mapping by adding to the 'Field mappings' table.
Field Type – This will be the type of Halo field the data will be imported into. See our lesson on Asset Fields if you are unsure on the difference between asset fields and custom fields in Halo.
Fig 9. Asset field mappings
Determine an Asset's type
When assets are imported from SentinelOne a new asset in Halo will be created, as SentinelOne does not have a concept of 'asset types' we will need to configure how the type of new assets created from SentinelOne are determined. This is done using the 'Determining an Asset's type' field.
Fig 10. 'Determining an Asset's type' field
Use the same type for all Assets
If you would like all imported assets to have the same asset type when imported set the 'Determining an Asset's type' field to be 'use the same type for all Assets' then set the 'Default Asset Type' field to be the asset type you would like assets from SentinelOne to be. In the figure 11 example all assets will be created as 'Application service' asset types.
Fig 11. Use the same time for all assets example
Use a field to determine each Asset's type
If you would like all imported assets' types to be determined by a particular field, set the set the 'Determining an Asset's type' field to be 'Use a field to determine each Asset's type'. This setting is used if you have a field in SentinelOne that already determines an asset's type and you would like the types to be consistent between Halo and SentinelOne. Then in 'Field for determining an Asset's type' choose the field you would like the type to depend on. The field you choose must contain the name of the desired asset type, if this name can be matched to an existing asset type in Halo, it will be assigned this asset type. If the name is not the same as an asset type in Halo, a new asset type will be created. Note that the names must be identical in order to match. You will still need to populate the default asset type and group fields as assets that do not have the selected field populated will be imported as the default asset type. New asset types created by SentinelOne will be created under the default asset group.
In the figure 12 example new assets will be assigned to an asset type in Halo based on their 'machineType' field. If the data in the machineType field matches the name of an asset type in Halo this asset will be created under the matched asset type. If a match cannot be made a new asset type will be created, under the asset group 'Network Equipment'. If the asset does not have the 'machineType' field populated the asset will be created under the default asset type, 'Application Server'.
Fig 12. Using field to determine asset's type example
Determine Asset type using rules
If you would like asset types to be determined by asset rules set the set the 'Determining an Asset's type' field to be 'Determine asset type using rules'. Now a table will appear and you will be able to set asset's types based on rules, These rules are based on field values, and if matched will assign an asset to the chosen asset type. When creating a rule first add criteria for the rule, select the Halo field that you would like to base the criteria on, then set the rule type and the outcome needed in the field to match the rule. If an asset matches this rule it will be imported as this asset type.
When adding an asset type rule you will notice the option *Determine Asset Type using a field*. When this is selected you can choose a SentinelOne field, an asset type will be created using the data within this SentinelOne field. If this field matches the name of an existing Halo asset type the asset will be created under this type, otherwise a new asset will be created. This works in the same way as when 'Use a field to determine each Asset's type' is selected in the 'Determining an Asset's type' field. This is available as an additional rule as more rules can be configured for assets that do not have this field or have data in this field. That is, some asset types can be determined based on a field, for other assets that do not use this field their type can be determined by other rules or another field.
If an asset is imported that does not match any of these rules, it will be created under the default asset type.
Miscellaneous settings
Fig 13. Miscellaneous settings for asset imports
Don't create new Assets – When enabled assets will only be updated, no new assets will be created by SentinelOne
Status of New Assets – This determines the status assets will have when imported from SentinelOne
Deactivate Assets in Halo when they are deleted from SentinelOne (Halo Integrator only) – When enabled assets will be deactivated in Halo (status change to 'Inactive') when they are deleted in SentinelOne. This setting works in conjunction with the Halo integrator, and assets will only be disabled when a sync runs using the integrator.
Import/update assets on a schedule
To have assets imported/update on a recurring schedule head to the 'Syncing' tab and enable 'Enable the Halo Integrator for the SentinelOne integration'. Once enabled ensure 'Assets' are selected in the following field. The integrator will run daily for asset updates.
Fig 14. Enable asset syncing
Alerting
Alerts and threats raised in SentinelOne can log tickets in Halo allowing technicians to manage these alerts and threats from Halo.
To configure how these tickets are created head to the 'Syncing' tab.
Fig 15. Syncing tab
In the 'Halo Ticket Type' field choose the Halo ticket type you would like to be created for alerts and threats (you may wish to create a new ticket type for this). Many defaults for the alert/threat ticket that is logged, such as, team, SLA and priority will be taken from the ticket type chosen here. However, if the severity of the alert in SentinelOne has a name that matched
In the 'Halo User' field choose the user you would like these tickets to be assigned to. It is best to choose a generic user here, then the alert/threat can be assigned to the affected user either manually or using ticket rules. See our lesson on ticket rules here.
Now to enable the sync of alerts and threats enable the Halo integrator for the integration and ensure 'Alerts' and/or 'Threats' are selected in the 'entities to sync' field. Alerts and Threats will be imported in a separate schedule to assets, these will be synced more frequently than assets. These should be on a separate schedule automatically but if when enabling alerts these seem to be syncing on the same schedule as your assets contact our support team so we can have these moved to separate schedules.
Now when a threat and/or alerts is raised in SentinelOne a ticket will be logged in Halo. Technicians can work on the ticket in Halo and sync updates on the alerts/threat back to SentinelOne. When the threat/alert is resolved and the technician closes the ticket in Halo the alert/threat in SentinelOne will be marked as resolved.
Alert severity/priority
Alerts/Threats imported from SentinelOne will have their severity checked when being imported, if the severity matches the name of a priority in Halo the ticket will be created with this priority. If they cannot be matched the default priority of the ticket will be used.
Outbound Requests Tab
Under the 'Outbound Requests' tab you will be able to see a log of each request sent from Halo to SentinelOne. This will include alert/threat updates and closures. A log can be selected to show more detail.
