# Your syslog line is audit information: AU-9 on network devices

> SP 800-53 counts audit log settings as audit information. What that means for the syslog, NTP and AAA lines on firewalls and routers, and how to catch changes to them.

**Compliance** · 2026-09-29 · 6 min read · By Beyrak A., Founder & Security/System Engineer

**Key takeaways**

- SP 800-53 Rev. 5 counts “audit log settings” as audit information, so the logging lines in a firewall or router config fall under AU-9, not just the log files.
- A removed syslog host or a lowered severity is a modification of audit information, and AU-9b asks for an alert that doesn’t depend on the log feed that was just cut.
- Configuration diffs are an independent check on AU-2: a change with no matching audit record points at a management path you aren’t logging.

## Logging settings count as audit information

Most audit-logging work lands on the SIEM: retention, storage, who can read the index. SP 800-53 Rev. 5 draws the line wider. AU-9 asks you to “protect audit information and audit logging tools from unauthorized access, modification, and deletion”, and its discussion defines audit information as including “audit records, audit log settings, audit reports”.

On a firewall or router, the audit log settings are lines in the running configuration: where syslog goes, at what severity, whether a local buffer keeps a copy, and which clock stamps the records. So when someone deletes the remote log destination on an edge firewall, nothing in the SIEM changes. No record is altered and none is deleted. The records just stop arriving. That’s a modification of audit information, and AU-9b asks for an alert “upon detection of unauthorized access, modification, or deletion of audit information”. The awkward part is that the alert can’t come from the logging pipeline that was just cut.

## The settings worth watching on network gear

The names differ by vendor, but every firewall, router and switch has some version of these six. Each one is a configuration setting, so each change to it shows up in a configuration diff, whether or not the device logged the change.

1. **Remote log destinations.** The syslog or log-forwarding targets. This is AU-4(1) in practice: sending logs to “a different system, system component, or media other than the system or system component conducting the logging.” A removed or repointed target is the most important change on this list.
2. **Severity level.** Dropping the threshold from informational to warnings quietly removes most of the admin-activity events you were counting on.
3. **Local buffered logging.** The copy that survives when the path to the collector breaks.
4. **Time sources.** NTP servers and the time-zone offset. AU-8 wants time stamps in UTC or with a known offset, and clock synchronization itself moved out of the AU family in Rev. 5: it’s now SC-45, “Synchronize system clocks within and between systems and system components”, with SC-45(1) for the authoritative time source. Records from a drifting clock are hard to correlate with anything.
5. **SNMP trap and notification targets.** Many teams send configuration-change notifications there, which makes the trap target part of the audit path.
6. **AAA accounting.** Command and session accounting to TACACS+ or RADIUS is often the only record of who ran what. AU-2 lists “administrative privilege usage” among the event types to log, and the old AU-2(4) Privileged Functions now lives in AC-6(9): “Log the execution of privileged functions.”

*Example: running-config diff, edge-rtr-02*

- unchanged: logging on
- removed: logging host 10.9.9.20
- removed: logging trap informational
- added: logging trap warnings
- removed: logging buffered 64000
- unchanged: ntp server 10.9.9.5
- changed by: ops-contractor (matched by time window)
- seen: next snapshot after the change
- rule fired: logging-settings changed, sent to #netops and the SIEM

One change removes the remote log destination, lowers the severity and switches off the local buffer. Every line in it is audit information under AU-9.

## Why that diff is an AU-9 event, and a CM-3 one

Read the exhibit against the controls. The removed host and the lowered level modify audit information, so the AU-9b alert applies. They also weaken AU-12, which asks for audit record generation on the components you named: after this change the firewall still generates records, but fewer, and it keeps them nowhere else. And it’s a configuration change like any other, so CM-3(7) applies: “Review changes to the system […] to determine whether unauthorized changes have occurred.”

Whether it was unauthorized is a question for your change records, not for the diff. Maybe the collector moved and nobody raised a ticket. AU-12(3) even expects authorized people to be able to change what gets logged, within limits you set. But turning logging down is also a common step after a break-in, and SI-7(7) asks you to fold detected unauthorized changes into incident response. Its discussion names “unauthorized changes to established configuration settings or the unauthorized elevation of system privileges” as the kind of change it means. Treat an unexplained logging change on an edge device as an incident until a ticket says otherwise.

> When logging stops, the log can’t tell you it stopped. The configuration can.

## When the audit log says nothing changed

AU-2 asks you to choose which event types to log, give “a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents”, and review that list on a schedule you set. Its discussion adds that “event logging includes all protocols that are operational and supported by the system”. On current network gear that means the REST API and the web GUI, not just the CLI.

A configuration diff is a cheap way to test that rationale. Every change the diff shows should have a matching record in the device’s audit trail. When one doesn’t, you’ve found an event type or a management path you aren’t logging. We’ve written about [why audit logs miss changes](https://nometa.az/en/blog/change-detection-without-audit-logs/): automation running through shared accounts, bulk imports, restores. The comparison below is also AU-6 work, since AU-6’s discussion counts logging that results from monitoring “configuration settings, system component inventory”.

*Example: diff vs audit log, edge-fw-02, last 30 days*

| change seen in diff | path | audit record | finding |
|---|---|---|---|
| security rule 214 edited | web GUI | yes | |
| address group web-srv updated | REST API | none | path not logged |
| logging trap level lowered | CLI | yes | |

Two of three changes have a matching audit record. The API change doesn’t, so either the AU-2 event list or the device’s logging setup is missing a management path.

## Where SAMURAI fits, and where it doesn’t

SAMURAI snapshots each device’s configuration and diffs it against the previous one, so the logging lines above are compared on every sync. You can write a detection rule for exactly these settings and send it to Slack, Teams, email, your SIEM or a ticket queue when one changes. Each change is attributed to an admin: matched to the commit on PAN-OS, and to a time window on FortiOS. That gives the AU-9b alert a path that doesn’t run through the syslog feed it’s protecting, and gives a CM-3(7) review a change record to work from, including changes the device never logged. The [firewall audit tool page](https://nometa.az/en/firewall-audit-tool/) lists what it reads from each vendor. Five limits are worth knowing before you lean on it:

1. **It sees configuration, not delivery.** A correct syslog line doesn’t prove records arrive. Alerting “in the event of an audit logging process failure” is AU-5, and it belongs to the devices and the collector.
2. **It doesn’t read logs.** Send its change events to your SIEM and do the diff-versus-audit-record comparison there.
3. **Attribution is inferred.** It’s good evidence for a review, but it isn’t AU-10 non-repudiation, which asks for “irrefutable evidence that an individual” did something.
4. **Evidence bundles are hash-stamped, not signed.** That shows a file wasn’t altered after collection. It isn’t the cryptographic protection of audit information that AU-9(3) describes.
5. **Snapshots are periodic.** A logging change made and reverted between two syncs never appears in a diff. The device’s own audit trail is the only record of it.

Put the logging lines on the watch list before audit week and the AU-9 question has an answer. If you’re preparing for a wider review, check 13 of our [firewall audit checklist](https://nometa.az/en/blog/firewall-audit-checklist/) covers the rule side of the same problem: a deny that logs, and allow rules that log too.

---

Canonical page: https://nometa.az/en/blog/nist-au-9-logging-configuration/
Part of SAMURAI, a self-hosted, multi-vendor network monitoring & security platform. Overview: https://nometa.az/llms.txt
Contact: info@nometa.az · Docker Hub: https://hub.docker.com/r/beyrak44/samurai