Having recently completed a multi-tenant Azure AD security baseline for a financial services client, I'm reminded how crucial—and costly—getting the logging right can be. The volume is staggering, and ingesting every single Azure AD audit log into your SIEM is a fast track to budget overruns without necessarily improving security. The key is strategic, intelligence-driven logging.
Based on incident response post-mortems and common attack vectors, here are the event categories I consider non-negotiable for a baseline detection capability. These should be your first priority when configuring diagnostic settings for export to Log Analytics or your SIEM.
### Core Authentication & Sign-in Logs
These are your primary source for credential-based attack detection.
* **All `SigninLogs` with detailed properties.** Filtering at export is a mistake. Ingest all, then filter/drop noisy low-risk events (like successful MFA) in your SIEM if you must. You *must* have:
* `ConditionalAccessStatus`
* `RiskDetail` (for Identity Protection)
* `DeviceDetail`
* `LocationDetails`
* `Status` (error code)
* **`NonInteractiveUserSignInLogs` & `ServicePrincipalSignInLogs`.** Critical for spotting token theft and service account compromise. Attacks shift here after you enable MFA for interactive users.
### Audit Logs - The "What Happened"
Prioritize events that indicate privilege escalation, persistence, and configuration change.
* **Directory Changes:**
* `Add member to role` / `Elevate role` (privilege escalation)
* `Add owner to application` / `Add service principal` (persistence)
* `Update application` – particularly credential adds (backdoor)
* `Add delegated permission grant` (consent phishing)
* **User/Group Lifecycle:**
* `Delete user` (destruction)
* `Add user` (especially guest users - potential lateral movement)
* `Add member to group` (especially to privileged groups like `Administrators`, `Domain Admins` equiv)
* **Device/Join Changes:**
* `Join device to workspace` / `Register device` (often a precursor to lateral movement)
### Must-Have Properties (The Devil's in the Details)
Simply ingesting the log category isn't enough. Ensure your export captures these critical properties for effective correlation:
* **`Actor`** (who performed the action)
* **`Target`** (who/what was acted upon)
* **`ModifiedProperties`** (exactly what changed in a config update)
* **`InitiatedBy`** (for user-driven vs. system actions)
### A Pragmatic Filtering Strategy
If cost is a severe constraint, start by *excluding* known noisy, low-severity events at the SIEM ingest parser level, not in Azure. For example, you might safely filter out `UserLoggedIn` from `AuditLogs` if you have all `SigninLogs`. A KQL function to tag high-value events can help downstream.
```kusto
// Example: KQL function to flag high-risk audit events for priority alerting
let HighRiskAuditEvents = () {
AuditLogs
| where OperationName in (
"Add member to role",
"Add owner to application",
"Update application",
"Add delegated permission grant",
"Delete user"
)
};
```
The goal is to have the granular data needed to investigate, not just to alert. You can't detect what you don't log, but you also can't afford to log everything. Focus on the events that map directly to the MITRE ATT&CK techniques for cloud identity (TA0001, TA0003).
What's everyone else's "drop-dead" list? Any specific event you've seen be the linchpin in an actual breach investigation?
- Mike
Mike
I run marketing ops at a 300-person SaaS company, and I built our current Azure AD monitoring stack to support both security and marketing use cases, like triggering onboarding journeys off secure sign-ins.
* **Cost vs. Volume Management:** The biggest operational factor is deciding which logs go straight to Log Analytics versus a cheaper intermediary. At my last shop, we used Azure Event Hubs as a buffer to filter and batch before forwarding to Splunk, which cut our ingest costs by about 30%. Without a buffer, be ready for a bill jump of $2-4K/month for a tenant of our size.
* **Deployment Gotcha - App Registrations:** One specific, critical event most guides miss is `Add service principal`. In a marketing context, this is often a new app registration for a tool like Marketo or Zoom. We alert on this because it's a common path for shadow IT; we caught our sales team trying to connect an unvetted sales automation tool this way.
* **The Break Point on Real-Time:** If you're using these logs for real-time marketing triggers (e.g., "user logged in from new device, send a welcome back email"), watch your Kusto query performance. Complex joins with user profile tables start to lag above ~50 queries/minute. We had to add a dedicated Azure Synapse pipeline for those high-volume, automated workflows.
* **Winning at Lead Scoring Integration:** The clear win for us was piping `SigninLogs` with `DeviceDetail` and `LocationDetails` into our CRM. It enriched our lead scoring model with behavioral data - like a lead from a target account suddenly signing in from our region got an immediate points bump for sales outreach.
For a financial services baseline like OP's, I'd prioritize the raw `SigninLogs` and `ServicePrincipalSignInLogs` export to a SIEM first, but only after routing through an Event Hub to control costs. If you're also using this data for business analytics, tell us your monthly log volume estimate and whether your team owns the Azure budget.
stay automated
Filtering at export is a mistake? That's a fast track to a six-figure SIEM bill and a meeting with finance. You ingest everything and then drop noise in the SIEM? That's paying for the privilege to throw data away.
We pipe the core SigninLogs directly to Log Analytics, but we strip out the fat first. Successful MFA from a trusted location for a regular employee? Gone before it leaves the diagnostic setting. We use a simple KQL transformation to drop those rows. Why pay to ingest what you'll never alert on?
Your list is fine for detection, but you're missing the operational reality. If you don't throttle the firehose at the source, you're just building a very expensive log lake.
If it ain't broke, don't 'upgrade' it.