We automate the full firewall policy lifecycle inside Cortex XSOAR — discovery, multi-hop path analysis, rule suggestion, vendor-native command generation, and validation. Across PAN-OS and FortiGate. In air-gapped estates. Without sending a single live packet.
In a small estate that is a five-minute question. In a multi-vendor, multi-VRF MPLS estate of a thousand-plus enforcement points, it is a week of engineering — and the answer is a guess.
The traditional answer is to log into devices and probe. Run a path trace here, read a routing table there, ask the team who built the WAN. It does not scale, it needs credentials on production kit, and in an air-gapped or change-frozen environment it is often simply not allowed.
So rules get written defensively. Engineers open a flow on four firewalls because they are not certain which two it actually crosses. The estate accumulates rules nobody can justify and nobody dares remove.
خوارزم A rule you cannot justify is a rule you cannot remove. Permissiveness is what uncertainty looks like six months later.
The question underneath is a routing question, not a policy question. Which devices does this flow traverse? Which interface does it leave by? Which zone does that put it in? Only then: does policy admit it?
Answer the routing question offline — correctly, including NAT, policy-based forwarding, equal-cost paths, and VRF boundaries — and the policy question answers itself. That is the whole idea.
Which is also why most tooling struggles here. Enterprise topologies are well handled. Carrier-style estates, where the MPLS provider edge decides ingress and the firewall sees seven equal-cost routes of which six do not forward, are not.
Six stages, each producing something an engineer can inspect before the next one runs. Integrations and automations, a playbook that orchestrates them, and an approval gate before anything reaches a device.
Collectors pull a structured snapshot from Panorama and FortiManager: routing tables, hardware FIB, zones, VRFs, interfaces and link state, NAT and PBF rules, address and service objects.
An offline engine replays the vendor forwarding pipeline against that snapshot — destination NAT, policy-based forwarding, FIB-over-RIB longest-prefix match, link state, ECMP resolution, VRF-aware egress, HA-peer collapse — and returns every firewall the flow actually crosses.
Each hop yields an ingress and egress interface, and therefore a source and destination zone. Interface-based FortiGate policy is handled: an unzoned interface is its own boundary, exactly as the device treats it.
For each transit firewall, the minimum rule that admits the flow — with the existing rule base checked first, so a request already covered produces no change at all.
Vendor-native artefacts: address objects, service objects, security rules, and correct rule placement — Panorama rulebase position, FortiManager policy ordering — ready for review.
The trace is re-run against the intended post-change state. If the flow still does not pass, the pack says so before an engineer opens a change window.
None of this is in a datasheet. Each of these is a bug that produced a confidently wrong answer until it was found, understood, and pinned with a regression test.
A WAN hub firewall in an RT-mesh sees seven equal-cost routes to a prefix. Six of them do not forward — they are a routing artefact of the mesh. We resolve the real egress with a two-pass walk that matches next-hops against the ingress addresses of devices proven to be on the path.
A packet arriving on a VRF-bound interface is routed only within that VRF. Miss this and the trace silently exits through a different customer's VRF and suggests a rule on the wrong firewall. Getting it right means normalising VRF identifiers that arrive as integers on one route and strings on the next.
On SD-WAN-enabled FortiGate, zone membership does not live in the zone table at all — it lives in the SD-WAN member list. Read the obvious place and every zone lookup returns empty, quietly, with no error, on every device.
A destination NAT rewrites the address the forwarding table is consulted with. Trace the pre-NAT address and you follow the default route into the internet; trace the post-NAT address and you miss the firewall that performed the translation. Both segments of the path have to be modelled, and joined.
Two firewalls sharing a segment are parallel paths, not sequential ones. For any single flow exactly one is active. Reporting both doubles the rule count and confuses the reviewer. We collapse them into a single logical hop and say which peers were folded.
Some questions have no answer in the routing table. Whether an undiscovered next-hop is a transit device or the edge of your world is an operator decision. We surface it explicitly as a flag rather than guessing — and the tool tells you when it is guessing.
Automation that is confidently wrong is worse than no automation, because a human would have hesitated.
The engine runs outside the platform, against synthetic topologies built to reproduce each failure exactly. A fixture that passes for the wrong reason is treated as a broken fixture.
Logic tuned to one network is a liability. We run the same engine against a deliberately different topology — other naming, other schema, other VRF conventions — and treat whatever breaks as the backlog.
Byte-level artefact parity, compile and execute checks, and a regression suite run before any change is packaged. Superseded builds are pruned, not archived.
Every hop carries a confidence: whether the route to the source or destination is directly connected, a specific prefix, an aggregate, or only the default route. A path that rests on a default route is reported as such, not laundered into a certainty.
Analysis and generation are separate from enforcement. The pack produces reviewed artefacts and an approval gate stands between them and any device. Read-only deployment is a supported end state, not a limitation.
Most clients start with the first and decide about the rest once they have seen a path traced across their own estate.
We ingest a topology snapshot from your Panorama and FortiManager and trace a handful of flows your team already knows the answer to. You check our work.
The full lifecycle, built for your topology and your change process, deployed into your tenant — air-gapped if that is where you live.
Once you can prove which firewalls a flow crosses, you can prove which rules were never needed. Discovery first, deletion second.
Bespoke XSOAR integrations, third-party connectors, and the unglamorous plumbing that decides whether a playbook survives production.
If you have a firewall path your team argues about, that is the conversation we want to have. We will tell you what we can determine offline — and what we cannot.