Special thanks to @Hesham Saad from our Cybersecurity Technical Solutions Specialist team for collaborating on this blog post with me!
Customers are frequently inquiring on how to migrate smoothly from their current SIEM solution to Microsoft Sentinel.
A couple of weeks ago, we started with a solution to export data from Splunk to Microsoft Sentinel. Highly recommended to check out the blog post by our colleague @yokhaldi (How to export data from Splunk to Microsoft Sentinel), a logical sequence to his blog post is a walk-through explaining how to consume security telemetry data directly from QRadar to Microsoft Sentinel.
One of the key challenges in migrating to another SIEM is the intermediate phase. In this phase, both SIEMs are running side by side until the migration is complete. To keep a good overview (single pane of glass) of all the incidents in your deployment from both SIEMs, it is of utmost importance to have all your alerts and incidents in one place.
This blogpost will describe how you can forward all your QRadar offenses to your Microsoft Sentinel environment.
Let’s get started!
As highlighted in @Alp Babayigit’s post "Microsoft Sentinel Side-by-Side with QRadar", there are many reasons why enterprises are using multiple SIEM products simultaneously. You can use various SIEM solutions at once as a permanent measure, for example, to correlate with available data sources while using Microsoft Sentinel as the single pane of glass to centralize all incidents). However, most of the time, the side-by-side architecture is used during a transition period for migrating from one SIEM to our SIEM and SOAR solution, Microsoft Sentinel.
Why do so many enterprises transition to Microsoft Sentinel?
The current trend in many businesses is the consumption of more and more cloud services, hence the huge ask for cloud-native SIEMs. This is where Microsoft Sentinel comes to the rescue with the following advantages:
There are several best practice integration options to operate Microsoft Sentinel Side-by-Side:
|
Alerts |
Events |
Upstream to Microsoft Sentinel |
CEF Logstash Logic Apps API |
CEF Logstash |
Downstream from Microsoft Sentinel |
Security Graph Security API Powershell Logic Apps API |
API Powershell |
This blog post will explain how to ingest QRadar offense data into an Microsoft Sentinel workspace. The solution will use the QRadar API and can be adapted to query event data from the QRadar event logs. That said, there is another solution for ingesting QRadar event log data: use routing rules and forwarding destinations in QRadar.
As mentioned, this blog post will focus on getting offenses from QRadar into Microsoft Sentinel as our primary SIEM.
There are two routes we can take to get offense data into Microsoft Sentinel:
In this blog post, we will detail the second option's implementation: Let’s assume that your SOC team wants to collect offense data from QRadar according to a specific schedule/timeframe. Azure functions will schedule API calls to QRadar to pull the desired data into our workspace. The response format when requesting data from QRadar via the API is in JSON.
The following guide will explain the process step by step.
We assume the onboarding Microsoft Sentinel is completed.
If not; I would like to forward you to the following links for a quickstart on onboarding Microsoft Sentinel:
We also assume that you have an up and running QRadar environment.
(For those who want to replicate this walkthrough in a lab environment, here is a guide on how to install QRadar in Azure: Configuring a Console on Microsoft Azure (IBM) )
To accomplish the exporting of offense data from QRadar, we will invoke GET requests from the QRadar API. You will need an authentication token to authenticate the API calls that the Azure Function will make. To create an authentication token in QRadar, go to the “Manage Authorized Services” window and create a new token.
You also have to make sure the Azure Function (which we will create in a couple of steps) has HTTP access to the QRadar system to make the API calls. A guide on how to determine which IP addresses will be used by your Azure Function can be found here.
Let’s walk-through which QRadar API calls we used for this blogpost:
Use your https://<management_ip>/api_doc link to get to the interactive QRadar API documentation to access technical details for the QRadar RESTful API and then look under /siem/offenses for our get request for the offense data:
In the following screenshot, you can see which fields you can filter on in your GET request or specify the fields you want to retrieve as a response.
This blog post will not specify specific fields to retrieve; we will retrieve them all. We will, however, set a filter parameter in the API calls.
As we previously mentioned, we will schedule requests to get the offenses from QRadar into our Microsoft Sentinel environment. To make it more efficient (less data overhead), we will only ask for the offenses generated since the last scheduled request.
For example, we will schedule our Azure Function to perform an API request every 24 hours, and we will only retrieve the offenses created in the last 24 hours in QRadar.
We will filter on start_time: "The number of milliseconds since epoch when the offense was started".
(Side note: you can also change the code to retrieve the offenses updated in the last 24 hours; you need to filter on last_updated_time in the API request instead of start_time).
To export offense data from QRadar and import it into Microsoft Sentinel, we create a scheduled Azure Function invoking a GET request to the QRadar API via PowerShell code.
In the PowerShell code, we will perform the following steps:
if ("TrustAllCertsPolicy" -as [type]) {} else {
Add-Type "using System.Net;using System.Security.Cryptography.X509Certificates;public class TrustAllCertsPolicy : ICertificatePolicy {public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) {return true;}}"
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
}
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
$headers = @{}
$headers.add("Version","12.0")
$headers.add("Content-Type","application/JSON")
$Headers.add("SEC",$token)
$url = ""https://" + $consoleIP + "/api/siem/offenses?filter=start_time%3E" + $unixTime
$OffenseInfo = Invoke-RestMethod -Method GET -Headers $headers -Uri $url
You can find the complete script code on Github.
The last step in this whole procedure is to run the PowerShell script in an Azure Function that will run on a schedule and push the QRadar offense data into our Microsoft Sentinel workspace.
In the following screenshot, you can see the configuration of the Azure Function:
The logs will go to a custom Microsoft Sentinel table ‘QRadar_Offense_CL’ (if you specified the table as QRadar_Offense like in our code) as shown in the screenshot below.
And this example corresponds to the following fictional offense in QRadar:
An ARM template to automate the onboarding of the Azure Function can be found on Github.
To export offenses from QRadar and import to Microsoft Sentinel, we created a scheduled Azure Function that will invoke a GET request to the QRadar API via PowerShell and push the data into your Microsoft Sentinel workspace. We encourage you to try it yourself and leverage the next generation of SIEM for your environment. You can also contribute your new connectors, workbooks, analytics, and more in Microsoft Sentinel. Get started now by joining the Microsoft Sentinel Threat Hunters GitHub community.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.