The future of Sentinel in ALZ (follow on from 29th January 2025 Community Call)

[jtracey93]

As you have heard or seen in the community call on 29th January 2025 we are considering the future of Sentinel in ALZ and whether we need to change the architecture or not.

We are looking for your input on what your are doing or seeing in the wild today, to help shape the changes to ALZ (if required) so it is based on real-world deployments 👍

Questions to answer (we want to hear from you 🫵 - reply in the comments below)

1. Do we need a separate LAW dedicated to Sentinel?
   1. We think so, mainly due to platform logs increasing costs and causing noise from required security logs
      1. Even though this will lead to some double logging into both LAWs (Platform + Sentinel)
   2. Often organizations have separate Security teams requesting/driving for this
   3. Product Group guidance leans to single workspace by default, see here.
2. Do we need a separate “Security” platform Subscription?
   1. Can it not just live in Management?
3. Does this need to be in a separate “Security” Management Group?
   1. Could it just live inside of Platform > Management?
      1. Does it need to be somewhere else?
   2. RBAC is suggested to be done at Subscription scope, not MG.
      1. MGs are primarily for policy assignments
4. Should ALZ deploy anything Sentinel related? Or should we just just provide placement guidance and platform pre-reqs?
   1. e.g. Should we just deploy and move a subscription to a management group that ALZ creates?
   2. This then allows security teams to deploy and mange sentinel however they wish
      1. Also, they then work with the ALZ/Platform team to get any additional RBAC and policy assignments created as they see fit?
   3. Or should ALZ deploy Sentinel All-In-One Accelerator, or just provide guidance and link to it?

[gr-gh-nexia]

For point 1.i.a (the double ingestion cost -- ex for Azure Firewall Network and Application rules logs which may be needed from an operational standpoint as well as security standpoint) the problem may be alleviated if the operations people have or can request access to the Sentinel SIEM LAWS as needed for troubleshooting (PIM if not permanent access).

[gallen-ms]

Technically they can through use of the Resource based RBAC model in Sentinel/LA and being given Reader access against the firewalls.

[christianGoe]

1. Yes because of costs and seperate Security Teams
2. RBAC for a different Management Groups should be enough for smaller customers
3. Wold be nice, but most different Teams deploy Sentinel to use ist mainly for M365

[lnfernux]

Chiming in from the security (MVP) side of things here - perspective is that of a medium sized MSSP, but this is in "europe" enterprise scale - so rarely any companies have two security teams:

Do we need a separate LAW dedicated to Sentinel?
Yeah, I think so. Reasons being mainly cost, but also access control. From our perspective it's easier to keep it separate and have security logs mainly go to the security LAW, then send all operation logs to the central mgmt law. We can open for table level access for operations on some dual-purpose logs, or log them two places. From what we've seen lately it would be cheaper than sharing a workspace in most cases.

Do we need a separate “Security” platform Subscription?
We operate on mostly resource group level using least privilege, but I guess it doesn't really matter. If we had a separate sub for security we could operate on sub level access and a few more thing would be open to automate. I would not be comfortable having sub level access on a SPN in the mgmt sub.

Should ALZ deploy anything Sentinel related? Or should we just just provide placement guidance and platform pre-reqs?
This will depend heavily on the security teams tbh, I would say it's fine to deploy resource group + law in the security sub, then leave the rest to the security team?

[sijday]

1. Do we need a separate LAW dedicated to Sentinel?
I believe so for a couple of reasons.
If the Sentinel deployment becomes heavily utilised then the use of workspace transformation DCRs may be used and it makes sense to limit the blast radius of any issues to a single LAW.
We typically have App Insights enabled LAWs in Application Landing Zones hosting workloads where the dev teams have delegated permissions specifically for app observability: performance metrics, troubleshooting, etc.
This is tied into the app lifecycle and has specific retention periods, workbooks and so on.
A big centralised LAW for app monitoring has challenges in a democratised development scenario.

2. Do we need a separate “Security” platform Subscription?
This would have a lot of utility as discrete add-on to an existing Landing Zone environment.
It also supports limiting blast radius and supports principle of least privilege.

4. Does this need to be in a separate “Security” Management Group?
Could but not need.

5. Should ALZ deploy anything Sentinel related? Or should we just just provide placement guidance and platform pre-reqs?
Yes. The Azure review ALZ checklist project checks for the use of a protective monitoring so it would be good to be consistent.
https://github.com/Azure/review-checklists
Also retrospectively adding diagnostics settings for Sentinel to a running large environment is a big headache.

[sebhe]

2. Do we need a separate “Security” platform Subscription?
I would say "yes" to limit the blast radius. Default permissions would be set on subscription level, and there will be a different team managing sentinel vs the other resources that are in the same subscription. having a dedicated subscription would make it easier to separate access between those two teams

[steventurner-msft]

Do we need a separate LAW dedicated to Sentinel?

Yes. Typically, security and IT ops teams are very separate and need that same separation in the data.

If IT ops uses the same LAW then the uplift in costs due to the enablement of Sentinel will most likely more then offset the costs associated with duplicate data. Also, with the introduction of auxiliary logs, any data which is required to be duplicated can be brought into this much cheaper data storage option. In my experience, I've rarely seen data duplicated between Sentinel and another LAW so I don't this is a major issue for most anyway.

There is often a requirement for outsourced SecOps (to a MSSP) teams to have that segregation of data so that it's not visible to the MSSP.

Do we need a separate “Security” platform Subscription?

Again yes, mainly due to the point about MSSP above (RBAC cleanliness). Also most in-house SecOps teams require segregation of not only the data, but the access to it.

Additionally, as subscriptions are billing mechanisms, costs associated with Sentinel and other dedicated, platform-wide security resources such as EASM, can be easily separated out by FinOps.

This would also help for multiple deployments on Sentinel within a single directory for data sovereignty reasons.

Does this need to be in a separate “Security” Management Group?

Probably not, at least not in the majority of cases. If the CAF guidance is followed well, then inherited RBAC from the management group should be minimal and necessary.

Should ALZ deploy anything Sentinel related? Or should we just just provide placement guidance and platform pre-reqs?

I really like this idea but could it made made an optional step? Many customers who outsource the build element of Sentinel use partners who will deploy Sentinel suing IAC from there own repos to ensure a consistent config across their clients

[gallen-ms]

1. Do we need a separate LAW dedicated to Sentinel?
Yes, primarily due to cost reasons, but also to allow the security team privacy of sensitive data.
The role based access structure allows limited access to particular assets logs from Sentinel for non-security users if necessary.
This also aligns well with Sentinel's concept of primary and secondary security data driving cost optimisation.
Operations teams wouldn't want their data in Auxiliary log tables in many cases, but for the Security team this would not be "Primary" data.

iii.
I would argue that the product group guidance strongly hints at separate workspaces, "might" is hardly a ringing endorsement of a single workspace design. If you want to provide multiple workspaces and better cost management then consider recommending Dedicated Clusters for Log Analytics, these can host Sentinel and non-Sentinel workspaces within region and consolidate the LA cost elements at least.

2. Do we need a separate “Security” platform Subscription?
Yes we do. I've seen to many organisations over-permission a common subscription with Reader access and then be concerned they can see Sentinel.

3. Does this need to be in a separate “Security” Management Group?
Ideally at the top, again to prevent over-granting of Reader roles in particular from the upper management root.
While we suggest RBAC is done at a sub level, this doesn't prevent people taking the easy route and using the management group.
We should try to counter bad-practise in other areas by covering it off with our own design.

4. Should ALZ deploy anything Sentinel related? Or should we just just provide placement guidance and platform pre-reqs?
I think the ALZ should deploy the Subscription and maybe a Resource Group to illustrate our recommendation.
I don't believe we should deploy the Sentinel-All-In-One (just reference it) as it isn't limited to free data only, will remove the customers trial period if they don't use it immediately.

[jtracey93]

Hey,@gr-gh-nexia, @christianGoe, @sijday, @lnfernux, @sebhe, @gallen-ms, @steventurner-msft

Thanks for your inputs here, really appreciated. Please checkout the proposal following this discussion thread over in #1978 and please vote in the poll 👍

Closing and locking thread, please continue over on #1978