Sending enriched Microsoft Sentinel alerts to 3rd party SIEM and Ticketing Systems

(Last updated January 18th 2021)

 

Special thanks to Ofer_Shezaf and Alp Babayigit that collaborating with me on this blog post.

 

In the blog post we will introduce a solution which uses Logic Apps to automatically attach evidence to Microsoft Sentinel alerts and send them to an Event Hub that can be consumed by a 3^rd party SIEMs and Ticketing Systems.

 

Using Sentinel alongside a 3^rd party SIEM and ticketing systems

 

From our customers engagements we learned that sometimes customers prefer to maintain their existing SIEM alongside Microsoft Sentinel.

 

Among the reasons for doing so are:

• Using Microsoft Sentinel as a cloud SIEM alongside the existing SIEM to monitor on-prem workloads.
• Using both during the transition period.

 

In addition, customers often use a ticketing system, such as Service Now or JIRA to manage incidents at the SOC and need to forward alert information to those systems.

 

Traditionally, customers forwarded alerts from Microsoft Sentinel to their existing SIEM or ticketing systems using the Graph Security API. You can do so for Splunk, QRadar, Service Now or any other SIEM or Ticketing System that supports Event Hub ingestion.

 

Microsoft Sentinel supporting evidence

 

However, in a side by side deployment, alerts from one platform need to be sent to the other to enable a single pane of glass for the analyst. To ensure efficient triaging on the primary pane of glass, the alerts have to include enough supporting information. When the 3^rd Party SIEM or ticketing system is used as the primary pane of glass, this translates to sending both Microsoft Sentinel alerts and their supporting events to this system.

 

 

When you press “Events”, you are redirected to the “Logs” screen to view the supporting events relevant to the alert. Those can be, but are not necessarily, raw events collected by Microsoft Sentinel. Instead, the alert rule determines what to present as supporting events. Learn more about how a rule controls the supporting evidence in the Microsoft Sentinel KQL lab (YouTube, deck) and the Microsoft Sentinel rule writing Webinar (YouTube, deck).

 

As an example, the following alert rule taken from the KQL Lab uses the summarize and extend keywords to produce just the data relevant to the detected anomalies:

 

Forwarding alerts with supporting events to an Event Hub

 

In this article, we demonstrate how to use Microsoft sentinel SOAR capability and leverage a Logic App playbook to send alerts with their associated supporting events to a 3rd party SIEM.

 

 

The playbook, available here, works as follows:

• The playbook triggers when an alert is created (1), this can be done automatically for each alert when it triggers, or on-demand by an analyst.
• Parse JSON actions are used throughout the playbook to transform JSON objects received to the format expected in subsequent steps.
• Query the workspace for the supporting events (2). Note that the query to fetch the supporting events is included as part of the alert extended properties.
• Send the enriched alert to an Event Hub (3).

 

The JSON that is sent to the Event Hub looks as below. The “SupportingEvents” attribute is added by the Playbook

 

 

 

 

 

 

 

 

{
    "Alert": "AD user created password not set within 24-48 hours",
    "AlertsDescription": "Identifies whenever a new account is created with a …",
… additional alert fields
    "AlertEntites": 
" [{ 
		" $id ": " 3 ",
		" DnsDomain ": " Contoso.Azure ",
		" HostName ": " ContosoDc ",
		" Type ": " host "
	}, {
		" $id ": " 4 ",
		" Name ": " MSOL_d9f03d5ca7ff ",
		" Type ": " account "
	] ",
    "Events": 
" [{
		" StartTimeUtc ": " 2020 - 06 - 02T17: 03: 16.44Z ",
		" EventID ": 4722,
		" Computer ": " ContosoDc.Contoso.Azure ",
		" TargetUserName ": " XXX ",
		" TargetDomainName ": " CONTOSO ",
		" SubjectUserName ": " ContosoAdmin ",
		" timestamp ": " 2020 - 06 - 02T17: 03: 16.44Z ",
		" AccountCustomEntity ": " XXX ",
		" HostCustomEntity ": " ContosoDc.Contoso.Azure "
	}, {
		" StartTimeUtc ": " 2020 - 06 - 02T16: 29: 56.963Z ",
		" EventID ": 4722,
		" Computer ": " ContosoDc.Contoso.Azure ",
		" TargetUserName ": " XXX ",
		" TargetDomainName ": " CONTOSO ",
		" SubjectUserName ": " ContosoAdmin ",
		" timestamp ": " 2020 - 06 - 02T16: 29: 56.963Z ",
		" AccountCustomEntity ": " XXX ",
		" HostCustomEntity ": " ContosoDc.Contoso.Azure "
	}]"
}

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Deploying the solution

• Create an Event Hub using the article “Create an event hub using Azure portal” or use an existing Event Hub.
• Go to the Playbook GitHub page.
• Press the “deploy to Azure” button.
• Once the playbook is deployed, modify the “Run query and list results” action (2) and point it to your Microsoft Sentinel workspace.
• Next, configure the “send event” action (3) to use your Event Hub.

 

Connect to your 3rd party SIEM or ticketing system

 

Most, if not all, SIEMs can consume the alerts from an Event Hub. Consult with your SIEM vendor on how. The following are instructions for consuming the alerts from the Event Hub to popular SIEM platforms:

• ArcSight can be found here
• LogRhythm can be found here
• McAfee can be found here
• QRadar can be found here
• For Splunk use Splunk Add-on for Microsoft Cloud Services, specifically the Event Hub input

 

Alternatively, if your SIEM or ticketing system supports an API, you may be able to connect directly from the Logic App playbook to your SIEM using the Logic App HTTP connector, or, if available a dedicated connector such as those available for Service Now or Jira

 

Summary

 

We just walked through the process of how enrichment can be done on Microsoft Sentinel level by leveraging could native capabilities in Azure before forwarding to 3rd Party SIEM or to a ticketing system. Stay tuned for more us cases in our Blog channel!

 

Thanks