FireSight docs

What FireSight is

FireSight is an in-house application for firewall rule changes. People ask for a rule by describing the traffic. FireSight works out which firewalls need a policy and where in each policy set it must go, checks it against the rules already there, sends it through your approval chains, deploys it, and can back it out again.

It also audits the rules you already have. It finds rules that never take effect, rules that duplicate others, rules nobody uses and rules that are too broad, and explains each one with a recommendation.

FireSight supports Fortinet today: FortiManager, and standalone FortiGates managed directly. It is built to be multivendor; other platforms are planned. See Supported and planned platforms.

The workflow end to end

  1. Connect. An administrator connects a FortiManager or a standalone FortiGate. FireSight syncs the management domains (Fortinet: ADOMs), firewalls, policy sets (Fortinet: policy packages), policies, objects, routes and hit counters, and audits every policy set. See Connections.
  2. Request. A requester describes the traffic: accept or deny, sources, destinations, protocol and ports. FireSight traces the path firewall by firewall, picks the interfaces and the position in each policy set, and runs a live pre-check. The requester confirms the firewalls and submits. See Create a rule request.
  3. Approve. The request goes to the approval chain of every management domain it changes, plus any chain a condition adds. All chains run in parallel; each must approve, and one rejection rejects the request. See Approve and reject.
  4. Deploy. An implementer who didn't request or approve it deploys it. Through FortiManager, FireSight saves a revision, writes the objects and policy, and installs. On a standalone FortiGate, it takes a configuration backup first and adds the policy disabled until it is in position. See Deploy and back out.
  5. Back out or expire. Every change is recorded, so Back out restores exactly what was there. Rules with an end date are backed out automatically when it passes.
  6. Audit and monitor. The rule base is re-audited after every scheduled sync, firewalls are checked for reachability and load, and every action is written to the audit log.

Roles

Each person holds one or more roles. Administrators hold every permission.

Role What they can do
Everyone signed in View rule requests, deployments, policy sets, audit findings, device health, regions and IP addressing. Download the findings CSV and PDF report.
Requester Create, edit, confirm, submit and cancel their own rule requests.
Team lead Approve or reject approval stages that require the Team lead role.
Security Approve or reject stages that require Security. Read and export the audit log. Run rule audits.
Change board Approve or reject stages that require Change board.
Implementer Deploy approved rules and back them out. Sync connections. Run rule audits. Manage regions, IP pools and allocations. Run health checks and mute alerts.
Auditor Read and export the audit log and run rule audits. Can't change anything.
Administrator Everything above, plus the Settings area: connections, sign-in methods, users, approval chains, policies and schedules, notifications, license and system.

See Users and roles for the details.

Requesters never choose their approvers

Requesters can never create, change or choose approval chains. The chains a request goes to follow from the management domains it changes and the conditions it matches, and only administrators set those up. A requester can see who will approve a draft before submitting it, but can't change it.

What it does

Area What you get
Inventory Management domains, firewalls, policy sets and their installation scope, address and service objects (including groups), per-policy hit counters, routing tables (IPv4 and IPv6, with VRFs), zones, policy routes, SD-WAN zones and rules, and normalised interfaces. Synced on a schedule and on demand.
Rule requests Requesters describe only the traffic. FireSight finds the firewalls on the path, the interfaces or zones, and the position in each policy set, with a live pre-check.
Approvals Named approval chains per management domain, conditions that add chains, parallel tracks, named approvers, separation of duties and emergency changes with a review afterwards.
Deployment Through FortiManager, or straight to a standalone FortiGate. Simulation mode for testing. One-click back-out. Automatic removal of temporary rules.
Rule audit Shadowed, redundant, crossing (partial overlap), never hit, inactive, disabled, too broad, not logged and best-effort findings, each with a recommendation. A rule-stack view draws the relationships.
Offline review Audit a rule base FireSight can't reach from FortiGate configuration files, a FortiManager backup or a FortiManager export made by a read-only script.
Reporting Findings as CSV, and a branded PDF audit report.
IP addressing Nested regions, regional IP pools, per-firewall allocations and next-free-block suggestions.
Device health Reachability, CPU, memory, sessions and link load of every firewall, with alerts by email, Microsoft Teams, Slack or webhook.
Governance Roles, single sign-on (LDAP, OpenID Connect, SAML) and an append-only audit log.

Where to start

Tip

Use Search the docs, above the page list, to find a setting, a button or an error message.

Concepts →