Migrate alert rules to another Azure Sentinel in the same tenant

In a large deployment, having a non-production environment to test Microsoft Sentinel analytics rule is recommended. Now when everything is ready you would need to copy your rules over to the production environment.

This article provides you a script to help you get the copy done. The script still has several limitations currently that you need to know too.

This script is created with the idea of moving all alert rules from a non-production environment to a fresh new production environment. Use the script as your own risk.

[12/04/2021] Use version 2 script to migrate scheduled analytics rule including custom entity mapping, custom detail, custom alert format, incident grouping configuration settings or so on. The version 2 uses a preview API which is described here.

Use case

For a large deployment of Microsoft Sentinel, you should write and test analytics rule in a development subscription. If you still worry about lack of data for testing you could use Azure Monitor HTTP Data Collector API to add sample logs to Log Analytics workspace.

When you have done testing your your analytics rules you start copying rules over to a production environment.

Script

AzSec has developed a script to help migrate analytics rule to another Microsoft Sentinel workspace in the same Azure tenant.

There are several limitations and known issues you need to know:

  • This script is using native PowerShell module for Microsoft Sentinel which is using Alert API version 2020-01-01. This API does NOT support custom details, entity mappings and new incident grouping configuration. You have to manually add custom details, mapping and action after the migration.
  • The destination Azure Sentinel should be empty so you won’t get duplications of built-in scheduled analytics rules Microsoft provides. You can add a filter in Where-Object to only move alert rules based on a pattern e.g. name contains a prefix.
  • This script works with scheduled analytics rule only. It doesn’t work with NRT (near real-time) analytics rule.
  • ¬†There are some built-in rules such as Encoded Invoke-WebRequest PowerShell¬†doesn’t have description so the script puts “TBD“.
  • Some rules are missing tactics so the script temporarily picks Discovery as the tactic for the migrated rule.
  • The analytics rule’s name (GUID format) does NOT remain.

AzSec will work on a newer version to help copy alerts with custom entities and incident grouping configuration when the API is ready. Stay tuned!

[11/28/2021] You can try this script to create a full scheduled analytics rule with custom entity mapping, incident grouping configuration, custom details and alert format.

If you have any feedback, please feel free to leave your comment in the Comment box or create a new GitHub issue.

This entry was posted in Secure Development, Security Automation and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.