Integrations

The Integrations view in the Telemetry section connects Alerts to your security tooling. Once a destination is connected, every new alert is rendered as an Detection Finding and delivered to it in near real time. This forwards alert findings derived from TrustGuard and TrustGate telemetry — the security detections raised in Alerts. To forward the tenant audit trail (authentication, user management, configuration changes) instead, see Audit Logs.

Supported destinations

Destination	Transport
Microsoft Sentinel	Azure Monitor HTTP Data Collector API
Datadog	Logs intake API
Splunk	HTTP Event Collector (HEC)
Elastic	Elasticsearch index / data stream
IBM QRadar	LEEF 2.0 over syslog (TLS)
Google SecOps (Chronicle)	Webhook feed (OCSF)
CrowdStrike Falcon Next-Gen SIEM	HEC / HTTP Event Data Connector
Rapid7 InsightIDR	Custom Logs event source (webhook)
Webhook	Generic HTTP POST (optional header auth + HMAC signature)

You can connect more than one destination — each new alert fans out to every connected integration whose filters match.

How forwarding works

A new alert is raised

Forwarding fires only for brand-new alerts. Repeated occurrences that dedupe into an existing alert do not re-forward, so a sustained attack won’t flood your SIEM.

The alert is rendered as OCSF

The alert is serialized into an OCSF Detection Finding — a vendor-neutral security event schema — carrying severity, source, entity, rule, and timestamps.

Filters decide the recipients

The finding is delivered to every connected destination whose filters match (see Delivery filters).

Delivery is retried on failure

Transient failures are retried with exponential backoff; permanently failed deliveries land in a dead-letter list you can inspect and requeue.

OCSF Detection Finding format

Every destination receives the same OCSF Detection Finding document (class UID 2004, category Findings). Splunk, Datadog, Elastic, Rapid7 InsightIDR, and webhooks get this JSON as the event body; QRadar receives a LEEF mapping derived from it; Sentinel wraps it for Log Analytics.

Top-level fields

Field	Type	Description
`class_uid`	`2004`	OCSF Detection Finding class
`category_uid`	`2`	Findings category
`type_uid`	`200401`	Create activity (`class_uid × 100 + activity_id`)
`activity_id`	`1`	Create
`severity_id`	int	OCSF severity: 2 Low, 3 Medium, 4 High, 5 Critical
`status_id`	int	1 New (open), 2 In Progress (acknowledged), 4 Resolved
`time`	ms epoch	Last seen
`start_time`	ms epoch	First seen
`end_time`	ms epoch	Last seen
`count`	int	Occurrence count (deduplicated matches)
`message`	string	Alert summary / use case description

`finding_info`

Field	Description
`uid`	Alert UUID
`title`	Use case / rule name
`desc`	Human-readable summary
`created_time`	First seen (ms epoch)
`types`	Product source array, e.g. `["trustguard"]`
`analytic.name`	Rule name (when present)
`analytic.type`	`"Rule"`

`metadata`

Field	Description
`product.name`	`NeuralTrust AlertEngine`
`product.vendor_name`	`NeuralTrust`
`version`	OCSF schema version (`1.3.0`)
`tenant_uid`	Team ID
`correlation_uid`	Dedup key (`use_case_id:entity_ref`)

`observables`

When the alert has an entity, one observable is included:

Field	Description
`name`	Entity type (e.g. `entity`, `user`)
`type`	OCSF observable type ID: 2 IP, 21 User, 99 Other
`value`	Entity reference (typically `consumer_id` UUID)

`related_events`

Array of { "uid": "<trace_id>" } entries — sample trace IDs linked to the alert for investigation.

Example (TrustGuard high-confidence threat)

This is the event body posted to Splunk HEC (inside the HEC envelope’s event field):

{
  "time": 1784134299689,
  "count": 1,
  "message": "A very high-confidence threat was blocked on a detection type without a dedicated rule.",
  "end_time": 1784134299689,
  "start_time": 1784134299689,
  "metadata": {
    "product": {
      "name": "NeuralTrust AlertEngine",
      "vendor_name": "NeuralTrust"
    },
    "version": "1.3.0",
    "tenant_uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "correlation_uid": "00000000-0000-4000-a000-000000000101:aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee"
  },
  "type_uid": 200401,
  "class_uid": 2004,
  "status_id": 1,
  "activity_id": 1,
  "observables": [
    {
      "name": "entity",
      "type": 99,
      "value": "aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee"
    }
  ],
  "severity_id": 4,
  "category_uid": 2,
  "finding_info": {
    "uid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "desc": "A very high-confidence threat was blocked on a detection type without a dedicated rule.",
    "title": "High-Confidence Threat (catch-all)",
    "types": ["trustguard"],
    "analytic": {
      "name": "High-Confidence Threat (catch-all)",
      "type": "Rule"
    },
    "created_time": 1784134299689
  },
  "related_events": [
    { "uid": "550e8400-e29b-41d4-a716-446655440000" }
  ]
}

start_time, end_time, time, and finding_info.created_time are Unix milliseconds. If you see -62135596800000, that indicates a zero first-seen timestamp from an older AlertEngine build — upgrade to a current release where first-seen is populated from the match timestamp.

Splunk HEC envelope

Splunk receives an outer wrapper around the OCSF body:

{
  "event": { "... OCSF finding above ..." },
  "source": "neuraltrust",
  "sourcetype": "neuraltrust:alert",
  "index": "your_index"
}

Default source type is neuraltrust:alert unless you override it in the integration settings.

Splunk search examples

index=your_index sourcetype="neuraltrust:alert"
| spath path=finding_info.title output=title
| spath path=severity_id output=severity_id
| spath path=finding_info.types{} output=source
| spath path=observables{0}.value output=entity
| spath path=related_events{0}.uid output=trace_id
| table _time title severity_id source entity trace_id correlation_uid

Map OCSF severity to labels:

`severity_id`	NeuralTrust severity
2	Low
3	Medium
4	High
5	Critical

Connect a destination

Open Telemetry → Integrations, choose a provider, and fill in its connection fields. Connections are validated on save — malformed settings are rejected before any alert is forwarded — and every secret is encrypted at rest.

Microsoft Sentinel

Streams findings to a Log Analytics workspace via the Azure Monitor HTTP Data Collector API.

Field	Required	Description
Workspace ID	Yes	Log Analytics workspace ID (GUID).
Shared Key	Yes	Workspace primary or secondary key (base64).
Log Type	No	Custom log table name (default `NeuralTrustAlert`).

Find both values in the Azure portal under Log Analytics workspace → Agents → Log Analytics agent instructions.

Datadog

Forwards findings to the Datadog logs intake.

Field	Required	Description
API Key	Yes	Created under Organization Settings → API Keys; sent as the `DD-API-KEY` header.
Region	No	Your Datadog site (e.g. `US1-datadoghq.com`). Must match your account region.
Service Tag	No	Optional service tag attached to all events.
Source	No	Source tag attached to events (e.g. `neuraltrust`).

Splunk

Posts findings to a Splunk HTTP Event Collector (HEC). Each alert is sent as one HEC event; the event payload is the OCSF Detection Finding JSON (see OCSF format above).

Field	Required	Description
HEC URL	Yes	HEC base URL. Splunk Cloud trial: `https://inputs.<stack>.splunkcloud.com:8088`. Production: `https://http-inputs-<stack>.splunkcloud.com` (port 443).
HEC Token	Yes	HTTP Event Collector token.
Index	No	Target index.
Source Type	No	Event source type (default `neuraltrust:alert`).
Skip TLS verification	No	Disable SSL verification for the HEC endpoint.
CA Certificate	No	Optional PEM CA for custom TLS verification.

CrowdStrike Falcon Next-Gen SIEM

Posts findings to a Falcon Next-Gen SIEM HEC / HTTP Event Data Connector. Each alert is sent as one HEC event; the event payload is the OCSF Detection Finding JSON (see OCSF format above).

Field	Required	Description
Ingest URL	Yes	The connector’s API URL. Accepted with or without the trailing `/services/collector` path.
API Key	Yes	The connector’s generated API key.

In Falcon Next-Gen SIEM, open Data connectors and add an HEC / HTTP Event Data Connector. Generate the API key — it’s shown only once, so copy it immediately — and copy the connector’s API URL into Ingest URL.

Elastic

Indexes findings into an Elasticsearch index or data stream. Authenticate with an API key or basic auth.

Field	Required	Description
URL	Yes	Elasticsearch base URL (e.g. `https://es.example:9200`).
Index	Yes	Target index or data stream.
API Key	No	Base64 Elasticsearch API key.
Username / Password	No	HTTP basic auth (alternative to the API key).

IBM QRadar

Sends LEEF 2.0 events to a QRadar event collector over syslog.

Field	Required	Description
Host	Yes	QRadar event collector hostname or IP.
Port	No	Collector port (default `514`).
Use TLS	No	Send over a TLS connection.
Skip TLS verification	No	Accept self-signed collector certificates.

Google SecOps (Chronicle)

Posts findings to a Google SecOps Webhook feed.

The integration is configured on the NeuralTrust side, so it won’t appear automatically in Google SecOps. This is expected.

In Google SecOps:

Create a Webhook feed with Log type Open Cybersecurity Schema Framework (OCSF).
Generate the feed’s Secret Key.
Copy the feed endpoint.

In NeuralTrust, open Telemetry → Integrations, select Google SecOps (Chronicle), and fill in:

Field	Required	Description
Webhook endpoint	Yes	The feed endpoint copied from Google SecOps.
API key	Yes	Google Cloud API key with access to the Chronicle API.
Webhook access key	Yes	The Secret Key generated for the feed.

Rapid7 InsightIDR

Posts findings to an InsightIDR Custom Logs event source that uses the Webhook collection method. Each alert is sent as one JSON event whose body is the OCSF Detection Finding (see OCSF format above), so InsightIDR parses its fields natively.

Field	Required	Description
Webhook URL	Yes	The URL InsightIDR generates for the event source, in the form `https://<region>.api.insight.rapid7.com/siem/custom/webhook/<id>`.

In InsightIDR, go to Data Collection → Add Data Source → Add Raw Data → Custom Logs, set the collection method to Webhook, leave JSON Events Key empty, and copy the generated URL into Webhook URL.The webhook URL is the only credential for the event source, so treat it as a secret: it is encrypted at rest and never shown again after saving. Only https URLs on <region>.api.insight.rapid7.com with the /siem/custom/webhook/ path are accepted.InsightIDR limits a single event to 100,000 characters. If an alert with many evidence events exceeds that limit, NeuralTrust keeps the earliest evidence, drops the rest, and sets unmapped.neuraltrust.evidence_truncated to true. The count field still reports the full number of occurrences.To find forwarded alerts in Log Search, select the event source’s log and filter with where(class_uid = 2004).

Webhook

POSTs the raw OCSF finding to any HTTP endpoint.

Field	Required	Description
URL	Yes	Destination URL.
Header Name / Header Value	No	An optional static request header for auth.
HMAC Secret	No	If set, adds an `X-NeuralTrust-Signature` signature over the request body so the receiver can verify authenticity.

Use Test connection after saving to send a synthetic finding through the destination and confirm connectivity before real alerts depend on it.

Delivery filters

A connected destination forwards all matching alerts by default. Filters only narrow that stream:

Filter	Effect
Minimum severity	Forward only alerts at or above a severity floor (e.g. `High` sends High and Critical).
Sources	Restrict to specific products (TrustGuard, TrustGate, Cross). Empty = all.
Severities	An explicit severity allow-list, when you want an exact set rather than a floor. Empty = all.

You can also pause a destination to stop forwarding without deleting its configuration.

Delivery health & troubleshooting

Each integration tracks a rolling 24-hour delivery health — the count of forwarded and failed events and the time of the last successful delivery.

Issue	What to check
Events not arriving	Verify the endpoint URL, credentials, and that the destination isn’t paused.
Authentication failed	Regenerate the API key / token and re-save (settings are re-validated on save).
Deliveries failing	Inspect the failed-delivery (dead-letter) list and requeue once the destination is healthy.
Nothing forwarded at all	Confirm the alert’s severity/source passes the destination’s filters.

Alerts

The detection use cases and alerts that produce the findings forwarded here.

Use Cases

Custom rule builder and compiled rule YAML reference.

Event schema

Metadata schema and detection field normalization.

Audit Logs

The tenant audit trail for authentication, user management, and configuration events.

Overview

Organization

Identity & Access

Telemetry

Audit & Compliance

Deployment

Integrations

Integrations

Supported destinations

How forwarding works

OCSF Detection Finding format

Top-level fields

`finding_info`

`metadata`

`observables`

`related_events`

Example (TrustGuard high-confidence threat)

Splunk HEC envelope

Splunk search examples

Connect a destination

Delivery filters

Delivery health & troubleshooting

Alerts

Use Cases

Event schema

Audit Logs

​Integrations

​Supported destinations

​How forwarding works

​OCSF Detection Finding format

​Top-level fields

​finding_info

​metadata

​observables

​related_events

​Example (TrustGuard high-confidence threat)

​Splunk HEC envelope

​Splunk search examples

​Connect a destination

​Delivery filters

​Delivery health & troubleshooting

​Related documentation

Alerts

Use Cases

Event schema

Audit Logs

Integrations

Supported destinations

How forwarding works

OCSF Detection Finding format

Top-level fields

`finding_info`

`metadata`

`observables`

`related_events`

Example (TrustGuard high-confidence threat)

Splunk HEC envelope

Splunk search examples

Connect a destination

Delivery filters

Delivery health & troubleshooting

Related documentation