Help CenterThreatLocker Detect allows you to integrate with your SIEM. This can be done with any SIEM security tool as long as you have the proper parameters set up beforehand. This requires an HTTP Event Collector or other methods to allow sending logs to your SIEM.
Once you have fully set up your SIEM, you can now create a ThreatLocker Detect Policy (or Cloud Detect Policy) that will forward a log to the SIEM whenever the policy’s parameters are met. In this example, we will be setting up a ThreatLocker Detect policy to log any ‘Deny (Option to Request)’ into your SIEM.
To start, select the ‘Modules’ dropdown using the left-hand menu in the ThreatLocker Portal.
To create a Cloud Detect policy, select the ‘Microsoft 365’ option from the ‘Modules’ dropdown:
Then select the ‘Microsoft 365 Detect’ tab from the top right corner of the page:
For either option, select the ‘+ New Policy’ button in the top left corner of the page.
A side panel will now open titled ‘Create Endpoint Detect Policy’.
In here, you will be able create your new policy. Start by naming it, selecting an icon from the available list, and providing a description of what the policy does.
In the ‘Applies To’ section, confirm that this applies to the correct group or machine. It is recommended that this be kept at the ‘Entire Organization’ level.
In the ‘Policy Conditions’ section, use the dropdown menu to select your conditions. For this example, we will be selecting ‘Policy Action’ from the dropdown labeled ‘If ALL Conditions Are True’. Select ‘Matches’ from the ‘Operator’ dropdown, then select ‘Deny (Option to Request)’ in the ‘Value’ dropdown menu.
Selecting conditions from the ‘If ALL Conditions Are True’ section requires all the conditions to be met before notifying you. Select the green ‘+’ button to add more conditions to this section if necessary.
You can also add additional conditions to the dropdown underneath. This dropdown is labeled ‘If ANY Conditions Are True’ and is used to meet the qualifications that conditions from the ‘If All Conditions Are True’ section are true AND at least one condition is true in the ‘If ANY Conditions Are True’ section.
For this example, we will only be using the ‘Policy Action’ condition shown above.
Next, navigate to the ‘Policy Actions’ section. Here, you will see a dropdown with several different options. The ones that will usually pertain to your SIEM integration will be as follows:
-
Call Rest API – This will make an HTTP request to a REST API and perform operations like data retrieval, deletion, creation, and more.
-
Call Rest API (Client) - A client application or service that makes HTTP requests to REST API.
-
Call Webhook – Sends data to a Webhook (a predefined URL) when an event occurs. This aids in real-time communication between systems.
-
Call Webhook (Client) - A client application or service that triggers a webhook, sending data to a predefined URL whenever an event occurs.
Note: ThreatLocker recommends using the Client option. This option is faster as the event will be sent directly from the agent to the SIEM.
Now, for any of the listed options above, you will be required to enter the following information:
Method – The following options will be available:
-
GET – Retrieve data from a server.
-
POST – Send data to a server. (Will be used in this example as we want to send data to our SIEM).
-
PUT – Updating a resource that already exists on the server.
-
DELETE – Used to remove a resource from a server.
-
PATCH – Used to apply partial updates to a resource.
URL - Here, you will enter the URL of your HTTP Event Collector, or whichever version of this is available for your SIEM. The URL will differ depending on which SIEM you are using. Be sure to look up the proper syntax depending on which resource you use.
Content Type - You can modify the content type of your API call. This is left to its default value in this example.
Headers - You will need to enter your event collector's authorization token here. This information can differ depending on which SIEM you are using.
Body - This is where you can modify the body to include any information you want to log into your SIEM. You can use {"event":"", "sourcetype": ""} in the body, where event will contain all the data you'd like to send and sourcetype is your own defined sourcetype. In the example below, we're sending over all the available information within the Unified Audit, using variables to insert different values in the body during processing.
If you select the ‘Call Rest API’ action within the dropdown, an additional dropdown will be available to you called ‘Authorization Token Response (Optional)’. This is to use a Bearer token in the event that your SIEM needs one. Expand below to see the configuration ThreatLocker used when building and testing the Bearer token ability.
Bearer Token Instructions
Select 'Call Rest API'.
Method: POST
URL: Insert the URL of the HTTP Event Collector
Content Type: application/x-www-form-urlencoded
Headers: Blank
Body: This is where you can modify the body to include any information you want to log into your SIEM.
Authorization Token Response (Optional): Select OAuth
Authorization Token Response Headers (Optional): Blank
Authorization Token Request Parameters (Optional): Insert the needed parameters. For example: client_id=, scope=, client_secret=, grant_type=
Please note: Inserting anything in the body using [] will result in [Object, object] being displayed.
Lastly, navigate to the ‘Policy Expiration’ section. Here, you can set when the policy expires. By default, there will be no policy expiration, but you can use the ‘Set Policy Expiration’ tab or ‘Schedule Policy’ tab to choose when a policy becomes active and when it expires completely.
Select the ‘Create’ button at the bottom of the page.
Your policy will now be available to view. Select ‘Deploy Policies’ once it has been created.
Your logs should now begin to populate within your SIEM.