Monitoring the publication of new Azure Sentinel alert rule templates

Anyone familiar with Azure Sentinel knows that one can open the portal one day and find 20 new additional data connectors and 50 new alert rule templates along with additional goodies such as hunting queries, parsers, workbooks and sometimes whole new major add-ons such as UEBA.

Unless one meticulously checks the rules on regular basis and knows them by heart, it is very easy to miss the new ones despite them being tagged as “new” by Microsoft when they are published. The challenge is that security admins usually live by incident notifications and don’t have enough time to peruse through the configuration portal. As I write this blog post, there are 270 alert rule templates available and even when working every day with them it is easy to lose track what changed.


For an MSSP, being aware of any new alert rules available is even more important as they have to either deploy the new rules, adjust, tune and incorporate into their monitoring process or simply notify their customer on their availability.

At BlueVoyant we are using Sentinel’s SOAR capabilities to keep track of all the alert rule updates and pipeline them directly into our alert rule development process where they are triaged and prepared by for conversion and integration into the list of supported use cases. For most of the Azure Sentinel environments that we review and enhance, we find a range of out-of-the-box alert rules enabled that we typically replace with our fine-tuned, production-proven custom rules.

The Azure Sentinel playbook described below performs multiple time consuming, error prone tasks – the exact type of work that we want an automated solution to assist with.


The high-level functionality for this playbook is as follows:

The current list of alert rule templates is retrieved through the Sentinel REST API – Triggered by a Recurrence connector, a REST API call is made to retrieve the current list of rule templates via an HTTP request Logic App connector and an SPN with the required permissions. The output is parsed using a Parse JSON Data Operation connector

The list is ingested into a Sentinel Log Analytics workspace – Using the Parse JSON output, the data is picked up by the Send Data Logic App and pushed into a custom log in our Azure Sentinel instance (we use SentinelAlertRules_CL). The data ingestion is followed by a “Delay” action to allow the new information to be indexed in Log Analytics.


A query against the workspace identifies alert rules published in the last 24 hours – Using an Azure Monitor “Run query and list result” connector, the historical data is correlated with the new list of alerts and the new alerts identified.

If new alert rules are identified (done through the Control connector checking the list of alerts returned), a number of tasks are performed for each alert:

A Jira task is created to initiate the tasks of reviewing the alerts, adjusting it with the BlueVoyant “special sauce” including but not limited to better handling of log ingestion time lag, tweaks to allow customization of alert sensitivity, additional metadata around MITRE Att&ck techniques, log source categories and many other improvements that are needed for proper integration into our Sentinel automation portal – A Jira Logic App connector is available for this and one can use either a personal account or a service account to obtain connectivity. The control allow the specification of the Jira project, the type of change and the full details to go with it.


Since we are nice, we will also tweet the update on our Tweeter account and notify those interested. Here one needs to be careful as one can have a large number of new alert rules published overnight and Twitter will not play nice with those that tweet automatically!


See an actual tweet from the playbook – we may decide to make it “production” following more due diligence around Twitter posting rules.

A notification is sent to the Teams channel used by Sentinel engineers for awareness – One can guess, the Microsoft Teams Logic App connector provide the full functionality to post messages, create channels, etc.


Finally, an email notification for quick update to various parties involved – We typically use the Office 365 Logic App “Send emails” to send rich, HTML-friendly emails.


The playbook can be continuously enhanced to notify through other means as well – for the Slack-loving developers it can look like this:


One can see that such combination of REST API requests, Sentinel playbooks and Logic App connectors provide limitless possibilities for automation and on daily basis I am impressed on how easy it is to build such playbooks that would bring consistency, improved productivity, awareness and overall awesomeness in our quest for doing just creative work and leaving the 24×7 watching and tolling to computers.