What should a business monitor in its firewall logs?

Effective firewall log monitoring is the process of identifying meaningful changes in network behaviour, validating whether they are authorised and preserving enough context to investigate them. A useful review does more than count blocked events: it examines trends, successful as well as unsuccessful connections, policy activity, device behaviour and the quality of the logs themselves.

Start by confirming that the right events are being recorded. The firewall should log security-relevant decisions, administrative activity, system errors, VPN activity, policy changes and events generated by inspection features enabled on the appliance. Logging every permitted connection without a clear purpose can create excessive noise, while recording only denied traffic may hide compromised devices communicating successfully. Log settings should therefore reflect the organisation’s risks and the systems the firewall protects.

Particular attention should be given to changes in the normal volume, timing and direction of traffic. A workstation, server or site that suddenly generates substantially more connections than its established baseline may warrant investigation, even when the individual connections are allowed. Useful indicators include:

• Repeated access to unusual destinations or newly observed services
• Large or sustained transfers that do not match the device’s role
• Unexpected traffic between internal network segments
• New communication paths involving servers, administration networks or backup systems
• Connections using protocols that are not normally required by the organisation
• Frequent short-lived sessions that may indicate scanning, automated callbacks or an unstable application

Successful activity is important as well as rejected activity. A threat actor using valid credentials, an approved remote-access route or a permitted application may not generate a simple blocked-event alert. Monitoring should therefore identify unusual use of allowed services, access to restricted network zones and deviations from established business patterns. This is especially relevant where multiple sites, cloud services, remote users or third-party connections share the same security infrastructure.

Administrative and configuration events require their own monitoring. Record who changed a rule or setting, what was changed, when it was changed and whether the change was authorised. Pay attention to newly created exceptions, broad source or destination scopes, disabled inspection features, altered VPN settings and changes that reduce logging. A rule change that appears operationally minor can materially alter the organisation’s exposure, so firewall records should be compared with approved change documentation.

Monitoring should also cover the health and reliability of the logging system. Gaps in records, a full storage destination, incorrect time synchronisation, repeated service restarts or a loss of communication with a central log platform can prevent an incident from being reconstructed. The organisation should know whether logs are being retained centrally, whether access to them is restricted and whether they can be searched without altering the original records.

Alerts are most useful when they are prioritised. A high-priority alert might involve a sensitive server, a disabled security control or a suspicious connection pattern across several systems. Lower-priority events can be grouped into summaries or reviewed as trends. Rules should be tuned when legitimate business activity repeatedly creates alerts, but exclusions should be narrow, documented and reviewed rather than used simply to make the alert queue smaller.

Firewall logs should be correlated with other evidence where possible. Identity records can show whether an account was expected to make a connection; endpoint security data can indicate whether a device was compromised; DNS records can add context about a destination; and cloud or application logs may explain an otherwise unfamiliar session. Correlation helps distinguish a genuine incident from routine software updates, automated backups or approved supplier access.

A practical monitoring process usually includes:

1. Defining which assets, services and connection types are most important to the business
2. Establishing normal patterns for those assets rather than relying on generic alert thresholds
3. Reviewing prioritised alerts and recurring trends at an agreed frequency
4. Documenting the reasoning and evidence for each investigation
5. Escalating events that suggest account misuse, malware, unauthorised access or a weakening of controls
6. Testing that alerts, central collection and retention continue to work after significant network or firewall changes

Retention should support the organisation’s investigation and regulatory needs, with access limited to authorised personnel. Records should be protected from unauthorised alteration, and the business should understand how long different types of evidence remain available. Reviewing the monitoring process itself is also important: new applications, sites, suppliers and remote-access arrangements can make old baselines and alert rules inaccurate.

For a small or medium-sized organisation without dedicated security staff, a managed IT provider can help establish sensible logging, centralise records, tune alerts and investigate patterns across the network. The objective is not to produce the largest possible volume of data, but to maintain trustworthy evidence and identify activity that genuinely needs attention.