{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Use one flow per row; headers are optional and quoted CSV cells are supported.
{{ params.source.length.toLocaleString() }} chars
{{ sourceStatus }}
{{ fileError }}
Choose the handoff style closest to the policy surface you are documenting.
Application flow inventories usually list explicit allows; deny rows remain supported for guardrail entries.
Use session-end logging for implementation handoff unless your environment has a different explicit standard.
Keep it short enough for tickets and change records.
Specific-first is useful before implementation review; input order is safest for change-record parity.
Leave blank when missing owners should remain visible in the audit queue.
Use 30-90 days for temporary exceptions and compliance-driven reviews.
days
{{ header }} Copy
{{ cell }}
No rows for the current input. 
{{ result.markdown }}
Tags: Networking, Security
Export to PDF Fullscreen
Customize
Advanced
:

A firewall rule matrix turns intended application flows into a reviewable table of sources, destinations, services, actions, owners, tickets, and review dates. That format matters before a firewall change because a single broad allow can expose more than the requester meant, while a missing owner or stale expiry can leave temporary access in place long after the business need has passed.

Firewall policy work is usually a translation problem. Application teams describe dependencies in business terms, network teams need address and service boundaries, and auditors need evidence that each row has a reason and an accountable owner. A matrix keeps those facts together so a reviewer can compare the rule intent against the access surface before anyone copies rows into a firewall, host policy, or cloud security control.

Diagram showing flow rows normalized into firewall matrix outputs, audit findings, object plans, and a zone heatmap.

Risk review needs more than the row count. Two rules can both say allow, but the first may limit a single jump host to TCP 22 while the second permits any source to any service. A matrix is useful because it makes the narrowness, reason, logging choice, and review evidence visible beside the requested action.

The result is still planning evidence, not deployment proof. Rule order, platform-specific object expansion, NAT, routing, identity-aware controls, and existing policy context can all change how traffic behaves after implementation. Use the matrix to find weak or incomplete rows, then verify the final policy in the firewall or cloud control plane that will enforce it.

Technical Details:

A firewall rule row is a tuple: source, destination, protocol, port or service, action, and supporting governance fields. Address precision is the first technical pressure point. 0.0.0.0/0, ::/0, any, and similar values represent unrestricted scope. IPv4 addresses without a prefix are treated as host routes, while CIDR prefixes describe ranges whose size grows quickly as the prefix gets shorter.

Private IPv4 scope follows the familiar RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Those labels help distinguish internal-style ranges from public, loopback, link-local, documentation, multicast, reserved, and named-object entries. A named object can be carried through the matrix, but its membership still needs platform-side verification because the row text alone cannot prove which IPs the object contains.

Rule Core:

The review logic favors concrete boundaries and accountability evidence. It assigns findings to rows, then keeps the highest finding score as the row risk score on a 0 to 100 scale.

Review signal When it appears Typical severity
Any source to any destination allow An allow row has unrestricted source, unrestricted destination, and unrestricted service. Critical, score near 96/100.
Any-service allow An allow row has no protocol or port constraint, or pairs an unrestricted source with any service. High, with stronger pressure when the source is unrestricted.
Broad source range An allow row uses any, IPv4 prefixes at /16 or wider, or IPv6 prefixes at /48 or wider. Medium to High, depending on width.
Sensitive service from broad source A broad source can reach watched administrative, database, file-sharing, cache, or remote-access ports. High.
Missing governance evidence Business reason, owner, ticket, logging, or review date is absent, expired, close, or not in YYYY-MM-DD form. Low to High, with expired review dates treated strongly.
Duplicate, conflict, or possible shadowing Rows repeat the same source, destination, protocol, and service, disagree on action, or follow an earlier broader row that may match first. Medium to High.
Cloud security group deny row The cloud security group profile contains an explicit deny row, even though common security group models rely on allow rules and implicit deny. Medium.

Port handling is intentionally conservative. Empty service cells become any, common service names such as ssh, https, postgresql, and rdp are mapped to their standard ports, and comma-separated or whitespace-separated services stay visible as a combined service set. A numeric range is allowed but receives a review note because ranges can hide unrelated access behind one row.

Field group Accepted content How it affects review
Source and destination Zone, name, IPv4 CIDR, IPv6 CIDR, any, or named object text. Controls scope, broad-range findings, object suggestions, and zone-pair heatmap cells.
Protocol and ports TCP, UDP, ICMP, ESP, AH, GRE, SCTP, any, numeric ports, ranges, or known service names. Defines the service label and triggers any-service, range, invalid-token, and sensitive-service findings.
Action Allow-style words, deny-style words, log or monitor words, or the configured fallback action when blank. Controls risk checks and highlights deny rows under the cloud security group profile.
Reason, owner, and ticket Business justification, responsible team, and approval or change reference. Missing values create audit queue entries; a fallback owner can mark unowned rows without hiding the gap.
Expires or review date YYYY-MM-DD dates, blank values, or unparsed text. Expired dates are high pressure, dates inside the warning window are medium pressure, and malformed dates stay visible.
Logging On, session-end, start-and-end, off, disabled, blank, or a custom label. Blank values use the logging default; disabled or unspecified logging is flagged, especially on allow rows.

Severity labels come from the strongest finding first. If no high-severity finding exists, the numeric score still maps to Critical at 85 or more, High at 60 or more, Medium at 35 or more, Low above zero, and Clear at zero. The score is a prioritization aid, not a platform-specific compliance verdict.

Everyday Use & Decision Guide:

Start with one change request, application migration, exception cleanup, or firewall review slice. Paste CSV rows into Flow rows, drop a text or CSV file, or use Browse. Headers are optional, quoted CSV cells are supported, and the legacy source, destination, protocol, port, action, and reason style is accepted when the row shape is clear.

Choose Matrix profile to match the handoff surface. Enterprise zone firewall suits zone-to-zone policy work, Cloud security group adjusts the review language around allow-first security group behavior, Host firewall fits local host policy review, and Change review worksheet keeps the wording closer to approval evidence.

  • Use Default row action only for rows that omit an action. Explicit allow, deny, block, permit, reject, and monitor-style words are still read from the source row.
  • Set Logging default to the standard expected by the target policy surface. Rows that explicitly set logging off remain visible in the audit queue.
  • Keep Rule ID prefix short enough for tickets and change records. It changes generated review IDs, not the parsed network fields.
  • Use Matrix order based on the review question. Input order preserves the source inventory, specific-first helps ordered-policy review, and risk-first puts broad or stale rows near the top.
  • Set Expiry warning window to match temporary exception review cycles. A value of 0 flags only expired rows.

Read the summary before the tables. Firewall Rule Matrix shows the top severity and top risk score, then badges count allow rows, deny rows, any-service allows, and logging gaps. If the warning area says a row has an invalid address or no flow rows were found, fix that before treating the matrix as handoff evidence.

The best first pass is to clear rows with Critical or High findings, then confirm that each remaining allow has a narrow source, narrow destination, specific service, logging choice, owner, ticket, and review date. A clear or low row still needs platform review if named objects, NAT, route domains, or inherited rules can change the real access surface.

Step-by-Step Guide:

Work from the flow inventory first, then tune review settings only where they match the policy surface.

  1. Paste or load rows in Flow rows. If the status line reports source row issues, read the warning list and correct invalid IP/CIDR text, empty input, or missing data before using the results.
  2. Pick Matrix profile. Watch for cloud security group deny findings when that profile is selected, because explicit deny rows may belong in another control rather than the security group matrix.
  3. Set Default row action and Logging default. The generated summary badges should reflect the expected allow, deny, any-service, and logging-gap counts.
  4. Open Advanced when you need a custom Rule ID prefix, Matrix order, Fallback owner, or Expiry warning window. The review matrix updates as those settings change.
  5. Use Normalize after the rows parse successfully if the source needs canonical CSV columns for review or handoff. This rewrites the input area into the supported column order.
  6. Review Review Matrix for row-level rule IDs, paths, services, action, logging, owner, ticket, review date, justification, and risk.
  7. Open Rule Audit Queue for the exact severity, finding, evidence, and recommendation behind each flagged row, then use Object Group Plan to check suggested source, destination, and service object candidates.
  8. Use Rule Scope Heatmap, Markdown Matrix, or JSON only after the row count, top severity, and audit findings match the change review you intend to share.

Interpreting Results:

The main decision cue is the combination of Risk in Review Matrix and the detailed reason in Rule Audit Queue. The matrix row shows where the access goes and how risky it looks; the queue explains why the row was flagged and what to change before implementation.

Output cue What it means Useful follow-up
Critical 96/100 An allow row can match any source, any destination, and any service. Replace it with named sources, destinations, and services or remove it before policy entry.
High with broad source or sensitive service evidence Administrative, database, legacy, cache, or remote-access services may be reachable from too wide a range. Limit the source to a VPN, bastion, partner range, service tag, or exact host group.
Duplicate tuple or Conflicting duplicate tuple Rows repeat the same source, destination, protocol, and service, possibly with different actions. Merge duplicates or resolve action conflicts before using the matrix as an implementation source.
Possible rule shadowing An earlier broad row may match traffic before a later specific row on ordered firewalls. Move the specific row earlier, split the broad row, or confirm that the target platform does not use ordered first-match behavior.
Baseline row in Rule Audit Queue No major findings were generated for the current input. Still verify object membership, routing, NAT, inherited policy, and platform syntax before approval.

A low score does not mean the rule is approved or safe. It means the supplied row did not trigger the built-in breadth, service, governance, duplicate, stale-date, or profile checks. Confirm the final objects and policy order in the enforcement platform before using the result as an approval record.

Worked Examples:

Partner HTTPS ingress:

A row such as Internet,Partner API,203.0.113.64/27,DMZ,api-lb,10.44.20.20/32,tcp,443,allow,https,Partner API ingress,appsec,CHG-2401,2026-08-31,on produces a scoped allow in Review Matrix. The source range is narrower than an unrestricted source, the destination is a host route, and the service is TCP 443. If the review date is outside the warning window, the row should stay below the higher-risk rows unless other evidence is missing.

Any-service admin access:

An allow row from 0.0.0.0/0 to an admin subnet with service any produces a High or Critical result depending on the destination. Rule Audit Queue will point to unrestricted source and any-service evidence, while Rule Scope Heatmap can make the affected source and destination zone pair stand out among ordinary application flows.

Expired break-glass SSH:

A break-glass SSH row from 10.44.99.10/32 to 10.44.40.10/32 on TCP 22 may look narrow, but an expiry date before today creates a High review-date finding. The fix is not to widen or remove the service automatically. The owner should renew, remove, or replace the row with current approval evidence.

Troubleshooting a rejected source row:

If a source address is entered as 10.44.300.5/32, the warning area reports that the address is not a valid IP/CIDR and keeps the value as an object name. That preserves the row for review, but broad-range checks no longer describe the real source network. Correct the address, then compare Risk, Object Group Plan, and the audit findings again.

Responsible Use Note:

Firewall flow rows can contain internal addresses, hostnames, partner ranges, ticket numbers, owner names, and change timing. Parse only the slice needed for the review and handle copied tables, Markdown, JSON, chart images, and shared links as security review material.

Parsing, scoring, charting, and exports run in the browser. The page can preserve entered settings through URL state, so check whether sensitive flow text is present in a link before sharing that link outside the review group.

FAQ:

What columns can I paste?

The fullest shape uses source zone, source name, source CIDR, destination zone, destination name, destination CIDR, protocol, ports, action, application, reason, owner, ticket, expiry date, and logging. Header aliases are accepted, and a shorter legacy flow shape can also parse when source and destination network fields are clear.

Why did a row become a named object?

If an address-like value cannot be parsed as IPv4 or IPv6 CIDR, the row is kept as object text and a warning is shown. That prevents data loss, but you should correct the value before relying on broad-range or private-scope findings.

Why is a deny row flagged for cloud security groups?

The cloud security group profile flags explicit deny rows because common security group models use allow rules and implicit deny. Move deny intent to the control that supports it, or record why the row belongs in the worksheet rather than a security group rule set.

Does a Clear result mean the rule is ready?

No. Clear means no built-in finding fired for the supplied row. You still need to check object membership, final policy order, routing, NAT, inherited rules, platform syntax, and the actual approval process.

Why did the row count stop before my full file?

The parser processes up to 600 non-empty flow rows and reports when extra rows were skipped. Split very large inventories into smaller review slices so summary counts and heatmap cells stay meaningful.

Glossary:

Firewall rule matrix
A table that keeps each requested access path, action, owner, approval reference, and review status in one row.
CIDR
Address notation such as 10.44.20.20/32 or 203.0.113.64/27 that describes a host or network range.
Any service
A row with no protocol or port boundary, meaning the service scope is unrestricted in the supplied flow data.
Rule shadowing
A situation where an earlier broader row may match traffic before a later narrower row on an ordered firewall.
Object group
A reusable source, destination, or service object candidate derived from repeated matrix values.
Implicit deny
A policy model where traffic is blocked unless a matching allow rule grants it.

References: