Firewall approval & analysis platform
Describe the traffic. FireSight finds the firewalls.
FireSight is an in-house web application for firewall estates. It works with Fortinet today (FortiManager, standalone FortiGates, or both), and Check Point, Palo Alto Networks, Cisco and Linux firewalls are being added. A requester says what needs to talk to what. FireSight traces the path, works out the firewalls, interfaces, packages and positions, checks the rule against the rule base, sends it through your approval chains and deploys it with a recorded way back.
A trace from the built-in demo: one SSH request, three firewalls, three policy packages, two ADOMs.
The problem
Every firewall change starts with the same three questions
Which firewalls does this cross?
Requesters know the source and the destination. They rarely know the path through hub-and-spoke VPNs, policy routes, VRFs and SD-WAN, so tickets bounce between teams while someone traces it by hand.
Where in the package does it go?
Too low and a rule above wins. Too high and it hides the rules below. Meanwhile shadowed, redundant and never-hit rules pile up, and nobody is sure which ones are safe to touch.
Who approved it, and how do we undo it?
Approvals in email threads and changes typed in by hand leave little to audit, no guarantee the right people signed off, and no exact record of what to put back.
How it works
From a description of traffic to a deployed, reversible rule
Describe
The requester enters sources, destinations and service. IPs, networks or host names; FireSight resolves the names.
Trace and place
FireSight walks policy routes, VRF routing tables and SD-WAN rules hop by hop, then picks the package, interfaces and position on each firewall.
Approve
The request goes to every approval chain that applies, in parallel, with separation of duties enforced. The requester can't pick or skip chains.
Deploy and back out
An implementer deploys through FortiManager or straight to a FortiGate. Every write is recorded so Back out restores exactly what was there.
Key features
Built around how FortiGates actually forward traffic
Automatic placement
Finds where each address lives, walks the path firewall by firewall, and creates one target per package and interface pair with Install On limited to the path.
Rule base audit
Shadowed, redundant, partial overlap, never hit, inactive, disabled, too broad and not logged, with objects resolved to real networks and ports.
Approval chains
Named chains per ADOM, conditions that add chains, parallel tracks, named approvers and emergency changes with a review after deploy.
Safe deployment
ADOM revision and workspace locking on FortiManager. On a standalone FortiGate: config backup, then add disabled, move, enable.
Exact back-out
Every object, policy and interface mapping is stored with its previous value. Rules with a remove after date back out on their own.
Offline assessment
Audit FortiGate configuration files, a FortiManager backup or an export without connecting FireSight to those firewalls.
IPAM and regions
Nested regions own IP pools, allocations can't overlap, and interface subnets are discovered on every sync with the next free block suggested.
DNS naming
Type host names as sources or destinations, see reverse DNS for single hosts, and optionally name the objects FireSight creates after the host.
Rule base audit
Findings worked out from real networks, not object names
Addresses, groups, ranges and services are resolved to real networks and port ranges, so LAN-All is correctly seen to cover LAN-Rome. Every package is re-audited after each scheduled sync.
| Finding | Meaning |
|---|---|
| Shadowed | A rule above matches all of this rule's traffic with the opposite action, so this rule never takes effect |
| Redundant | A rule above already does the same thing for all of this rule's traffic |
| Partial overlap | Some of this rule's traffic is handled differently further up |
| Never hit / Inactive | No hits on any device, or none for N days (configurable) |
| Disabled | The rule is switched off |
| Too broad | Accepts with all sources, destinations or services |
| Not logged | Accepts without logging |
- Evaluation order, drawn. The package view lists policies top to bottom and draws which rule hides or makes redundant which.
- Hit counters from every device. Never hit means no hits on any device; the inactive threshold in days is yours to set.
- No false shadowing. Rules that use FQDN, geography, negation, identity or internet-service matching are analysed on a best-effort basis and never reported as shadowing other rules.
- Exportable. Filter findings by type and severity, and download them as CSV.
Approval chains
The right approvers, decided by admins, not by requesters
Only administrators set up approval. Requesters can't choose, change or avoid the chains their request goes to, and drafts show who will approve before anything is submitted.
- Named chains per ADOM. Reusable chains such as "APAC network team" or "PCI data owners". ADOMs without one use the standard chain: team lead, then security, then change advisory board.
- Conditions add chains. Match on addresses, interfaces or zones, ports or "all services", internet traffic, or specific ADOMs. Conditions only ever add approvers.
- Parallel tracks. Every chain that applies runs at once. All must approve; one rejection rejects. Each track shows why it applies.
- Emergency changes. Off until an admin turns them on. Approved by the emergency chain alone, then reviewed by the normal chains within a deadline (72 hours by default).
- Separation of duties. No approving your own rule, no approving two stages of one chain, and nobody who approved or reviewed a rule can deploy it.
Safe deploy and back-out
Every push is staged carefully and recorded so it can be undone
Through FortiManager
per ADOM, workspace mode detected- 01Save an ADOM revision
- 02Lock the ADOM if it uses workspace mode (detected per ADOM, overridable)
- 03Create or reuse objects; add missing normalised-interface mappings
- 04Add and position the policy
- 05Commit (workspace mode), then install to the firewalls in scope
Straight to a standalone FortiGate
every write is live, so it goes disabled-first- 01Take a full configuration backup, stored encrypted
- 02Add the policy disabled
- 03Move it into position
- 04Enable it enabled
- —If anything fails before the last step, the policy is left disabled, so it never takes effect in the wrong place.
Back out exactly
Every object, policy and interface mapping written is recorded with its previous value, and Back out restores exactly that.
Never someone else's rule
A policy is only deleted if it still carries FireSight's name, so a reused policy ID never removes someone else's rule.
Rules that expire
Rules with a remove after date are backed out automatically and marked Expired. Failing back-outs retry three times, then wait for a person.
Offline rule assessment
Audit firewalls FireSight can't reach
Upload a snapshot of a customer's firewalls or an isolated environment and get the full rule audit, with a CSV report, without connecting FireSight to them.
FortiGate configuration files
One or more plain-text backups, from the firewalls or from FortiManager's device revisions. Multi-VDOM files are supported.
A FortiManager system backup
With its password, used only to open the file and never stored or logged. FireSight audits the newest configuration per firewall, and says why if a backup can't be read. Backups from FortiManager 7.4 can't be read yet: use the export.
A FortiManager export
A single read-only Python script run from any PC that can reach FortiManager. The most complete option: it includes hit counters.
Snapshots are strictly read-only: never used to plan live rules, never deployed to, and left out of IP address management, approval routing and the overview counts. Uploaded files are stored encrypted.
Security and sign-in
Your directory, your roles, an append-only trail
Sign in with FireSight accounts or your identity provider. Roles come from directory groups and are re-read at every sign-in.
- FireSight accounts
- LDAP / Active Directory
- OpenID Connect
- SAML 2.0
- FortiManager and FortiGate API tokens, the LDAP service password and the OIDC client secret are encrypted at rest.
- Every sign-in, decision, push, back-out, expiry, sync and setting change is in an append-only audit log, exportable as CSV.
FIRESIGHT_DEPLOY_MODE=simulateis the default: deployment plans are recorded without writing anything until you switch tolive.
Platforms
Fortinet today. Multivendor by design.
FireSight is built so that placement, auditing, approvals and back-out don't depend on the vendor. Each platform plugs in through its own connector, with the aim that one request is traced through every firewall on its path, whoever made it.
Fortinet
FortiManager with its managed FortiGates, standalone FortiGates, and offline snapshots from configuration files or a FortiManager export.
Palo Alto Networks
Panorama with its device groups, and standalone PAN-OS firewalls.
Check Point
Security Management Server and Smart-1, with their policy packages and gateways.
Cisco
Secure Firewall Management Center with Firepower Threat Defense, and standalone ASA.
Linux
Hosts and gateways filtering with nftables or iptables.
Mixed estates
The same request form, audit findings, approval chains and audit log for every vendor, with each firewall's rule written in its own platform's terms.
Need a platform sooner? Tell us what you run and it helps us decide what comes next.
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.
