FortiGate Logging and FortiAnalyzer as Operational Evidence
A firewall log is useful only if it helps someone reconstruct a decision. FortiGate can record traffic, security events, administrative activity, VPN behavior, system events, and other operational data, while FortiAnalyzer can receive, store, index, search, and report across larger environments. The value is not the volume of records. It is the ability to answer what happened, when, to which session, under which policy, and with what security result.
Log configuration and diagnosis are part of the ordinary administration measured by the current FortiOS 7.6 Administrator exam. That is appropriate because troubleshooting without trustworthy logs quickly degenerates into recreating incidents and guessing at transient state.
The Fortinet certification ecosystem also includes dedicated FortiAnalyzer knowledge at higher specialization levels. Even when an administrator is focused primarily on FortiGate, understanding how logs leave the firewall and become searchable evidence changes how policies should be instrumented.
A strong logging design begins before the incident. If critical policies do not log the right sessions, timestamps are inconsistent, FortiAnalyzer registration is broken, or retention is too short, the missing evidence cannot be recreated after the attack or outage is over.
Traffic logs record the firewall decision in context
A useful traffic log can connect source and destination, interfaces, policy, action, bytes, duration, application information, translation details, and other session attributes depending on configuration. That context lets an operator distinguish “the firewall denied it” from “the firewall allowed it but something later failed.”
Logging every possible session at maximum detail can create cost and noise, so policy logging should reflect operational value. Internet egress, published services, privileged administration, and high-risk zones may justify different retention or verbosity than routine internal traffic.
Security-event logs explain what inspection engines observed
Antivirus, IPS, web filtering, application control, DNS security, and other profiles can generate events that describe content or behavior beyond a simple allow or deny. These records are essential when users report that an application partially works because a firewall policy may have accepted the session while a security profile blocked a file, category, signature, or protocol behavior.
The operator should correlate the security event with the parent traffic context. Looking at an IPS alert without the session, user, destination, and policy can overstate or understate its significance.
System and administrative logs make configuration changes traceable
Operational evidence includes what administrators changed, not just what users sent through the firewall. Configuration edits, logins, HA events, interface changes, routing events, and system conditions can explain why traffic behavior changed at a particular time.
This becomes especially important during multi-person incidents. If the environment changed while troubleshooting was underway, the timeline should show who changed what and whether the change preceded the symptom or was part of the response.
FortiAnalyzer turns distributed logs into a searchable history
FortiAnalyzer can receive logs from registered Fortinet devices, keep real-time and archive data, index analytics logs, and provide centralized searching and reporting. That separation matters because a FortiGate’s local storage and retention may be limited, while investigations often need longer history or data from multiple devices.
Older editorial material such as FortiAnalyzer 7.4 administration remains useful for the broad architecture, but current deployments should validate 7.6 behavior and supported workflows against current Fortinet documentation.
Registration and secure transport are prerequisites for central evidence
FortiAnalyzer must recognize and authorize devices before their logs become useful centrally. Connectivity, device registration, encryption compatibility, storage allocation, and time synchronization all affect whether a record sent by FortiGate becomes searchable evidence in FortiAnalyzer.
Monitoring should therefore include the logging pipeline itself. A healthy firewall with a broken log-forwarding path creates an observability blind spot that may go unnoticed until an incident requires history.
Time is the join key across systems
Investigations often correlate firewall logs with endpoint, identity, server, cloud, or application data. Accurate time makes that possible. Clock drift or timezone confusion can make one event appear to precede its cause and can waste hours during incident reconstruction.
Use consistent time sources and record timezone assumptions in operational procedures. When exporting evidence for another team, include enough timestamp context that the sequence can be aligned with their systems.
Fields should be interpreted as evidence, not as labels
A log action such as accept does not mean the application succeeded. It means a particular FortiGate decision allowed the traffic at that stage. Likewise, a security event does not automatically prove compromise. Analysts need to read policy, session, direction, signature, user, application, and surrounding events together.
This interpretation discipline is central to FortiAnalyzer security logging: the platform is most valuable when it helps connect records into operational meaning rather than when it merely retains more data.
Retention should follow investigative and compliance needs
High-volume logs can consume storage quickly, but deleting them too aggressively can make longer-running investigations impossible. Retention design should consider incident response, audit requirements, legal obligations, typical detection delay, and the cost of central storage.
Different log classes may justify different retention. Administrative changes and critical security events may deserve longer history than routine allowed traffic. The policy should be explicit so storage pressure does not lead to ad hoc deletion during the period when evidence is most valuable.
The best log design answers questions operators actually ask
Before enabling another log category, define the question it should help answer. Which policy handled the flow? Was NAT applied? Did the IPS block it? When did the tunnel fail? Who changed the configuration? Did both cluster members report the event? That question-first approach keeps logging aligned with operations.
Then test the evidence path. Generate representative traffic, confirm FortiGate records it, verify FortiAnalyzer receives and indexes it, and make sure an operator can find the event with fields available during a real incident. A logging system that works only when someone already knows the exact message ID is not operationally mature.
FortiGate and FortiAnalyzer become most valuable together when logs preserve the decision trail from packet to policy to inspection to administrative change. That trail turns a firewall from a black box into an explainable security control and gives responders something more reliable than memory when the incident is already in the past.
Log-volume planning should begin with the events that drive decisions. High-throughput internet gateways can produce enormous allowed-traffic datasets, while a low-volume administrative interface may generate only a few events that are extremely important. Storage allocation and forwarding policy should recognize that value is not proportional to record count. Some rare events deserve longer retention and stronger alerting than millions of routine sessions.
Normalization also matters when FortiAnalyzer data is exported to a SIEM or combined with other security platforms. Field names, address translation, user identity, policy identifiers, device names, and timestamps need consistent interpretation. If one system records the client before NAT and another records only the translated source, correlation rules can join the wrong activity or fail to join at all.
Incident responders benefit from preserving raw evidence as well as derived dashboards. A chart can show that blocked connections increased, but the original records may be needed to examine a previously ignored field or reconstruct a single session. Retention architecture should therefore distinguish searchable analytics, compressed archives, and reports rather than assuming a dashboard can replace source events.
Alerting should be selective enough that operators trust it. A FortiAnalyzer event handler or external SIEM rule that fires constantly on expected administrative or scan activity teaches teams to ignore alarms. Tune rules around conditions that imply action: configuration changes outside maintenance windows, repeated authentication failures, HA state changes, critical threat events, or a logging gap from an important device.
Logging failures themselves should generate operational attention. If a FortiGate stops sending events, the absence may be caused by connectivity, certificate or encryption mismatch, storage pressure, authorization, or service failure. A monitoring system should distinguish “nothing happened” from “the sensor stopped reporting.” That distinction is essential during an incident because silence can otherwise be misread as safety.
Finally, evidence handling should account for access control. Firewall and FortiAnalyzer logs can reveal internal addressing, usernames, applications, threats, and administrative actions. Analysts need enough access to investigate, but broad log access can itself expose sensitive operational information. Role design, audit trails, and export procedures should protect the evidence while preserving its usefulness.
Report design should be treated differently from investigative search. Executives and service owners may need trend summaries, top threats, bandwidth patterns, or compliance evidence, while an analyst needs raw fields and pivots across individual events. Trying to make one dashboard serve both audiences often produces a view that is too detailed for governance and too shallow for incident response.
Backup and disaster recovery plans should include the logging platform because historical evidence can be as important as the firewall configuration itself. If FortiAnalyzer is unavailable during a major network event, operators may lose the central view needed to distinguish a device problem from a wider attack. Recovery objectives for the logging service should reflect its role in security operations.
Periodic evidence drills are useful even when there is no incident. Choose a known session or configuration change and ask an analyst to reconstruct it from FortiGate and FortiAnalyzer records. Gaps in timestamps, fields, retention, or access permissions become visible immediately. That exercise validates the logging architecture far more effectively than confirming only that disk usage is normal.
The operational standard should also define who can alter retention, filters, and forwarding. A silent configuration change to the logging pipeline can erase future evidence without affecting production traffic, making change control around observability itself a security requirement.