Finding types

Every finding the rule audit or the pre-check can report, with its severity, what it means and what to do. The audit compares each policy with the enabled policies above it in the same policy set (Fortinet: policy package), top-down, first match wins.

Severities

Summary

The internal name appears in the CSV export.

Shadowed

What it means. A policy above matches all of this policy's traffic and does the opposite (it allows what this one blocks, or the reverse). The firewall stops at the first match, so this policy never takes effect. The rule base doesn't do what it appears to.

What to do. If the policy is meant to apply, move it above the policy that hides it, or narrow that policy so it no longer covers this traffic. If it isn't needed any more, disable or remove it.

Drawn as a red line in the rule stack.

Redundant

What it means. A policy above already does the same thing (same action) for all of this policy's traffic, so this one is never reached.

What to do. It can usually be removed to keep the policy set tidy. First check it doesn't carry something the upper policy lacks, such as logging, a schedule or a security profile; if it does, move it above the other or merge the two.

Drawn as a grey line.

Partial overlap (crossing rules)

What it means. Two policies with opposite actions share some traffic, but neither contains the other, so it isn't a simple exception above a general rule. The shared traffic is decided by the upper one; the rest of the lower policy's traffic still reaches it. This is rarely deliberate.

A narrow exception above a broader policy (for example specific allows above a final deny-all) is normal design and is not reported.

What to do. Check the shared traffic is handled the way you intend. If the lower policy should win for it, move it above; otherwise narrow one of them so they no longer cross.

Drawn as a dashed orange line. The PDF report calls it Crossing rules.

Never hit

What it means. No firewall that installs this policy set has counted any traffic for the policy.

What to do. If the service it was made for is gone, disable it for a while and remove it if nobody complains. New policies and rarely used services (backups, disaster recovery) can legitimately show no hits.

Needs hit counters. It isn't reported for snapshots from configuration files or backups, which have none.

Inactive

What it means. The policy had traffic in the past, but none within Inactive rule threshold (days) (90 by default; set under Settings).

What to do. Confirm with the owner whether it's still needed; disable it first, then remove it.

Needs hit counters, like Never hit.

Disabled

What it means. The policy is switched off, so the firewall ignores it. It still has to be read and maintained. Disabled policies are not checked for anything else.

What to do. Remove it if it's no longer needed, enable it if it was turned off by mistake, or record why it is kept.

Too broad

Reported for accept policies only.

What to do. Narrow it to the networks and services that really need it. The hit counters and Never hit findings help show what's actually used.

Not logged

What it means. An accept policy doesn't log traffic, so there's no record of what it lets through.

What to do. Turn on logging for all sessions (or at least security events), unless the volume is known to be a problem.

Best-effort

What it means. The policy uses FQDN, geography, negation, identity, internet-service or other dynamic matching that FireSight can't resolve to exact networks. Its overlap checks are best-effort, and it is never reported as hiding other policies, to avoid false alarms.

What to do. Nothing, unless it matters; then review it by hand.

In the pre-check of a new rule

The pre-check runs the same checks on a new policy at its planned position, and also looks at the policies below it:

Never hit, Inactive and Best-effort aren't reported for new rules.