Deploying and managing Sentinel out-of-box content as code

Question

Hello,

Could anyone chime in with their approach to automating the deployment and management of Sentinel out-of-box content as code?
Posted in January 2020 there is the Microsoft Sentinel Blog post by Javier Soriano, describing a community provided method to Deploying and Managing Microsoft Sentinel as Code 1131928.

Since November 2021 Microsoft announced a new feature in Microsoft Sentinel called Microsot Sentinel Repositories. To deploy content to Sentinel from a Azure DevOps or GitHub repository. 2929413. The previous method described by Javier thus seems to be deprecated (or at least not the currently recommended solution).

The documentation states that only custom content in valid ARM templates can be deployed through the deployment pipelines created by Sentinel Repositories. Which leads me to question how one would deploy and manage out-of-box content using Sentinel Repositories, or rather whether or not this is actually possible?

Additionally the Sentinel Repositories function is currently limited to the deployment of six content types (analytic rules, automation rules, hunting queries, parsers, playbooks and workbooks).

I have written a PowerShell script to download all Sentinel alert rule templates through the Azure API (list) and write the contents to valid ARM templates (alertrules).
However when deploying these alert rule templates (400+) through a connected Azure DevOps repository, the pipeline fails around the deployment of rule 200, due to the limit of 60 minutes of runtime of Microsoft-hosted build agents (phases). Deployment of out-of-box content through Sentinel Repositories thus seems to be taking too long. As far as I can determine through the documentation, the deployment of out-of-box content is only shown to be done using the Sentinel interface (sentinel-solutions-deploy).

Currently we are deploying analytic rules through a PowerShell script (similar to the script used to download the analytic rule templates) and create the analytic rules using the Azure API (create-or-update). However this method does not allow us to tailor the out-of-box content to our environments and also keep track of these changes (using version control) and deploy these changes to other Sentinel instances.

What is your approach deploying and managing Sentinel out-of-box content as code?

Kind regards,

Answer 1

Hi @kkoole

Sentinel Repositories and Javier's blog are options for customers, especially as there are a lot SOC's who do not have the capacity / knowledge to manage Sentinel as code. How you manage Sentinel (or the wider Azure infrastructure) will really be done to your organisation's deployment strategy.

In a ideal scenario, you would deploy Sentinel as part of an enterprise scale landing zone, whether this is using a Microsoft template, or a custom template based on the cloud adoption framework. This would deploy the core components of an enterprise, including Sentinel.

Using the Sentinel Repositories, you can deploy and manage the Sentinel content independently to the enterprise scale landing zone. With the build agent limits, you can consider using your own build agents (or runners in GitHub) to get around the agent runtime limit.

The out of the box content, such as analytic rules can be exported and redeployed using Sentinel repositories, the analytic rules for example, have the template id of the original analytic rule, so if Microsoft update the rule, you will see be prompted to update the analytic rule in the Azure Portal. If you remove this, then you won't.

Other things you could do is compile an ARM template with multiple analytic rules within a single template, this would reduce the number of deployments, the same can be done for the other content types, though this wouldn't work with the out of the box template unless you had a separate build action prior to committing to the main branch, and you excluded the individual analytic rules in the workflow trigger YAML file.

Something you will need to consider is the deployment history limits (800) within resource groups, meaning you will not be able to deploy any new ARM templates until you clear the deployment history.

Sentinel Repositories is still in preview, so please give feedback on the feature here

Answer 2

Hi kkoole,

I've run into similar challenges exporting/importing sentinel rules from powershell.
You will find that not all of the rules play nice with that method.
I've spent much time going through the rules and removing 'suspect' json.
I suggest breaking the rules into smaller blocks to it's easier to identify faulty rules.
The latency could also be related to this issue.

If you have a simple, repeatable, example of where you're running into this issue please share it here.

Good luck!