Services › Firewall Assessment

Firewall Assessment and Rule Review

A reviewed firewall assessment across FortiGate, Cisco ASA, Palo Alto, Juniper and the rest of your estate — with the judgement calls a tool cannot make.

India:All customer data is stored and processed in India. Our infrastructure runs in Indian data centre regions, and no customer data is replicated outside the country.

The Situation

Firewall rule bases are written forwards and almost never read backwards. A rule is added for a project, the project ends, and the rule stays because nobody can prove it is safe to remove. Repeat for five years and you have a policy where a meaningful share of the rules serve no current purpose and a few of them are dangerous.

The automated part of reviewing that is genuinely automatable, which is why we give the tool away. A machine can find any-to-any rules, shadowed rules, cleartext management and firmware with published advisories, and it can do it identically every time across nine platforms.

What a machine cannot do is tell you which permissive rule is deliberate. A rule allowing any source to a payment system might be a catastrophic oversight or a documented, compensating-controlled decision made by someone who thought about it harder than the tool ever will. Telling those apart requires asking people, reading change records, and understanding what the business actually does. That is the part worth paying for.

Who This Is For

Organisations with more than one firewall, a rule base nobody fully understands, or an auditor asking when the rules were last reviewed. Also anyone who has run our free tool and wants the findings interpreted against how the business actually works.

What You Get

  • Every firewall in the estate assessed against 21 controls, not a sample
  • Rule-by-rule review: what each rule permits, whether it is still needed, and who asked for it
  • Shadowed, duplicate and unused rules identified for removal, with the order to remove them in
  • Management plane review: administrative access, authentication, logging and time sources
  • Firmware and advisory check against published vulnerabilities for your versions
  • Findings rated by exploitability in your topology, not by generic severity
  • A remediation plan sequenced so that nothing breaks when it is applied
  • Re-test after remediation, confirming each finding is closed

What We Usually Find

Not a list of everything possible — the things that come up again and again, in roughly the order they come up.

  • Rules permitting any source to any destination, usually near the top of the policy where they shadow everything beneath
  • Management interfaces reachable from user networks or from the internet, often over cleartext protocols
  • Rules that can never match because an earlier rule already covers the traffic, which makes the policy longer and the audit harder
  • Permissive rules created for a migration or an incident years ago, with nobody left who knows why
  • Firmware several versions behind, with published advisories affecting the exact feature set in use
  • Logging disabled on exactly the rules whose traffic would matter during an investigation
  • Device hygiene gaps: default accounts, SNMP v1 or v2c with guessable communities, no NTP so log timestamps cannot be correlated

How the Engagement Runs

  1. CollectConfiguration backups, taken by you. Nothing is extracted from live devices.
  2. AssessThe deterministic checks run first, so the mechanical findings are complete before anyone forms an opinion.
  3. InterpretThe part a tool cannot do: which permissive rules are deliberate, which are forgotten, and which are dangerous here specifically.
  4. ReviewWalk the findings through with the people who own the rules.
  5. RemediateA change plan in an order that will not take production down.
  6. VerifyRe-assess after the changes and confirm what is now closed.

Questions We Are Asked

Which firewalls do you support?

FortiGate, Cisco ASA, Cisco IOS and IOS-XE, Palo Alto PAN-OS, Juniper SRX, MikroTik RouterOS, pfSense and OPNsense, Linux iptables, and AWS security groups. The free tool supports all of them and detects the vendor automatically.

Do you need access to our firewalls?

No. We work from configuration backups that you export and send, or that you never send at all if you run the offline tool yourself. We do not require credentials and we do not connect to your devices.

How is this different from the free tool?

The tool runs the same 21 deterministic checks and the findings are identical. The engagement adds interpretation: which findings matter in your topology, which permissive rules are deliberate, what order to remediate in so nothing breaks, and a retest confirming each one is closed.

How often should firewall rules be reviewed?

Most standards expect at least annually, and PCI DSS requires it every six months for in-scope environments. In practice the useful trigger is change volume: a rule base receiving weekly changes drifts faster than a calendar can track.

Can you review cloud security groups too?

Yes. AWS security groups are supported by the same engine, and a security group is a firewall even though it is rarely reviewed like one. Azure and GCP are not yet supported.