Introducing Agentic Compliance for Fortinet

CIS Benchmark audits for FortiGate firewalls, run by an agent that can only read.

IT Compliance Studio now audits FortiGate firewalls against the CIS FortiGate Benchmark, from inside your own network. Each automated control comes back with a result and the evidence behind it, ready for your next audit.

Watch the audit run on a FortiGate

Benchmark	CIS FortiGate Benchmark, v1.0.1
Coverage	64 controls: 48 automated, 16 manual
Levels	Level 1 (39 controls) and Level 2 (all 64)
Access	SSH with a read-only audit account. Nothing to install on the firewall
Mode	Audit only. Read commands (`get` and `show`)
Output	HTML report, JSON, CSV and Excel, with evidence per control
Deployment	On-prem, in your network, through a customer-hosted Site Runner

Firewall compliance is a copy-and-paste job

Proving that a firewall matches the CIS Benchmark is mostly manual. Open the benchmark. Log in to the firewall. Check one setting. Paste the output into a spreadsheet as evidence. Then the next setting, and the next firewall.

The FortiGate benchmark has 64 controls. If you audit every control on every firewall, 1,500 firewalls is 96,000 checks in a single cycle.

One team we spoke to runs about 1,500 Fortinet firewalls. By their own estimate, keeping them compliant takes more than 40% of the team's time every quarter. Most of that effort is collection, not judgment: the same commands, the same comparison, the same paste. When the quarter ends, it starts again.

And when an auditor asks why a control passed, the answer is a block of pasted output in a spreadsheet.

That team asked us a direct question: could we solve this? This release is our answer.

What we built

Agentic Compliance for Fortinet adds FortiGate to IT Compliance Studio. You pick a firewall and a benchmark level, and an agent runs the audit from start to finish. Runs start through the compliance API. SIA can start the same runs through MCP tools, and operators can use the command line.

The Site Runner in your network connects to the firewall over SSH with a dedicated audit account. Nothing is installed on the firewall.
It runs get system status to learn the FortiOS version and whether VDOMs are enabled.
For each control it runs the read commands that control needs. The whole benchmark uses a little over thirty distinct get and show commands.
Every control is judged against a written rule and ends as pass, fail, manual, not applicable or error.
Results and evidence are uploaded to Scogo, and you get an HTML report plus JSON, CSV and Excel. Each result carries the command, the line that was judged, and the reason.

In our own test, a Level 2 audit of one FortiGate finished in about 27 seconds. Level 1 took about 17. These are single-firewall timings.

The agent runs the audit. It does not decide the result. Pass or fail comes from a rule written against the CIS text, so the same output gives the same answer every time, and an auditor can see exactly why a control failed:

2.1.10  Ensure management GUI listens on secure TLS version    FAIL
Regex '^\s*admin-https-ssl-versions\s*:\s*tlsv1-3\s*$' not matched.
Got: admin-https-ssl-versions: tlsv1-2 tlsv1-3

2.1.10  Ensure management GUI listens on secure TLS version    FAIL
Regex '^\s*admin-https-ssl-versions\s*:\s*tlsv1-3\s*$' not matched.
Got: admin-https-ssl-versions: tlsv1-2 tlsv1-3

2.1.10  Ensure management GUI listens on secure TLS version    FAIL
Regex '^\s*admin-https-ssl-versions\s*:\s*tlsv1-3\s*$' not matched.
Got: admin-https-ssl-versions: tlsv1-2 tlsv1-3

Deployed in your network

For private networks, a customer-hosted Site Runner connects to approved firewalls locally and initiates outbound HTTPS connections to Scogo. Target credentials stay on the runner. Results and evidence are uploaded for centralized reporting. Local policy controls which targets and benchmarks it may audit. No inbound connection from Scogo to the runner is required.

You run the Site Runner as a container on a host in your network. It enrolls with a one-time token, and an administrator confirms its key fingerprint before it can take any work. Every request it sends is signed, the jobs it receives are signed by Scogo, and it pins each firewall's SSH host key, so an audit stops if the key does not match. The runner also keeps a local log of every audit it performs.

What you get - The full CIS FortiGate Benchmark

All 64 controls, v1.0.1, across seven areas:

Area	Controls
Network settings	3
System settings (general, password policy, SNMP, administrators, HA)	31
Policy and objects	4
Security profiles (IPS, antivirus, DNS filter, web filter, application control)	17
Security Fabric	2
VPN	2
Logs and reports	5
Total	64

48 controls are fully automated. The other 16 are marked manual, because the answer is a decision and not a setting. "Ensure that unused policies are reviewed regularly" is a question for a person. So is "Allow only trusted hosts in SNMPv3", since only you know which hosts you trust.

It checks what firewall policies actually use

CIS asks for things like "Detect Botnet connections" and "Apply DNS Filter Security Profile to Policies". A check that only looks at the profile table would pass as soon as a good profile exists. But a clean profile that no policy references protects nobody.

So the audit starts from the firewall policies that are enabled and accept traffic. It follows each one to the profile it names, directly or through a profile group, and judges those profiles. Where the benchmark is about Internet-facing traffic, only policies that reach a WAN-role interface count, including through zones and SD-WAN. The evidence states what was looked at:

4.1.1  Detect Botnet connections    PASS
Policy check passed: ips-sensor "default", used by 1 enabled accept
policy to a WAN interface (port1): each matches
/^\s*set scan-botnet-connections\s+block\b/

4.1.1  Detect Botnet connections    PASS
Policy check passed: ips-sensor "default", used by 1 enabled accept
policy to a WAN interface (port1): each matches
/^\s*set scan-botnet-connections\s+block\b/

4.1.1  Detect Botnet connections    PASS
Policy check passed: ips-sensor "default", used by 1 enabled accept
policy to a WAN interface (port1): each matches
/^\s*set scan-botnet-connections\s+block\b/

Read-only, enforced before anything is sent

Every command in the benchmark is a get or a show, and the guardrail allows those two verbs and nothing else. config, execute and diagnose are refused on our side, before they reach the firewall. So are pipes, and two commands joined by a newline. show full-configuration is blocked too, because it dumps credential material into the output.

We also recommend giving the audit account a read-only admin profile on the FortiGate. Then two locks hold the line: ours and the device's.

Results you can trust, or a clear reason why not

A compliance tool that passes a control it could not check is worse than no tool. So the audit refuses to guess:

If VDOMs are enabled, the firewall is refused and every control is reported as an error. VDOMs are not supported yet, and we will not score half a device.
If the firmware is not the release the benchmark was written for, the report says so at the top.
FortiOS prints some errors as normal output with a success status. We treat those as errors, so a "must not contain" check cannot pass on an error message.
A policy table that arrives cut short fails the control. It is never read as "nothing configured".
HA checks on a standalone unit are marked not applicable and left out of the score. The control "is HA enabled" still fails.
If the audit account cannot see super_admin accounts, the default-admin check fails and says why. It does not pass on an account that is only hidden.

Secrets stay out of the report

show prints stored secrets as ENC blobs, and SNMP v1 and v2c community strings in clear text. Both are redacted before anything is judged or stored, so they do not end up in a report that gets mailed around.

Built on what Compliance Studio already does

IT Compliance Studio was built for servers and databases: Ubuntu, Debian and SUSE hosts, PostgreSQL and MongoDB. Firewalls were not part of the plan.

But a firewall audit needs what the product already had. Agentless access over SSH. A catalogue of benchmark checks. A guardrail on every command. Evidence kept for every control. FortiOS needed its own command profile, its own safety rules, and the benchmark written out as checks. The rest was in place.

We built it together with the team that asked for it, and we will keep working this way: start from a customer's problem, and build next to the people who have it.

What it covers today

It audits FortiGate firewalls running FortiOS. FortiSwitch, FortiAP and FortiManager are not covered.
It is audit only. Nothing on the firewall is changed. On Linux servers, IT Compliance Studio can also apply fixes behind guardrails and a dry run. On a perimeter firewall a wrong write is an outage, so FortiGate starts with audit only. Remediation is on the roadmap.
16 controls stay manual.

Who it is for

Network and security teams that run many FortiGates, including ones in private networks, and want to stop repeating the same checks by hand. It also gives compliance owners evidence an auditor can follow, and an answer to "are our firewalls compliant" that does not depend on one person's spreadsheet.