Skip to content
downpipes docs

Forward the downpipes audit trail to FortiSIEM

FortiSIEM receives the downpipes audit trail as CEF carried over real syslog transport. On the scheduler tick the engine shapes each audit event as a CEF line, wraps it as an RFC 5424 syslog record, and writes the batch over one TLS socket to your FortiSIEM collector.

One honest caveat sets your expectations before you start. FortiSIEM parsing this CEF into named fields is reported by the community, not documented by Fortinet, so treat it as unconfirmed. Point FortiSIEM at the stream, then verify with a live send that the fields actually parsed the way you need before you rely on it. If they did not parse, you may need a custom event parser on the FortiSIEM side.

Because the engine makes the outbound call, a Cloudflare Access perimeter on your console hostname never blocks this: there is no inbound request for Access to turn away.

CEF only parses when it arrives over real syslog transport, an RFC 5424 record over TCP with TLS, by default on port 6514, which is the Syslog over TLS delivery. A plain HTTPS POST of a CEF line is never parsed, and the console blocks the CEF-over-HTTP pairing outright. Cloudflare does not document whether a Worker can open an outbound connection to port 6514, so confirm the connection lands from your own engine with Test send before you rely on it.

What you need

  • A FortiSIEM collector or supervisor listening for syslog over TLS, and the access to check how an incoming event was parsed.
  • Owner access to the downpipes console, and confirmation that your engine can reach the collector on port 6514.

Set it up

  1. In FortiSIEM, confirm a collector or the supervisor is listening for syslog over TLS, and note the address and port it accepts on (6514 by default).
  2. In the downpipes console, open Integrations, choose this vendor’s tile, and set up the SIEM audit push there (owner-only, asks for a fresh step-up sign-in).
  3. Set Delivery to Syslog over TLS, Format to CEF, enter your FortiSIEM collector’s address as Syslog host, and leave Port at 6514.
  4. Choose Test send to write one event over the socket. A test send never advances the delivery cursor, so use it to confirm the connection lands.
  5. In FortiSIEM, open the event that arrived and check whether the CEF fields (act, suser, src, seq, the hash) parsed into named attributes rather than sitting as raw text. Only if they parsed as you need, choose Enable back in the console.

What lands in FortiSIEM

Each event is one CEF line wrapped as an RFC 5424 syslog record and octet-counted per RFC 6587:

CEF:0|Maelstrom AI|Downpipes|<engine version>|restore-approve|Restore approve|3|rt=1750299248221 suser=ops@acme.example src=203.0.113.7 act=restore-approve outcome=success cs3Label=targetKind cs3=restore cn1Label=seq cn1=4097 flexString1Label=hash flexString1=sha384:22cd...01

The act, suser and src fields are the audit action, operator email and source IP; cn1 is the sequence number and flexString1 the event hash. Whether FortiSIEM lifts these into named attributes is exactly what your live test confirms.

Good to know

  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and a hash; index on either and a re-sent event lands as a duplicate you can drop rather than a second incident. The feed carries operator identity (member emails, source IPs, roles and approver emails) and no backup data or secret values, so apply your FortiSIEM data-handling rules to it as you would any access log.
  • FortiSIEM parsing of this CEF is not documented by Fortinet. Confirm it with a live send and check the fields before you rely on it, and keep a custom parser in reserve if your version does not lift them. For the shared push mechanics and the pull alternative, see Forwarding the audit log to your SIEM.

Last updated .

Community-reported CEF parsing behaviour last confirmed .