Service Catalog — Network Configuration Analysis

Know what your firewalls permit, and prove it was reviewed

Rule bases grow for years, and the dangerous entries are rarely the obvious ones: an any-to-any permit left over from a migration, Telnet still reachable, allow rules that log nothing. Upload a firewall, WAF or load-balancer configuration export and get every rule graded by severity: broad and insecure firewall rules queued for a written decision, and WAF protections that only look active called out beside them.

22 firewall, WAF and load-balancer platformsNine rule checks — seven firewall, two WAFA written decision on every risky ruleSelf-hosted, no device access
The network picture

Every permitted path, graded

Uploads from across the estate merge into one picture: the internet at the top, published services and firewalls beneath it, and your network segments below. As findings resolve, each node and permitted path takes the colour of the worst thing it allows.

  • Critical
  • High
  • Medium
  • Low
  • Internet-facing

An illustration of the network map, not live data. In the product the same view is built from your own configuration exports and asset inventory.

22

Firewall, WAF and load-balancer platforms supported today

9

Rule checks — seven for firewalls and load balancers, two for WAFs

19

Cleartext and high-risk service families detected

4

Severity levels on every finding

What one upload gives you

A firewall review that produces evidence

Nine checks — seven that run over every rule in a firewall or load-balancer export, two over every rule in a web application firewall export. Each returns a severity, a plain-English title and the configuration lines it came from.

Every rule, every vendor, one table

FortiGate, Cisco ASA, PAN-OS, Check Point and the rest arrive in the same filterable table with the same columns — severity, rule, action, source, destination, service, status — so a reviewer reads one format instead of six, and the worst-graded rules sort to the top.

Broad permits, graded and labelled

An any-to-any permit on any service is critical. Any service with a broad endpoint, and any source to any destination, are high. An any source on its own is medium. Every finding also carries an enforcement level — violation, deviation or advisory — so a sanctioned business decision is never put in front of an auditor in the language of a policy breach.

Cleartext and exposed services named

Nineteen service families across 27 ports: Telnet, FTP, TFTP, the r-services, SNMP v1/v2c, NetBIOS, SMB, RDP, VNC, cleartext LDAP and the common database, cache and search ports. Severity escalates with reach — Telnet from any source resolves to critical, Telnet from a single host to high.

Ports hidden inside wide ranges

A rule opening TCP 3000–4000 is flagged for RDP, because every risky port is tested against the span a rule actually opens rather than matched literally. Wide service objects stop concealing what they contain.

Protections that only look active

Across eight web application firewalls, a protection sitting in count or monitor mode is flagged: the dashboard reads protected while the configuration blocks nothing. Broad, unconditional allow rules that short-circuit the blocking rules after them are flagged as well.

Configuration evidence attached

Open any flagged rule and the configuration block it was parsed from sits with its findings, so a reviewer or an auditor can verify what a finding is based on without asking the network team for the file again.

Coverage

22 platforms you can upload today

Most estates run more than one brand. The same nine checks, the same severity language and the same review record apply whatever the estate is built from.

ClassPlatforms supported todayCount
FirewallsFortinet FortiGate · Cisco ASA · Cisco IOS / IOS-XE / NX-OS · Palo Alto PAN-OS · Juniper SRX (JunOS) · Check Point · pfSense / OPNsense · SonicWall SonicOS · Sophos XG / SFOS · WatchGuard Fireware · MikroTik RouterOS · Huawei USG (VRP)12
Web application firewallsAWS WAF · Azure WAF (Application Gateway / Front Door) · Cloudflare WAF · FortiWeb · Barracuda WAF · Imperva · Akamai App & API Protector · ModSecurity / OWASP CRS8
Load balancers and application delivery controllersF5 BIG-IP · Citrix NetScaler / ADC2

Load balancers are read from their device configuration — VLANs, self-IPs, pools, access lists and published virtual servers — and are assessed with the firewall checks; the two WAF-specific checks apply to the eight web application firewalls above, and load-balancer application-firewall policy files are outside today's analysis. Cisco Firepower (FTD) is a roadmap item and is shown in the product as such.

How it works

From a configuration export to a decision on the record

No device access, no credentials to hand over, no data-modelling project first.

  1. 01

    Export

    Take a plaintext configuration export from the device. The upload screen shows the exact command or menu path for each supported platform, so the request to the network team is unambiguous.

  2. 02

    Upload

    Drop the file in, up to 15 MB. The platform is recognised from the file's contents, so nobody has to declare it — and you can still name the vendor yourself when you upload. Encrypted and binary device backups are refused rather than guessed at, with guidance on producing a plaintext export instead, so an unreadable file never turns into invented findings.

  3. 03

    Review

    Every rule lands in one table with the flagged ones first. Open a rule to read its findings, its severity, its enforcement level and the configuration lines behind it. Partial or unusual exports import as far as they can, and anything that could not be read is listed alongside the rules rather than failing the import.

  4. 04

    Decide

    Record Justified, Risk accepted, Remediation planned or False positive with the business reasoning in writing, or leave the rule In review while you chase the answer from its owner.

  5. 05

    Evidence

    Every decision keeps the reviewer's name, the date and the reasoning exactly as written, attached to the rule itself rather than to a spreadsheet somebody has to go and find. The record is already there the next time someone asks how the rule base was reviewed.

The audit record

Who looked at this rule, when, and why does it still stand?

Every risky rule carries a name, a date and the reasoning behind the decision — who examined it, when, and on whose authority the exposure was accepted. The output is a persistent, filterable review that a second person can pick up months later.

  • Five decision states cover the whole review: In review, Justified, Risk accepted, Remediation planned and False positive. Four of the five cannot be saved without written business reasoning, so the rationale is part of the record rather than an optional note.
  • Only broad-scope and insecure-service findings enter the queue. Advisory findings — an allow rule with logging switched off, a disabled rule left behind in a policy — are recorded against the rule but never demand a signature, so the queue holds decisions a person genuinely has to make.
  • Findings are written to avoid manufacturing work: scope is judged only on enabled allow rules, so a broad deny is left alone, and logging is only reported as off when the device explicitly says so rather than inheriting a default.
  • Imports, deletions and every decision also land in the platform audit log, stamped with the actor and the time. The table is append-only, and a revised decision adds an entry rather than replacing one, so the trail survives the review itself being revised — the durable record of a periodic firewall rule review.
  • Viewing and changing are separate rights: a compliance analyst can read the rules and findings without being able to upload a configuration or record a decision, while a single upload-and-justify right covers the review itself. Every record is scoped to the workspace that owns it.
  • Nothing leaves your network: the review runs inside a self-hosted installation, including natively on Windows Server, with no connection to any device.
Rule 1042 · core-firewallIn review
Any source → any destinationDeviationHigh
Insecure service permitted: TelnetDeviationCritical
Allow rule without loggingAdvisoryLow

Exposure

Which segment is exposed, and whose business line sits behind it

A rules table answers whether rule 47 is broad. Merged with your asset inventory, the same uploads answer the question a security architect is actually asked: what can be reached from outside, across which segments, carrying which service.

  • Subnets unify across devices. Two firewalls from different vendors that both touch 10.11.0.0/24 collapse into one segment listing both, so several uploads read as one network rather than one diagram per appliance.
  • Assets are placed onto segments by their IP address, and business lines come from asset attributes you already maintain, so nothing stands between an upload and the picture.
  • Allow rules become paths between the segments they cross: where the export places both ends of a rule — as zone-based policies like FortiGate, PAN-OS, SRX and Check Point do — the path carries the number of rules behind it, their services and the worst finding among them. A permissive any-source rule reaching a known segment draws that path from the internet straight to it.
  • Rule severity rolls up onto segments, devices and permitted paths in an interactive 3D view that an executive can read without opening the rules table.
  • Select a business line and the rest of the estate recedes, leaving that line's segments, the devices in front of them and the route back out to the internet.
  • The merge surfaces governance gaps in both directions: published assets whose address appears in no configuration, published addresses with no inventory asset behind them, and assets sitting outside every known subnet.
Exposure readoutNetwork map
Internet → VLAN 60 · 10.13.0.0/24Permitted pathCritical
10.11.0.0/24 · seen by 2 devicesSegmentHigh
Payments · 3 segmentsBusiness lineInternet-facing
198.51.100.20:443Published serviceMatched to asset
4 published assets absent from every configurationData gapReview

Frequently asked questions

Does this connect to our firewalls?

No. It reads configuration exports that a person uploads: no live connection, no agent and no device credential to hand over, which is usually what makes it acceptable to a network team that will not grant a governance tool access to production equipment. Each upload is an independent snapshot of that device at that moment, and a device is re-reviewed by uploading its current export after a change window.

What exactly do we upload, and what happens if the file cannot be read?

A plaintext configuration export, up to 15 MB per file, with the first 5,000 rules of a configuration imported and the truncation reported with the import if the rule base is larger — so you always know whether you are looking at all of it. Encrypted and binary device backups are recognised and refused, with guidance on producing a readable export. Partial or unusual exports import as far as they can and list what could not be understood.

How much work does this create for the reviewer?

Five of the seven firewall checks put a rule into the justification queue — the broad-scope and insecure-service findings, where a human genuinely has to make a call. Advisory findings such as a disabled rule left in the policy, or an allow rule with logging switched off, are recorded against the rule without demanding a written decision.

Do findings come tagged to ISO 27001 or PCI DSS clauses?

Not today. Each finding carries a severity and an enforcement level of Violation, Deviation or Advisory, and each risky rule carries a named reviewer, a date and written reasoning. Your control owner maps that record to the clause it evidences; the evidence itself is the rules table, the retained configuration lines and the audit log.

What does the analysis deliberately not do?

It reviews rules — nine checks over the rules themselves. Device-hardening checks such as management services, cryptography, administrator accounts and SNMP trusted hosts, along with rule shadowing and redundancy analysis and control-framework tagging, are roadmap items rather than capabilities today. Findings do not raise risk-register entries or compliance gaps automatically, and there is no exported findings report: the evidence is the on-screen review plus the audit log.

How is it licensed, and who can use it?

It is part of the Service Catalog module and is licensed with it, which is also what allows configurations to be correlated against the asset inventory — nothing further has to be licensed for the picture to be complete. Two rights govern it: one to view the rules and findings, one to upload configurations and record justifications.

Get started

See UniSentinel running on your terms

Book a 30-minute walkthrough. We'll map your program to the modules you need — cloud, on-prem Linux or Windows Server.

Every module works standalone. License only what you need — grow when you're ready.