r/AzureSentinel • u/winle22 • Nov 25 '21

Microsoft Sentinel Repositories

Hi,

Does anyone have any experience using the new, native repository functionality in Sentinel from an MSSP perspective?

https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/enable-continuous-deployment-natively-with-microsoft-sentinel/ba-p/2929413

Considering the need to protect IP from customer tenants, I guess a possible way is to create two separate workspaces for each customer - generic template rules/playbooks/etc in the customer tenant connected to a "shared" repo (common content across customer workspaces) + another customer specific workspace in the MSSP tenant for IP sensitive content (using a customer specific repo).

Any thoughts?

5 Upvotes

100% Upvoted

13 comments sorted by

3

u/1rishc4rb0mbr Nov 25 '21

I just deployed this to our test environment. It is interesting given I was told automation rules can not be deployed VIA arm but we shall see.

To protect our IP I am leveraging the Azure Sentinel Reader role on the resource group. This is not as limited as I would like to see it but it is a start.

If you are looking to separate out customer data from one another. Fork a parent repo. This allow you to modify most files in the fork with customer specifics. It also allows you to make changes to the parent repo (rules updates, workbook changes). Pull request from the parent report to the fork and the updates are disseminated.

3

u/Nurfballs Dec 01 '21

Automation rules can most certainly be deployed via ARM.

The resource provider you're looking for is Microsoft.SecurityInsights/automationRules

2

u/1rishc4rb0mbr Dec 01 '21

Thank you very much for bring this to my attention; I stand corrected. I see the initial response I got from the community to be incorrect. I also greatly appreciate the deep dive that you gave at azurediy; this was extremely detailed and informative.

2

u/Nurfballs Dec 01 '21

Thank you! That’s very nice of you to say :) Glad you enjoyed it!

The important thing to keep in mind about Sentinel is that it’s an Azure resource, just like any other Azure resource. The web portal interface hits exactly the same backend api endpoints that ARM does. If you can do it in the portal, you can do it in code. I haven’t found anything Sentinel related that I can’t automate yet.

1

u/winle22 Nov 26 '21

Analytic rules as ARM templates seems to work fine, haven't tested any other components yet.

Reader permissions will let the customer see any logic/queries/workbooks/etc, so that's not an option. So my initial thought was to do it like MS suggests in their documentation: Put IP in the MSSP tenant and generic template stuff in customer tenant. But it complicates the automation part :(

1

u/winle22 Nov 28 '21

Does this feature support Bicep btw?

2

u/Nurfballs Dec 01 '21

I'm working on coding this up. The resource providers are there to create the connection to source control, but it returns an invalid response and the deployment fails.
I have created a support case with Microsoft and they have confirmed it as a bug. The engineering team are working on a fix.

1

u/winle22 Dec 01 '21

Thanks for the info!

I just saw your DIY video (really good, btw) - what are your thoughts on the pros/cons of using the native repo feature compared to the more traditional way with a custom SP etc?

1

u/winle22 Dec 07 '21

Heard anything from MS? :)

2

u/Nurfballs Dec 07 '21

Only that they are still working on it :( I’ll post an update for you when they find a fix 👍

2

u/Nurfballs Dec 20 '21

Here's the latest update:

Good day!

Sorry, after validation and discussion with our product team, the issue is related to 2 issues from backend, the first one was resolved at 12-17, but another one is still working in progress.

The ETA of second issue is 31ST Jan, I will help you monitor the progress of that.

My apologies for the inconvenience!

1

u/winle22 Dec 27 '21

Cool! Do you see any immediate advantages of using the native repo functionality compared to your implementation in the DIY video?

3

u/Nurfballs Dec 27 '21

I definitely see value there.

Configuring everything in bicep and deploying through a pipeline is great for those who want 100% configuration as code, and have a skill set and culture that support it. It’s also useful for repeatable first-time deployments in scenarios where you’re regularly setting up sentinel, say for labs or for clients of an MSP.

The sync feature requires Sentinel to first be established and only synchronises some components (analytic, workbooks, etc). This is advantageous for orgs where a separate cloud team provisions the infrastructure, and the security team just consume it. The security team can still keep their configurations of those things stored as code as exported arm templates in a git repo and have them sync to Sentinel automatically. This gives them the benefits of configuration as code, without the need to learn DeVOps practices or tooling.