A branch IPS has raised no alerts in a week and there are no local hands -- how do you prove it is not passing an intruder unjudged?

## Three states, one symptom An empty alert feed from a branch is consistent with: 1. **A healthy engine and a quiet week.** Small branches are often genuinely uninteresting, so this is common and normal. 2. **A running engine that is not judging what you think.** A rule set that failed to load, an interface pair that came back in the wrong order, a policy applied to the wrong zone. 3. **A latched or engaged bypass.** The relay is closed, packets cross the box untouched, the link is up and the branch works perfectly. The third is the one that survives longest, because every other failure mode annoys somebody. A crashed box with link-state propagation takes the branch offline and a human phones within minutes. A bypassed box produces no complaints at all -- its only symptoms are the silence you were already treating as good news and a collapse in inspected volume that nobody is watching. ## Why alert volume is the wrong health signal Using alerts per day as the sensor's heartbeat conflates two independent things: whether the control is working and whether anyone is attacking the branch. At a small site the honest baseline is near zero, so any threshold sensitive enough to catch a dead engine fires constantly on healthy quiet ones, and any threshold quiet enough to live with will never catch it. Health has to be measured on something the box does regardless of adversary behaviour. ## Three checks that give a positive answer **State.** Ask the appliance directly for its bypass status, its engine status and its rule set version and load time, and alert on the state rather than on its silence. This is the cheapest check and the first to build, with the caveat that a box sick enough to be bypassed may also be too sick to answer -- so absence of a reply is itself a signal, not a gap in the data. **Volume comparison.** Compare what the box says it inspected with what the link actually carried, taken from a device that is not the box: interface counters on the router, or flow records for that WAN interface. A bypassed engine reports approximately nothing while the branch moves its usual gigabytes, and that divergence is unambiguous and easy to alert on. It also catches the subtler case where the box is inspecting one direction, or one VLAN, rather than the whole link. **Synthetic proof.** Schedule a benign transaction from inside the branch that a specific known rule must fire on -- traffic that is harmless in itself but unmistakable to the rule set. If the expected alert appears, telemetry arrived, the engine ran, the rule matched and the pipeline delivered, all in one signal. If it does not, you have a positive failure rather than more silence. Two disciplines matter here: the test must be distinguishable from real activity so it never contaminates an investigation, and it must never be quietly suppressed for being noisy, which would turn your only proof into a tuned-out rule. ## Deciding what a confirmed bypass costs Once you know a branch has been bypassed for a week, the questions are commercial, not technical. Is it a van tonight, a courier with a spare in the morning, or a ticket for Monday? That depends on what the branch carries, and it is much easier to decide beforehand than in the middle of a Friday night. Whatever the answer, the branch owner is owed a straight account: the interval, that nothing was inspected in it, what upstream records can still reconstruct -- addresses, ports, byte counts, times, and no payload -- and what they cannot. ## The habit that prevents it Every maintenance window ends with a verification step, not with the absence of a complaint. The box is back in path, its inspected volume matches the link, and the synthetic test fired. Three checks, a few minutes, and the difference between a control you have and a control you believe you have.