How It Works

From raw configuration to clear security insight

Use this page for the technical workflow: how FortiGate configuration data is parsed, modelled, checked, and turned into deterministic findings.

Workflow

A simple product workflow from input to report

Start with a manual export or a read-only collector path.

Policies, objects, services, interfaces, VDOMs, and administrative settings are parsed into a structured model.

The product follows linked address objects, service definitions, and scope relationships so the review reflects the real policy meaning.

Repeatable audit logic runs against that model to surface findings such as default admin exposure, any/any/any policy, or broad east-west access.

The same audit run produces detailed technical findings and a simpler leadership-facing summary.

Context

Policy example

Finding logic

ConfigSentry evaluates the policy together with the linked address group, service scope, and logging state.

That means the finding reflects broad exposure, weak auditability, and the affected FortiGate area rather than only showing that a rule exists.

Methodology

The configuration is modelled before analysis so checks use meaningful relationships, not only raw text matches.

Checks run consistently across policy, objects, services, admin settings, and posture signals.

Mappings support control discussion and evidence gathering, but they are not a compliance guarantee by themselves.

Next step

Start with a FortiGate export, or review sample output first if you want one more proof point.