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

[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