Automation case study · August 2026
Turning FortiGate Daily Reports and Logs into Something People Can Read
A firewall produces one PDF security report a day and log files too large to open. I wrote Python and PowerShell tools that turn a month of daily reports into one report, and policy exports and traffic logs into audit workbooks.
Nobody reads thirty daily reports.
The firewall emails a PDF security report every day. Each one is readable, but nobody can see a month from thirty of them. Separately, a policy review needed the firewall rules, address translation rules and logs in a form that could actually be checked.
One report from a month of daily PDFs.
Python extracts traffic, sessions, top applications, filtering events and system events from each report.
The report opens with how many days were available, for example 25 of 31, and lists the missing dates.
Traffic and session totals, peak days, and evidence that web filtering was enforcing policy.
Events worth reviewing are pulled out of the data into a short list for the administrator.
The report does not state 'no threats' when raw logs and the configuration were not part of its input.
When the logs are too big for normal tools.
The traffic logs for one week came in 18 parts of 50–220 MB each. Spreadsheet tools and simple scripts could not handle them, so I wrote the parser in C# and ran it from PowerShell.
Inputs
Outputs
- Hit count, bytes and first and last use for every rule, so unused rules stand out
- A sources sheet in every workbook, so anyone can see what the numbers came from
- A verification step that checks every sheet for formula errors and records key counts before anything is shared
Reports that can be trusted.
A report that hides a missing week is worse than one that lists it.
Summary PDFs cannot prove there were no threats, so the report does not say so.
The workbook check catches problems a reviewer would otherwise find first.
The same daily-report parsing was later used for a field station's bandwidth analysis.