Syslog Integration Guide

Overview

The Syslog integration allows your NINA workflows to send structured log messages to any RFC 5424-compliant syslog collector over TLS (RFC 5425). This enables SIEM integration, centralized logging, and real-time security event correlation from workflow outputs.

Status

The integration currently supports:

• Message Sending: Send syslog messages with configurable facility, severity, hostname, app name, and message ID
• TLS Transport: Mandatory TLS encryption with certificate validation
• Mutual TLS (mTLS): Optional client certificate authentication for zero-trust environments
• Structured Data: RFC 5424 structured data elements for machine-parsable metadata
• Execution Metadata: Automatic injection of workflow execution context (execution ID, workflow ID, node ID) for SIEM correlation
• JSON Envelope: All messages are wrapped in a {"data": ..., "metadata": ...} JSON envelope for consistent parsing

Credential Configuration

Before using the Syslog integration in your workflows, you need to configure credentials for your syslog collector.

Authentication Fields

Field	Description	Required	Default	Example
Host	Syslog collector hostname or IP	Yes	—	siem.company.com
Port	Syslog TLS port	Yes	—	6514
CA Certificate	PEM-encoded CA certificate to verify the server	No	System CA pool	—
Client Certificate	PEM-encoded client certificate for mTLS	No	—	—
Client Key	PEM-encoded client private key for mTLS	No	—	—
Insecure Skip Verify	Skip TLS certificate verification (testing only)	No	false	true

Note: Client Certificate and Client Key must be provided together for mTLS. If only one is provided, credential validation will fail.

Provider-Specific Setup

Devo

Field	Value
Host	us.elb.relay.logtrust.net or eu.elb.relay.logtrust.net
Port	443
CA Certificate	Devo relay CA (download from Devo console)
Client Certificate	Your organization's Devo client certificate
Client Key	Your organization's Devo client key

Note: Devo requires mTLS authentication. Both client certificate and key are mandatory.

Splunk (HEC Syslog Input)

Field	Value
Host	Your Splunk HEC endpoint
Port	6514
CA Certificate	Splunk server CA if using self-signed certificates

QRadar

Field	Value
Host	Your QRadar Console or Event Collector IP
Port	6514
CA Certificate	QRadar server CA if using self-signed certificates

Creating a Syslog Credential

1. Navigate to the Credentials section in NINA
2. Click Add New Credential
3. Fill in the credential details:
   • Name: A descriptive name (e.g., "Production SIEM - Devo")
   • Description: Optional details about the credential's purpose
   • Integration Service: Select "Syslog"
   • Fill in the authentication fields (Host, Port, certificates if needed)
4. Click Create to save and validate the credential

Note: Credential validation performs a real TLS handshake to the configured host:port to verify connectivity and certificate validity.

Supported Resources and Operations

Message

Operation	Description
Send	Sends a syslog message to the configured collector

Send Message Parameters

Required Parameters

Parameter	Type	Required	Description
facility	string	Yes	Syslog facility (see table below)
severity	string	Yes	Syslog severity level (see table below)
message	string	Yes	The log message body. Can be plain text or JSON.

Advanced Options (additionalFields)

These parameters are nested under the Advanced Options section in the node configuration UI.

Parameter	Type	Required	Default	Description
hostname	string	No	zynap	Source hostname (max 255 chars per RFC 5424)
appName	string	No	zynap	Application name (max 48 chars per RFC 5424)
procId	string	No	Auto (execution ID)	Process identifier. If omitted and metadata is enabled, automatically set to the workflow execution ID for SIEM correlation.
msgId	string	No	- (nil)	Message type identifier for categorizing log types (max 32 chars per RFC 5424)
structuredData	JSON	No	[]	RFC 5424 structured data as JSON array: [{"id":"sdID@enterprise","params":[{"name":"key","value":"val"}]}]
includeMetadata	boolean	No	true	Include Zynap execution context (workflow ID, execution ID, node ID) as RFC 5424 structured data and in the JSON envelope

Facility Values

Value	Code	Description
kern	0	Kernel messages
user	1	User-level messages
mail	2	Mail system
daemon	3	System daemons
auth	4	Security/authorization
syslog	5	Syslog internal
lpr	6	Line printer subsystem
news	7	Network news subsystem
uucp	8	UUCP subsystem
cron	9	Clock daemon
authpriv	10	Security/authorization (private)
ftp	11	FTP daemon
local0–local7	16–23	Local use. Recommended for SIEM integrations.

Severity Values

Value	Code	Description
emergency	0	System is unusable
alert	1	Action must be taken immediately
critical	2	Critical conditions
error	3	Error conditions
warning	4	Warning conditions
notice	5	Normal but significant
informational	6	Informational messages
debug	7	Debug-level messages

Message Format

JSON Envelope

All messages are wrapped in a JSON envelope in the RFC 5424 MSG field:

{
  "data": "<original message>",
  "metadata": {
    "workflow_execution_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "workflow_id": "11111111-2222-3333-4444-555555555555",
    "node_id": "66666666-7777-8888-9999-000000000000",
    "node_execution_id": "aaaaaaaa-1111-2222-3333-444444444444"
  }
}

• If the original message is valid JSON, data contains the parsed object/array (not a double-escaped string)
• If the original message is plain text, data contains the string as-is
• metadata is present when includeMetadata is enabled (default: true) and the node is executed from a NINA workflow
• When includeMetadata is false, the envelope contains only {"data": ...} without the metadata object

RFC 5424 Structured Data

When execution metadata is available, the integration also injects RFC 5424 structured data:

[zynap@0 executionId="..." workflowId="..." nodeId="..."]

This allows SIEMs that parse structured data (Devo, Splunk, QRadar) to index these fields natively.

ProcID Auto-Population

When no procId is specified in the node parameters, the integration automatically sets the RFC 5424 PROCID field to the workflow_execution_id. This enables correlation of all syslog messages from the same workflow execution.

If you explicitly set procId, your value takes precedence over the automatic injection.

Example: Basic Security Alert

Node Configuration:

{
  "resource": "message",
  "operation": "send",
  "parameters": {
    "facility": "local0",
    "severity": "warning",
    "hostname": "zynap-scanner",
    "appName": "vuln-scan",
    "msgId": "VULN-001",
    "message": "Open port 3389 (RDP) detected on 10.0.0.42"
  }
}

Resulting RFC 5424 message:

<132>1 2026-05-19T16:49:55Z zynap-scanner vuln-scan <exec-id> VULN-001 [zynap@0 ...] {"data":"Open port 3389 (RDP) detected on 10.0.0.42","metadata":{...}}

Example: Forwarding Structured Scan Results

When an upstream node produces JSON output (e.g., a nuclei scan), pass it directly as the message parameter. The integration embeds it as a native JSON object — no double-escaping:

Node Configuration:

{
  "resource": "message",
  "operation": "send",
  "parameters": {
    "facility": "local0",
    "severity": "critical",
    "appName": "nuclei",
    "msgId": "SCAN-RESULT",
    "message": "{\"host\":\"10.0.0.42\",\"template\":\"CVE-2024-1234\",\"severity\":\"critical\"}"
  }
}

Resulting JSON in MSG field:

{
  "data": {
    "host": "10.0.0.42",
    "template": "CVE-2024-1234",
    "severity": "critical"
  },
  "metadata": {
    "workflow_execution_id": "...",
    "workflow_id": "...",
    "node_id": "...",
    "node_execution_id": "...",
    "organization_id": "..."
  }
}

Example: Custom ProcID Override

If your SIEM expects a specific procId format (e.g., a ticket ID or scanner session):

{
  "resource": "message",
  "operation": "send",
  "parameters": {
    "severity": "informational",
    "procId": "SCAN-20260519-001",
    "message": "Scan completed: 142 hosts, 3 critical findings"
  }
}

The user-specified procId takes precedence. Execution metadata is still included in the structured data and JSON envelope.

Troubleshooting

Common Issues

1. Connection Timeout:

   • Verify the host and port are correct
   • Check that your network/firewall allows outbound connections on the syslog TLS port (commonly 6514)
   • Ensure the syslog collector is listening for TLS connections (not plain TCP/UDP)

2. TLS Handshake Failed:

   • Verify the CA certificate matches the server's certificate chain
   • For self-signed certificates, provide the CA PEM or enable insecureSkipVerify (testing only)
   • For mTLS, ensure both client certificate and key are valid and match

3. Credential Validation Fails:

   • Validation performs a real TLS connection attempt. If the server is behind a VPN or private network, ensure the NINA worker has network access
   • Check that the port number is correct (6514 is standard for syslog-over-TLS)

4. Messages Not Appearing in SIEM:

   • Verify the facility and severity match your SIEM's filter/routing rules
   • Check that the SIEM is configured to accept RFC 5424 format (not legacy BSD/RFC 3164)
   • Some SIEMs require specific appName or hostname values for routing — consult your SIEM documentation

5. JSON Parsing Issues in SIEM:

   • The MSG field contains a JSON envelope. Configure your SIEM to extract data and metadata fields
   • For Devo, use jsonparse() in LINQ queries. For Splunk, use spath
   • Ensure your SIEM is not truncating the MSG field (check max message length settings)

Best Practices

1. Security:

   • Always use mTLS when your collector supports it (zero-trust principle)
   • Never use insecureSkipVerify in production
   • Store CA certificates and client keys in NINA credentials, not in node parameters

2. SIEM Correlation:

   • Use the auto-populated procId (workflow execution ID) to correlate all messages from a single workflow run
   • Use msgId to categorize log types (e.g., VULN-001, SCAN-RESULT, ALERT-CRITICAL)
   • Use consistent appName values across workflow nodes for source identification

3. Performance:

   • Each message opens a new TLS connection (per RFC 5425 best practice for reliability)
   • For high-volume logging, consider batching messages in the upstream scripting node and sending a single JSON array

4. Structured Data:

   • The metadata field in the JSON envelope is your primary correlation tool
   • Use workflow_execution_id to group all events from a single run
   • Use node_id to identify which workflow step generated the log

Updated: 2026-05-20