Purpose
This guide explains how to connect Logsign USO to a Fortinet FortiDLP (cloud) tenant's Event Streaming Service and ingest detection, incident, action, and audit log events for security analytics and forensic purposes.
FortiDLP can also be reached indirectly today through a FortiAnalyzer webhook. That path only forwards a summarized alert and loses most of the event's own fields (file name, URL, sender/recipient, USB identifiers, matched policy, MITRE mapping). The Event Streaming Service API described here pulls the full event instead and is the supported way to get complete FortiDLP data into Logsign USO.
Prerequisites
- A FortiDLP Event Streaming Service stream, created specifically for Logsign. Do not point Logsign at a stream another system already consumes. A FortiDLP stream can only be read by one consumer at a time, and each event is removed from the queue the moment it is delivered. If Logsign and an existing SIEM both read the same stream_id, events are split between the two and neither receives a complete picture.
- An API access token for that stream, generated in the FortiDLP console with the SIEM Integration role. A token without this role authenticates but is rejected on every request to the streaming endpoint.
- The stream's event type filters confirmed with whoever configured it in FortiDLP. Each event family (Detections, Incidents, Audit Log, Actions) is enabled independently when the stream is created, and Detections/Incident formation additionally carry their own Minimum risk score filter (see the format trap below). Logsign only receives what the stream itself is configured to forward.
Step 1: Confirm Your Tenant Host and Stream ID
FortiDLP tenants are addressed by a region-specific host, for example eu-0.fortidlp.forticloud.com. There is no fixed, publishable list of these hosts: the value is assigned per tenant. Get the exact host and the stream's stream_id (a UUID) from your FortiDLP administrator or partner; both are shown on the stream's configuration page in the FortiDLP console.
Format trap: enter only the bare hostname in the Host field, for example eu-0.fortidlp.forticloud.com. Do not include a https:// prefix or a trailing path. The protocol is selected separately in Logsign (Step 3).
Step 2: Confirm the Token's Role and the Stream's Event Types
In the FortiDLP console, open the stream Logsign will use and confirm:
- The token attached to it (or the token you were given for it) carries the SIEM Integration role. Any other role produces a
403 Forbiddenon every request (see the error table below). - Which of the four event families, Detections, Incidents, Audit Log, and Actions, are enabled. Only enabled families reach the stream at all.
- If Detections is enabled but no detection events ever arrive: open the Detections filter panel and check the Minimum risk score field. This is a separate threshold from the family checkbox: a detection below the configured score is silently never sent to the stream, even though the family itself is turned on. The Incident formation section carries the same field. Set it to
0if you expect to see every detection Logsign's policies would otherwise catch.
Step 3: Configure the Integration in Logsign USO
Add a new FortiDLP data source in Logsign USO and provide:
| Field | Value |
|---|---|
| Protocol | HTTPS (default; HTTP is only offered for lab/test environments) |
| Host | Your tenant host from Step 1, for example eu-0.fortidlp.forticloud.com. Do not include a https:// prefix. |
| Stream ID | The stream's UUID from Step 1 |
| Access Token | The token confirmed in Step 2, with the SIEM Integration role |
| Verify TLS | Leave enabled unless your network team has a specific reason to disable certificate validation |
Logsign calls GET https://<host>/api/siem?stream_id=<stream_id>&format=jsonlines with the token as a Bearer credential, using FortiDLP's long-polling mode: each request stays open for up to 30 seconds and returns as soon as either that time elapses or 1,000 events accumulate, whichever comes first. Logsign chains consecutive long-polls together internally so the stream is read continuously rather than for only part of each collection cycle.
How Delivery Works: Read This Before Onboarding
FortiDLP's Event Streaming Service has no time filter, cursor, offset, or acknowledgement. An event is removed from FortiDLP's queue the instant it is written into the HTTP response Logsign receives, and there is no way to ask for it again. This is different from every other API source Logsign supports, which can replay a time window if a poller restarts.
Logsign is built around this: each event is written to raw storage before anything else touches it, which narrows the window in which an event could be lost to the moment between FortiDLP deleting it from its queue and Logsign's own write completing. It does not eliminate that window; it cannot, since FortiDLP itself offers no redelivery mechanism. In practice this means:
- There is no historical backfill. Turning the integration on does not retrieve anything that happened before the stream started being read, only what is waiting in the queue (or arrives afterward) is delivered.
- The "Initial lookback" field shown in the standard Logsign data source form has no effect for this integration and can be left as-is: FortiDLP's API has no time parameter for it to configure.
- If Logsign is offline for longer than FortiDLP retains undelivered events in the queue, events from that gap are not recovered when Logsign resumes. Fortinet's documentation does not state a specific retention duration for an unconsumed queue.
Error Codes and Troubleshooting
| HTTP Status | Meaning | What to check |
|---|---|---|
| 200 | Success | Events (if any accumulated during the 30-second window) were returned. |
| 204 | Success, no content | No events were waiting; normal on a quiet stream. Not an error. |
| 401 Unauthorized | The access token is missing, invalid, or revoked | Regenerate the token in the FortiDLP console and update it in Logsign USO. |
| 403 Forbidden | The token is valid but lacks the SIEM Integration role | Confirm the token's role in FortiDLP (Step 2). A token created for another purpose will authenticate but always fail here. |
| 404 Not Found | The stream_id does not exist, or does not exist on the tenant reached at this host | Re-confirm both the stream_id and the region host: a host for the wrong region will not find a stream_id that is valid elsewhere. |
| 409 Conflict | Another consumer is already reading this stream | Confirm no other system (including a second Logsign collector, in an HA setup) is configured with the same stream_id. This is the single-consumer constraint described in Prerequisites. |
| 429 Too Many Requests | Rate limited by FortiDLP | Logsign backs off automatically and retries. If this persists, it usually means the stream is receiving more volume than a single 30-second long-poll cycle can drain; contact Logsign support. |
Notes and Limits
- Single consumer per stream. A stream can only be read by one system. If you later need to send FortiDLP data to Logsign and another platform simultaneously, ask Fortinet/your FortiDLP administrator to create a second, independent stream with its own token rather than sharing one.
- At-most-once delivery. See "How Delivery Works" above. This is a property of FortiDLP's API, not a Logsign limitation, and applies to every consumer of this API, not only Logsign.
- Audit Log events are mapped generically. Fortinet's published documentation for this family (operator login/logout, policy and settings changes, data deletion) does not give a complete, stable set of event subtypes. Every Audit Log event is currently classified under a single generic category rather than split out by subtype; this will be refined once enough live traffic is available to confirm the exact values FortiDLP sends.
- Coverage. This integration covers the four Event Streaming Service families (Detections, Incidents, Audit Log, Actions) only. It does not cover any FortiDLP management/configuration API beyond what is described here.
- If you were previously receiving FortiDLP alerts through a FortiAnalyzer webhook, that path can be kept running in parallel or retired once this integration is confirmed to be receiving the event types you need. The two are independent and do not conflict.