Skip to content
downpipes docs

Forward the downpipes audit trail to Securonix

Securonix 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 Securonix listener.

The one-time step is on the Securonix side: the incoming fields do not normalise into its schema until you have added the matching connector and its resource-type parser. That is a documented Securonix step, not an automatic one, so the events can arrive and still show unnormalised until the parser is in place.

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. Securonix’s own documentation does not confirm an HTTPS intake for this feed either, so the syslog-over-TLS path is the one to use. 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 Securonix role that can add an ingestion connector and select or define its resource-type parser.
  • Owner access to the downpipes console, and confirmation that your engine can reach the Securonix syslog listener on port 6514.

Set it up

  1. In Securonix, add an ingestion connector for CEF over syslog, and select or define the resource type and parser that map the CEF fields into the Securonix schema. Until that parser exists, events arrive but the fields do not normalise.
  2. Note the syslog-over-TLS listener address and port for that connector.
  3. 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).
  4. Set Delivery to Syslog over TLS, Format to CEF, enter the Securonix listener as Syslog host, and leave Port at 6514.
  5. Choose Test send to write one event over the socket (the cursor does not advance), confirm the connection landed, then check the fields normalised against your resource type in Securonix. Once they do, choose Enable.

What lands in Securonix

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. Your resource-type parser is what maps these into the Securonix schema fields.

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 Securonix data-handling rules to it as you would any access log.
  • The connector and its parser are the gate here: no parser, no normalised fields. For the shared push mechanics and the pull alternative, see Forwarding the audit log to your SIEM.

Last updated .