Audit the live FortiGate configuration behind every policy.
Retrievy collects the live FortiGate configuration over a read-only SSH session and analyzes administration-plane controls, firewall policy hygiene, referenced security profiles, Layer 7 inspection relationships, and change between snapshots. It shows configuration evidence and remediation guidance without pushing changes to the firewall.
A policy can look complete while its controls remain ineffective.
A firewall rule may reference antivirus, IPS, and web filtering while those engines have reduced or no encrypted-payload visibility because deep inspection is absent or weakened. A permissive rule can also make a later, narrower rule likely unreachable even though both look valid in isolation.
Screenshots and intended templates do not establish what the collected device configuration contains now. Retrievy reads the live configuration and compares it with the prior live snapshot. This page does not claim a FortiManager connector or intended-versus-deployed comparison.
The audit connects management-plane checks, policy relationships, security-profile configuration, evidence, remediation ownership, and the next scan so operators can address the control that causes the downstream exposure.
Review the administration plane and the traffic-control chain together.
Retrievy analyzes the configuration relationships that determine whether a FortiGate policy is hardened and whether referenced controls can inspect its traffic.
Read-only live collection
The Windows collector connects over SSH with a read-only administrator profile, runs the supported configuration collection, and sends the snapshot for server-side analysis.
Administration-plane hardening
Review trusted hosts, secure administrative access, password and lockout policy, management exposure, session controls, SNMP, logging, and related supported checks.
Policy and Layer 7 analysis
Evaluate policy breadth, logging, referenced objects, likely shadowing, and SSL, antivirus, IPS, application control, web, DNS, and other supported profile configuration.
Evidence, drift, and verification
Retain policy and profile evidence, compare consecutive live snapshots, guide the correction, and use a later scan to verify that the configuration finding cleared.
Configuration evidence from administrator access to downstream inspection.
Some hygiene signals have explicit data requirements. Retrievy qualifies those signals rather than treating missing telemetry as proof of safety.
Administrative access
Trusted-host restrictions, default or risky administrators, secure management protocols, password policy, retry and lockout settings, and exposed management services.
Session and service hardening
Supported administration-session controls, HTTPS/TLS posture, SSH access, SNMP versions and trusted hosts, logging, time, and other system settings.
Firewall policy hygiene
Overly broad sources, destinations, or services, missing logging, disabled rules, and heuristic evidence of policies likely shadowed by earlier rules.
SSL inspection
Whether a policy references deep, certificate-only, disabled, missing, or weakened SSL inspection and how that affects visibility into encrypted traffic.
Layer 7 profiles
Referenced antivirus, IPS, application-control, web-filter, DNS-filter, and supported related profile settings, including monitor-versus-block behavior where collected.
Domino Effect
Configuration-based propagation showing how an SSL inspection gap reduces visibility for downstream controls on encrypted traffic.
Objects and dependencies
Referenced address and service objects plus the policy dependencies that provide context for the likely impact of a configuration change.
Usage telemetry when enabled
Zero-hit and stale-policy intelligence only when the separate REST policy telemetry needed for hit-count analysis is configured. SSH configuration alone does not prove non-use.
Audit the live snapshot, fix the root control, verify the next one.
-
1 Detect
Collect without write access
A read-only SSH profile supplies the live device configuration. Optional policy telemetry adds hit-count context where configured.
-
2 Prioritize
Rank root causes and likely impact
Policy breadth, administration exposure, referenced profiles, control dependencies, and hygiene evidence help move the root configuration gap ahead of its symptoms.
-
3 Remediate
Use device-specific evidence
The work item retains the policy, profile, setting, reason, and guidance so the network team can review the production impact and implement the change itself.
-
4 Verify
Re-audit the live device
A subsequent collection evaluates the live configuration again. Cleared evidence verifies the correction; recurring or new evidence stays visible.
Security profiles are attached, but HTTPS remains opaque
In this fictional lab, outbound policy 37 references antivirus, IPS, and web-filter profiles but uses certificate-only SSL inspection. The policy permits broad HTTPS traffic from a user network.
- Policy
- 37 · Users-to-Internet
- SSL inspection
- certificate-inspection
- Attached controls
- Antivirus, IPS, Web Filter
- Audit interpretation
- Downstream controls have reduced payload visibility on encrypted traffic
Analysis
The audit does not merely count attached profiles. Policy X-Ray identifies the SSL layer as the shared configuration dependency that limits what the downstream controls can inspect.
Remediation
The firewall owner reviews certificate distribution and required exceptions, then applies an appropriate deep-inspection design through the normal FortiGate change process. Retrievy does not push the change.
Verification
The next live snapshot is analyzed again. The finding clears only when the collected policy and SSL-profile evidence show the corrected configuration.
Configuration relationships, with honest telemetry boundaries.
Live snapshot focus
The audit describes the configuration collected from the device, not an unverified intended template or a screenshot supplied months earlier.
Root-cause context
Domino Effect connects an inspection-layer gap to the downstream controls whose visibility it reduces.
Qualified hygiene signals
Likely shadowing is described as heuristic, and unused or stale policy claims require the separate policy telemetry that supports them.
Read-only by design
Retrievy gathers and analyzes evidence. Production firewall changes remain in the network team’s controlled workflow.
Questions the same snapshot can help answer.
- Which administrators lack trusted-host restrictions?
- Which interfaces expose insecure or unnecessary management services?
- Which policies are overly broad or lack traffic logging?
- Which later policies are likely shadowed by earlier matching rules?
- Where does SSL inspection reduce downstream Layer 7 visibility?
- Which live policy or profile settings changed since the prior snapshot?
Continue with the relevant solution and technical guidance.
Related Retrievy solutions
Related security guidance
FortiGate Security Audit, answered.
1. Does Retrievy need write access to the FortiGate?
2. Does the audit compare FortiManager intent with the live device?
3. Can a read-only SSH snapshot identify unused policies?
4. Does “shadowed policy” mean mathematically unreachable in every case?
5. How is a FortiGate remediation verified?
Audit what the firewall is configured to do now.
Connect a FortiGate with read-only access and review management hardening, policy relationships, Layer 7 evidence, and drift.