We run a lean Azure setup. The goal: visibility without a vendor bloatware suite. Here's what we actually monitor and what we skip.
**What we monitor:**
* **Entra ID (Azure AD) audit logs:** Piped to a Log Analytics workspace. Critical for spotting anomalous sign-ins, privilege escalations. We use KQL alerts, not a vendor's proprietary rule engine.
* **Activity Logs for key resources:** Subscriptions, network security groups, key vaults. Again, Log Analytics. Alerts on policy changes, security rule modifications.
* **Network Flow Logs (NSG):** For critical subnets. We sample and analyze for unusual patterns, not full packet capture.
* **Container insights (AKS):** Built-in. Tells us most of what we need about cluster health and pod anomalies.
**What we skipped:**
* **Trend Micro Vision One.** Evaluated it. It's a classic EDR/XDR trying to be a platform. It wants to ingest everything and replace native tooling.
* **We don't need another agent.** Our VMs use the Azure Monitor agent. Adding another for "deep visibility" is overhead.
* **We don't need their "correlation engine."** Our threat model is simpler. We wrote targeted KQL queries for the specific risks we care about. Example alert for a suspicious series of events:
```kql
SecurityEvent
| where EventID == 4624 // Successful logon
| where AccountType == "User"
| join (
SecurityEvent
| where EventID == 4688 // Process creation
| where CommandLine contains "powershell" or CommandLine contains "cmd"
) on AccountName, Computer
| summarize Count=count() by AccountName, Computer, bin(TimeGenerated, 5m)
| where Count > 10
```
This catches rapid, interactive logon-to-scripting sequences. Simple, effective, no extra license cost.
The sales pitch is "see more, respond faster." The reality is more complexity, more noise, and another console. Native Azure tools + focused logging get us 95% there for a fraction of the cost and cognitive load.
Simplicity is the ultimate sophistication
Your approach of using targeted KQL queries over a vendor's correlation engine is spot-on for a lean setup. I'd suggest formalizing those queries into Azure Sentinel analytics rules, even if you're using the free tier. It gives you a structured alert lifecycle and incident management without the cost of the full SIEM.
One caveat on the network flow logs: ensure you're sampling enough to catch low-and-slow exfiltration attempts. The default sampling rate can miss subtle patterns. We had to adjust ours after a pen test showed gaps.
You mentioned skipping VM agents for "deep visibility." Are you finding the Azure Monitor agent's baseline security events sufficient for your workloads, or is there a compensating control like immutable infrastructure?
Interesting approach. On skipping additional VM agents, how do you handle detection for things that don't hit the logs? For example, a process executing in memory that the Azure Monitor agent wouldn't see.
We're considering a similar lean setup, but that's the gap we're stuck on.
You're chasing a ghost. If a process is running in memory without touching disk or spawning a child that logs, it's already game over for any agent-based monitoring, fancy or not.
The compensating control is immutable infrastructure, like the other commenter hinted. If you bake your images and rotate pods or VMs frequently, the window for a purely in-memory attack is tiny. Trying to monitor that in real-time from inside the VM is a fool's errand.
Focus on the artifacts you *can* catch: network egress, unexpected log entries, resource consumption spikes. Otherwise you're just buying snake oil and calling it security.
If it ain't broke, don't 'upgrade' it.