Centralizing Syslog the NIST SP 800-92 Way

What NIST SP 800-92 asks of a logging pipeline

NIST SP 800-92, the guide to computer security log management, is the yardstick a logging pipeline gets judged against, and its guidance is usually summarized by a few properties:

• Centralization. Logs should be collected from many systems into a central location instead of left on each device, so a compromised host cannot delete the only copy of its records.
• Protection from tampering and undue influence. Collected log data should be protected from alteration or deletion, and the collection machinery should resist undue influence from unauthorized users.
• Access control. Access to logs and the systems that collect them should be restricted to authorized people and processes.
• Completeness and timeliness. Collection should capture what devices actually generate, with few gaps and little delay.

The standard names no products and prescribes no specific collector; the property list is this post's checklist for the Syslog Source.

The syslog source

Cribl Stream ships with a Syslog Source preconfigured to listen for both UDP and TCP traffic on Port 9514, per the Syslog Source documentation. Clone it or modify it directly, then enable it. The Source receives syslog data from devices, parses messages into structured fields, and stores unrecognized messages in a raw format.

The page marks the Source as Push type with TLS support: YES and Event Breaker Support: No. It documents the RFC 3164 and RFC 5424 structured formats (timestamps, facility codes, severities, message content) and RFC 5425 and RFC 6587 message-length prefixes, which the page says ensure complete and accurate data transmission. Noncompliant messages arrive with only the raw message, receive time, and sender IP.

Under General Settings, the page documents an Input ID (prefilled in_syslog_default on the default Source, unchangeable in the UI), a Description, an Address to listen on (default 0.0.0.0, all interfaces; 127.0.0.1, localhost only), a UDP port (optional when listening on TCP; maximum 16,384 bytes per message), and a TCP port (optional when listening on UDP). Fields to keep (defaults to keeping all fields) and Tags (group and filter Sources in the UI; not added to events) complete the tab.

The TLS Settings section is labeled TCP Only, and Enabled is off by default. Enable it and you supply a PEM Certificate path and Private key path, from a predefined certificate or entered manually, plus a Passphrase. Authenticate client (mutual auth) is off by default; enabled, it requires client certificates validated against a Trusted client CA path. Peer certificates must match a Common name regex (default .*). Minimum and Maximum TLS version reject out-of-range clients, and a TLSv1 or TLSv1.1 minimum triggers a deprecation warning.

Persistent Queue Settings optionally configure a queue that buffers and preserves incoming events when a downstream Destination has an outage or experiences backpressure. Enable persistent queue is off by default. Mode is Always On (the default; events are written to the queue before forwarding) or Smart (backpressure only; deprecated for hybrid and on-prem, auto-migrating to Always On in January 2027). The page documents Buffer size limit (bytes) (64KB to 10MB, default 1MB; replaces the deprecated events-based setting as of 4.18.0), Queue size limit (default 5 GB), Compression (default None), and Queue-full behavior: Block (default) or Drop new data. On Cribl-managed Cloud Workers (Enterprise plan), only the enable toggle appears, and PQ runs Always On at a fixed 1 GB.

Processing Settings documents Fields (add or modify fields via JavaScript expressions), Auto parse (off by default), and a pre-routing Pipeline. Advanced Settings documents the transport options: Enable proxy protocol for proxied TCP (the enhanced TLS handshake preserves the original source IP), Single msg per UDP (off by default; newlines within a packet act as event delimiters), Allow non-standard app name (hyphens in RFC 3164 TAG sections), Enable TCP load balancing (single-instance and Distributed deployments; needs a TCP port), IP allowlist regex (default .*, all IPs), Active connection limit (default 1000), TCP socket timeouts, a UDP-only Buffer size limit (events), and UDP socket buffer size (kernel SO_RCVBUF). Connected Destinations offers Routes for conditional routing and cloning, or QuickConnect for direct delivery.

Mapping the standard's properties to the source

The mapping below is deliberately narrow: for each property I name the specific setting this page documents, with its conditions, and mark plainly where the page documents nothing. The post does not claim the Syslog Source satisfies or meets NIST SP 800-92.

• Centralized collection. Centralizing is the Source's whole purpose: it listens on a configured address and ports for syslog senders, and the default Source listens on Port 9514 for both UDP and TCP.
• Protection from tampering in transit. The page documents TLS for this Source under a section labeled TLS Settings (TCP Only), so TCP syslog can be encrypted in transit. Both conditions matter: TLS applies to TCP only, and Enabled is off by default, so it is configured behavior, not a default posture. Minimum TLS version adds a protocol floor.
• Protection from undue influence. The page documents the access controls at the collection point: the IP allowlist regex, limiting which sender addresses may connect, and mTLS, which requires client certificates validated against a trusted CA and a Common name regex. The caveat is in the defaults: the allowlist defaults to .* (all IPs) and client authentication is off by default, so these are controls you configure, not a posture you inherit.
• Completeness of collection. Persistent queue covers the collector losing records during downstream trouble: it buffers and preserves incoming events when a downstream Destination has an outage or backpressure, and with Queue-full behavior as Block (default) the Source waits for capacity instead of discarding. For UDP the page is explicit that high send rates can drop data, so UDP completeness depends on the documented tuning.
• Timely collection. The page documents a live listener: the Live Data tab captures real-time events as they are ingested. It gives no latency figures or timing guarantees; the mapping covers only the Source receiving data as it arrives.
• Protection of stored logs. The page does not address this. Persistent queue Compression exists to reduce size, not to secure data, and the page documents no encryption at rest.
• Non-repudiation. The page does not address non-repudiation as a security property. It does define the host field as the sender's IP address. That is not non-repudiation, and I will not stretch it.

Where a standard property lands on no setting this page documents, that work sits in other layers of the logging stack and is out of scope here.

What the docs flag

The page's UDP Tuning section applies only to UDP-based syslog ingest with on-prem or hybrid Cribl Stream Worker Groups or Cribl Edge Fleets, not to TCP-based syslog or Cribl-managed Stream Workers in Cribl.Cloud, and within that scope it shows checking the kernel receive buffer with this command from the Syslog Source documentation:

$ sysctl net.core.rmem_max

The page says a typical value of about 200 KB is far too small for even a moderately busy syslog server. The permanent fix it gives, copied from the Syslog Source documentation, adds these lines to /etc/sysctl.conf:

net.core.rmem_max=26214400
            net.core.rmem_default=26214400

On the data-loss side, the page states that sending large numbers of UDP events per second can cause Cribl.Cloud to drop some data, which it attributes to the UDP protocol's restrictions. Its mitigations: a customer-managed (hybrid) Worker Group placed as close as possible to the UDP senders, and OS UDP buffer tuning.

For devices hardcoded to port 514, the page documents listening on 514 on Cribl.Cloud via the built-in in_syslog_default Source. It flags that port 514 traffic is unencrypted and may collect fake or undesirable data, and says to enable that Source only if you are aware of the risk.

In Cribl Stream 4.2.2 and newer, stats log messages report events received, buffered, or dropped for exceeding the maximum Cribl buffer size, and these are logged every 60 seconds by default. The page also warns that the eight default parsed fields can roughly double stored size for short messages, controllable through Fields to keep or a Pipeline.

Frequently asked questions

Does the Cribl Stream Syslog Source listen on both TCP and UDP?

Yes. The default Source is preconfigured to listen for both UDP and TCP traffic on Port 9514, and the UDP port and TCP port fields are each optional depending on protocol.

Is TLS enabled by default on the Cribl Stream Syslog Source?

No, the TLS section is labeled TCP Only, and its Enabled toggle is off by default. You enable it, supply a server certificate for TCP syslog, and can optionally require client certificates through mutual authentication.

Which NIST SP 800-92 properties does the Cribl Stream Syslog Source map to?

The post maps centralization, protection in transit via TLS, protection from undue influence via the IP allowlist and mutual authentication, and completeness during downstream outages via the persistent queue. The page does not address protection of stored logs or non-repudiation.

What does the Cribl Stream documentation say about UDP data loss?

Sending large numbers of UDP events per second can cause Cribl.Cloud to drop some data, which the page attributes to the UDP protocol's restrictions. The page recommends a customer-managed hybrid Worker Group close to the UDP senders and OS UDP buffer tuning.