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