The life of a rule

A rule moves through draft → in review → approved → active. Approved means somebody else decided the rule may exist. Active means operations confirmed it actually exists on every assigned component — the status switches automatically when the last component reports "implemented", and falls back to "approved" when one no longer does. The distinction makes visible what would otherwise be invisible: approved but never rolled out.

A content change to an approved rule resets it to draft — the old approval belonged to the old rule. Components already implemented switch to "to change" after re-approval, so operations applies the difference.

Nothing is ever deleted. A rule no longer needed takes the status "deleted", stays visible in the overview (struck through) and keeps its history and comments as evidence. What ends is its effect: no export, no path analysis, no drift comparison.

Recertification: campaigns

Extending an expiry date is a decision about a calendar. A campaign asks the actual question, rule by rule: is it still needed, is its scope still right, does its owner still exist? That is what a BSI NET.3.2 review demands — and what a date field cannot answer.

How a campaign runs:

1. A change approver starts it: name, cut-off date and scope — all (every rule in force), zone:Z040 (every rule out of or into the zone) or component:3 (every rule on that component). The list is frozen at start; rules created later belong to the next campaign.
2. Every rule sits on the list with its owner. The "Only my rules" filter shows each person their share. Owners matching no active user are flagged — nobody will work on those rules otherwise, and often this is the first sign an owner has left the organisation.
3. Per rule, one of three decisions: "Still required" confirms it (optionally with a new expiry — otherwise it expires despite the confirmation). "Needed, but wrong" sends it back into review with a mandatory reason — the middle path, so nobody has to wave through or kill an almost-right rule. "No longer needed" deactivates it and sets its components to "to remove".
4. Every decision is recorded by name and cannot be overwritten — whoever tries is told who decided first. The rule itself then shows who last deliberately confirmed it, and when.
5. At the cut-off, the report (CSV) shows who decided what and what is outstanding. Open items stay open when the campaign is closed — an undecided rule is a finding, not a blemish. The report is what an auditor actually asks for.

The "Expired" and "Expiring" sections below are independent of this: that is the daily expiry control, which keeps running as before.

Emergency change

Three in the morning, the application is down, no change approver reachable: the rule gets opened on the firewall — no tool prevents that. What Permitra prevents is that it stays unrecorded. "Emergency change" documents the rule already in place, with a mandatory reason: incident, ticket, who was reachable.

The rule goes into review carrying a clock: without an approval after the fact within the window (default 24 hours) it deactivates itself, and operations is told to remove it. Until then it sits prominently on the dashboard.

The path is deliberately narrow rather than convenient: not a shortcut around approval, and its own audit event — so it stays countable how often this happens. Twice a year is a working process; weekly is a finding.

Ping baseline

When a system stops answering, the first question is not "which port" but: does the network reach it at all? Without an answer the search starts at the firewall — the very place that could have answered it already. A ping baseline answers it: a standing rule letting every address in the source zone ping every address in the destination zone. It turns "the network is broken" into "the path is open, the service is down" — the difference between a change request and a restart.

It is created from "New rule" with the "Ping baseline" option. There are no addresses — the rule covers whole zones, so the two zones are picked rather than derived. Everything else stays as it is for any rule: approval, export, recertification, expiry.

It is permitted under four conditions, and those conditions are the point:

• Between internal zones only. Below the P-A-P structure the zones already trust each other enough to carry an allow relation. Towards the P-A-P layer and outwards, ICMP is reconnaissance — an attacker's first question is the same as the operator's, and out there we do not answer it.
• On a relation the matrix already allows. The baseline rides on a permitted relation, it never creates one. Whether two zones may talk stays a matrix decision with its two approvals.
• Echo only. Not every ICMP type: no redirect, no timestamp, no address mask. The export says junos-ping accordingly and not junos-icmp-all — otherwise the rule would document something other than what the device does.
• One direction. The matrix cell is directional and so is the rule. The answer to an echo request comes back through the session the firewall already tracks; pinging the other way is a second question with its own cell.

The firewalls it is rolled out on follow from the two zones and the topology between them — including clusters that merely sit on the path and hang off neither zone.

In the risk assessment it appears as its own finding ("Ping baseline") at low severity — not as "the rule is too broad". Filing a rule that is broad by exception as an error would say the assessment does not know what was approved; and a criterion firing on every rule of a kind is one people learn to scroll past. It is still named: a standing rule nobody sees is how one outlives its reason.

Zones, networks and the matrix

A rule's source and destination zones are derived, not entered: every network belongs to exactly one security zone (Networks page), and the rule's addresses determine its zones. If an address is rejected ("not assigned to any zone"), the network mapping is missing — maintain it once on the Networks page and it applies to every future rule.

The communication matrix governs, per zone pair, whether rules are admissible at all. If the relation is Block (or unmaintained, with default-deny active), the rule is refused with a message — the matrix is not changed in passing but by request with two approvals by different change approvers.

A zone transition always crosses a firewall (BSI principle): a cross-zone rule whose components are all ACI is refused. ACI contracts are the tool within a zone.

When a network moves to another zone, every affected rule is re-assessed: zones re-derived, matrix re-checked. Rules that become inadmissible go into review as removal proposals — approving one approves its removal.

Path analysis: which firewalls are in between

For a pair of addresses the analysis answers: does the traffic get through, across which firewalls, and which rule permits it there. Several firewalls in a row is the normal case in an enterprise, so the path is derived from the documented links between components (the components page: OSPF, BGP, transfer networks). The address mapping only says which firewall an address sits behind; everything in between follows from the topology. A hop neither address sits behind is marked transit.

Three answers only exist because of that. No route: where the topology connects no way between the two components, the analysis says so — instead of an order that reads like a working path. Redundant routes: two equally short ways are both shown, because a rule that sits on only one of them holds until the failover. And the clusters on a route without an approved rule are named. Where no links are recorded at all the analysis says that too and falls back to the north-south tiering — "not documented" is not the same statement as "not reachable".

Drift comparison and coverage

The comparison checks the documented rules against an uploaded device configuration (Reports page) and answers both directions. First: did my rules arrive? missing = approved but not on the device; stale = on the device but no longer approved; unknown = an SR ID Permitra does not know.

Second, the question Permitra exists for: is every rule on the device backed by an approved security rule? Rules without an SR ID — opened by hand, predating Permitra — appear as unjustified, with name and line number. This produces the coverage figure on the dashboard.

The figure is honest or it is nothing: it never appears without stating how many components it was measured on. Components without a configuration, or in an unreadable format, are named rather than averaged away — "cannot read it" never becomes "all clear". A pending emergency change does not count as stale: it sits on the device on purpose while its window is open.

Risk findings

Rules are checked against visible criteria: any-to-any, any as source, very broad networks, risky services (port list maintainable by admins; ranges like 20-25 are expanded), an any service across zones — and a rule logging nothing into a zone with high protection requirements.

Severity rises with the destination zone's protection level and with an exposed source. Findings block nothing: they stand beside the review so the decision takes them into account. "By which criteria?" on the rule page shows the full yardstick — an absent finding means "not on the list", not "harmless".

Logging, deny and reject

Every rule states what it logs: none, standard (each match) or detailed (including session end — Juniper session-init session-close, Check Point "Detailed Log"). The check against the zone's protection level runs through the risk findings.

There are two refusals: deny (drop) discards silently — the caller runs into a timeout. reject answers with ICMP unreachable or a TCP RST — the caller gets an immediate error. Rule of thumb: silence outward, an answer inward; a drop inside your own network turns a misconfiguration into a thirty-second hang and a ticket. Platforms without reject (e.g. Cisco extended ACLs) render deny — that is the device's limit, not a lost setting.

Exports

Permitra never writes to devices itself. It produces the configuration to apply: Juniper set commands, Check Point mgmt_cli and Management API, EPG-based ACI contracts, host firewalls, Capirca/Aerleon targets, CSV/JSON.

Only rules in force (approved or active) enter an export — even with explicit IDs: ids= narrows *which* rules are meant, not whether their status still counts. Previewing unapproved rules needs only_approved=false and is marked as such in the audit log. Every export writes an audit entry.

Evidence report for audits

An audit asks for a document: every change to zone Z in period T, with requester, approver, justification and date. Under Reports → Evidence report that is what you get — pick the period, optionally narrow it to a zone or an application. "Print / PDF" turns it into the document to hand over; CSV is the sortable version.

The report also states what it can vouch for: the result of the hash-chain verification, and whether the audit log still covers the period. Rule and matrix changes are not subject to retention and are always complete; the audit log may have been shortened by the retention policy. If the period reaches back beyond it, the report says so — a document that hides a gap would be worse than no document.

Retiring an application

When an application is replaced its rules otherwise stay behind — the application is gone, the openings are not. It is one of the most common ways a ruleset rots. Under Rules → Retire application an architect proposes every rule in force for an application ID for removal.

Nothing is removed or deactivated by this. Each rule goes back into review carrying the reason and is decided one at a time; only the approval deactivates it and sets the components to "to remove". A preview shows which rules would be affected before it is triggered — and which would not (a draft, for instance, stands on no device). Four eyes still hold: whoever starts the retirement counts as the submitter and cannot approve those removals.

Roles and the four-eyes principle

Architects create rules and submit them. Change approvers decide: one approval per rule review, two different approvers per zone, network or matrix request; they also start and close the recertification campaigns. Operations maintains the implementation status per component, exports, and uploads device configurations for the drift comparison. Admins are responsible for installation and administration only — deliberately not a superuser: no rule views, no approvals, no recertification.

An account can hold several roles, and its permission is their union — small teams do not have four people for four roles. This leaves the four-eyes principle intact, because the checks key on the acting account, not on a role: whoever requested, created or submitted a rule cannot approve it, not even when the same account also holds the approver role. And the two approvals on a zone, network or matrix request must come from two different accounts. Two hats on one person is still one pair of eyes.

The audit log records every sign-in, administrative action and data access, chained with SHA-256 hashes and delivered to a SIEM if configured. Entries render in the instance's language — retroactively, after a language switch.