On-call widened a host's egress firewall rule at 03:00 to end an incident and the baseline now fails: what did that cost the control?

## The cost is not the host The instinct is to treat this as a host problem: the egress rule is too wide, narrow it, close the finding. That part is real but cheap. The expensive damage is to what the control lets you say. A preventive or detective control is only interesting as a statement about a **period**: this egress restriction was in force on this host for the quarter. Every measurement is a point sample, and a re-failure converts the statement from *held throughout* to *held at the last passing sample, does not hold now, unknown in between*. That interval is the gap, and its length is not a property of the incident — it is a property of how far apart the samples are. The host is a one-line fix; the period cannot be repaired retroactively by any amount of remediation. ## Bounding the gap honestly The defensible statement has two bounds and you should be explicit about both: - The **outer bound** is what the measurements alone support: non-compliant at some point within the interval between the last pass and this failure. - The **inner bound** is what independent evidence supports: if the incident timeline puts the firewall change at 03:12 on a specific night, the gap starts then, not at the previous measurement. A senior answer reaches for the second bound and names where the evidence would come from — the incident record, the modification time on the saved ruleset, the shell history on the host, the converging agent's log, the change ticket if one exists. If none of those exist, say so plainly rather than quietly asserting the narrower window. Reporting *at most eleven days, at least since the incident at 03:12* is a stronger position than either an unbounded shrug or a confident number you cannot support. ## The evidence can delete itself Here is the detail that separates people who have operated hosts from people who have not. Firewall state is layered: the ruleset live in the kernel and a saved ruleset restored at boot. If the on-call engineer widened only the running ruleset — which is exactly what happens when you are trying to unblock traffic in seconds — the change is in force but never persisted. The next reboot restores the compliant saved ruleset, the machine passes the following measurement, and the only trace of the gap is gone. The finding closes itself and the period still contains the hole. Audit configuration behaves the same way: rules loaded into the kernel at runtime disappear on reboot, and rules written to disk do nothing until they are loaded. So *it passes now* is not evidence the gap did not happen, and a control that only ever compares against current state cannot see its own history. This is the argument for keeping the observed values from each measurement, not just the verdicts. ## Do not blame the engineer The organisational read matters as much as the technical one. The engineer widened the rule because the alternative was a longer outage, and any process that makes that the wrong call has mispriced the risk. Decay of this kind is a consequence of legitimate work. The defect is not that a rule was widened under pressure — it is that the system had no cheap path for the change to be *recorded* as it happened, so a correct operational decision silently became a compliance finding discovered days later by a machine. That reframing changes what you ask for afterwards. Not *stop touching production*, but: can the change be captured at the moment it is made, can the measurement interval be short enough that the outer bound is not embarrassing, and is this control one that should live somewhere an incident cannot reach it at all. ## The second-order effect on the claim One more consequence is worth stating because interviewers listen for it: a re-failure resets any continuity clock. If the control's value came from *continuously in force since March*, that phrase is no longer available and the earliest date you can restart it from is the first measurement that passes after the gap closes. That is why the same finding lands very differently on a host nobody claims anything about and on a host inside a scope where the claim is the product. ## What a strong answer covers Host fixable, period not; the outer and inner bounds and where independent timestamps come from; the running-versus-saved split that can erase the evidence; and the refusal to treat a correct incident decision as negligence.