Platform

How it works The analyst team Trust & audit Integrations Deployment Evidence

Solutions

Defense & suppliers Government Healthcare Financial services MSSPs

Company

About Partners Resources Contact Responsible disclosure
Home/Platform/Integrations

Integrations

Connect what you already run

Purpose-built connectors for the sources most teams are on, and a universal OCSF path for everything else. Whatever route an alert takes in, it lands in the same decision record with the same reasoning attached.

Alert sources

Native connectors, and a path for everything else

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.

Splunk

A native Splunk app for delivering search results as alerts, with multi-value field parsing handled properly rather than flattened.

nativepush

Microsoft Sentinel

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.

nativewebhook + poll

Microsoft Defender for Endpoint

Endpoint alerts polled through the Graph API and normalized into the same decision record as every other source.

nativepoll

Microsoft Intune

Device compliance signals, treated as alerts that can participate in a correlation rather than as a separate reporting silo.

nativepoll

Acronis EDR

EDR incidents and endpoint behavioral detections, with a dedicated specialist analyst on the other side of the connector.

nativepush

Any source, over REST

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.

OCSFuniversal

The generic path

A native connector is a convenience, not a requirement

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.

POST /v1/alerts
{
  "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": { ... }
}

Normalized to OCSF → routed to a specialist → enriched → dispositioned with confidence and reasoning.

Enrichment

Threat intelligence

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.

  • Results cached, so the same indicator is not billed twice within a window
  • Internal history weighed alongside external reputation
  • Sources are configurable, and can be turned off entirely for offline deployments

Automation

SOAR and playbooks

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.

  • Execution audit trail persisted against the alert
  • Approval gate, on by default
  • Actions execute in your automation, under your change control

Notification

Where escalations land

Email escalation over your own SMTP configuration, and Slack webhooks. Both configured per tenant.

  • Ticketing driven from the same automation path
  • Jira issues and ServiceNow records opened through your existing workflow
  • The full investigation package travels with the escalation, not a one-line summary

The point of normalizing

One decision record, whatever the source

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.

Bring us an alert you already know the answer to

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.