Third-Party Firewall Logs Missing from Reports
A utility company runs FortiAnalyzer 7.4 on a VM with a 500 GB/day license and 4 TB of virtual disk. It receives about 300 GB/day from 120 FortiGates and 150 Cisco ASA firewalls. The ASAs send syslog over UDP 514 to a single Linux relay, which forwards to FortiAnalyzer; all ASA messages arrive with the relay's source IP and appear in a generic syslog ADOM. Reports for ASA traffic show only raw message text, and many ASA events are missing. FortiGate logs also stop for 10-20 minutes during daily peak, and the FortiAnalyzer disk is at 93%. Archive logging is disabled, and the default retention is 60 days. The security team wants 180-day retention for PCI and wants to query ASA deny events by source and destination IP.
1. Why are the ASA logs unparsed, and how should the company fix parsing?
Read the worked answer
The ASA logs are arriving, but FortiAnalyzer sees them as coming from the relay's IP address and in a generic syslog format. FortiAnalyzer cannot normalize fields such as srcip, dstip, and action unless it recognizes the device type and has a parser for that format. Fix in layers: first, stop hiding the original source by using a relay that preserves the sender IP, or register each ASA separately; second, assign the correct device type and ADOM; third, verify whether this FortiAnalyzer release has a built-in Cisco ASA parser. If not, use a custom parser or normalize at the relay into a supported format. Reports will only show raw message text until fields are extracted. Test with one ASA and compare a known deny event in the raw log, the parsed fields, and a report filter. Do not assume that placing logs in an ADOM magically parses them.
2. What explains the FortiGate log gaps and the 93% disk usage, and what should be changed?
Read the worked answer
Two separate problems. The 4 TB disk at 300 GB/day gives roughly 13 days of raw capacity, but retention is set to 60 days, so the disk is nearly full and FortiAnalyzer is likely dropping or overwriting logs. That explains gaps and 93% usage. The 500 GB/day license is above the 300 GB/day average, but peak ingest may exceed it; check the FortiAnalyzer event log for license or log-rate alarms. UDP 514 is fire-and-forget, so any relay or FortiAnalyzer overload loses messages. Use TCP/TLS where supported, enable buffering on the relay, and monitor. Reduce retention to what 4 TB can actually hold, add disk or forward logs, and filter low-value traffic. Do not raise retention before adding capacity.
3. Can the company meet 180-day retention on this system? What architecture and settings would you recommend for PCI?
Read the worked answer
180 days at 300 GB/day is 54 TB before overhead, so 4 TB cannot meet it. Even with compression, expecting more than a 13x reduction is unrealistic. Options: keep 14-30 days of analytics on FortiAnalyzer and forward all logs to a syslog/SIEM or cold storage that can hold 54 TB; reduce what is stored by filtering permit/close logs and keeping deny, VPN, and threat logs; or buy a larger platform or external storage. For PCI, confirm the retention requirement is for readily available investigation, not necessarily hot search. Document the tiering and test retrieval from the archive. Also verify that ASA parsing works before promising PCI queries by source and destination IP.