Microsoft Sentinel – Migrating to another Subscription
Last Updated: 17/12/2024
It’s common to move resources around within Azure, especially between subscriptions and resource groups. However, when it comes to migrating Microsoft Sentinel, things get a little bit tricky.
Microsoft Sentinel is underpinned by Log Analytics Workspace (LAW). LAW is the work horse that is responsible for ingesting and storing the data. The Microsoft Sentinel solution then connects to it and gives us a platform for running rules, investigating security incidents and kicking off playbooks for automation.
The issue is, Microsoft does not support moving a Log Analytics Workspace that has Microsoft Sentinel attached to it. However, the option in the portal to move the resource is still present and we can do this.
What does the migration break?
After doing some testing and some research online, the main thing that migrating Microsoft Sentinel breaks is the UEBA functionality. Additionally, some of the incidents prior to migration had a few issues finding & referencing the resources that were associated.
Looking online there were discussions around issues with the analytical rules themselves, however the fix for this was to disable and reenable all of your analytical rules.
Options for moving
Even with the above, there is still going to be the need to migrate Microsoft Sentinel. Whether it’s moving your pilot Sentinel into your production subscription or moving Sentinel to its own dedicated subscription. So, what can we do about it?
Option 1 – Side by Side
The safest option is to create another instance and run two Sentinel instances side by side. You would provision the second instance in the desired location and export/import the configuration to the new instance. You then run these two instances until the retention period lapses.
Pros:
- The new/second instance will be supported by Microsoft, as it has not been migrated.
- You can do this over a longer period if needed.
Cons:
- You will be paying for another Sentinel instance, potentially doubling the cost.
- Retention periods configured for a longer period could make this option to costly.
- You will need to manage and monitor two instances.
Option 2 – Cut Over
Similar to option 1, but the key difference is when we cut over to the new instance, we disable to data connectors on the original instance of Microsoft Sentinel. In this method, we keep the original instance for archiving purposes.
Pros:
- The new/second instance will be supported by Microsoft, as it has not been moved via the Azure portal.
- Cost effective.
- Once cut over, only a single Sentinel instance needs to be managed. With the original as archive.
Cons:
- Investigations that require data from the original instance of Sentinel may impact investigation time & complexity.
Steps for Exporting Configuration
Exporting the configuration for each object differs:
Data Connectors: These cannot be exported and will have to be setup again.
Analytical Rules: You can export/ analytical rules as JSON.
Workbooks: Any template Workbooks can be implemented on the new Sentinel instance. Custom Workbooks is best to export in JSON.
Hunting Queries: No options to export in bulk. Custom hunting KQL queries would need to be saved manually.
Playbooks: These are Azure Logic Apps and are a separate Azure resource that will need to be migrated.
Automation Rules: You can export/import your automation rules to JSON.
Once the configuration has been copied across, you can run the two instances until the data retention period lapses.
Other Options
The other option I am currently investigating is how to move the data from one log analytics workspace to another. This would allow us to make a replica of the underpinning Log Analytics Workspace in a new subscription. Then attach Microsoft Sentinel to it. In this case, you are moving the data and not the workspace.
Summary
Hopefully this post helped show the potential options you can implement to migrate Microsoft Sentinel to another subscription. I am hoping Microsoft will one day support Microsoft Sentinel movement to other resource groups and subscriptions. For tips on planning and deploying Microsoft Sentinel, please visit this post.
Great post, not much resources out there for migration of Sentinel and am surprised that it’s not supported!
Thank you! and I agree, I didn’t come across much when investigating. I am hoping that Microsoft will support the migration of Sentinel instances soon using the native functionality in Azure, but only time will tell!