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

Special thanks to  and 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 Azure Sentinel alerts and send them to an Event Hub that can be consumed by a 3rd party SIEMs and Ticketing Systems.


 


Using Sentinel alongside a 3rd party SIEM and ticketing systems


 


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


 


Among the reasons for doing so are:



  • Using Azure 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 Azure 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.


 


Azure 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 3rd Party SIEM or ticketing system is used as the primary pane of glass, this translates to sending both Azure Sentinel alerts and their supporting events to this system.


 


1.png


 


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 Azure Sentinel. Instead, the alert rule determines what to present as supporting events. Learn more about how a rule controls the supporting evidence in the Azure Sentinel KQL lab (YouTubedeck) and the Azure Sentinel rule writing Webinar (YouTubedeck).


 


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:


 


2.png


Forwarding alerts with supporting events to an Event Hub


 


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


 


3.png


 


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 Azure 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:



 


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 Azure 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

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.