FireSight

Features

Everything FireSight does today

FireSight connects to any number of FortiManagers and standalone FortiGates. A small organisation with a single FortiGate gets the same placement, auditing, approval and back-out as a FortiManager estate.

Inventory and sync

FireSight reads every ADOM, FortiGate, policy package, policy, object and route.

  • Syncs ADOMs, FortiGates, policy packages and their installation scope, address and service objects (including groups) and per-policy hit counters.
  • Reads routing tables (IPv4 and IPv6, with VRFs), zones, policy routes, SD-WAN zones and rules, and ADOM normalised interfaces.
  • Syncs on a schedule (hourly by default) and re-audits every package afterwards. Both can be run on demand.
  • Detects each ADOM's workspace mode separately, so locked and unlocked ADOMs can share a FortiManager.
  • Each VDOM of a standalone FortiGate appears as its own ADOM-like entry with one package.
Settings, Connections: a FortiManager and a standalone FortiGate, both synced, and a table of ADOMs showing how changes are made, workspace mode and the approval chain for each.

Automatic placement

A requester describes only the traffic: sources, destinations and service. FireSight works out where the rule needs to go.

01Finds where each address lives

From FortiGate interface subnets, IP allocations and internal routes that point at a site's core switch. Addresses no managed FortiGate owns are treated as external, such as the internet or partners.

02Walks the path the way a FortiGate forwards

Policy routes first, then the routing table of the incoming interface's VRF (longest prefix first), then the first matching SD-WAN rule when the egress is an SD-WAN zone. The walk continues across managed FortiGates, including from a FortiManager-managed firewall to a standalone one.

03Translates interfaces into what the policy needs

An interface in a zone becomes the zone, an SD-WAN member becomes the SD-WAN zone, and in FortiManager the result is matched to the ADOM's normalised interface. Missing mappings are added at deploy and removed again on back-out; existing mappings are never changed.

04One target per package and interface pair

Each target holds only the sources and destinations that really cross it, and FortiManager's Install On is limited to the firewalls on the path.

05Placed where it takes effect

Usually above the first policy that would treat the traffic differently. Firewalls where an existing policy already allows the traffic are marked as needing no change.

06Confirmed, and kept honest

The requester sees the traced path, can leave any firewall out, and must confirm the firewalls. If the rule base changes after confirmation or approval, FireSight refuses to submit or deploy until the request is re-planned. Placement can also be chosen manually.

See the hop-by-hop walk in detail →

Rule base audit

Addresses, groups, ranges and services are resolved to real networks and port ranges before rules are compared.

  • Shadowed, redundant and partial overlap, compared against the rules above in evaluation order.
  • Never hit on any device, or inactive for N days (configurable).
  • Disabled, too broad (accepts with all) and not logged.
  • FQDN, geography, negation, identity and internet-service rules are analysed best-effort and never reported as shadowing others.
  • New requests are checked live for the exact ADOM, package and position, including whether they would shadow rules below.
  • Findings can be filtered by type and severity and downloaded as CSV.
Audit findings table listing critical, high and medium findings such as too broad, shadowed, never hit, redundant and inactive, each with the policy, package and an explanation.

Change workflow

One path from request to deployed rule, with each step recorded.

  1. Request

    The requester describes the traffic and confirms the firewalls FireSight worked out, or picks an ADOM, package, interfaces and position by hand. Ticket references can be required.

  2. Approval

    The request goes to every chain that applies, in parallel. A rejected request must be changed before it can be resubmitted.

  3. Deploy

    An implementer deploys through FortiManager or straight to a standalone FortiGate.

  4. Back out or expire

    Back-out restores exactly what was there. Rules with a remove after date are backed out automatically.

Approval chains

Only administrators set up approval. Requesters can't choose, change or avoid the chains their request goes to.

Named chains

Reusable chains, such as "APAC network team" or "PCI data owners", assigned per ADOM. ADOMs without one use the standard chain: team lead, then security, then change advisory board, by default.

Conditions

Add a chain on top when a request matches addresses (source, destination or either), interfaces or zones, ports or "all services", traffic from or to the internet, or specific ADOMs. Matching is deliberately generous: any interfaces, any protocol and public ranges all count.

Parallel tracks

One track per chain, all at once. All must approve and one rejection rejects. The request shows each chain and why it applies, for example "ADOM APAC" or "condition: Remote admin ports".

Named approvers

Any stage can be limited to named people instead of everyone with the role, administrators included.

Emergency changes

Off until an admin turns them on. The requester ticks emergency and says why; the emergency chain alone approves, and it can be deployed straight away. The normal chains then review it within a deadline (72 hours by default), reviewers must differ from the emergency approvers and the deployer, a rejected review flags it for back-out, and overdue reviews are highlighted.

Switching off and deleting

Any chain except the standard one can be switched off; its ADOMs fall back to the standard chain so a request never goes without approvers. Deleting needs the chain's name typed, and deleted chains can be restored with their ADOMs and conditions. Submitted requests keep the approvers they started with.

Approval chains settings: the standard chain with team lead, security and change advisory board stages, alongside the APAC network team, Security architects and Emergency change chains, ADOM assignments and conditions.

Deployment

Through FortiManager

FortiManager 7.0 or later, API token
  1. 01Saves an ADOM revision
  2. 02Locks the ADOM if it uses workspace mode. ADOMs in workflow mode are refused with a clear message
  3. 03Creates or reuses objects, and adds missing normalised-interface mappings
  4. 04Adds and positions the policy
  5. 05Commits (in workspace mode), then installs to the firewalls in scope

On a standalone FortiGate

FortiOS 7.0 or later, REST API administrator
  1. 01Takes a full configuration backup, stored encrypted and downloadable by admins
  2. 02Adds the policy disabled
  3. 03Moves it into position
  4. 04Enables it enabled. If anything fails before this step, the policy is left disabled

Back-out and expiry

  • Every object, policy and interface mapping written is recorded with its previous value, so Back out restores exactly what was there.
  • A policy is only deleted if it still carries FireSight's name, so a reused policy ID never removes someone else's rule.
  • Normalised-interface mappings added at deploy are removed again, and only those.
  • Rules with a remove after date are backed out automatically when it passes and marked Expired. Requests never deployed are simply closed.
  • A back-out that keeps failing is retried three times, then left for a person, with each attempt in the audit log.

Offline rule assessment

Audit a rule base without connecting FireSight to it: a customer's firewalls, or an environment FireSight can't reach. Add it under Settings → Connections → Add offline snapshot.

.conf

FortiGate configuration files

Plain-text backups taken from the firewalls or downloaded from FortiManager's device revisions. Multi-VDOM files are supported. Password-protected .conf backups can't be read, so back up without a password.

.dat

FortiManager system backup

Plain or AES-256 encrypted, with its password (never stored or logged). FireSight finds each managed FortiGate's configuration and audits the newest one per firewall. If a backup can't be read, it says why and lists what it found.

.json.gz

FortiManager export

A single-file Python 3.8+ script, run from a jump host or admin laptop. It only reads, signs out when done, and never exports a password, session or token. It includes hit counters.

# read-only export from any PC that can reach FortiManager
python fmg-export.py --host fmg.corp.example --user admin
python fmg-export.py --host 10.0.0.5 --user admin --adom EMEA --adom APAC
  • Full rule audit under Audit findings, or Download CSV for a report. Configuration files hold no hit counters, so never hit and inactive are only reported for exports.
  • Snapshots are strictly read-only: never used to plan live rules, nothing can be deployed to them, and they're left out of IPAM, approval routing and the overview counts.
  • Uploaded files are stored encrypted; loading, replacing and deleting snapshots are all audited.

IP addressing and regions

  • Organise devices into nested geographic regions, for example EMEA, then Italy, then Bari.
  • Each region can own IP pools. Device allocations must come from the nearest region's pools and may not overlap any other allocation.
  • Interface subnets are discovered on every sync, and FireSight suggests the next free block of a given size.

DNS

  • Sources and destinations can be typed as host names; FireSight resolves them and plans with the addresses.
  • Single-host entries (/32 and /128) are looked up in reverse DNS, and the names are shown to requesters and approvers.
  • Optionally name the firewall objects FireSight creates after the host's DNS name, matching on the IP address (recommended) or as FQDN objects that follow DNS.
  • DNS servers can be set; otherwise the server's own resolver is used.

Sign-in, roles and audit log

  • FireSight accounts, LDAP / Active Directory, OpenID Connect and SAML 2.0, each with group-to-role mapping.
  • Roles: requester, team lead, security, change board, implementer, auditor and administrator.
  • An append-only audit log of every sign-in, failed sign-in, decision, push, back-out, expiry, sync, backup download, IP allocation and setting change, with person and source IP. Filter it and export it as CSV.

Details on the security page →

Running FireSight

  • Runs in your environment as one container serving the API and the web interface, with PostgreSQL. Put a TLS-terminating reverse proxy in front.
  • The database schema is migrated automatically at start-up.
  • Run several replicas if you like: scheduled jobs are claimed in the database, so each runs once.
  • Ships in simulate mode, which records deployment plans without writing anything, until you set it to live.
  • A built-in demo estate with a FortiManager, two ADOMs and a standalone FortiGate for trying it out. The screenshots on this site come from it.
  • An HTTP API with OpenAPI documentation.

Not done yet

What FireSight doesn't do today, so you can plan around it.

  • SAML encrypted assertions and signed authentication requests.
  • FortiManager workflow mode (approval sessions inside FortiManager). Such ADOMs are refused.
  • Placement models static routing state as synced. Dynamic routing (BGP/OSPF) is used as far as it appears in the synced routing table, but SD-WAN performance SLAs, ECMP load balancing and policy routes matching on ToS aren't evaluated.
  • FortiManager 7.4 system backups can't currently be read; use the export script instead.
  • FireSight connects to Fortinet platforms today. Connectors for Check Point, Palo Alto Networks, Cisco and Linux (nftables / iptables) are planned.

See FireSight on your own rule base

We'll walk you through placement, the audit, approval chains and back-out using the built-in demo estate, and talk through what connecting your FortiManager or FortiGates would involve.

Request a demo Browse every feature