ArcSight

SIEM Platform

Synopsis

The ArcSight target forwards events, formatted as CEF, to Micro Focus / ArcSight over syslog. It handles transport framing (UDP, TCP, or TLS) — the event payload is expected to already be in CEF format when it reaches the target.

Schema

- name: <string>
  description: <string>
  type: arcsight
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    address: <string>
    port: <numeric>
    protocol: <string>
    hostname: <string>
    priority: <numeric>
    template: <string>
    max_message_size: <numeric>
    application_name: <string>
    tls:
      status: <boolean>
      verify: <boolean>
      server_name: <string>
      ca_name: <string>
      cert_name: <string>
      key_name: <string>
      passphrase: <string>
      min_tls_version: <string>
      max_tls_version: <string>
    field_format: <string>
    debug:
      status: <boolean>
      dont_send_logs: <boolean>

Configuration

The following fields are used to define the target:

Field	Required	Default	Description
name	Y		Target name
description	N	-	Optional description
type	Y		Must be arcsight
pipelines	N	-	Optional post-processor pipelines
status	N	true	Enable/disable the target

Connection

Field	Required	Default	Description
address	Y	-	ArcSight SmartConnector (CEF Syslog) IP or hostname. Resolved at dial time
port	N	514	Remote receiver port. 514 for tcp/udp, often 6514 for tls. Valid range 1–65535
protocol	N	tcp	Transport protocol: tcp, udp, or tls

note

In the GUI, the Port field is prefilled with 514 and switches to 6514 — the IANA syslog-tls port — as soon as protocol is set to tls or TLS Encryption is enabled. It switches back if TLS is turned off. A port you type yourself is never changed, and leaving it blank keeps the server-side default. This runs in the create wizard only: a saved target keeps its stored port when its transport changes. The prefill is a console convenience — the configuration default remains 514 regardless of transport.

Framing

Field	Required	Default	Description
hostname	N	this host's name	Hostname written into the syslog header
priority	N	13	Syslog PRI value (facility×8 + severity). Valid range 0–191; 13 = user.notice
template	N	`<{{.Priority}}>{{.BSDTimestamp}} {{.Hostname}} {{.Message}}`	BSD (RFC 3164) syslog header template. Set to `{{.Message}}` to send the raw payload with no header
max_message_size	N	0	Maximum framed line length in bytes. 0 sends the full event
application_name	N	product name	Syslog tag / app-name. Only rendered when template references `{{.AppName}}` — the default template does not use it

TLS

Field	Required	Default	Description
tls.status	N	false	Enable TLS. Must be true for any other tls field to take effect, including with protocol: tls
tls.verify	N	true	Verify the server certificate
tls.server_name	N	-	SNI / expected server hostname
tls.ca_name	N	-	Custom CA to trust. Empty uses the OS trust store
tls.cert_name	N*	-	Client certificate for mutual TLS
tls.key_name	N*	-	Client key for mutual TLS
tls.passphrase	N	-	Passphrase for an encrypted client key
tls.min_tls_version	N	tls1.2	Minimum negotiated TLS version
tls.max_tls_version	N	tls1.3	Maximum negotiated TLS version

* = Conditionally optional. tls.cert_name and tls.key_name must be supplied together to enable mutual TLS; supplying only one fails configuration validation.

note

TLS material fields (cert_name, key_name, ca_name, client_ca_name) accept any of the following:

• File name — resolved relative to the service root directory. Nested paths such as certs/prod/server.pem are supported.
• Absolute path — honored only if it resolves inside the service root. Any path that escapes the root is refused.
• Inline PEM content — used verbatim when the value contains -----BEGIN.
• Environment variable — ${ENV_VAR}.
• Vault reference — $secret{id=...} or $secret{store=...,ref=...}.

Processing

Field	Required	Default	Description
field_format	N	-	Optional target-side normalization format applied before delivery. Typically left empty, since the payload already arrives in CEF from upstream processing. See applicable Normalization section

Scheduling

See Scheduling and Pool Behavior for interval and cron fields shared by all targets.

Debug Options

Field	Required	Default	Description
debug.status	N	false	Enable debug logging
debug.dont_send_logs	N	false	Process logs but don't send to target (testing)

Details

This target is transport-only: it does not render CEF itself. It expects each event to already be a complete CEF record when it reaches the target, and applies syslog framing and delivery on top of that payload. There is no batching — each event is a single, complete delivery to the ArcSight SmartConnector CEF Syslog receiver.

Template Variables

The following variables are available in template:

Variable	Description
{{.Year}}	Current year (4-digit)
{{.Month}}	Current month (2-digit)
{{.Day}}	Current day (2-digit)
{{.Priority}}	Syslog PRI value
{{.Timestamp}}	Current time, RFC3339
{{.BSDTimestamp}}	Current time, RFC3164 (Jan _2 15:04:05)
{{.Hostname}}	Syslog-header hostname
{{.AppName}}	Application name (application_name)
{{.PID}}	Process ID
{{.Message}}	The CEF payload

If template fails to render, the target falls back to sending the raw, sanitized payload with no header.

Framing and Transport

Embedded carriage returns and line feeds in the payload are neutralized before framing, so one event cannot forge a second line on the wire. On a TCP or TLS stream, exactly one trailing newline delimits each event (RFC 6587 non-transparent framing); this is harmless on UDP. No size limit applies by default (max_message_size: 0); set a cap when the transport is UDP and the receiver enforces a lower datagram limit.

TLS

Set tls.status: true to enable TLS. The flag also controls whether the rest of the tls block is read, so it is required even with protocol: tls. Without it, protocol: tls still encrypts the connection, but with defaults only: the receiver certificate is verified against the host trust store, the name checked is the host part of address, and tls.verify, tls.ca_name, tls.server_name, tls.cert_name and tls.key_name are all skipped. Setting tls.status: true also selects TLS whatever protocol says. A client certificate is optional, but supplying tls.cert_name without tls.key_name, or the other way round, fails configuration validation. tls.verify defaults to true.

note

The target does not perform CEF rendering or field mapping — it only frames and delivers the payload it receives. Format the event as CEF before it reaches this target.

Examples

Basic Configuration

Sending CEF events to an ArcSight SmartConnector over TCP...

targets: - name: arcsight type: arcsight properties: address: "10.0.0.50"

Secure TLS

Delivering over an encrypted TLS connection with server verification...

targets: - name: arcsight-tls type: arcsight properties: address: "arcsight.example.com" port: 6514 protocol: tls tls: status: true verify: true

Capped UDP

Capping message size for a UDP receiver with a limited datagram size...

targets: - name: arcsight-udp type: arcsight properties: address: "10.0.0.50" protocol: udp max_message_size: 8192

Troubleshooting

This section covers the errors you are most likely to see with the arcsight target, what causes each one, and how to fix it. The opentext, trellix, snare and logpoint targets deliver over syslog in exactly the same way, so every entry here applies to them as well, with their own target type in place of arcsight. Only the payload your pipeline renders differs. Those pages point here.

Where to look:

• Director logs. Target errors are tagged with the target name and carry "Section":"SenderPool". The part after Reason: or after the last colon is the actual cause.
• The target's connection status in the web interface. It shows the same reason as the log line, prefixed with connection failed for <target name>:.

See Target Delivery Errors for how Director logs and retries target failures.

What the receiver needs

This target opens a socket and writes framed syslog lines to it. It uses no credentials and calls no API, so every prerequisite is network- or certificate-level.

Prerequisite	When it applies	Error when missing
A listener on the receiver, on the same protocol and port the target is configured with	Always	A dial failure on tcp and tls, typically reading connection refused. On udp nothing is reported at all
Outbound tcp or udp from every Director host to address and port	Always	i/o timeout while connecting, or target broken: write ... once an established session is blocked
DNS resolution of address from the Director host	When address is a hostname	dial tcp: lookup ...: no such host
The receiver's certificate chain trusted, through the host trust store or tls.ca_name	When TLS is used	tls: failed to verify certificate: x509: certificate signed by unknown authority
A receiver certificate that carries the address you connect to, or a tls.server_name that it carries	TLS with tls.verify at its default of true	x509: certificate is valid for ..., not ...
A client certificate and key issued by the authority the receiver trusts	Only when the receiver enforces mutual TLS	An alert from the receiver, typically remote error: tls: bad certificate
Room for one connection per sender worker, plus one opened at startup to validate the configuration	Always	failed to create per-worker siem syslog client: ... when the receiver's connection limit is reached
A source on the receiver that reads the format you send, delimited by newlines	Always	None. Director reports success and the receiver drops or mis-parses the events

Every certificate row above also requires tls.status: true, otherwise the setting that would fix it is never read. See the entry on that below.

"connection refused", and the target never initializes

[Error] [director] [target-<target id>] [arcsight] Failed to reinitialize target "arcsight" (attempt 6). Reason: dial tcp siem.example.com:514: ...

Cause: nothing accepted a connection on that port. The text after the last colon is the host operating system's own wording. It typically contains connection refused on Linux, and on Windows a longer sentence stating that the target machine actively refused it. Usually the receiver listens on a different protocol or port than the one configured here, is bound to another network interface, or is not running.

Fix: check which protocol and port the receiver actually listens on, and match protocol and port to it. The default 514 is normally plaintext, and TLS listeners normally sit on 6514. A tcp connection to a port where the receiver listens on udp only is refused, and the reverse combination reports nothing at all. Confirm the receiver is bound to an address the Director host can reach rather than to loopback, and allow the outbound flow from every Director host that runs this target. When only some connections fail, and the reason reads failed to create per-worker siem syslog client: ..., the receiver is out of connection slots: it needs one per sender worker, plus the one opened at startup to validate the configuration.

Data impact: nothing is sent while this lasts. Director retries after 5, 10, 20 and 40 seconds and then every minute, so the attempt counter climbs for as long as the cause persists. Data waits in the queue and is delivered once the target initializes. See Persistent Storage for how long the queue holds it.

"i/o timeout" or "no such host" while connecting

[Error] [director] [target-<target id>] [arcsight] Failed to reinitialize target "arcsight" (attempt 4). Reason: dial tcp siem.example.com:514: i/o timeout
[Error] [director] [target-<target id>] [arcsight] Failed to reinitialize target "arcsight" (attempt 2). Reason: dial tcp: lookup siem.example.com: no such host

Cause: connecting is bounded to 30 seconds, and that budget also covers the TLS handshake. A timeout means the attempt was dropped rather than refused, which points to a firewall that discards the packets, a wrong route, or a receiver that accepts the connection but never starts the handshake it was configured for. no such host means address does not resolve from the Director host. It applies to udp too, because the name is resolved before the first datagram is sent.

Fix: open the path on every firewall between the Director host and the receiver, and verify the route. With protocol: tls, confirm the receiver speaks TLS on that port. For the lookup failure, fix DNS on the Director host or set address to the IP address.

Data impact: the same as a refused connection. Nothing is sent, the queue grows, and delivery resumes without a restart once the target initializes.

TLS settings do nothing unless tls.status is true

tls.status is the switch that makes Director read the tls block at all. Until it is true, every other field in that block is skipped without a warning.

The symptom depends on protocol:

• With protocol: tcp or protocol: udp, the connection carries no TLS. Events leave the Director host in the clear even though the tls block is filled in. Against a receiver that only accepts TLS on that port, this typically fails in a way that looks like a protocol mismatch: the target initializes, then the receiver closes the connection and events fail with target broken: write ....
• With protocol: tls, the connection is encrypted, but with defaults only. The receiver certificate is verified against the host trust store, and the name checked is the host part of address. tls.verify, tls.ca_name, tls.server_name, tls.cert_name and tls.key_name have no effect. A private authority still fails with x509: certificate signed by unknown authority while tls.ca_name names the right file, and tls.verify: false appears to be ignored.

Fix: set tls.status: true whenever any tls field is meant to apply, including with protocol: tls.

protocol: tls
tls:
  status: true
  ca_name: "certs/corp-ca.pem"

warning

Setting protocol: tls alone is not enough. It selects an encrypted transport, but it does not enable the settings that control how the receiver's certificate is checked.

Data impact: nothing is logged about the skipped settings. Either events keep flowing over a connection you did not configure, or the target sits in the retry loop with data queued while a certificate setting that looks correct is never applied.

note

tls.status: true wins over protocol. With tls.status: true and protocol: udp the target sends over TLS on TCP, since TLS always runs over TCP. Set protocol: tls so the configuration reads the way it behaves.

"x509: certificate signed by unknown authority"

[Error] [director] [target-<target id>] [arcsight-tls] Failed to reinitialize target "arcsight-tls" (attempt 5). Reason: tls: failed to verify certificate: x509: certificate signed by unknown authority

Cause: the receiver presents a certificate from a private or self-signed authority that the Director host does not trust, and tls.ca_name is either unset or not in effect because tls.status is false.

Fix: set tls.status: true and point tls.ca_name at the issuing authority in PEM form. Two follow-up reasons mean the material itself was rejected rather than the chain:

• ca_name "ca.pem" contains no valid PEM certificate(s) means the file is not PEM. Convert it, so that it begins with -----BEGIN CERTIFICATE-----.
• ca_name: "..." could not be resolved (env/vault token, inline PEM, or a path under the service root) means the path is outside the service root, or the file is empty or unreadable by the service account. Copy the file under the service root and reference it relatively.

Turning tls.verify off hides the error instead of fixing it, and leaves the connection open to interception.

Data impact: nothing is sent, data waits in the queue, and the retry loop repeats the reason on every attempt. Certificate material is read when the target starts, so a rejected file shows up as a repeating retry reason rather than as a configuration validation failure.

"certificate is valid for ..., not ..."

[Error] [director] [target-<target id>] [arcsight-tls] Failed to reinitialize target "arcsight-tls" (attempt 3). Reason: tls: failed to verify certificate: x509: certificate is valid for siem.example.com, not <address>

Cause: the certificate is trusted, but it does not carry the address you connect to. This is normal when address is an IP address, since a certificate matches an IP only when it carries that IP itself. The name checked is the host part of address, unless tls.server_name is set and in effect.

Fix: set address to a name the certificate carries, or keep the IP and set tls.server_name to one of those names, together with tls.status: true. A related reason, x509: certificate has expired or is not yet valid, means the receiver certificate is out of date or the clock on one of the two hosts is wrong.

Data impact: nothing is sent and data waits in the queue until the handshake succeeds.

"first record does not look like a TLS handshake", or an alert from the receiver

[Error] [director] [target-<target id>] [arcsight-tls] Failed to reinitialize target "arcsight-tls" (attempt 2). Reason: tls: first record does not look like a TLS handshake

Cause: the two ends disagree about the connection. The reason above means the target speaks TLS to a plaintext listener, typically protocol: tls against port 514. A reason that starts with remote error: tls: is the receiver rejecting the handshake instead. Which alert it sends is up to the receiver: typically bad certificate or unknown certificate authority when it requires a client certificate and none or the wrong one was presented, and protocol version not supported or handshake failure when no TLS version or cipher suite is common to both.

Fix: point port at the receiver's TLS listener, often 6514, or use protocol: tcp for a plaintext one. For a receiver that requires mutual TLS, set tls.cert_name and tls.key_name to a pair issued by the authority it trusts. They must be supplied together, otherwise the configuration is rejected with invalid tls configuration and nothing is sent. If the receiver only offers an older TLS version, lower tls.min_tls_version.

Data impact: nothing is sent and data waits in the queue until the handshake completes.

"target broken: write ..." after a quiet period

[Error] [director] [target-<target id>] [arcsight] Sender worker 2 execute() failed for arcsight/...: target broken: write tcp ...->siem.example.com:514: ...
[Information] [director] [target-<target id>] [arcsight] Target "arcsight" reinitialized successfully (generation 2).

Cause: the connection was open and something closed it. The cause after the last colon is the host operating system's wording, and typically contains broken pipe or connection reset by peer on Linux, and on Windows a sentence stating that an existing connection was forcibly closed. The target keeps one long-lived connection per worker and only writes to it when events flow, so a receiver, firewall or load balancer that drops idle sessions closes it during quiet hours. Nothing notices until the next event, which is why this appears as a write failure on the first batch after the gap. A receiver restart produces the same error.

A write that fails with i/o timeout in the same shape is different. There the connection is alive but the receiver stopped reading for 30 seconds. Check the receiver for back-pressure, a stalled parser, or a full disk.

Fix: none is usually needed. Director reconnects and logs Target "arcsight" reinitialized successfully (generation N). If it recurs on a fixed rhythm, raise the idle timeout on the receiver and on everything in the path.

Data impact: the record that hit the closed connection is redelivered about every 5 seconds until a write succeeds. Records written before the failure are checkpointed and skipped on redelivery, so they are not sent twice, and delivery resumes from the record that failed. Events written just before the close can still be lost with no error at all, because syslog has no application-level acknowledgment and the target has already counted them as sent.

"message too long" on udp

Cause: a framed line larger than the datagram limit of the host, which is typically just under 64 KB, while max_message_size is 0. The cause after the last colon comes from the operating system, and typically contains message too long on Linux, and on Windows a sentence stating that the datagram was larger than the internal message buffer.

Fix: set max_message_size, for example 8192, or switch to tcp or tls, where no cap is needed. Receivers typically accept far less than the host limit, so a cap is worth setting on udp even before you see this error.

Data impact: this record is not discarded. It is retried every few seconds and fails every time, and nothing queued behind it is delivered until the configuration changes. Once a cap is in place the record is truncated and the queue moves again.

"ValidateConfig failed for target ..."

[Error] [director] [target-<target id>] [arcsight] ValidateConfig failed for target "arcsight": unknown connection type

Cause: the configuration was rejected before any connection was attempted. The reason names the field:

Reason	Meaning
invalid address	address is empty
unknown connection type	protocol is not exactly tcp, udp or tls. The check is case-sensitive, so TCP, Tls and ssl all fail, and the message does not echo the value
port must be between 1 and 65535, got ...	port is outside the valid range
priority must be between 0 and 191, got ...	priority is outside the syslog range. It is the facility times 8 plus the severity, and 13 is user.notice
invalid tls configuration	tls.status is true with only one of tls.cert_name and tls.key_name. Supply both for mutual TLS, or neither

Fix: correct the field the reason names. Nothing is sent until the configuration changes, and the configuration is re-checked on its own, so no restart is needed once you save it.

The target is healthy but nothing arrives at the receiver

Check these in order.

1. debug.dont_send_logs is enabled. Events are processed and then discarded instead of being sent, and the target's outgoing event counter does not move. When debug.status is enabled as well, startup logs Log sending is disabled for this target (arcsight). Logs will be processed by the pipeline but will not be sent to the target. With debug.status off there is no trace at all. Remove the flag.

2. The transport is udp. Nothing acknowledges a datagram. The write succeeds as soon as the host accepts it for sending, so a receiver that is down, overloaded or on another port loses the events with no error, while the target counts them as delivered. When the receiver's host answers with an ICMP port-unreachable message, a later write typically fails with a refused-connection cause. Otherwise the loss is completely silent. Use tcp or tls when you need delivery to be visible.

3. max_message_size is set and the events are longer. The framed line is cut at the cap with no marker and no log line, and the counter reports the length before the cut. The cut is by bytes, so it can split a multi-byte character or a key=value pair and leave the receiver with a partial record. Raise the cap, or set it to 0 on tcp and tls.

4. template does not render. A template that fails to parse or execute is not reported. Every event goes out as the bare sanitized payload with no syslog header, and nothing is logged to say so. Unbalanced braces are the common case. A variable that does not exist is not one of these failures: it renders the literal text <no value> into the header, and the event is still framed and sent. Use only the variables listed above, and test at low volume after editing.

5. The receiver reads the events as another format. This target only frames and delivers the payload it is given, so a source configured for a different format accepts the connection and then drops or mis-parses what arrives. Check the receiver's own parser or source logs, and confirm the pipeline attached to the target renders the payload that source expects.

6. The events never reach the target. The pipeline that prepares the payload drops events it cannot classify. Those show in the pipeline's drop counters rather than the target's, so the target stays idle and healthy.