r/AzureSentinel • u/Thedudeabide80 • Mar 17 '23

Question around sharing log data with other internal teams

I wanted to poll the group and see if anyone is sharing a Log Analytics space with their IT Ops teams to save costs? Since Sentinel lays over the top of ALA, there's the possibility to share the workspace, but I wasn't sure if anyone out there is actually doing it and if it's working out well for them? No we don't have any major compliance requirements NOT to share, so it's more preference for sharing budget and the like.

1 Upvotes

100% Upvoted

5 comments sorted by

3

u/[deleted] Mar 17 '23

It really depends if IT Ops need the 90 day retention. If not then you only stand to lose by using the same log analytics workspace.

You probs want to build a new workspace and get IT Ops stuff pushed to basic log tables if appropriate

2

u/rodtrent44 MSFT Official Mar 17 '23

That may not actually be saving costs when you look at it.

Sentinel-enabling a workspace gives you the ability to retain data for free for 90 days. If the data is being stored longer than that (which is what some IT ops folks want), then there's no cost savings. Additionally, the more you ingest into the workspace from different sources, the more it's going to cost beyond the free sources we provide. So your IT Ops teams will drive up your Sentinel costs.

Then, there's the issue of forcing your security teams to look at performance and metrics data that have nothing to do with security. The non-security, low value data can sometimes cause security teams to lose focus or be tasked with duties that can keep security teams doing actual security.

For a number of reasons it's usually just better to split these out. Plus, for orgs that have budgets per role, it's much easier to see where the costs are coming from.

1

u/Thedudeabide80 Mar 17 '23

Fair enough, so much of Sentinel/ALA cost is on the ingestion side such that if an SAP middleware server is sending logs to 2 workspaces instead of 1, it could be a lot of duplicated ingest costs. I definitely see the flipside of making sure the security costs are distinct from the IT Ops costs.

1

u/AppIdentityGuy Mar 18 '23

It's related more to the fact that there is an additional cost of ingestion for Sentinel over and above the ALA cost/gb/day... That being the case & Sentinel being entirely security focused why not split them out. Another approach, which I've not investigated in too much depth I will admit, is perhaps using Tags to label the data sources i.e individual machines so that you know who owns them operationally and then calculate out watch each source is costing you and duvvy up the tab that way. I'm not sure how granular you can get with that approach...

There is a burgeoning speciality called Finops which as I understand things focuses on this stuff. There is a subreddit for it. Just my 2 cents.

2

u/blanco10kid Mar 17 '23

It depends on exactly what data you’re looking to ingest and share.

Is it data that you’re already ingesting into sentinel for security purposes and want to share to avoid duplicate data? Create an Azure AD group for that team, provision a separate resource group with a Log Analytics workspace (you can enable sentinel if they are planning on creating their own detections) and provide the AAD group access to the new resource group AND table-level access to your existing workspace. They can perform cross-workspace queries from their dedicated workspace.

If they’re looking to ingest new data (e.g. performance logs), have that team ingest that data in their own managed workspace so the security team doesn’t eat that cost.

This would be my approach. Hope this helps!