A security layer that shows real, active hit counts (a firewall dropping packets, an intrusion-prevention system logging a block, a local security tool logging a ban) has proven exactly one thing: that layer is doing its job. It has proven nothing at all about whatever else sits behind or beneath it. A live counter is easy to read as “this is covered,” and that reading is only ever true for the one layer producing the counter.
Why a working control doesn’t imply a safe system
The instinct to check is right; the scope of what gets checked is usually too narrow. Seeing a control fire tells you that control caught something, on that occasion, by its own logic. It says nothing about whether a different problem is being caught by a different layer you haven’t looked at, whether the thing being blocked would also have been stopped somewhere else, or whether something entirely unrelated is passing straight through untouched. Each layer’s evidence is scoped to itself. Treating one layer’s hit count as evidence about the system as a whole is the gap, not the count itself; the count is correct about what it measures.
The only way to know what a full stack actually does with a given case is to test that case end to end, not to read one layer’s log and generalize outward from it.
Two related failure shapes worth checking for separately
Two more specific facts sit underneath the general one, and both are easy to miss because they each look, from a distance, like the same kind of thing as something else already checked.
Independent layers can each be right, and each be blind to the other. Two separate security systems, one at the network level and one running locally on a host, can each correctly decide to block the same activity, for their own separate reasons, with no channel between them and no way for either to know the other has already acted. Confirming that a block is in place at one layer does not confirm, or rule out, whether another layer is also involved. Each has to be checked on its own.
Surviving one kind of restart is not the same property as surviving every kind. A setting built so that a service can restart or upgrade in place without disrupting what depends on it says nothing about whether the same dependents survive a full reboot of the host underneath them. The two situations look identical from the outside, since the service comes back either way, until the day the untested path is the one that actually happens and the setting has no coverage for it at all. If a resilience setting has only ever been exercised by one kind of restart, treat its behavior under any other kind as unknown until it’s tested, not as already proven.
This came out of a night with three independent, mutually blind blocking layers behind one failed connection test, and a reboot that traded a lockout for a much larger recovery problem, told as it happened in Three layers behind one timeout.