Okay, so we've been using Entra ID for identity governance and conditional access for a while, and I kept thinking: those risk detections are gold for our security posture, but they live in their own silo. Our SOC team lives in Splunk. Why not connect the dots?
I finally automated the export of Entra ID risk signals into Splunk for correlation with other logs. The goal was to create richer alerts—like pairing a 'risky sign-in' with a weird outbound traffic spike from that same user's device. Here's the basic workflow I pieced together:
* **The Source:** You'll be working with the **Azure AD Identity Protection** signals. Think 'user risk' (compromised credentials) and 'sign-in risk' (impossible travel, unfamiliar locations).
* **The Connector:** Microsoft Graph API is your friend here. Specifically, the `riskDetections` and `riskyUsers` endpoints. I set up a dedicated Azure App Registration with just the `IdentityRiskEvent.Read.All` and `IdentityRiskyUser.Read.All` permissions.
* **The Pipeline:** I used Azure Logic Apps as the glue—it's low-code and handles the scheduled polling nicely. The app fetches new risk events every 10 minutes, transforms the JSON into a more Splunk-friendly structure, and then posts it to our Splunk HTTP Event Collector (HEC) endpoint.
* **The Payoff in Splunk:** Now we can correlate! A simple search might join `signinRiskEvents` from Entra with our network firewall logs on `userPrincipalName` and `timestamp`. Suddenly, a medium-risk sign-in from a new country *followed* by an attempt to access a sensitive SharePoint file gets flagged automatically.
The trickiest part was mapping the Entra ID risk detail (like `riskEventType`) to our internal severity tiers. Also, watch out for API throttling if you have a huge tenant—you might need to implement some pagination logic.
Anyone else tried this? Curious if you're pulling different signals or using something other than Logic Apps (Azure Functions, Sentinel connectors?). And how are you building your correlation rules?
It's not marketing, it's logic.
Excellent initial setup. The choice of a dedicated app registration with minimal permissions is spot on, that's a security best practice often overlooked. A question for you as you build out the pipeline: have you given any thought to the event volume and potential duplication? When I set up a similar flow, I found the Graph API endpoints don't always have a strict "new events since" logic, so you'll need a robust de-duplication mechanism in your Logic App or on the Splunk ingest side to avoid alert fatigue from the same risk event being processed multiple times.
Also, while Logic Apps are great for a quick start, keep an eye on cost if your event volume climbs. Some teams eventually move the polling to a simple Azure Function for more control over batching and error handling. Really keen to see how you handle the data transformation for Splunk's CIM, that's often the trickiest part.
Stay curious.
Graph API and Logic Apps? You're building a house of cards on Microsoft's billing meter. That polling loop will either cost you a fortune or fall over when volume spikes.
Just write a python script that uses the delta query, run it in a cron job on a cheap VM. It's stupid, but it won't break and you can actually debug it when it does. Throwing more "low-code" at a log forwarding problem is how you end up with three different black boxes and no one who knows how any of them work.
If it ain't broke, don't 'upgrade' it.