fortigate-firewall-audit

FortiOS VDOM segmentation audit with UTM profile binding validation, FortiGuard service health assessment, SD-WAN security evaluation, and HA cluster posture check. Systematic per-VDOM policy analysis for FortiGate appliances and FortiGate-VM instances.

# FortiGate Firewall Security Policy Audit

Policy-audit-driven analysis of FortiGate/FortiOS firewall policies. Unlike
generic firewall checklists that check for open ports and default-deny, this
skill evaluates the FortiOS-specific security architecture: Virtual Domain
(VDOM) segmentation, UTM profile binding on every allow policy, FortiGuard
signature freshness, and SD-WAN SLA-based traffic steering security
implications.

Covers FortiOS 7.x+ on FortiGate hardware appliances and FortiGate-VM virtual
instances. For FortiManager-managed deployments, the audit addresses ADOM
hierarchy and policy package consistency. Reference `references/policy-model.md`
for the full VDOM/UTM inspection chain and `references/cli-reference.md` for
read-only CLI commands.

## When to Use

- Post-change policy review after rule additions or VDOM topology changes
- VDOM segmentation audit verifying inter-VDOM link isolation and per-VDOM policy independence
- UTM profile coverage assessment — finding allow policies without antivirus, IPS, or web-filter inspection
- SD-WAN security evaluation — confirming SLA violations do not steer traffic around security controls
- FortiGuard license and connectivity validation — ensuring signature databases are current
- HA cluster security posture check — verifying firmware parity, config sync, and session-sync settings
- Quarterly or annual compliance audit requiring per-policy justification
- Pre-upgrade baseline before FortiOS major version changes

## Prerequisites

- Read-only administrative access to FortiOS CLI (or `diagnose`-level privilege for runtime state)
- Understanding of the VDOM topology — which VDOMs exist, their function (management, traffic, DMZ), and expected inter-VDOM links
- Knowledge of expected UTM profile assignments per policy category (internet-bound, inter-zone, intrazone)
- For FortiManager-managed environments: access to the ADOM with visibility into policy packages
- Awareness of SD-WAN configuration — SLA targets, member interfaces, and health-check definitions
- Running configuration committed — audit evaluates the active configuration, not pending changes

## Procedure

Follow this audit flow sequentially. Each step builds on prior findings.
The procedure moves from VDOM architecture inventory through per-VDOM
rule-level analysis to UTM coverage, FortiGuard health, SD-WAN security,
and HA posture.

### Step 1: VDOM Architecture Inventory

Collect all VDOMs and their roles.

```
config vdom
edit root
end
get system status
```

On a multi-VDOM system, list all VDOMs:

```
diagnose sys vd list
```

For each VDOM, record: name, type (traffic/management/admin), assigned
interfaces (physical and virtual), inter-VDOM link pairs, and VDOM resource
limits (session count, CPU quota). Identify the management VDOM — this
is where FortiGuard updates, logging, and administrative access are
configured.

Check inter-VDOM links:

```
show system vdom-link
```

Inter-VDOM links function as virtual interfaces connecting two VDOMs.
Traffic crossing a VDOM link is subject to the receiving VDOM's firewall
policies — verify that inter-VDOM traffic is not bypassing inspection.

Verify VDOM resource limits to detect unbounded VDOMs that could starve
other VDOMs during volumetric events:

```
config global
get system vdom-property
```

Flag any VDOM without explicit resource limits in a multi-VDOM deployment.

### Step 2: Firewall Policy Rule-by-Rule Analysis

For each VDOM, retrieve the full policy table:

```
config vdom
edit <vdom-name>
show firewall policy
```

FortiOS evaluates firewall policies top-down by sequence number within each
VDOM. The first matching policy is applied. Evaluate each policy against
these criteria:

- **Overly permissive policies:** Policies with `srcaddr "all"`,
  `dstaddr "all"`, `service "ALL"`, and `action accept` are Critical
  findings — they accept all traffic on all ports with no restriction.
- **Missing UTM profiles:** Allow policies without antivirus, web-filter,
  application-control, or IPS profile binding pass traffic uninspected.
  Check `utm-status`, `av-profile`, `webfilter-profile`,
  `application-list`, and `ips-sensor` on each allow policy.
- **Disabled policies:** Policies with `status disable` still occupy
  sequence numbers and create audit confusion. Flag for cleanup.
- **Schedule-based policies:** Policies with `schedule` other than `always`
  may create time-window security gaps. Verify schedules align with
  intended access windows.
- **Implicit deny:** FortiOS has an implicit deny (policy ID 0) at the
  bottom of each VDOM's policy table. Verify it is logging traffic for
  visibility into denied connections.

Check for unused policies using hit count data:

```
diagnose firewall iprope show 100004 <policy-id>
```

Policies with zero hits over 90+ days are cleanup candidates.

### Step 3: UTM Profile Binding Audit

For each allow policy in every VDOM, verify that UTM inspection profiles
are bound. The goal is zero allow policies without threat inspection.

Check each allow policy for these profile bindings:

- **Antivirus (`av-profile`):** File-based malware scanning. Required on
  all internet-bound and inter-zone policies.
- **Web Filter (`webfilter-profile`):** URL categorization and blocking.
  Required on all policies permitting HTTP/HTTPS.
- **Application Control (`application-list`):** Application identification
  and enforcement. FortiOS equivalent of App-ID.
- **IPS (`ips-sensor`):** Intrusion prevention signatures. Required on
  all allow policies carrying untrusted traffic.
- **Email Filter (`emailfilter-profile`):** Anti-spam for SMTP/IMAP/POP3.
  Required on email-carrying policies.
- **DLP Sensor (`dlp-sensor`):** Data loss prevention pattern matching.
  Required where sensitive data egress risk exists.
- **SSL Inspection (`ssl-ssh-profile`):** Determines whether encrypted
  traffic is decrypted for UTM inspection. Without SSL inspection set to
  `deep-inspection`, AV and IPS see only connection metadata on HTTPS.

Summarize coverage: count allow policies with full UTM binding versus allow
policies with partial or no UTM profiles. Calculate the UTM coverage ratio.

Check the inspection mode per VDOM:

```
config vdom
edit <vdom-name>
get system settings | grep inspection-mode
```

Flow-based mode applies all UTM in a single pass (faster, less thorough).
Proxy-based mode buffers and inspects fully (more thorough, more resource
intensive). The mode affects which UTM features are available and their
efficacy.

### Step 4: FortiGuard Service Validation

FortiGuard provides the signature databases that UTM profiles depend on.
Stale signatures reduce detection efficacy.

```
get system fortiguard-service status
diagnose autoupdate versions
```

Verify the following signature databases are current:

| Database | Maximum Acceptable Age | Check Command |
|----------|----------------------|---------------|
| Antivirus definitions | 24 hours | `diagnose autoupdate versions | grep -A2 'Virus'` |
| IPS signatures | 7 days | `diagnose autoupdate versions | grep -A2 'IPS'` |
| Web filter database | 7 days | `get webfilter status` |
| Application control DB | 7 days | `diagnose autoupdate versions | grep -A2 'App'` |
| Anti-spam database | 7 days | `diagnose autoupdate versions | grep -A2 'Spam'` |

Check FortiGuard connectivity:

```
diagnose debug rating
execute ping service.fortiguard.net
```

If FortiGuard is unreachable, all cloud-dependent features (web filter
rating queries, FortiSandbox cloud, outbreak prevention) operate in
degraded mode using cached data only.

Verify the update schedule:

```
show system autoupdate schedule
```

Best practice is scheduled updates every 1–4 hours for AV and daily for
IPS/App-Control. Manual-only updates are a finding.

### Step 5: SD-WAN SLA and Rule Security

If SD-WAN is configured, evaluate security implications of traffic steering.

```
config vdom
edit <vdom-name>
show system sdwan
```

Review SD-WAN components:

- **SLA tar