Syslog Done Right on Network Devices

By Taylor Thomas · 2026-09-01

When an incident review starts, the first question is almost always what happened, in what order — and the answer is assembled from logs. Syslog is where most network and security devices tell their story, which makes it simultaneously mundane and critical: mundane because every engineer has configured it, critical because the quality of your incident evidence is fixed by configuration decisions made months earlier. Doing it right is a short list of disciplines, applied consistently.

Severity Is a Threshold, Not a Label

Syslog carries eight severity levels, 0 through 7: Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug — lower numbers more severe. The detail that shapes configuration: the level you set is a threshold. A device configured to send at Informational sends severity 6 and everything more severe, 0 through 6. That shapes the steady-state baseline — Informational is the common operating choice, capturing the operational record without debug noise, though it should be validated against the events you actually need and the volume your collector can absorb, while Debug is a troubleshooting tool you turn on for a window and turn off again, because its volume can strain the device, the network path, and the collector all at once. Devices also let you set that threshold per destination — what goes to the central collector, what stays in the local buffer, what reaches a console session — and the thresholds do not have to match: a common pattern keeps the local buffer more verbose than the export stream, so the deeper detail exists on-box when you need it without paying to ship it continuously.

The severity number is also not a triage verdict. Plenty of lower-priority messages are security gold — configuration changes, login events, whose exact severities vary by platform and message — while some higher-severity messages are operational noise in context. Severity thresholds are the first filter on what leaves the device; what deserves attention is decided downstream, in the SIEM or the analytics layer that consumes the stream.

Transport: UDP Is a Habit, Not a Design

Traditional syslog rides UDP, and UDP syslog has three properties that should bother a security engineer: no delivery guarantee, no acknowledgment, and no confidentiality. A message lost between device and collector vanishes without a trace — precisely the failure mode you cannot afford in evidence. And cleartext transport means log content, which routinely includes usernames, addresses, and topology detail, is readable in transit, and messages can be forged or altered along the way.

The standardized answer is syslog over TLS, RFC 5425: transport that is encrypted, peer-authenticated when certificate validation is configured properly, and reliable enough that many connection failures are at least detectable — though even here, delivery to the socket is not confirmation that the collector durably stored each message. This is exactly what the SCOR blueprint means when objective 2.7 names secure syslog alongside NTP with authentication as part of secure device management. Where a device or collector cannot do TLS, treat that as a known gap — and keep the logging path inside protected management networks rather than crossing user space in the clear.

Time Is the Backbone of Correlation

Devices should be configured to timestamp every message — timestamping behavior is itself configurable, and a message without a usable timestamp is a data point without a place in the timeline — and timestamps are only as good as the clocks behind them. Unsynchronized clocks drift; drifted clocks make cross-device correlation guesswork; and correlation is the entire job during reconstruction. NTP everywhere is the fix, with two refinements worth adopting: authenticate NTP associations to reduce the risk of accepting spoofed time — the blueprint’s phrasing, NTP with authentication, is deliberate — and standardize timezone handling across the estate, UTC being the usual choice, because mixed local timezones in log data are a classic self-inflicted confusion.

What to Log, and What It Costs

A collector-plus-buffer design beats either alone: send to central collection for correlation and retention, and keep the device’s local logging buffer sized generously as the forensic fallback for when the collector, or the path to it, is down — remembering that a conventional RAM logging buffer is volatile and circular: a reload clears it, it overwrites oldest-first, and how far back it reaches depends on its size against the device’s message rate, which bursts can shorten sharply. On content, the security-relevant floor is consistent: configuration changes, authentication successes and failures, interface and adjacency state changes, and policy denies. That last one carries a cost worth knowing: depending on the platform, logging access-list matches can punt packets or log generation to software processing, so a log keyword on a busy ACL entry can become a device-load problem. Log the denies that carry signal — at the edges, on rules that should rarely fire — rather than reflexively logging everything.

Telemetry does not end with syslog — flow data answers questions logs cannot — but syslog is the layer everything else assumes. It is also blueprint material: SCOR 350-701 objective 2.7 covers secure management of the devices doing the logging, and the SCOR course configures it on real gear, secure transport and all.

Frequently Asked Questions

What syslog severity level should network devices send to a collector?

Informational — severity 6 — is the common operating choice: it captures the operational record, including the notifications and warnings above it, without the flood of debugging output. Because the configured level is a threshold, sending at 6 includes everything from 0 through 6. Debugging (7) belongs in targeted troubleshooting windows, not in steady state, where its volume can strain both the device and the collector while burying the messages that matter.

Why is syslog over UDP a problem, and what is the alternative?

UDP syslog is fire-and-forget: messages lost in transit are gone without a trace, nothing is acknowledged, and the content crosses the network in cleartext where it can be read or spoofed. Syslog over TLS, standardized in RFC 5425, encrypts the transport and authenticates the peers when certificates are properly validated, and its TCP transport detects many connection failures — substantially more reliable than UDP, though RFC 5425 does not confirm that each individual message was durably stored by the collector. For security-relevant logs — the record you may one day rely on in an investigation — the secure transport is worth the setup.

Why do logs need NTP if every device already timestamps its messages?

A timestamp is only meaningful relative to a clock, and unsynchronized device clocks drift apart. When the firewall says 14:02:10 and the switch says 14:05:37 for the same event, no analyst can order the sequence with confidence, and correlation across devices — the core of incident reconstruction — falls apart. NTP across the estate, ideally with consistent timezone handling, makes every device tell time against the same reference.