Converged operations
What is firewall monitoring, and who owns it?
Firewall monitoring is the continuous watching of a firewall across three layers: its health and capacity, the security events in its logs, and changes to its configuration. Most organisations split those layers across different tools and different teams — the network team polls the hardware, the security team collects the logs if anything collects them at all, and configuration changes surface in the post-mortem. Watched together, the same device stops being three partial pictures and becomes one.
The three layers of firewall monitoring
A firewall is unusual among network devices: it is a piece of infrastructure that can fail, a security control that sees every connection, and a configuration that changes more often than almost anything else on the network. Monitoring it properly means watching three different kinds of signal — and most of the practical difficulty is that each signal conventionally belongs to a different team and a different tool.
- Health and capacity — CPU load, interface state and errors, VPN tunnel status, throughput
- Security events — the syslog stream of connections, authentication events and device alerts
- Configuration drift — what changed, on what, and when, against a known-good baseline
Health and capacity — the NOC half
The infrastructure layer is what a network operations centre (NOC) watches: is the device up, are its interfaces clean, are its tunnels established, is it running hot. These signals are polled over SNMP and read from the device's own counters, agentlessly — you cannot install software on a firewall, so collection has to work from the outside. A firewall running hot is not yet an outage, but it is very often the first symptom of one — or of a security event nobody is looking at yet.
Security events and logs — the SOC half
A firewall's syslog stream — denied and permitted connections, authentication events, the device's own alerts — is among the highest-volume and highest-value telemetry an estate produces. Collected into a queue nobody reads, it is a storage cost. Correlated against identity, endpoint and network signals, it is how a probe, a brute-force attempt or an exfiltration path shows itself. This is the layer that belongs with the security operations centre (SOC) — and the layer that firewall monitoring set up as a purely network concern quietly omits.
Configuration drift — the layer everyone forgets
Configurations are retrieved on a schedule and after change events, snapshotted, and diffed against the previous version and against a known-good baseline. The practical value is answering what changed, on what, and when in the first minutes of an incident rather than in the post-mortem. Firewalls earn this layer more than any other device class: they change often, they change under pressure, and an unreviewed change is indistinguishable from an unauthorised one until somebody can produce the diff.
The CPU-spike problem — why the split hurts
Here is the failure mode the three-way split produces. The NOC sees a firewall CPU spike and raises a performance ticket. The SOC sees nothing — that firewall's logs go somewhere else. If the spike is a misbehaving application, the performance ticket is right. If it is a flood or a scan, it is a security incident wearing a performance costume, and the one team that could have told the difference was never shown both signals. This is the argument for watching all three layers in one stream: not tidiness — correlation the split makes impossible.
A working checklist: what to watch on a firewall
Teams asking what firewall monitoring should cover in practice can start from this list. It is deliberately three lists, because the layers fail differently and are read by different people.
- Health: device reachability, CPU load, interface state and error counters, VPN tunnel status, throughput against expected capacity
- Events: denied and permitted connection patterns, authentication successes and failures, the device's own threat and system alerts, log delivery itself — a firewall that stops sending logs is an incident, not a quiet day
- Change: configuration retrieved after every change window, diffed against the last version and the approved baseline, with the diff attached to whoever asks what changed
What a firewall monitoring service includes
Delivered as a service — on its own or inside NOC as a Service — firewall monitoring pairs the platform with the people. Agentless collection over SNMP, syslog, flow protocols and vendor APIs. Around-the-clock watching, including the overnight and weekend hours that are hardest to roster. Escalation with diagnosis attached rather than a raw alert forwarded. And the operating record — availability, performance and configuration history — kept current for the audit, the insurer or the vendor-support escalation that asks for it at short notice.
What firewall monitoring is not
It is not firewall management. Changing rules, tuning policies, patching firmware and supplying the appliance are the administrator's or the provider's job — the discipline sold as managed firewall or Firewall as a Service. Monitoring is the layer that watches state, events and change regardless of who holds the keys, and it is deliberately supplier-neutral: whoever runs your firewall, its telemetry still needs to land somewhere that can see the rest of your estate.
Have Questions? We've Got Answers.
Firewall monitoring is the continuous collection and watching of three things: the device's health and capacity, the security events in its logs, and changes to its configuration. Done properly, all three land in one timeline, so a performance symptom and a security cause can be seen together instead of being worked as two unrelated tickets.
Monitoring watches — health, events, configuration change. Management changes — rules, policies, firmware, and often the supply of the appliance itself. They are usually different teams and frequently different companies, and monitoring stays valuable under every model: whoever manages the firewall, somebody still needs the full picture of what it is doing.
SNMP for health and interface state, syslog for events, NetFlow, sFlow and IPFIX for traffic, SSH for configuration retrieval, and vendor REST APIs where a manufacturer exposes more through them. Collection is agentless of necessity — a firewall does not accept installed software.
Both, and that is the problem. Health and capacity are network-operations signals, the log stream is a security signal, and configuration drift matters to both sides. Split across two teams and two tools, the two halves of one incident can be worked as two unrelated tickets. Platforms that put both halves on one timeline exist precisely to close that gap.
They can be collected and searched without one, but correlation is what makes them useful — a burst of denied connections means little until it is seen next to the authentication failures and endpoint alerts around it. That correlation is a SIEM's job, whether you run the SIEM yourself or consume it as part of a managed service.
Keep reading
Want all three layers on one timeline?
Point one firewall at the platform in a POC — health, logs and configuration history land in a single stream, alongside the rest of your estate.