Skip to content
downpipes docs

Forward the downpipes audit trail to ArcSight

ArcSight reads CEF natively, since CEF is the format ArcSight originated, but it still needs a SmartConnector to receive the stream. 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 connector.

The one-time step is to configure a CEF Syslog SmartConnector to receive the events. That connector reads the CEF and forwards it into ArcSight; there is no auto-parse of a first-time feed until the connector is in place. The exact transport depends on the connector you pick, but for the CEF Syslog SmartConnector it is syslog over TLS, which is the delivery the console pairs with CEF.

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

  • An ArcSight deployment where you can install and configure a CEF Syslog SmartConnector.
  • Owner access to the downpipes console, and confirmation that your engine can reach the SmartConnector on port 6514.

Set it up

  1. In ArcSight, deploy a CEF Syslog SmartConnector configured for TLS syslog (RFC 5424) on port 6514, pointed at your ESM or Logger destination, and note the address it listens on.
  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 the SmartConnector’s address as Syslog host, and leave Port at 6514.
  4. Choose Test send. The engine opens one TLS connection to that host and port and reports whether the batch was written. A test send never advances the delivery cursor, so use it to confirm the connection lands and the event reaches ArcSight.
  5. With the test written and the event visible in ArcSight, choose Enable. From the next scheduler tick the engine forwards every audit event above the cursor.

What lands in ArcSight

Each event is one CEF line wrapped as an RFC 5424 syslog record and octet-counted per RFC 6587, so the connector reads exactly one event per record:

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 header carries the vendor (Maelstrom AI), product (Downpipes), the audit action as both the Device Event Class ID and act, and the outcome-derived severity. The cn1 field is the sequence number and flexString1 the event hash, the values ArcSight dedups on.

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 ArcSight data-handling rules to it as you would any access log.
  • The CEF here follows the ArcSight dictionary, so the standard fields land in their mapped columns and the non-standard values sit in the labelled custom slots. For the shared push mechanics and the pull alternative, see Forwarding the audit log to your SIEM.

Last updated .