Adding a vendor subnet to a firewall object group at 02:00 ends the outage: what else did it open to an intruder in that subnet?
answer
- the unit of access is not the rule
- one line in the record, several in effect
- the reviewed diff is not the enforced diff
- expiry attached to the wrong object
- membership survives the rule
basics
~20 sEvery rule that references that object group. Group membership is not scoped to the rule you were fixing, so a one-line change widens paths the change record never names — and deleting that rule later leaves the group member behind.
solid answer
~50 sObject groups exist so a rulebase stays short: one named group of addresses, referenced by many rules. That is exactly why editing one at 02:00 is dangerous. The change record reads as a single line — a subnet added to the vendor-support group — but every permit referencing that group now accepts the new subnet as a source or a destination, including permits written years earlier for a different purpose. An intruder who lands in that subnet inherits all of them, not just the imaging path you were restoring. There are two prices. First, the diff a reviewer approves is not the diff the firewall enforces, so a review has to expand groups before it means anything. Second, an expiry set on the rule does not undo the widening, because the widening lives in the group. Time-bound the membership, or the cleanup misses it.
go deeper
Know what an object group is and that rules reference it by name, so changing the group changes the behaviour of every rule that uses it, not just the one in front of you.
Explain the propagation precisely: which rules gain a source or destination, why the change text hides it, and why an expiry on the rule leaves the group member behind.
Show how you make the effective scope visible at change time, and how you would find historic group edits that nobody tracked as access grants.
Frame it as a change-governance question: which groups are trust boundaries deserving a heavier gate, and what you are willing to slow down to get that visibility during incidents.
## What an object group is, and why it is the fast path at 02:00 A firewall object group (address group, network group, service group) is a named collection referenced by rules instead of repeating literal addresses. It exists for a good reason: without grouping, a rulebase of any size becomes thousands of near-identical lines, and every routine change means touching many of them. Groups compress the rulebase and make routine change cheap. That compression is also why, during an incident, adding a member to an existing group feels safer than writing a new rule. It is one small edit to a structure that already exists, it needs no new approval line, and it usually works on the first try. The engineer's mental model is "I widened the rule I was working on". The firewall's model is different. ## What the firewall actually does Membership is a property of the group, not of the rule you had open. Consider a boundary between a clinical imaging VLAN and a vendor-support zone, where one group is referenced by several permits accumulated over years: | Rule (oldest first) | Source | Destination | Service | | --- | --- | --- | --- | | R14 | VENDOR-SUPPORT group | imaging archive | archive protocol | | R22 | VENDOR-SUPPORT group | imaging archive | remote administration | | R47 | management hosts | VENDOR-SUPPORT group | any | | R51 | VENDOR-SUPPORT group | modality VLAN | any | Add one subnet to VENDOR-SUPPORT and you have simultaneously granted that subnet remote administration of the archive (R22) and any-service reach into the modality VLAN (R51), and you have made it a legitimate destination for management hosts (R47). None of that appears in the change text, which says only that a subnet was added to a group. ## What the adversary inherits An intruder does not need to know the group exists. They need a foothold in the subnet you added — a vendor's support laptop, a shared jump host, a poorly held remote-access account in that range. From there the boundary permits them along every path that references the group, and the traffic matches approved rules, so it is not anomalous by any policy the firewall knows. This is the difference between a control that was bypassed and a control that was widened: the second leaves no trace of being defeated. ## The two prices the defender pays **The review becomes untrustworthy.** The approver at 02:00 reads one line and approves one line. Unless the change process expands group references — showing every rule whose effective scope changed — the reviewed diff is not the enforced diff. Making that expansion routine costs tooling and time, and it slows exactly the changes people make when they are in a hurry, which is where the resistance comes from. **The obvious cleanup misses it.** The instinct is to attach an expiry to the rule. But you did not create a rule; you changed a group. If the emergency rule is deleted or expires, the group member survives it, still widening every other reference. Conversely, removing the member can break flows that predate your incident entirely. So a time-bound permit that was implemented as a group edit has to be tracked as a **time-bound membership**: the register records the group, the member, the expiry and the person, not just "rule added". ## What good practice looks like - During an incident, prefer a **new, narrow, explicitly time-bound rule** over editing a shared group, even though it makes the rulebase one line longer. A dedicated rule can be deleted with confidence; a group member cannot. - If the group edit is unavoidable, record the membership itself in the temporary-permit register, with the expiry and the named person, and note the incident reference. - Make the change process show effective scope, not textual diff. "This edit changes four rules" is the sentence that stops the 02:00 mistake. - Distinguish the groups that are *containers of convenience* from the ones that are *trust boundaries*. Adding a member to "internal servers" is not the same act as adding one to a group that appears on cross-zone permits, and only the second deserves a heavier gate. ## The wrong answer this question is aimed at A competent senior engineer will say "I widened one rule for one night and set it to expire." Both halves can be false at once: the edit widened several rules, and the expiry was attached to the wrong object. The correcting fact is that in a grouped rulebase, the unit of access is the group membership, and that is what has to carry the expiry.
- Why write a new narrow rule during an incident instead of editing an existing group?Because a dedicated rule is reversible with confidence. You can expire or delete it knowing exactly what it permitted, and nothing else in the rulebase changes. A group member is entangled with every rule that references the group, so both creating it and removing it have effects you did not intend and cannot easily enumerate.
- What should a change record show so this mistake is visible at 02:00?Effective scope, not text. The record should expand group references and state which rules changed behaviour and how — "this adds source 10.x/24 to four permits, including any-service to the modality VLAN". A reviewer who sees that sentence asks a different question than one who sees a one-line group edit.
- How do you record a time-bound permit that was implemented as a group edit?Track the membership as the object: the group name, the member, the expiry timestamp, the named person who must renew, and the incident reference. The removal action is "remove this member from this group", not "delete a rule". Otherwise the cleanup runs, reports success, and leaves the widening in place.
saying these in an interview costs you the question
- Says only the rule being edited is affected
- Assumes the change record's one line describes the effect
- Sets the expiry on the rule when the widening is in the group
- Treats all object groups as equally low risk to edit
- Believes matching an approved rule means the traffic is legitimate