Forum Discussion
Adopting Sentinel into an existing Azure Cloud environment
Hello, having App Insights in a workspace with Azure monitor logs is a preview feature: https://docs.microsoft.com/en-us/azure/azure-monitor/app/create-workspace-resource#:~:text=%20Workspace-based%20Application%20Insights%20resources%20%28preview%29%20%201,workspace-based%20Application%20Insights%20resource%20has%20been...%20More%20
Typically today we have one or more workspaces for Logs and that is then associated with Azure Sentinel.
Reading between the lines, it seems as though if we have a single Log Analytics workspace that is used by Sentinel and AI, all our in-house application logs would be ingested into (or otherwise queryable by) Sentinel. However, I'm not positive this is true.
Azure Sentinel doesn't do ingestion (Log Analytics does that); Sentinel provides security analytics / insights onto that data. If Azure Sentinel sees data from Logs and AI it will analyze it / allow you to query it.
I recall reading something a few days back that indicated the LA workspace for Sentinel should be dedicated to Sentinel
That could be a option, however people sometimes separate Operational logs (and maybe application logs) as they can have low security value and you maybe you don't want Azure Sentinel to charge you to analyze those sources (per GB/day). e.g.
Sentinel makes use of a lot of the PaaS log sources and logs from ASC (SecurityEvents) etc... data in the Perf table may not have such high security value (but it will to the Operation team), that's why you often see Perf in another workspace.
If we create a new LA workspace to use with Sentinel, will we still be able to use this workspace to create more traditional infrastructure/development dashboards and alerts?
Yes, the underlying query language and capability is still there. So you can build an Azure Dashboard on the data (Log Analytics or Azure Sentinel), or use KQL to query, or build a Workbook to visualise the data - Workbooks are delivered by Azure Monitor but you see them in many portal blades such as Azure Sentinel.
Modules 2-4 will help you from the Azure Sentinel training: https://techcommunity.microsoft.com/t5/azure-sentinel/become-an-azure-sentinel-ninja-the-complete-level-400-training/ba-p/1246310
Thanks, CliveWatson! This is super helpful.
I think part of what's tripping me up is Monitor vs Log Analytics vs Application Insights. Based on the https://docs.microsoft.com/en-gb/azure/azure-monitor/overview, I was under the impression that Monitor was the "umbrella" that housed all the underlying services. Given what you're saying above, and now that I'm a bit more familiar with the portal, it seems that Monitor is more of a "family" of related services rather than a distinct resource that we would be provisioning or managing.
That being said, it seems that we should be able to create a single Log Analytics workspace, configure Sentinel to use this workspace, and migrate all our Application Insights resources into this workspace as well. This will likely require some RBAC to keep things sane and partitioned appropriately.
That could be a option, however people sometimes separate Operational logs (and maybe application logs) as they can have low security value and you maybe you don't want Azure Sentinel to charge you to analyze those sources (per GB/day). e.g.
Sentinel makes use of a lot of the PaaS log sources and logs from ASC (SecurityEvents) etc... data in the Perf table may not have such high security value (but it will to the Operation team), that's why you often see Perf in another workspace.There is a distinct drawback in having all your operational logs analyzed by a SIEM, both in up-front analysis costs and in long-term query complexity and computation time. There is a reasonably small subset of operational logs that we would want to ingest into Sentinel, but I'm unclear as to what would be entailed in splitting up the logs appropriately so that we can have only the security-sensitive logs analyzed by Sentinel while still having the full set of operational logs available to our developers and infrastructure people.
There's sufficient "magic" in Azure that it is surprisingly challenging coming in with no Azure knowledge or experience, and trying to figure out how to implement a logging pipeline. Most of the documentation boils down to "send it to Log Analytics and you're done". I'll start looking at your suggested training modules and see if that helps clear it up; they're definitely topical, and I'm looking forward to Module 5 having more content as well!
Given that there doesn't appear to be any technical concerns (at our size) with having a single Log Analytics workspace that is used by Sentinel and our in-house applications, for the sake of simplicity, I suspect that's where we'll wind up (barring corrections from those training modules). And so long as we're keeping our dashboards, alerts, and Sentinel configuration defined in Powershell/Terraform, it should be reasonably straightforward to change things up in the future.
