Splunk
A native Splunk app for delivering search results as alerts, with multi-value field parsing handled properly rather than flattened.
Alert sources
Purpose-built connectors understand the source's quirks (multi-value fields, incident evidence, polling windows) rather than treating it as a generic parser with a vendor name on it. The set below is where we are today; new connectors follow demand.
A native Splunk app for delivering search results as alerts, with multi-value field parsing handled properly rather than flattened.
Incident delivery by webhook, plus evidence polling through the Graph API so the investigation sees the entities attached to the incident, not just its title. MITRE tactics carry through.
Endpoint alerts polled through the Graph API and normalized into the same decision record as every other source.
Device compliance signals, treated as alerts that can participate in a correlation rather than as a separate reporting silo.
EDR incidents and endpoint behavioral detections, with a dedicated specialist analyst on the other side of the connector.
A generic endpoint that accepts JSON and normalizes it to OCSF on the way in. If your platform can fire a webhook or run a script, it can feed Intruex.
The generic path
A connector is only doing two jobs: getting the alert here, and expressing it in a shape the analysts understand. The second job is the hard one, and OCSF solves it in general rather than once per vendor.
If your SIEM can POST JSON (and every one of them can), you write a small mapping once and the entire pipeline works: routing, specialist analysis, enrichment, correlation, the decision record, all of it. There is no degraded mode for non-native sources.
In practice this is how most teams connect a second or third source, and it usually takes an afternoon. Bring us the payload shape and we will map it with you on the call.
{
"event_type" : "brute_force_success",
"severity" : "high",
"source" : "acme-siem",
"observed_at" : "2026-08-29T08:41:02Z",
"entities": {
"user" : "svc_backup",
"src_ip" : "203.0.113.44",
"dest_host" : "SRV-DC02"
},
"raw": { ... }
}
Enrichment
Indicators are resolved against multiple external intelligence sources (reputation, passive DNS, file and URL analysis, breach data and network telemetry) using your API keys, per tenant.
Automation
Response runs as a generic REST call into whatever automation you already own. Intruex selects and recommends; your system executes, after a human says yes. If you do not have an automation layer, we set one up with you.
Notification
Email escalation over your own SMTP configuration, and Slack webhooks. Both configured per tenant.
The point of normalizing
A Splunk search result, a Sentinel incident and an EDR detection arrive in three different shapes and mean three different things to three different consoles. After normalization they mean one thing to Intruex, which is what makes correlation across them possible at all.
It is also what keeps the audit trail uniform. The record an assessor reads is the same record regardless of which tool produced the alert, so your evidence does not fragment along vendor lines.
Hand it something from last week and read the reasoning. If the verdict is wrong, you will see exactly where it went wrong, which is the whole point.