Okay, so I finally got tired of jumping between the Sophos Central dashboard and our SIEM (we're using Datadog, but I've also done this with Splunk at previous companies). The context switching was killing my efficiency. Intercept X throws a great alert, but I needed to see it *next* to our application logs and network traffic patterns to really judge the blast radius.
I built a pretty straightforward workflow that I think others here might find useful. It's not fully automated remediation (I'm not that brave yet!), but it auto-creates a correlated incident ticket.
Here’s the basic flow:
* **Trigger:** A "Malware Found" or "Exploit Prevented" alert from Intercept X (via the Central Events API).
* **Enrichment:** The workflow grabs the endpoint hostname and timestamp, then queries our SIEM for events in a 5-minute window around that time, looking for:
* Unusual outbound connections from that host
* Failed login attempts in related systems
* Any process spawns from the affected user account
* **Correlation & Ticketing:** If any related SIEM events are found, it bundles the Intercept X alert details and the SIEM events into a single incident in our ticketing system (Jira Service Management, in this case). If nothing is found, it still creates a ticket, but with a lower priority.
The biggest **pitfall** I hit was timezone sync between Sophos Central (UTC) and our internally logged timestamps. That ate up an hour of debugging 😅.
**My question for the community:** Has anyone else built something similar? I'm curious about:
* What other SIEM data points you found valuable to correlate with.
* If you've taken the next step to automated containment (like isolating the endpoint via the API).
* How you're handling false positives – are you feeding that back into the workflow to auto-close?
I love this kind of integration work – it's like connecting your CRM to your marketing automation, but for security. The value is totally in the workflow connections.
Still looking for the perfect one
This is such a smart approach, and I've felt that exact pain of context switching. Your enrichment step looking for failed logins and process spawns is spot on - that's often where the real story is.
One thing I've found useful in similar workflows is adding a quick lookup against our asset management database. Knowing if the flagged host is a developer's laptop, a CI/CD server, or a public-facing web node instantly changes the incident's priority. It adds maybe two more API calls, but it helps our team triage way faster.
Have you thought about adding a simple scoring mechanism? Like, one related SIEM event creates a P3 ticket, but three or more different event types (like your outbound connection plus failed logins) auto-escalate to a P1? It's a logical next step from what you've built.
hannah
Nice setup! The 5-minute window is smart, but I've found it can be a bit tight sometimes, especially with log ingestion delays. I usually set mine to a 10-minute lookback and a 2-minute lookaward. Gives the SIEM a chance to catch up without pulling in too much noise.
Bundling it all into a single incident ticket is the real win. That's what finally stopped our security and platform teams from having the "whose data is this?" ping-pong match.
cost first, then scale
Agreed that the time window is critical, but "10-minute lookback and a 2-minute lookahead" is just kicking the can. You're still assuming logs land in order and that a 2-minute cushion solves it.
It doesn't. What happens when the SIEM is under load and you get a 15-minute delay from a particular data source? Your correlated ticket is now wrong or empty. This whole approach breaks without rock-solid, monitored log ingestion SLAs. Most shops don't have that.
The ticket consolidation is a good political fix for team ping-pong, I'll give you that. But if the data feeding it is unreliable, you're just creating a more authoritative-looking false positive.
Trust but verify.
The workflow itself is solid for cutting down toil. But I'm curious about the cost impact of querying your SIEM for that 5-minute window on every Intercept X alert, especially in Datadog. Their logs analytics pricing is per scanned GB.
Have you checked the volume of logs that query pulls back on average? If you're scanning several GB per alert and you get a lot of alerts, you might be adding hundreds to thousands to your Datadog bill monthly. Might be worth adding a filter to only query specific high-value log sources, not everything.
cost optimization, not cost cutting
You're absolutely right to flag the cost angle, it's an operational detail that often gets overlooked in the design phase. Datadog's scan-based pricing means this workflow's runtime cost scales directly with alert volume and log ingest volume.
The specific log sources you query make a massive difference. A blanket search across all ingested logs is financially untenable. In my setup, the enrichment step only targets three specific Datadog indexes: one for authentication events, one for network flow logs, and one for process execution logs from our EDR agent. This reduces the scanned data per query from potentially tens of GB to typically under 500 MB.
However, there's a secondary cost you didn't mention: the increase in indexed log volume if you start routing additional context into Datadog purely to support these correlated queries. That's where a cost-benefit analysis against using a separate data warehouse for the correlation logic comes in.
Data doesn't lie, but folks sometimes do.