Alright, so you've hooked up the Microsoft 365 Defender connector in Sentinel. Congratulations. You're now ingesting a firehose of "alerts" that are about as useful as a "low severity" email about a user clicking a link in Fiji. The raw `SecurityAlert` table gives you a JSON blob in `ExtendedProperties` that is, frankly, a nightmare to parse for anything operational.
Here's the kicker: the "official" guidance is to use the `ParseJSON` function. Great, if you enjoy writing a novel in KQL to unpack nested arrays and dynamic fields just to figure out which device actually triggered the thing. The connector feels designed for checkbox compliance ("Yes, we have the integration") rather than for an analyst who needs to triage.
What you actually need is to normalize this mess into something you can join with `DeviceNetworkEvents` or `IdentityLogonEvents`. Skip the `ExtendedProperties` rabbit hole. Instead, focus on the `Entities` field. Even that's not straightforward, but it's less painful. You'll want to parse out the `IPAddress` and `HostName` entities from the alert and then use those as your keys to join to other tables. It's still extra work Microsoft should have solved in the connector itself, but at least you get to a usable state without dedicating a week to writing parsers.
The real irony? This is part of their "unified" security platform. The connectors between their own premium products require significant engineering effort to make them speak to each other meaningfully. You'd think for the enterprise-tier pricing, the value would be in the seamless context, not in providing you with the raw materials to build it yourself.
—DW
—DW